Four Phases. No Skipping.

Ask an engineering leader how AI is going and you will usually get a tooling answer. Everyone has a coding assistant. Half the team is running agents from the terminal. Somebody wired up a bot that comments on pull requests. All of that can be true while the team is still exactly where it was 18 months ago, shipping the same way, with faster typing.

Tooling is not the phase. What separates one phase from the next is what your engineers are accountable for. In phase one they are accountable for code they wrote with help. By phase four they are accountable for systems that write code without them in the loop. That is a different job, and we see teams move through it in four recognizable steps.

This is the model we use when we look at an engineering org, and the reason we bother with a model at all is the sequence. Each phase builds the thing the next one runs on. Teams that try to buy their way past a phase end up paying for it twice.

Phase 1: Prompting, skills, and plan mode

This is where nearly everyone is. Engineers use AI inside the editor as an assistant: writing functions, generating tests, auditing unfamiliar code, planning a change before touching it. The skill being developed is personal technique. How to prompt, when to plan first, when to hand it the whole file and when to hand it three lines.

Two things about this phase get misread, and they pull in opposite directions.

The first is that it usually gets slower before it gets faster. People are learning a new way to work, the pipeline was not built for this, and every generated block has to be read carefully by someone who did not write it. That last part does not go away, it just gets cheaper with practice. Leaders who promised a quarterly number off phase one tend to spend that quarter explaining themselves.

The second is that the gains are real but personal, and personal gains do not survive contact with an org chart. One engineer gets meaningfully faster. The team does not. The knowledge lives in that person’s habits, it leaves with them at 5 PM, and it goes on vacation when they do.

Neither of those makes phase one a waste, because phase one produces something the next phase cannot run without: judgment. An engineer who has watched AI produce wrong, plausible, confidently formatted code develops an instinct for where it fails. An engineer who has only read about that has opinions instead. You cannot write useful guardrails from opinions.

You are in phase one if: the honest answer to “what would we lose if AI went away tomorrow” is “some speed.”

Phase 2: Agentic development systems

Phase two starts when engineers stop asking AI to help them write code and start building agents that own a class of work outright. Defined role, defined context, defined tools. The agent is forward deployed: it picks up incoming requests, makes the changes, and opens pull requests. A human reviews the PR rather than every keystroke that produced it.

The shift is from “AI helped me do my job” to “this agent does this job.” That is a real handoff, and it has a prerequisite most teams discover late.

An agent is only as good as the context and the boundaries it was given, and both of those are written artifacts that somebody has to maintain. This is where the work stops being clever and starts being unglamorous. Before the third or fourth agent exists, you need standards that answer:

• When to build an agent and, more usefully, when not to. Most repeatable work does not justify an agent. Plenty of it justifies a script, and a script does not surprise you.
• What guardrails it runs under. What it can touch, what it can merge, what requires a human sign-off, and what it must never do under any circumstances.
• How context is structured. Repo-level and directory-level instruction files, versioned and code-reviewed like everything else, because an agent’s instructions are production configuration whether you treat them that way or not.
• Who owns it when it does something strange at 11 PM.

Your team also needs training on all of it, because building a reliable agent is a distinct skill from prompting well. Plenty of strong engineers are excellent at phase one and have never designed a context boundary in their lives. That is a gap you close deliberately, not one people fill in on their own time.

Most teams stall right here, and the reason is predictable. Standards feel like bureaucracy right up until three agents are running and nobody can explain what one of them did last Thursday. Then they feel cheap. The teams that write them early are not more disciplined by nature. They have usually just been burned once and decided not to repeat it.

You are in phase two if: an engineer who did not build the agent can read its instructions, understand its boundaries, and debug it.

Phase 3: Orchestrated agentic workforce

Phase two works until it works too well.

Follow the arithmetic. If agents are opening three times the pull requests, and every one of them still stops at a human reviewer, you have not removed a bottleneck. You have moved it, and you have moved it onto your most experienced people, who are now spending their week reading other people’s first drafts. Teams hit this faster than they expect, and the first instinct is usually to throttle the agents. That works, in the sense that turning something off always works.

