When DevEx Problems Scale Beyond Engineering

At DeepL, I see it every day. But first — what even is DevEx?

But something shifted. The chaos we spent years untangling in engineering: fragmented tooling, undocumented everything, ownership living exclusively in one person's head, is spreading. Marketers, analysts, ops teams: they're all builders now. And most of them have no idea what they just shipped.

Here's what that looks like in practice, and what to do about it.

The DevEx Blind Spot: Non-Engineers are now Builders

Give someone a no-code tool and they'll automate a workflow. Give them an LLM, and they'll automate twelve, document none of them, and go on holiday. The tools abstract away complexity. Great for velocity, terrible for everything that happens next.

• Marketing sends promotions for features that no longer exist. Support gets flooded with anger.
• An analyst's report pulls from a deprecated API for months. Leadership decides on bad data and heads in the wrong direction.
• Two ops teams build the same monitoring script. Double alerts, half the signal. Alert fatigue kicks in.
• Someone ships a beautiful dashboard built entirely on vibes. Three decisions later, someone notices. By then, it's too late to blame the spreadsheet.

We’ve replaced engineer frustration with business risk. And the people least equipped to debug it — the builders — are the ones that are now challenged with those problems.

Fragmentation: The Silent Killer of DevEx at Scale

Vibe-coded tools, scripts, and automations are proliferating without central oversight. What starts as a quick fix or a clever workaround compounds into a labyrinth of undocumented, redundant, and orphaned systems. At scale, this fragmentation doesn’t just create inefficiency, it erodes trust in the entire system.

The antidote is a centralized catalogue — a developer portal that acts as a single source of truth for everything floating around, not just services. This isn’t just about visibility; it’s about governance. Every agentic workflow, script, dashboard, data pipeline, or AI model should live in this catalogue, with clear metadata: who owns it, its lifecycle stage, a plain-language description, its dependencies, and links to documentation. If it’s not in the catalogue, it doesn’t exist.

This approach doesn’t just prevent redundancy, it enables trust. When a dashboard or automation breaks, teams can trace its dependencies, find the owner, and access the docs to debug it. When a new project spins up, builders can look for the catalogue to see if a solution already exists. And when someone leaves, their knowledge doesn’t vanish, it’s preserved in the system.

At DeepL, we’re already using Backstage to organize services and infrastructure, and we’re actively working to extend it to AI-related tools and workflows. Even as a work in progress, the impact is clear: fewer redundant systems, faster debugging, and better knowledge sharing. We already expose this information to AI agents via MCP (Model Context Protocol), and I can only recommend doing this and promoting the hell out of it — because it can solve so many context issues. This includes Tech Radar for technical decisions, documentation, ownership, entities, and more, all automatically sourced by agents based on the entirety of the inventory.

The Inventory Gap: You Can’t Govern What You Can’t See

A catalogue is only as good as what’s in it. And right now, most organizations have a massive inventory gap, a chasm between what exists and what’s documented. This gap isn’t just a missing list of services; it’s the absence of a single, trustworthy source of truth for all the vibe-coded tools, scripts, dashboards, and agentic workflows floating around.

The problem starts with visibility. Engineering might have a handle on core services, but what about the marketing team’s AI-generated content pipelines? The analyst’s ad-hoc data transformations? The ops team’s custom monitoring scripts? These live in the shadows, unknown to engineering and ungoverned by DevEx principles. Without a comprehensive inventory, you can’t enforce standards, debug failures, or prevent redundancy. You’re flying blind.

But the gap runs deeper than just what exists. Even registered items are usually half-documented at best: no owner, no lifecycle status, no Runbook. Just a name and a prayer.

You can tackle this by expanding your developer portal catalogue to include everything, not just services, but scripts, workflows, and agentic tools. Especially making sure this inventory is machine-readable, so AI agents can consume it directly via MCP.

This isn't just about humans finding what they need to do their work. It's about agents having the context they need to act safely and autonomously. An undocumented tool is an unsupervised tool.

Knowledge as a Single Point of Failure

Even with a catalogue and developer portal, knowledge itself is fragile. It lives in too many places: the heads of a few key people, undocumented Slack threads, or custom AI memories that no one else can access. And when that knowledge disappears because someone leaves, a thread gets buried, or an AI’s context drifts — the system breaks with it.

I have seen this firsthand. A script fails, and the only person who understands it is on holiday. An AI agent generates a report based on outdated assumptions, and no one notices until a decision is made. A dashboard looks perfect, but the data pipeline feeding it was never documented, and now the pipeline’s owner has moved teams or abandoned the project. These aren’t just inefficiencies; they’re ticking time bombs.

The problem isn’t just missing knowledge, it’s siloed knowledge. Human knowledge is tribal: passed down informally, lost when people move on. AI knowledge is even worse: trapped in custom RAG setups, vector databases, or prompt histories that no one else can query. And when these silos collide, when an AI’s memory contradicts a human’s understanding, or when a script’s logic is only half-documented — the result is chaos.

The fix: treat docs like tests, required, versioned, tied to the entity they describe. Expose everything via MCP, so agents work from the same source of truth as humans. And when a system changes, the knowledge updates automatically. No more 'ask Dave, he built this' because Dave left in March.

The Role of Engineers in the Agentic Era

Engineers used to be the gatekeepers of technology. The ones who kept unstable ideas out of production and judged what was actually robust enough to survive contact with reality. Back then, the worst we had to deal with was someone asking us to 'build a search engine, like Google, but better.' Now they just ask the AI directly, and the AI says yes.

In the agentic era, that role has evolved. We're not just writing code. We're defining what good looks like, and quietly making sure nobody burns down production on a Tuesday.

The rise of agentic tools means everyone is a builder — but not everyone is an engineer. Our job isn't to be the people who just say no. It's to build the system that makes yes safe.

Conclusion

The organizations that thrive in the agentic era won't be the fastest. They'll be the ones who made the invisible visible before it blew up in their face. Engineers, that's on us — not as gatekeepers, but as the people who build the floor everyone else stands on. So get the catalogue going, expose it via MCP, and for the love of all things deployable, document your stuff.