When the phrase "vibe coding" entered the software vocabulary in 2025, it described a surprisingly simple loop.
Describe the outcome. Let a model produce the code. Try it. Keep prompting until the result feels right.
The phrase was playful. The shift was not.
One year later, the model is no longer waiting in a chat window for the next instruction. Claude Code can navigate a repository, edit multiple files, run commands, test its work, and commit a change. The Codex app can take on long-running tasks, work in parallel, and hand a developer a diff to review.
The prompt now starts an execution loop.
That is a much bigger capability than prompt-driven code generation. It also exposes a harder question: what has to be true before anyone should trust the resulting change in production?
Three Modes That Look Similar but Are Not
The term vibe coding has become broad enough to hide three different ways of working.
Prompt-driven generation starts with a request and iterative feedback. The system produces code or a small application. Success often means the demonstrated flow works.
Agentic coding adds a repository, tools, and a longer task horizon. The system can plan, edit, run commands, test, inspect failures, and continue working.
Production engineering adds the controls and evidence needed for a team to own the release. It begins before the prompt and continues after the agent says the task is complete.
These modes can use the same model. What changes is the operating contract around it.
Vibe coding is an interaction style. Agentic coding is a system capability. Production engineering is an organizational responsibility.
Treating them as synonyms makes a successful agent run look like a release decision. It is not one.
The Tool Changed Category
The first generation of AI coding tools helped developers type. The current generation acts.
An agent can install a dependency, change an interface, update its callers, run the suite, inspect a failure, and try again. It can make a sequence of technical decisions and observe the consequences.
That execution loop is why the old distinction between AI-generated code and human-written code is becoming less useful. A single change may contain model output, human edits, generated tests, copied patterns, and a second agent's review.
The practical unit is not authorship. It is the change the team is considering releasing.
This matters because a change can be technically coherent and still be wrong for the product around it. The repository gives an agent a great deal of implementation context. It does not automatically contain every customer expectation, operational dependency, security boundary, or undocumented behavior that must remain stable.
The Bottleneck Moved
When implementation gets cheaper, more ideas become changes.
That is a real productivity gain. Every additional change still needs intent, context, review, security, validation, and ownership. Generating five plausible implementations does not create five times the capacity to understand their consequences.
In a June 2026 survey commissioned by GitLab and conducted by The Harris Poll, 85% of 1,528 developers and technology buyers agreed that AI had shifted the bottleneck from writing code to reviewing and validating it.
A survey records perception rather than delivery telemetry, so it is not proof of a universal effect. It does show that teams adopting these tools feel pressure moving into verification and governance.
The scarce resource is no longer only the ability to produce a candidate change. It is the ability to state what should happen, provide the context the agent cannot infer, and decide which evidence is strong enough to ship.
Working Is a Narrow Claim
A working result is valuable. It may mean the application loaded, the requested flow worked once, or the tests selected by the agent passed.
Production asks wider questions:
- Does the implementation match the real product intent?
- Does it follow architectural and security constraints that were absent from the prompt?
- Does it integrate with private systems correctly?
- What established behavior outside the changed files could be affected?
- What was not tested or inspected?
- Who owns the remaining uncertainty?
Claude Code and Codex reduce the effort required to implement and investigate. They do not collapse these questions into a green test run.
In 2025, the production gap looked like a limitation of generation quality. In 2026, capable agents show that the deeper gap is the delivery system around generation.
A Successful Task Can Still Produce a Bad Release
Consider an illustrative case.
A team asks an agent to replace authentication middleware in one service. The agent updates the interface, migrates the known callers, adds tests, and passes the repository checks. Against the assigned task, the result looks complete.
After release, an internal administration flow fails because it depends on an undocumented error response from the old middleware. The broken behavior sits outside the files and checks the agent used.
The agent completed the assigned task. The delivery system failed to describe the full behavior that had to remain stable.
This is the production boundary. Agent execution is judged against the task. A release must be judged against the product behavior and operational dependencies the change could affect.
Expertise Became More Valuable
The more capable the agent becomes, the more valuable clear judgment becomes.
Anthropic's research on agentic coding found a recurring division of labor: people made most planning decisions about what to do, while Claude made more execution decisions about how to do it. Domain expertise helped people give better direction and recover when the agent misunderstood the task.
The agent can remove a great deal of implementation friction. That increases the leverage of the person who understands the problem, the system, and the consequences.
The valuable developer is not merely the fastest typist. It is the person who can turn an ambiguous request into a precise task, recognize when a plausible implementation violates an important constraint, and ask for evidence that tests the real risk.
Five Responsibilities That Become More Important
Engineering leaders should stop treating agent supervision as only an upgraded code-review problem. It is a release-accountability problem.
Five responsibilities become more important as agents become more capable:
- Specify intent. Define the behavior, boundaries, and acceptance criteria before implementation begins.
- Curate context. Maintain repository instructions, architectural decisions, product constraints, and operating knowledge the agent needs.
- Bound execution. Decide which files, tools, networks, credentials, and environments the agent may access.
- Demand evidence. Require the relevant builds, tests, reviews, and inspections, including a clear record of what did not run.
- Own the outcome. Keep the release decision with an accountable person who understands the remaining uncertainty.
This is not a retreat from automation. It is how automation becomes usable for consequential work.
Agent adoption should not be measured only by completed tasks or accepted code. The stronger measure is whether faster execution is matched by clearer intent, independent evidence, and explicit ownership.
Vibe coding grew up because the tools grew up.
Production got harder for the same reason.
The prompt can start the implementation. It cannot own what ships.
This article is adapted from Vibe Coding Grew Up. Production Got Harder. on the Early blog, which includes the full source list and Part 2 of the series.
Top comments (1)
Where has your team drawn the line between an agent-completed task and a release-ready change?