Stop Complaining About Vibe Coding. Start Engineering the Future of Software.

I've had conversations with experienced software engineers who dismiss AI-powered development tools because they associate them with "vibe coding." I understand their skepticism. I've spent years working with engineering teams and dealing with the consequences of technology decisions. Poor architecture, technical debt, security vulnerabilities, and software nobody understands are real problems.

But here's what I find frustrating. Some of the engineers best qualified to make AI-driven development safe and effective are dismissing the tools because they don't like how other people are using them. That's not a technology problem. It's a missed opportunity for the profession.

Vibe Coding Isn't Agentic Engineering

Vibe coding, as Andrej Karpathy originally described it, involves letting AI generate software without paying much attention to the underlying code. You describe what you want, keep prompting, and stop when it seems to work. There's a place for that. Experimentation, prototypes, disposable applications. But building production software that people depend on is different.

Disciplined agentic development uses AI agents throughout the software development lifecycle, from requirements and architecture to implementation, testing, and deployment. The difference isn't who writes the code.

It's who understands the system, who controls the engineering process, and who is accountable when something breaks. Martin Fowler, Simon Willison, and other respected practitioners have made this distinction. Yet the two approaches continue to be conflated. An engineer using AI to investigate a codebase, evaluate architectural alternatives, develop an implementation plan, write tests, and execute controlled changes isn't abandoning software engineering. They're using new tools to practice it.

The Opportunity Is Faster Development AND Better Engineering

Much of the conversation about AI software development focuses on how quickly AI can generate code. That matters. A lot. The ability to dramatically accelerate implementation, troubleshooting, refactoring, and testing represents an enormous productivity opportunity.

But focusing exclusively on coding speed misses half the story. In my own work, I've increasingly used AI agents to investigate complex existing software systems before making changes. Rather than immediately asking an agent to implement a feature, I can direct it to examine the architecture, trace dependencies, identify existing patterns, and propose a technical approach. I then challenge the design, refine the implementation plan, and oversee execution and validation.

Work that previously required considerable time investigating a codebase, developing technical specifications, and coordinating implementation can now be accelerated through agentic workflows. And that creates an interesting opportunity. How often do development teams skip documentation because they're behind schedule? Postpone refactoring? Accept limited test coverage? Avoid exploring architectural alternatives because implementation has already started? These problems existed long before AI.

We shouldn't compare agentic development with an imaginary world where traditional software engineering always follows best practices. We should compare it with the development processes organizations actually use. Agentic tools can help us produce software faster while making it more practical to apply rigorous engineering practices throughout the development lifecycle.

That doesn't happen automatically. AI-generated plans can be wrong. AI-generated tests can validate flawed assumptions. Faster code generation can just as easily accelerate technical debt. Google's 2025 DORA research reinforces an important point: AI amplifies the strengths and weaknesses of existing organizations. Increased throughput doesn't automatically translate into more stable software. The goal shouldn't be choosing between faster development and better engineering. It should be using agentic AI to achieve both.

We're Generating Code Faster Than We Can Understand It

Here's where I share the skeptics' concerns. AI agents can generate software faster than engineers can reasonably examine every line. And that creates a dangerous temptation: accepting software because it works, passes tests, or comes with a convincing AI-generated explanation. But working software isn't necessarily well-engineered software. What happens when an agent introduces an architectural decision nobody recognizes? What happens when generated tests overlook the same flawed assumptions as the generated code? What happens when a production system fails and the engineers responsible for it can't explain how it works?

Thoughtworks has described this growing gap between code production and developer understanding as codebase cognitive debt. A small Anthropic study also found that engineers using AI assistance performed worse on subsequent comprehension tests, particularly when they delegated more of the work. The study focused primarily on junior engineers and doesn't establish long-term outcomes for autonomous agents, but the warning is worth taking seriously. If AI reduces the amount of code engineers write, it cannot also be allowed to eliminate their understanding of the systems they maintain. That's the challenge engineering leaders need to solve.

There's an Even Bigger Problem: Who Trains the Next Generation?

