My recommendation: train an engineer at the stage they're actually stuck on, not the stage you want them at. Nobody moves from pasting code into a chat window to running a multi-agent harness with its own test suite because a slide told them to. They climb one wall at a time, and the wall only becomes visible once the stage they're on stops working for them.

I learned this the slow way, on my own work, before I ever taught it to anyone else. A year ago I was one engineer on one repository, writing most of my own code, with AI helping at the edges and tests as an afterthought I'd get to "later." In the months since, my own codebase went from roughly 200,000 lines of AI-assisted code back down to about 40,000 — and the point it shrank was the point it actually started working. That's the shape of the whole story: not a straight climb, but a fast rise, a plateau into a mess, and then a deliberate descent into something that ships.

The six stages, and the wall at each one

I gave an internal talk on this at the firm where I work, laid out as a six-stage ladder. Every stage gets earned by hitting the wall of the one before it — you don't graduate because someone recommends the next tool, you graduate because the tool you're using stops being enough.

  1. Prompting. Ask a question in a chat window, get an answer, iterate. It's a smarter search engine. The wall: every task needs the same boilerplate context restated by hand, and the output is only as good as a prompt written from scratch each time.
  2. Meta-prompting. Stop writing prompts directly; describe the goal and let a reusable persona hold house style and constraints once instead of every time. I built one of these to hold accessibility-first layout rules for Samarthyam's site, then reused the same pattern for Replate's, under a different brand entirely. The wall: every new project still needs a persona built from scratch, and a persona built for one page doesn't scale to a real codebase.
  3. Copy-paste building. Code moves from editor to chat window and back, by hand, on every change. Crude, but it builds real applications past what a single prompt can hold. The wall: you are the integration layer, manually, on every single change — the slowest component in your own pipeline.
  4. IDE integration. The assistant moves inside the editor. Multi-file edits happen in one shot, the copy-paste tax disappears, and velocity feels enormous. This is the most dangerous stage, because the productivity gain is real enough that nothing warns you it's also the highest-risk stage for what I'd call AI slop — code that looks like progress and behaves like debt. This is where my own codebase went from roughly 10,000 to 200,000 lines in a few weeks, no tests, the same logic duplicated in three places. It felt like flying. It was a crash in slow motion, and the wall stayed invisible until releases started breaking.
  5. Context engineering, TDD, and a harness. The turn. Stop letting the assistant see everything; feed it only what the task needs. Write tests first, racing ahead of releases instead of chasing them. Wrap every change in a structured plan-execute-test loop. This is the stage where the codebase actually shrank — 200,000 lines down to 40,000, split roughly evenly between source and tests — and releases stopped breaking. The shrinkage wasn't a loss of output. It was the output.
  6. Multi-agent, with a self-improving harness. One model stops being enough, so the work splits across specialised agents — one that writes code, one that tracks project state and deliverables, one that drafts proposals, one that researches. The harness starts learning from its own audit trail instead of only from corrections I make by hand, and routing sends each job to the right-sized model instead of the biggest one by default.

The most dangerous stage isn't the first one

If I had to warn a team about exactly one stage, it's the fourth — IDE integration — precisely because it doesn't feel dangerous. The first three stages are visibly slow and manual, which keeps people honest about their limits. The fourth removes the friction entirely, and removing friction removes the checkpoints where a person used to stop and think before merging. Training that jumps straight to "here's how to use the IDE assistant" without first building the discipline of stage five — tests before code, minimal context, a harness that checks its own output — trains people into the fastest available way to accumulate debt they can't see yet.

Think in systems, not tasks

The instinct that matters more than any specific tool recommendation: name the system a piece of work belongs to before automating any part of it. A prompt that speeds up one task isn't automation — it's a faster version of the same ad hoc work. Automation starts with describing the process end to end and then deciding, deliberately, which parts a model should own.

Turning this into a course, and the mandate that came with it

This ladder became the spine of a four-part internal course I designed and now lead: development and branching, testing, deployment and versioning, and planning and agile. The course teaches a small, concrete set of disciplines — prompt with intent, read every diff hunk before it merges, keep changes minimal, never push code you can't explain yourself in your own words. One rule from the first session has stuck with participants more than any other: a branch prefixed feat/ means something new, fix/ means something broken; if you can't decide which one your change is, the change is doing two things and should be split before it goes any further.

Leadership approved the course, then handed back a bigger brief than teaching it: roll the practices out across every project, measure the improvement within a week, and keep tracking it from then on. I'm personally answerable for whether that measurement holds up, which changes how carefully I have to build it. The trap sitting inside that mandate is a familiar one, and I named it explicitly rather than let it surface later as a credibility problem: reporting that people adopted the practice — branch names changed, push cadence changed, visible within days — is not the same claim as reporting that the practice worked — time-to-merge improved, rework dropped, fewer defects reached production, a signal that needs weeks to settle, not days. I keep those two tiers of evidence separate in every report, because collapsing them is the standing trap of any measured rollout, and a training program's credibility rests on not making that mistake once, in public, in front of the people being asked to trust the number.

This course runs inside a weekly internal talk series I co-founded at the firm where I work, built around one target: get every person on the team to speak at least once. Each session gets recorded, promoted, and archived with a one-page written summary — the same governance discipline I'd apply to a client deliverable, because a recurring internal ritual quietly stops the moment nobody's tracking whether it's still running.

Exercises for each stage, if you're running this with a team

  1. At prompting: have each person write down their most-repeated prompt boilerplate, then rebuild it as a saved persona instead of retyping it — that's the push into meta-prompting.
  2. At IDE integration: pick one real feature and require a failing test before any code gets generated for it. Watch how much the velocity number changes, and write down both numbers, not just the one that looks good.
  3. At any stage: audit one week of commits for duplicated logic. The same function doing the same thing in more than one place is the earliest visible sign of the stage-four wall, well before releases start breaking.
  4. Before scaling any practice: define the compliance signal (visible in days) and the outcome signal (needs weeks) separately, in writing, before measurement starts — and report them as two numbers, never collapsed into one.
  5. Every quarter: ask each engineer which wall they're actually stuck at right now, not which stage they'd claim in a self-assessment. The two answers are usually different, and the gap between them is the actual training need.

Sources

  • Internal talk, "From AI Slop to Systems: Six Levels of Automation," delivered April 2026; figures (lines of code, stage descriptions) as originally reported in the talk's written version.

Read next

What Building an Accessibility Practice Taught Me About Real Conformance →

Automated conformance is an assertion; manual testing plus a code-level fix is evidence — and building a practice on the second one kept costing me deals the first would have won.