Dispossessed Developers: Visitors in Our Own Codebase

Foreword: the emergency exit is bricked up Let's start with the ending — it's more honest that way. If I had to quit LLMs tomorrow — for political reasons, a prolonged outage, or simply because the bill became indecent — I would face a massive cleanup phase just to take back ownership of my own code. Today, I estimate that 60% of the code in my projects has become unreadable to a human, and that share grows with every orchestration run. Is quitting LLMs on the table? No. Of course not. That's exactly the problem. It all started innocently. Questions asked the way you'd ask Google, but with answers in full sentences. Then targeted code writing: "write this function," "fix this test." Then full audits of entire modules. By that point I had found the right mental model: LLMs are versatile, non-expert, infinitely multipliable agents. Not brilliant, not useless — just available in unlimited supply. Which is perfect for every task where I'm the novice: organizing, planning, producing the team-lead paperwork nobody ever taught me. Meeting notes, roadmaps, prioritization matrices — the non-expert agent does it better than I do, and it never sighs. Let's define the terms first, because the entire paradox of this story lives on this boundary. LLM-assisted development: the machine generates, but every increment is reviewed by the developer before it lands. Vibecoding: nothing is verified — at best, you validate the functionality by running the app locally and on the develop environment, and you call that a review. I tried vibecoding three times. Three times, the output matched no efficient or readable architecture. Every attempt to graft the generated code onto the existing codebase failed. The only thing that worked: radical changes, full rewrites, to finally end up with clean code. This time I drew the right conclusion: stop vibecoding, and do nothing but LLM-assisted development. Every increment reviewed, every change validated. A grown-up resolution. Remember it well — it's not going to survive very long. So the usage intensified. MCP servers to wire agents into the tooling. Skills to encode procedures. Specialized agents, automations, and — I confess as I type it — the --dangerously-skip-permissions flag, whose name is a warning I chose to read as an invitation. The grand finale: full orchestration through Orca and its git worktrees. Multiple agents in parallel, each in its own worktree, merging their work while I do something else entirely. Today my work consists of checking that the orchestrations went well, and answering the LLMs' questions to make the call on infrastructure or business logic — only when the agent isn't sure of itself. When it is sure, I ignore most of its changes. And this is where the paradox closes in. My great post-failure resolution — every increment reviewed, no vibecoding ever again — did not survive the escalation of responsibilities handed to the LLMs. By delegating ever higher up the chain, I ended up in exactly the state I had sworn to avoid: I no longer verify the code. I didn't relapse into vibecoding; I reinvented it with extra steps. I review my agents' code about as carefully as I read the terms of service on an app update. The more I abstracted myself away from the code, the more the code abstracted itself away from me. It has become far more verbose, saturated with comments explaining the obvious. But the most disturbing part lies elsewhere: the best practices changed completely, and nobody decided it. Faced with specifications that were never written down, the LLMs made the calls on their own — conventions, structures, patterns. The result is code that is largely unreadable to a human, and now suitable for… vibecoding only. The loop is closed: LLM-generated code can only be maintained by LLMs. Let me be factual for a second: the amount of finished work is not greater. Functionality and architecture haven't moved any faster. The urgent tickets still haven't been cleared in two months. I multiplied the agents, not the outcomes. And this detail is anything but a detail, because we work in an Agile setup. Our entire team culture is built on outcomes first: delivered value, sharing, product evolution, the collective. That's the founding pact. So what do the indicators say? The KPIs show work moving at a lukewarm pace — and those numbers aren't gathering dust in some ignored dashboard: they are seen and re-read by management, sprint after sprint. The irony is complete: we industrialized code production in the name of velocity, and velocity stayed exactly where it was. We optimized the activity, not the outcome. In Agile terms, that is precisely the definition of failure — a very busy, very well-tooled failure, thoroughly documented by our own metrics. What this story is really about is a certain laziness — mine, ours — about producing clean, concise code aligned with the best practices the team chose. That kind of rigor takes effort, and we delegated it with relief. While LLMs embed themselves ever deeper into the codebase, developers don't even open their IDE anymore. On paper, the code is still ours. In practice, we've become its visitors. To dig deeper — on my side of the argument, and on the other: The Vibe Tax: How Unvalidated AI Code Is Flooding the Market — the hidden cost of code accepted without being understood, right here on dev.to. The Productivity Paradox of AI Coding Assistants — why the feeling of speed doesn't show up in the metrics (my backlog concurs). Debt Behind the AI Boom (arXiv) — a large-scale empirical study of the technical debt introduced by AI-generated code in production repositories. Technical Debt Predates AI — the counter-argument: 300 repositories analyzed to show we were already writing unreadable code before LLMs. A fair point. Annoying, but fair.