Most discussions about AI coding focus on what happens to today's developers. I'm increasingly concerned about what happens to tomorrow's. Traditionally, junior software engineers develop their skills by writing code, debugging problems, reviewing other people's work, and gradually taking responsibility for more complex systems. They make mistakes. They learn why those mistakes matter. They gain the experience that eventually allows them to make architectural decisions and diagnose difficult production failures. But what happens when AI agents perform much of the implementation work that once provided that experience?

We can't simply assume that junior developers will develop deep engineering judgment by supervising systems they never learned to build. And we can't build a sustainable engineering profession in which a shrinking group of senior engineers understands the software while everyone else, including AI agents, produces it. The human in the loop needs a development pipeline of their own. That means deliberately designing agentic workflows that develop human expertise alongside software.

Junior engineers should participate in reviewing AI-generated architecture, explaining implementation decisions, tracing dependencies, evaluating tests, and diagnosing failures. They should be challenged to understand why an agent selected a particular approach, what alternatives existed, and what could go wrong. They should periodically solve problems without delegating the thinking to AI. And their progress should be measured not simply by how much software they deliver, but by how well they understand the systems they're becoming responsible for. This is not nostalgia for manually writing boilerplate.

It's recognizing that engineering judgment has to be developed somewhere. If senior engineers retire or move on without developing their replacements, we may find ourselves with enormous software production capacity and a diminishing number of people capable of exercising independent judgment over it. That's not an AI strategy. It's a succession crisis.

Human Oversight Needs to Be Engineered, Too

The solution isn't requiring someone to manually inspect every line of AI-generated code. That approach may become increasingly impractical as agents generate larger volumes of software. Instead, we need engineering processes that combine automated controls with deliberate human judgment. That includes architecture reviews, test coverage, security scanning, static analysis, dependency checks, CI/CD enforcement, observability, and controlled deployment. Birgitta Böckeler and others at Thoughtworks describe an emerging approach called harness engineering, where agents operate within constraints and feedback systems designed to detect problems. Human oversight should also be proportional to risk.

A documentation update shouldn't need the same scrutiny as a change to authentication, payment processing, or critical infrastructure. And in addition to testing whether the software works, we should be testing whether the engineers responsible for it understand the software. Can they explain the architecture? Identify failure modes? Diagnose problems? Challenge an agent's proposed design? A human approval step is meaningless if the human doesn't understand what they're approving. The point isn't to replace engineers with automated controls. It's to give engineers better tools for exercising meaningful control.

Senior Engineers Should Be Leading This, Not Sitting It Out

Experienced engineers have spent careers learning lessons that AI agents don't reliably understand. They recognize architectural weaknesses, hidden dependencies, operational risks, and technical decisions that may create problems years later. Those skills are becoming more valuable, not less. But the role of the experienced engineer is changing. It's increasingly about directing implementation, establishing standards, designing verification processes, evaluating architectural decisions, and developing the next generation of engineering talent. That requires learning how to use agentic tools effectively.

It also requires engineering leaders to create workflows where AI accelerates delivery without bypassing the learning experiences junior engineers need. I'm not suggesting every skeptical engineer is wrong. Some of the concerns are backed by research. And current tools are far from perfect. But dismissing agentic development because someone else used AI to build a poorly engineered application is not a serious strategy for the future. The people who understand software engineering best should be the ones defining what good agentic engineering looks like.

The Profession Has a Choice

We can continue arguing about whether AI-generated code qualifies as real software engineering. Or we can focus on the harder questions. How do we use agents to deliver better software faster? How do we preserve human understanding as development accelerates? How do we train junior developers when AI increasingly handles implementation? And how do we make sure engineering accountability doesn't become a ceremonial approval step? These questions aren't reasons to reject agentic development. They're reasons experienced engineers need to engage with it.

The biggest threat isn't simply that AI will write bad code. It's that we'll build a world where AI writes most of the code and too few humans understand it well enough to take responsibility. The opportunity is faster development, better engineering, and stronger engineers. Achieving all three requires something more than better AI models. It requires engineering leaders willing to rethink how software is built, how quality is enforced, and how expertise is developed.

Stop complaining about vibe coding. Start engineering what comes next.