The Problem Isn't the Agent. It's the Approach.

There is a narrative gathering momentum right now, and it is not entirely wrong. The argument goes something like this. Agentic coding tools are producing vast quantities of poorly structured, insecure, hard-to-maintain code. We are building a mountain of technical debt that will cost far more to remediate than we saved in delivery speed. The bill is coming.

The evidence people cite is real. A 2025 Veracode report found that roughly 45% of AI-generated code samples contain security flaws. A December 2025 analysis by CodeRabbit of 470 open-source GitHub pull requests found that AI co-authored code contained 1.7 times more major issues than human-written code, with security vulnerabilities occurring at 2.74 times the rate. GitClear, which analysed over 200 million lines of code, was blunt. “I don’t think I’ve ever seen so much technical debt created in so little time.” One analyst has put a figure on what is coming. $1.5 trillion in accumulated technical debt by 2027, from poorly structured AI-generated code.

This is the case against agentic coding. And if you are looking at how most people are using these tools, it is a fair one.

The problem is that the critics are conflating two very different things. They are looking at vibe coding, and calling it agentic engineering. Those are not the same thing.

Vibe Coding Is the Symptom, Not the Problem

Andrej Karpathy, who coined the term, described vibe coding as “fully giving in to the vibes, embracing the exponentials, and forgetting that the code even exists.” It is an evocative description of what a lot of people are actually doing. Type a prompt, accept whatever comes back, ship it. Repeat. No architecture review. No planning. No understanding of what has been built.

A December 2025 study from UC San Diego and Cornell, which observed experienced developers over three to twenty-five years working with coding agents, reached a rather different conclusion about how professionals approach this. The paper’s title says it all. “Professional Software Developers Don’t Vibe, They Control.” The research found that experienced practitioners retain agency in software design, insist on fundamental quality attributes, and deploy explicit control strategies that leverage their expertise to manage agent behaviour.

Stack Overflow’s 2025 developer survey confirms the picture. 72% of developers say vibe coding is not part of their professional work.

The vibe coding horror stories are real. In late 2025, a startup called Enrichlead used Cursor to write every line of their lead generation platform. The interface looked polished. The AI put all security logic on the client side. Within 72 hours, users discovered they could change a single value in the browser console and access all paid features without paying. The founder could not audit 15,000 lines of code they had never really understood. The project shut down.

That is not an indictment of agentic coding. It is an indictment of deploying something you do not understand.

The Approach That Actually Works

Since November last year, we have built and deployed three large production systems at inmydata. What would previously have represented at least two years of development work. I have not read every line of code. But I have a thorough understanding of every architectural decision, every integration, every deployment configuration. I am confident that these codebases are better planned, better documented, more secure, and ultimately cheaper to run and maintain than anything we built before. Here is how.

Start with the plan, not the code

The first thing I do with any significant project is open a session with the best available model, which right now means Claude Opus, and I work through the architecture before a single line of code is written. Every architectural choice, surfaced and discussed. I tell the model explicitly not to ask me several questions at once. We go one decision at a time. When a decision is made, we move to the next. This is not bureaucratic overhead. It is the equivalent of sitting down with a senior architect before you start building something complex. You would not skip that meeting just because the tools got faster.

The output is a phased implementation plan. Each phase has a clear scope. Critically, the plan includes both a local testing setup and a complete deployment architecture. This forces you and the model to think through both sides before you start. Infrastructure decisions that trip people up mid-build, authentication patterns, environment configuration, secrets management, deployment pipelines. All of it. Addressed upfront, documented in the plan.

Iterate on the plan until it is ready

Before touching the implementation, I start a clean session in Claude Code, ask it to read and fully understand the plan, and ask if it is ready to implement. This step is undervalued. A model reading a plan carefully will surface the things you have not thought through in enough detail. It will ask questions you had not anticipated. It forces you to address gaps before they become bugs.

