Vibe Coding vs. Agentic Engineering: Writing Code Is No Longer the Hardest Part

The bottleneck moved

I’ve spent more than 20 years building software and running the systems underneath it: networks, security, infrastructure, DevOps, product and operations. Lately I’ve been spending a lot of time with AI coding agents, mostly Claude Code and Codex. I still enjoy writing code. What makes AI interesting to me is how much of the software lifecycle I can now explore and automate on my own.

I’ve also noticed patterns. The agent produces working software quickly. Then I see the same shapes again and again: more abstraction than the problem needs, a second version of something that already exists, and rework when the first answer solved a slightly different problem than the one I had.

AI has made writing code cheaper and faster. It hasn’t made bad engineering decisions cheaper. It implements them faster.

The bigger change is where the time goes. A team with AI agents can now produce code faster than it can review, test and validate it. The bottleneck has moved from writing code to deciding what to build and verifying that it works. That shift is the main difference between vibe coding and agentic engineering.

What vibe coding is good at

Andrej Karpathy coined “vibe coding” for a way of working where you describe what you want, accept what the model writes, and mostly forget the code exists. The workflow is a loop:

Prompt → generate code → run it → find problems → prompt again.

It’s exciting, and it opened software up to people who couldn’t build it before. A product manager can try an idea before asking for engineering time. An operations lead can build the internal tool they’ve wanted for a year. It’s also a cheap way to find out in an afternoon whether an idea is worth more time.

It works well for prototypes, demos, throwaway scripts, personal tools and experiments where being wrong costs very little.

The risk starts when the loop is all there is. If nobody understands the implementation, every new prompt is a guess about code you haven’t read. Fixes stack on fixes. The app works until it meets real data, a second user role, or an attacker. And a prototype that “just works” has a way of becoming production without anyone deciding it should.

What makes it agentic engineering

About a year after coining vibe coding, Karpathy suggested “agentic engineering” for the more disciplined version: you orchestrate agents that write most of the code, and you provide the oversight. The term is still settling, and people use it loosely.

When I say agentic engineering, I mean AI agents working inside a normal engineering lifecycle: requirements, planning, architecture, implementation, testing, review, user acceptance, deployment and monitoring. Agents can do real work at every one of those stages. Engineers stay accountable for the decisions.

Using several agents doesn’t mean you’re practicing agentic engineering. If five agents are prompting, generating and rewriting each other’s code without written requirements, an agreed design or a definition of done, you’re vibe coding with five agents instead of one.

One feature, built two ways

Here’s a hypothetical feature from a multi-company SaaS product. A user can belong to several companies. Each company can have more than one business identifier, such as a tax ID and a government registration number. Each user has a role per company: owner, admin, member or read-only.

Vibe coding it. I prompt for “multi-company accounts with roles.” In minutes I have tables, a company switcher and role checks. It demos well. Then the questions arrive one at a time, each as a new prompt. Can one identifier belong to two companies? What happens to open sessions when a user is removed from a company? Does the API check the role, or only the UI? Each answer patches the last one. A week later the permission logic lives in four places, and nobody can say with confidence that a member of company A can’t read company B’s data.

Engineering it with agents. Before any code, I write the rules down. Who can see what, and which identifiers must be unique. What “switching companies” means for cached data and open tabs. I ask an agent to challenge that spec and list the cases I missed. We agree on one place where authorization is enforced, on the server, for every request. Then agents implement small pieces against that design, write tests for the risky paths (cross-company access, role changes, removed users), and run a first review. I review the authorization layer myself. Business users try it on a preview environment before it merges.

The second path takes longer to get to the first demo. It’s usually much faster to get to something I’d put in front of customers. I looked at the user’s side of this same kind of workflow in code review doesn’t start with a pull request.

The tradeoffs side by side

Vibe coding wins on speed to a first version and on cost when the code is disposable. Agentic engineering wins once the software has to be secure, maintained by a team, and changed for years. The mistake is using one where the other belongs.

Code review still matters

When AI writes the code, it’s tempting to let AI review it and stop there. AI code review is useful, and I use it for the first pass on style, common bugs, missing error handling and known security patterns. But code review was never mainly about syntax. It should answer questions like these:

