The Pilot Has Moved to the Tower
Last year, I wrote that working with coding agents needed pilots: people who fly agents through a new airspace of work by guiding the outcome, setting the context, and validating the output. That was one person landing one agent’s work. Watch an engineer today and you’ll see how much has changed. Four sessions running: one waiting on tests, one mid-migration, one blocked on a decision, one off the rails ten minutes ago and unaware. We are not flying anymore. We’re managing airspace and sequencing arrivals.
All those extra flights carry increased baggage that lands somewhere. I’ve seen our team’s delivery volume increase several-fold within a year and each change is carrying more code than it used to. This aligns with industry-wide trends: in the codebase, short-term churn is increasing and refactored code is falling; in delivery, AI is improving our throughput, but often at the cost of stability. Most people call that technical debt. Debt is a shortcut taken deliberately, priced at the time, with a plan to repay it. As Uncle Bob put it, “a mess is not a technical debt. A mess is just a mess.” This mess has a name: workslop.
Directing agents to increase throughput without decreasing quality requires a new set of skills and being a great pilot does not necessarily translate to the new role as an Air Traffic Controller. It starts with improving the quality of the flight plan.
Flight Plans Are Cheaper Than Go-Arounds
A flight plan settles the route, the altitude, and the timing before the wheels leave the ground. A bad one costs go-arounds: circling the field, burning fuel, and retrying the approach again…and again. When working with coding agents, every weak plan creates more work through multiple review rounds, rework and merge conflicts.
The plan is the work product now. Research-Plan-Implement became the emerging best practice for agentic work: research the codebase, write a plan, then implement. Crafting a “quality plan” has been hard to scale from “prompt protips” to “standard operating procedures” for the whole team. Question, Research, Structure, Plan, Implement is the evolution, and the two stages it adds in front of the plan are what turn a knack into a procedure.
Decisions…Decisions…Decisions. Good engineering has always required good judgement for what problems need to be tackled now vs later. Most of this lives in our heads as constraints, assumptions, and non-functional requirements and the questions phase captures these essential inputs up-front into a reviewable artifact that influences the downstream implementation plan. Each decision also records how firmly it’s held (from hard line requirement to open to interpretation), so later phases know which calls are fixed and which are still in play. Silicon Valley has become infatuated with the concept of “taste”, but this is just a new term for an old skill: discernment. Taste isn’t a thing you can point at, so nobody can review it and nobody can be wrong about it. Discernment is a specific call on a specific tradeoff, written down, and you can be demonstrably wrong about it.
Chunk it up. Agents love to build horizontally. Left alone, one writes all the backend, then all the frontend, burning tokens for hours before anything exists you can run. The structure phase breaks the work into independently shippable phases, each carrying its own verification step. Those are checkpoints: places for the agent to test what it built, clean up, simplify, and correct the architecture while correcting it is still cheap, instead of one enormous review at the end. Great engineers have followed a similar process for years, building a small functional product and iterating from there, with each step an opportunity to challenge initial assumptions, constraints, and research.
Reviewing a change used to require hallway conversations and architecture reviews to recover the context, the intent, and the phasing. These artifacts capture all of it up front, so an agent and a human reviewer can both see the assumptions behind a specific set of changes, and debate them with less bikeshedding on the implementation details.
Getting More Planes in the Air
A plan good enough to leave without you raises the next question: how many can you launch at once? For twenty years, developer productivity tooling aimed at making one piece of work go faster. Running many at once is a different problem.
The goal is to maximize the number of sandboxes you can run in parallel, locally through git worktrees, containers and throwaway checkouts, and remotely through cloud development environments. Then keep them busy…and while they are busy, queue up the next change. Waiting on agents has led to a return of the classic XKCD “Compiling” meme. The explosion of parallel in-flight changes leads to a new problem-space: what’s working, what’s blocked, and what finished while you were looking elsewhere. Tools like Herdr are emerging to show what’s running where. But every workstream you add is more context to hold, and to pay for again every time you switch between them. Similar to the fatigue and burnout experienced by air traffic controllers, early research points to AI work contributing to “brain fry”. There is no solve for this yet, and it is worth talking about as we learn more.
Running more changes in parallel increases pressure on two things that gate a landing: review and verification. First, lower the cost of review by putting an agent on the first pass. One protip from our own testing: use a different model than the one that wrote the code. You get higher quality feedback, and a more diverse set of it. A model reviewing its own output shares its own blind spots and misses exactly what it was always going to miss. Next, take the human out of the landings that don’t need one. Classify changes by risk and route them: real blast radius goes to a person, while the trivial group runs the full CI/CD pipeline and self-approves. Early analysis within our team shows nearly a third of pull requests can be fully hands-off (dependency bumps, documentation, test-only updates), and that floor will continue to rise over time. Automating the merge is only half of it. The other half is the delivery infrastructure that makes a bad release survivable: observability, canary deployments, automated rollback, and SLAs that define what broken actually means. Every investment there raises the number of releases you can safely hand off.
The sandboxes, the routing, the verification loops are the infrastructure that needs to be built, all while the flights keep going.
Building the Tower
Moving from the cockpit to the tower is a shift in skillset and environment. The tower needs to be built intentionally, brick by brick, by the same team that’s still responsible for flying the planes. Nobody finds that time on their own; somebody has to decide the tower is worth more than another quarter of features. There are four things to build, and none of them arrives on its own.
The scaffolding. The harness the work runs on: the sandboxes, the routing, the verification loops. We are entering an era where running SOTA for every operation is not worth the expense, and investments in the harness are almost always worth the ROI. Model upgrades will come whether you want them or not, and the real value comes from investing in the harness around the model. A controlled experiment that held the model and the evaluator fixed found the harness alone can increase the performance of a model by as much as 21 points. We’ve seen harness improvements unlock a failed long-running agent-led migration to success. Same task, same codebase, different system around it.
The plans. The quality of your outputs is a function of the quality of your inputs, and the codebase is one of those inputs. An agent inherits whatever your code already communicates: the structure, the naming, the tests, the conventions it can infer without being told. That legibility is planning investment, and it compounds every time an agent touches the code. Question, Research, Structure, Plan, Implement gives agents (and humans) the decisions and phasing to guide implementation more reliably to a swift and smooth landing.
The instruments. You can’t take off or land consistently, let alone autonomously, without reliable observability of the overall system. Not just number of pull requests (which we’re seeing explode). DORA metrics continue to be the industry standard for health of the system: change failure rate and time to recover, plus batch size, which DORA treats as a practice rather than a key metric. Productivity metrics are a challenge given the pace of change, and they will mislead you before anything else does; measure against where the trend was already heading, or you can’t answer “we would have improved anyway.” With those in place I’ve watched cycle time improve while volume rose and while each change got bigger.
The people. Agents write more of the code every month. What’s scarce is understanding it, and the discernment to know what’s worth building. Stop asking candidates to write the function. Hand them a pull request and ask what’s wrong with it. The job change is real and worth naming: if you identify as a programmer, this is hard. Annie Vella said it: “Many of us don’t just write code — we love writing code. It’s not just work, not just a craft — it’s who we are.” I love code. I love the craft. But I’ve never hired a programmer. I’ve hired people to solve customer problems, and wrote the tenet down years ago: if you can deliver impact to our customers without writing a line of code, do it. The identity was never in the code. It was in the impact.
A pilot sees one aircraft. A controller sees the whole airspace. Flying was good work. This is bigger work.