I do this at least five times. The model will never tell you the plan is perfect. But there is a threshold where the reservations it raises start to become genuinely minor. When the “yes, but…” starts to feel like housekeeping rather than architecture, you are ready to build.

Build in phases, with a review gate between each

Once you start, you implement one phase. When it is complete, you ask the model to re-assess everything that was built in that phase before moving on. Are there issues to address? Anything that changes the approach for phase two? Only when that review is done do you proceed.

This matters more than it might sound. In traditional development, the pressure to ship means review gates get compressed or skipped. Here, the review is low-cost because the model does it. There is no excuse not to.

Documentation is part of the build, not an afterthought

Throughout every phase, I instruct the model to document what it has implemented to the planning document. By the time the build is complete, you have comprehensive, up-to-date documentation that reflects what was actually built, not what was planned before reality intervened. When the build is finished, I ask the model to do a full documentation pass across the whole project.

This has a direct impact on maintenance. When you need to revisit something months later, or when a bug surfaces that needs investigation, you are not starting from scratch. You have context.

Test properly, including for security

There will be bugs. But with good documentation and the models alongside you, they resolve quickly. The one exception is CSS layout issues. Models cannot see the page, so visual problems are genuinely quicker to fix yourself, as you would have in the past.

For security, we do not rely on a hope and a prayer. As I wrote recently, we built our own penetration testing suite in a Friday afternoon using OWASP ZAP and Nuclei, orchestrated through a Python script that handles the full workflow. Authenticate via AWS Cognito. Spider the application. Run active scans. Execute detection templates targeting patterns common in agentic applications. Merge findings, deduplicate, rank by severity, produce a unified HTML report with remediation guidance. We built it in two hours. We run it continuously across everything we deploy.

We also run Claude Code Security reviews across the codebase, and we commission professional penetration tests periodically, exactly as we would have before. The automated tooling does not replace professional judgement. It means we arrive at the professional test with far fewer easy wins for the pen tester to find.

What the Research Actually Says About Disciplined Use

The evidence for disciplined agentic engineering is compelling, and it is distinct from the vibe coding horror stories.

Rakuten engineers gave Claude Code a genuinely hard task, implementing an activation vector extraction method inside a 12.5-million-line codebase. Claude Code completed it in seven hours of autonomous work, achieving 99.9% numerical accuracy. TELUS used agentic workflows to create over 13,000 custom AI solutions while shipping engineering code 30% faster. McKinsey research across AI-centric organisations found 20 to 40% reductions in operating costs, driven by automation and faster cycle times.

Anthropic’s own 2026 Agentic Coding Trends Report describes a shift that matches exactly what we have experienced. Engineers are moving from writing code to orchestrating agents that write code, focusing their expertise on architecture, system design, and validation. The CIO article from earlier this year described the emerging operating model in terms that resonate. Delegate, review, and own. AI agents handle first-pass execution, scaffolding, implementation, testing, and documentation. Engineers review for correctness, risk, and alignment. Ownership of architecture, trade-offs, and outcomes stays human.

That is not a description of forgetting the code exists. It is a description of engineering discipline applied to a new set of tools.

The Real Question

The critics pointing at vibe coding debt are identifying a genuine problem. Unreviewed, undocumented, architecturally naive code being shipped at scale will create a reckoning. The GitClear data, the Veracode findings, the wave of security incidents in hastily built vibe-coded startups, all of that is real.

But the answer is not to slow down. The answer is to be disciplined about how you use the tools.

The speed advantage of agentic engineering is not primarily about skipping steps. It is about compressing the cost of doing them properly. Architecture review happens faster because you have an intelligent collaborator who never gets tired. Documentation happens as you build because it costs almost nothing. Security review happens continuously because you can automate it. The things that used to get cut because there was not enough time or budget are now affordable.

We spent roughly four months building what previously would have taken two years. We have not cut corners. We have eliminated the friction that used to make doing things properly so expensive.

The tools work. The discipline is the variable.