• Does the implementation satisfy the business requirement?
• Is the architecture appropriate for the problem?
• Is it adding complexity the problem doesn’t need?
• Are security boundaries enforced on every path?
• Are we duplicating something that already exists?
• Can the team maintain it?
• Are we building something nobody actually needs?

AI can help ask every one of those. It can’t own the answers, because it doesn’t carry the business context or the accountability. When the same model wrote the code and reviewed it, both can share the same misunderstanding of the requirement. I wrote about what that looks like in a diff in I can recognize AI-generated code.

Review, testing and UAT in parallel

If implementation got faster, the checks after it have to keep up. Running them one after another (review, then QA, then UAT) turns a two-hour change into a two-week wait. With pull-request preview environments, they can run at the same time.

Every pull request gets its own deployed preview. Automated unit, integration and end-to-end tests run in CI. An AI first pass on code and security runs alongside human review. An agent can walk through the main flows as a simulated user and flag confusing steps, unclear errors or dead ends. Business users can try the real thing on the preview while review is still going.

AI-simulated usability testing is a cheap early filter. It doesn’t replace a business user accepting the feature, because the agent doesn’t know how the work is actually done. And parallel checks only work if you retest when something changes. If review feedback changes the permission logic, the earlier UAT result no longer counts for that part.

The hidden cost of doing it wrong

Used badly, AI coding gets expensive in ways that don’t show up on a demo:

• Repeated prompts that resend the same context and burn tokens
• Several agents doing overlapping work, or rewriting each other’s implementations
• A simple requirement turned into a framework
• Hundreds of tests that don’t match where the real risk is
• Features generated before anyone checked that customers want them
• AI-generated technical debt piling up faster than a team could ever write it by hand

More AI-generated code doesn’t mean more engineering productivity. Code is a liability someone has to read, secure, test and run. Just because AI can build something in a few minutes doesn’t mean we should build it. I went through the token and rework math in the hidden cost of AI coding, and the bigger version of this problem in the most expensive engineering work is work nobody needed.

Judgment is worth more now

When typing the code is no longer the slow part, the engineer’s job shifts toward everything around it. Developers increasingly need to understand the business problem, define acceptance criteria, evaluate architecture, spot security and operational risks, review AI-generated implementations, design a testing strategy, understand deployment and production, and make build-versus-buy decisions.

That’s why I think experienced generalists have an advantage with AI agents. Someone who has worked across product, development, infrastructure, security and operations knows which questions to ask at each stage, and notices when an agent’s confident answer doesn’t fit. Teams still need deep specialists. I wrote more about that balance in why being a generalist is an advantage in the AI era.

What engineering leaders should change

For engineering leadership in the AI era, the work shifts toward deciding what gets built and making sure it’s verified. A few things I’d change:

• Move review earlier. Review the plan and acceptance criteria before the agents start. A wrong design costs a conversation there and a rewrite later.
• Scale review to risk. Docs and copy can rely on automated checks. Authentication, permissions, billing, data migrations and production infrastructure always get a human approval.
• Treat AI-generated debt like any other debt. Set standards the agents follow, keep pull requests small, and budget time to remove duplication before it spreads.
• Balance speed against operational risk. Feature flags, gradual rollouts and a tested rollback let you ship fast without betting everything on each release.
• Protect how juniors learn. Ask them to explain the code and the tradeoff before merging, and give them decisions to make, not only prompts to write. Judgment comes from making decisions, with a mentor close by.

Then measure outcomes instead of output. Lines of code and prompt counts got even less meaningful once an agent can produce thousands of lines in an hour. I’d watch these at the team level:

• Lead time for changes: from commit to running in production
• Change failure rate: how often a release causes a problem
• Rework rate: deployments that exist to fix a recent one, which DORA added to its delivery metrics
• Escaped defects: bugs found by customers instead of by us
• Production incidents: how many, and how severe
• Cost per successfully delivered feature: people, tokens and infrastructure, divided by features customers actually use

These describe how the system of work is performing. They shouldn’t be used to rank individual developers, because people learn to game whatever they’re ranked on. If lead time drops while rework and escaped defects climb, the team got faster at producing problems.

The goal isn’t to generate more code. The goal is to deliver better software with less unnecessary work. More on how I approach that in how I run engineering.

Short answers