The Agent She Told You Not to Worry About

We promised to raise the difficulty until the bare agent broke. We raised it. It did not break.

The setup was built to be unkind: harder tasks, on a real 170-file service, big enough for an agent to get genuinely lost in. Handed no documentation at all, two coding agents satisfied nine of nine non-obvious functional requirements. Not approximately. Identically, both of them.

This is the result that turns the previous one on its head. The incurious-agent study said the agents were not reading the context we prepared. The natural conclusion was that they were therefore worse off. This study says: on these tasks, they were not. The engineering judgement was already in the model.

The one thing left

If an agent can infer the architecture, the error handling and the shape of the work from the code itself, then most of what a project brief tells it is something it could have worked out. What it cannot work out is the arbitrary part: the conventions a team chose that could just as easily have gone the other way.

So the study did the sharpest possible test of that. It put the missing piece exactly where the agent always looks, in the root contract it reads first, and confirmed the agent read it. Capability still did not move.

That is a stranger result than it first sounds, and it narrows the target hard. Being read is not sufficient. Whatever makes a document change an outcome, mere presence in the agent's attention is not it.

From incurious to self-sufficient

The framing shift matters more than the numbers. "Incurious" is a complaint about the worker. "Self-sufficient" is a description of a capability, and it puts the question back on us: if the agent does not need most of what we write, what exactly should we be writing?

The programme's next study answers that with the cleanest result it has, and it is not about volume.

The tasks, the task-by-task breakdown and the limits are in the research note.