The next phase of AI-assisted engineering will not be more magical. It will be more explicit.

There was a moment when software engineering felt like it had found a cheat code.

You opened a prompt box. You described what you wanted. The model produced code.

Sometimes it worked. Sometimes it worked well enough that the profession paused to wonder whether the map had been redrawn.

This was the age of vibe coding: follow the instinct, describe the outcome, let the machine fill the gaps, regenerate, keep going until something appears on the screen. For prototypes, internal tools, and side projects, it was good fun and genuinely useful.

But every new frontier eventually meets the same old ghosts. Production. Maintenance. Security. Cost. Ownership. Audit. Drift. Failure. And the quieter question that follows all of those: who understands this thing now?

This is why the death of vibe coding will not be dramatic.

It will be boring.

It will arrive as checklists, tests, contracts, coding standards, runbooks, repository instructions, evaluation harnesses, access boundaries, pull request templates, and logs.

It will arrive as engineering.

The magic was real

It would be easy to dismiss vibe coding as unserious. That would be a mistake.

The early phase of any new capability often looks undisciplined because people are still discovering what the tool can do. Before a practice becomes a profession, it is usually a craft. Before it becomes a craft, it is play.

Vibe coding revealed something real: language models can reduce the distance between intent and implementation.

For decades, software engineering has been constrained by translation layers. Business intent becomes requirements. Requirements become tickets. Tickets become designs. Designs become code. Code becomes incidents. Incidents become lessons, usually too late.

AI collapses part of that distance. A developer can express intent in natural language and get a plausible implementation. A product person can explore working behaviour before the specification is complete. An architect can test an idea before a committee can schedule the review.

The magic is not that the machine understands everything. The magic is that the first draft is no longer expensive.

But first drafts are not systems. I made a longer version of this argument in March: when execution gets cheap, ambiguity stops being slowed down by friction and starts surviving into production.

The problem with vibes is not the vibe

The problem with vibe coding is not that it is playful, intuitive, or fast.

The problem is that it hides the structure that made the result acceptable.

A human developer looks at generated code and unconsciously applies years of judgment: this feels wrong, that dependency is suspicious, this pattern will not scale, this error path is missing, that naming will hurt us later.

The model does not know which of those instincts matter in your organisation unless the environment tells it. A prompt describes the task. It rarely describes the architecture decisions, production constraints, threat model, cost limits, deployment rules, data classification, logging expectations, rollback strategy, or the scars from the last incident.

So the model fills the gaps.

That is useful when the gaps are small. It is dangerous when the gaps are where the engineering actually lives.

Agents make the problem sharper

This matters more now because the tooling has moved beyond suggestion.

GitHub’s Copilot coding agent runs in a GitHub Actions environment, researches a repository, creates a plan, makes changes on a branch, and opens a pull request. OpenAI describes Codex as part of a shift where developers orchestrate multiple agents, delegate work, run tasks in parallel, and hand off projects that span hours or days.

That changes the shape of the risk.

Autocomplete can be ignored. A bad suggestion can be deleted. But an agent operating across a repository, tools, branches, tests, and pull requests is not producing text. It is participating in the software delivery system.

The question is no longer “can the model write code?” The question is “can the system absorb machine-generated work safely?”

That is a more boring question. It is also the right one.

AI does not remove the system. It amplifies it.

DORA’s 2025 State of AI-Assisted Software Development puts this directly: AI does not fix a team, it amplifies what is already there, including the quality of platforms, workflows, and team alignment.

A team with clear architecture, strong tests, good documentation, reliable CI, small pull requests, and a healthy review culture will use AI to move faster.

A team with tribal knowledge, weak ownership, broken environments, flaky tests, and ambiguous accountability will use AI to create confusion faster.

The model is not the operating model. It is an accelerator inside one. Accelerators do not care whether they are attached to a race car or a shopping trolley.

This is the same shape of argument I made in Tiny teams, heavy systems: the visible win is real, and the invisible substrate that makes it safe is doing most of the work.

The boring stack

The next serious phase of AI-assisted engineering will be built on boring things. Not because engineers lack imagination. Because imagination without constraints is not delivery.

A mature AI engineering environment does not start with the perfect prompt. It starts with a system that makes good work easier than bad work.

It has repository-level instructions that explain how work is done here. Architecture decision records short enough to be read and precise enough to matter. Tests that describe expected behaviour, not just line coverage. Evaluation datasets for the behaviours that matter most. CI pipelines that verify security, policy, cost, and operational expectations, not only that the code builds. Dependency rules, secret scanning, static analysis, and review gates. Tool permissions that define what an agent can read, write, execute, and change. Logs that record what the agent attempted, what evidence it used, and where a human made the final call. Rollback paths. Owners.

