From Vibe Coding to Agentic Engineering

AI coding has changed twice in a few years, and the second change is easy to underestimate.

At first, the model sat beside the engineer in the editor. It completed the line or function already being written. The engineer chose the direction, saw the suggestion arrive, and accepted or rejected it in context.

Then the prompt became the working surface. You could describe a feature rather than a function, run what came back, paste the errors into the conversation, and keep going until the software looked right. That mode became known as vibe coding.

Now coding agents can inspect repositories, edit several files, run commands, read failures, and continue without someone approving each move.

The obvious description is that code generation got better. I think that misses the more useful change: the conversation is no longer large enough to hold the whole engineering process.

Autocomplete improved a familiar process

Inline completion made coding faster without moving responsibility very far.

The engineer still decided what to build. They wrote the surrounding code, saw each suggestion arrive, and judged it against a system they already understood. The model helped with implementation, but the shape of the work stayed familiar.

The question was usually local:

Is this suggestion useful here?

That remains a good way to work. Autocomplete is still valuable when the change is narrow, the engineer understands the code around it, and close review is part of the task.

Then the prompt became the workplace

Vibe coding changed the unit of interaction. Instead of asking for the next line, you could ask for the feature.

The conversation began to carry the intent, the corrections, and much of the working context. When something failed, the failure became another prompt. The model could replace several hours of implementation with a short cycle of description, execution, and correction.

I don't see vibe coding as a failed version of agentic engineering. For a prototype, a personal script, or a disposable experiment, it can be exactly right. The code is cheap to replace, and learning quickly matters more than maintaining the result for years.

The trouble appears when that temporary working style becomes the default for durable software.

A feature can look right while hiding weak assumptions, incomplete failure handling, broad permissions, or a design the next engineer will struggle to extend. More prompting may improve the output. It doesn't create the missing controls around it.

At that point, the consequences have outgrown the feedback available inside the conversation.

The chat is no longer big enough

Coding agents add sustained action.

An agent can inspect the current repository, form a plan, make changes, execute tools, read the results, and revise its own work. It may continue for long enough that a person no longer sees every local decision as it happens.

That is useful. It also means several decisions need a more durable home than chat history.

Before the run starts, the engineering system should already know:

• the outcome the task is meant to create
• the parts of the repository and environment the agent may use
• the checks and observations required as evidence
• the situations that require a person or specialist reviewer
• the valid stopping states
• the record that must remain after the conversation ends

The agent can have considerable freedom over implementation while those decisions stay outside its control.

What moves into the engineering system

The practical difference is easier to see when the two workflows are placed side by side.

The last row carries most of the difference. Agentic engineering starts before the first command runs. The team has already decided what the work means and how it will be judged.

A small workflow is enough

You do not need an orchestration platform or a collection of specialised agents.

Start with one task your team already understands. A bug fix, dependency update, small feature, or documentation change tied to code is enough. The task should have a verification surface that people already trust.

Put the task in a file

The task contract can be plain text or YAML. It only needs to be short enough that someone can review it before the run.

goal:
  Users can export every invoice matching the active filters.

scope:
  - app/reporting
  - tests/reporting

allowed:
  - inspect and edit the repository
  - create tests
  - run local development commands

forbidden:
  - deploy
  - access production data
  - merge the branch

evidence:
  - ./scripts/verify.sh succeeds
  - pagination and empty results are tested
  - the actual interface is used once outside the test harness

stop:
  accept:
    - required evidence exists
    - no blocking review issue remains
  escalate:
    - product behaviour is ambiguous
    - a migration or public API change is required
  reject:
    - the requested outcome cannot be demonstrated

This is only one way to describe the task. A short Markdown file can work just as well. The important part is that another engineer can understand the work without reconstructing the conversation.

Give the agent a safe place to work

A branch, worktree, container, or sandbox is usually enough.

Constrain the risks that matter: unrelated file changes, network access, credentials, and deployment paths. The aim is not to interrupt the agent for every harmless command. It is to make ordinary work easy while consequential actions remain blocked or require approval.

I would start here before adding schedules or parallel agents. Isolation exposes weak assumptions early, and it gives the team a clean place to inspect or discard the result.

Make verification a repository capability

Give the repository one command that expresses the checks every task should run.

./scripts/verify.sh

The script may run type checks, linting, tests, policy checks, and a production build. Product-facing work can add runtime evidence, screenshots, logs, or a short manual review.

The same command should be available to the agent and the reviewer. That makes verification part of the repository rather than a claim made in the final message.

I would invest in this before building a sophisticated agent router. Better routing cannot compensate for weak evidence.

Leave a run record

When the task stops, preserve enough information for another engineer to review the work without reconstructing the chat:

• files changed
• commands run
• checks passed and failed
• runtime scenarios tried
• assumptions made
• unresolved questions
• the reason the workflow stopped

The record does not need to be elaborate. It needs to survive the session.

Keep acceptance outside the producing agent

The agent may recommend that the change is ready. It should not approve its own permissions, merge its own work, or redefine success after seeing what it managed to build.

A human reviewer is the simplest acceptance boundary. Some review can be delegated later, provided the authority and independence remain clear.

Don't begin with a software factory

The jump from a chat window to a multi-agent platform is tempting. It also adds coordination, cost, state, failure modes, and review work before the underlying process has proved itself.

One well-bounded agent is enough to discover whether the task is clear, the permissions are appropriate, the evidence is useful, and the acceptance boundary works.

A sensible progression is usually:

1. one agent with repository access
2. one task contract
3. one isolated workspace
4. one verification command
5. one review and acceptance gate
6. durable run records
7. scheduling or parallel execution after the workflow is reliable

This order is not universal. A team with a genuine parallel workload may need more earlier. I am less convinced by orchestration that arrives before the team can explain how one agent earns acceptance.

These modes overlap

Autocomplete, vibe coding, and agentic engineering are not a strict maturity ladder.

A single session may contain all three. An engineer might use inline suggestions for a local edit, prompt-led generation for a throwaway visual experiment, and a bounded agent loop for a change that will reach production.

The extra process of agentic engineering has a cost. Writing task contracts, maintaining verification, recording runs, and reviewing evidence all take time. That overhead is difficult to justify for work that is genuinely disposable.

The choice should follow the responsibility attached to the software.

Use the lighter mode when failure is cheap and the result is easy to replace. Add stronger controls when the task is delegated, repeated, long-running, shared, sensitive, or expensive to undo.

Start with four decisions

The move from vibe coding to agentic engineering does not begin with a longer prompt or a larger agent platform.

Before the next delegated task, write down:

1. the outcome
2. the authority
3. the evidence
4. the acceptance decision

Then open the chat and give the agent room to work inside those boundaries.