Phase three is the other choice, made deliberately. Engineers architect multi-agent workflows that run loops, pass work between steps, review each other’s output, and catch their own errors without a person standing at every gate. The checking does not disappear. It gets built into the system instead of queued in front of it.

This takes concepts most engineering teams have never had to hold. Loop engineering, so a system knows when to iterate and when to stop, because a loop with no exit condition is just an expensive way to burn tokens. Graph engineering, so work moves between steps carrying the state each step actually needs. Orchestration, so the whole thing can be reasoned about rather than merely watched.

What comes out looks familiar, which is the point. A well-built orchestration mirrors the development process you would hand a team of people. Something plans the work, something implements it, something reviews it against standards, and something verifies the result and sends it back when it fails. The process was always the valuable part. Phase three is where a team realizes the process does not require a person in every seat.

It also changes what engineers do all day. Less time reading a stack trace, more time asking why the review step approved something it should have caught. Debugging moves up a level, from the line to the system that produced the line. Some engineers find that the most interesting work of their career. Some find it hollow, and it is worth knowing which of your people are which before you restructure around it.

You are in phase three if: work completes correctly without a human touching the middle of it, and when it fails, you fix the workflow rather than the output.

Phase 4: AI engineering at scale

Phase four is not a new technique. It is phases one through three being normal across every team, not just the one pod with the enthusiast in it.

At that point engineers spend most of their time on the layer underneath: guardrails that keep AI systems inside their boundaries in production, tooling that makes building and operating agents routine rather than heroic, and workflows that detect their own failures and recover without paging anyone at 3 AM. The job is closer to platform engineering than to feature development, because the thing being engineered is the system that produces the features.

Very few organizations are here yet. The ones that are did not get here by buying anything.

Why the order is not optional

The uncomfortable thing about AI is that it does not install discipline. It scales whatever discipline is already in the building.

If code review on your team is a rubber stamp today, agents opening 40 pull requests a week give you a rubber stamp applied 40 times as often, and the review queue becomes a formality nobody admits is a formality. If nobody writes down how anything works, agents built on undocumented context will fail in ways nobody can reconstruct afterward, because the context that produced the failure was never written down either. If your engineers have not developed the instinct for when output is subtly wrong, orchestrating five agents to review each other does not add up to judgment. It automates the miss and adds a layer of confidence to it.

That is what makes skipping expensive rather than merely premature. The phases are not difficulty tiers you graduate through. Each one produces the raw material the next one consumes. Phase one builds judgment. Phase two turns that judgment into written standards. Phase three turns those standards into architecture. Phase four turns that architecture into a platform other teams can use. Skip a step and the next one is building on nothing.

Buy phase three tooling for a phase one team and you get a phase one team with an impressive diagram, plus a system nobody can safely change.

One more thing we would rather say now than have you discover later. The payoff is not evenly distributed across your codebase. Agents do their best work where the code is well structured, the tests are real, and the intent is documented. On a system somebody wrote in 2013 that only two people understand, the same agent produces less and needs more supervision. That is not a reason to skip the legacy system. It is a reason to plan a smaller number for it, and to notice that the work of making a codebase legible to an agent looks almost exactly like the work of making it legible to a new hire.

The move this week

Name your phase honestly. Not the most advanced thing anyone on your team has ever done, and not what you told the board. The thing that is true for most of your engineers most of the time.

Then look at the gate directly in front of you. If you are in phase one, the gate is written standards and training on how and when to build an agent. If you are in phase two, the gate is whether your agents are documented and owned well enough that someone could orchestrate them. If you are in phase three, the gate is whether any of it exists outside the team that built it.

The gate is almost never the model, and it is almost never the budget. It is organizational, which is inconvenient, because it means the work belongs to you rather than to a vendor. It is also the reason the teams that do this properly are so hard to catch.