Boring names for dangerous things.

This is where vibe coding ends. Not because the vibe disappears. Because the vibe gets surrounded by rails.

Verification is the new prompt

In the first phase, the prompt was everything. A better prompt produced a better answer.

When agents act inside engineering systems, the prompt becomes one part of a larger control surface. The rest of that surface includes tests, contracts, tools, permissions, examples, policies, feedback, and runtime evidence.

A prompt can say “refactor this module safely.” A test suite defines what “safely” means. A policy gate defines what is not allowed. A repository instruction defines preferred patterns. A dependency policy prevents a risky package from entering the system. A pull request template forces a summary of risk, assumptions, and test evidence. A human reviewer decides whether the change belongs.

The prompt asks. The system verifies. That is the shift, and it is also why “human in the loop” stops being a credible strategy without the rest of the substrate underneath it.

Security also becomes less glamorous

The same boring turn is happening in AI security.

The OWASP Top 10 for Agentic Applications 2026, released in December 2025, focuses on the risks specific to autonomous and agentic systems: agents that plan, call tools, persist memory, and act across environments. The framework spans goal hijacking, memory and context poisoning, tool misuse, cascading failures, and human-agent trust exploitation, among others.

Agentic risk is not only about hallucination. It is about authority.

What can the agent access? What can it change? What can it trigger? What can it remember? What can it call? What can call it? What happens when one agent trusts another?

A chatbot that says something wrong is a problem. An agent that does something wrong is a different class of problem.

The solution will not only be better model behaviour. It will be identity, least privilege, scoped credentials, sandboxing, approval workflows, audit trails, policy enforcement, and separation of duties.

Boring. Essential.

The future belongs to explicit organisations

The uncomfortable lesson is that AI rewards organisations that can explain themselves. Not in slideware. In executable form.

A good engineering organisation increasingly needs to describe its intent, standards, constraints, and feedback loops in ways that both humans and machines can use.

Less tribal knowledge. Less “ask Sarah, she knows.” Less architecture hidden in someone’s memory. Less process encoded in calendar rituals. Less production knowledge trapped in Slack threads. Less governance performed as theatre after the fact.

The agentic organisation is not the one with the most agents. It is the one whose environment is legible enough for agents to participate without chaos.

Documentation becomes infrastructure. Tests become instructions. Pipelines become policy. Runbooks become interfaces. Architecture becomes executable context. And engineering leadership becomes less about approving every decision and more about designing the system in which decisions are made.

What dies, exactly?

Vibe coding will not disappear. People will still use AI to sketch, explore, prototype, and learn. That is fine.

What dies is the belief that this is enough.

What dies is the idea that generated code is valuable because it exists. What dies is the theatre of productivity without maintainability. What dies is the screenshot-driven demo that leaves behind an unowned system. What dies is the fantasy that AI removes the need for engineering discipline.

The future is not “everyone becomes a prompt engineer.” The future is that serious teams become better at making their engineering environment explicit.

The prompt becomes smaller. The system becomes smarter.

Six rules for working with agents

If there is a manifesto here, it is short and unromantic:

  • No agent without a boundary. Every agent needs a defined scope, identity, permission model, and stop condition.
  • No change without evidence. Generated work comes with tests, traces, assumptions, and verification output, or it does not get merged.
  • No context without ownership. If agents rely on documentation, examples, or repository instructions, someone owns their quality.
  • No speed without reversibility. The faster the system moves, the more important rollback, isolation, and blast-radius control become.
  • No autonomy without accountability. Agents perform work; humans and organisations remain accountable for outcomes.
  • No magic in production. What cannot be explained, tested, observed, or reversed does not belong on a critical path.

None of this sounds exciting. That is the point. The real industrialisation of AI-assisted engineering will not feel like a magic trick. It will feel like a control room.

The return of engineering

Every wave of software has its romantic phase.

The web had “view source.” Cloud had “just deploy it.” Microservices had “small autonomous teams.” Data science had notebooks. AI has vibe coding.

Each phase begins with freedom from old constraints, and matures when new constraints get discovered, named, and engineered. That does not make the movement less important. It makes it real.

Vibe coding showed that intent can travel further than it used to. Agentic engineering will decide whether it arrives safely.

The next frontier will not be won by the teams with the longest prompts, the most agents, or the flashiest demos. It will be won by the teams who make the work legible. Who turn judgment into context. Who turn standards into systems. Who know that the boring parts are where trust is built.

The death of vibe coding will be boring.

That is how we will know software engineering survived it.