Who stays in control when agents write the code?

Why coding, part 1 of 3. Part 2 shows how it works; part 3 asks whether it holds.

AI agents can now write much of the code. For me the real question is no longer whether they can. It is who stays in control when they do.

At Software Natives, we build software for industrial machines and for businesses. On a machine, “it seemed to work” is not good enough, and we bring that standard to everything we build. For months I have been asking how to stay in control. Two weeks ago, one answer came to me: give the agents the reasons, not the instructions. I call it why coding: coding from the whys.

A staircase that keeps moving

“Shift left” started in testing: in 2001, Larry Smith urged teams to test earlier. I use the phrase more broadly, for where people put their effort. Think of a staircase, where each step moves that effort further away from the code:

1. Code first. You write the code, then check whether it works.
2. Tests first. In test-driven development, you write a failing test, then the code that makes it pass.
3. Behaviour first. In behaviour-driven development, tests describe behaviour in plain language: given this, when that, then this.
4. Specs first. In spec-driven development with agents, you describe what you want, review the specification an agent drafts from it, and the agent turns it into a plan, tasks and code.

Agents climb the same staircase, one step behind us. They now write much of the code and many of the tests, and they are starting to help with architecture and specs. Each time they master a step, our effort moves one step further. So where does the staircase end?

Beyond the spec, there is the why

Code is the how. A spec still describes a solution: the what. Behind every what there is a reason: the why. Asking why takes you outward from the code; asking how takes you back in. User stories already hint at it: their common template ends with “so that…”, which names a why. In why coding, that clause becomes the main input.

You find whys by asking why, again and again. Toyota’s five whys does the same, though it digs for the cause of a fault. The first answers still carry your environment. “Each agent writes its code in its own Docker container” is how one company works. Ask why once more and you get “pieces of work done at the same time must not interfere with each other”. That holds wherever work runs in parallel, however a company is organised. I call such an answer a root why: one found by asking why until the environment drops away. Why keep the two apart? Whys rarely change; the environment changes often.

How far should you go? At least until the environment drops away, and stop before it turns into philosophy. Asked often enough, every chain of whys ends in something about the person, not the software. So stop at the last why the software can still serve, such as saving brain power, before it reaches “I want to be happy”.

What only you can give

Whys collide. Mine did right away, when I set out to build a tool that helps me work with agents. I do not want to sit idle while agents work, so I run several sessions at once. But I also want to save brain power, and every switch between sessions costs some.

If whys never conflicted, an agent could simply collect them and build. Because they do, someone has to decide which one wins. That ranking is the part no agent can supply. This is where the staircase ends: not because agents lack the skill, but because the choice is yours. Without a ranking, an agent does what a new colleague would: it either asks you at every conflict or decides on its own, guessing what matters most to you. Neither works when you want the work to run without you. It is also why two people with the same whys can rightly end up with different software, and in my tests, changing the ranking changed what the agents built. With my whys in one order, three agents each built a tool that runs delegated work in isolation, lets me review it, then apply or undo it. With the order turned upside down, they built a friction ledger instead: a log of what slows the work down, and of what each fix saved (more in part 3).

So have I answered the question in the title? Not yet, only the first step: owning the whys and their ranking is the base that will let you judge the software by checking its behaviour, instead of reading every line of code or trusting that it seemed to work. But whys alone are not enough. The agents also need the environment and what can go wrong, and you need checks traced back to your whys. Part 2 shows how that fits together.

Where I stand

This is an early thesis, not a proven method. I have only just started using it, and the first experiments are promising (more in part 3). None of the pieces is new on its own: similar ideas exist in requirements engineering, goal models and leading by intent, and part 3 credits them.

But from a purely logical point of view, I see no other direction. If agents keep taking over each step, people end up at the reasons, because the reasons and their ranking are the one input no agent can supply for us. Others may call it something else; I call it why coding, and it is the direction I am betting on.

You can try the core of it today: next time you hand a task to an agent, tell it why you want it, and which of two goals wins when they clash.

Next week, in part 2: what an agent needs besides your whys, and how I intend the work to run.