Feedback Needs Somewhere to Land

Jim Highsmith wrote a post about doing agile and being agile that argues the two were never opposites. You get experiences from the practices you use. Those experiences change how you think, and how you think changes which practices you use next. Neither one comes first. It is a loop, and it only keeps going if feedback comes back into it.

He backs that up with a story, and the story is what I keep thinking about.

An architect wanted two months to document a system with UML diagrams. Highsmith gave him two weeks. Four iterations later the architect admitted he had needed to redo a large part of the architecture. He also admitted that with the original two months he would never have considered the version he ended up with. The change in his behaviour came first, and it caused the change of mind. His old way of thinking could not explain what had happened.

That experience did not happen on its own, though. Nobody talked him round. He could not have set the deadline himself either. The thinking that needed to change was the same thinking that would have called two weeks impossible. Somebody else had to take the option away.

So the loop does not keep going on its own. Somebody has to set it up, and then the experience happens to you.

So who sets it up now, when the thing doing most of the typing cannot be changed by experience at all?

The step that needs a mind

That loop has a requirement in it that is easy to miss. Something in it has to be able to change its mind.

John Boyd's OODA loop is a useful way to describe this. The four steps are Observe, Orient, Decide and Act. Orient is the step where a person changes their mind. You act, reality disagrees with what you expected, and the model that produced the expectation has to give way. The architect was contradicted once and carried it into every project after that. That is the part that makes the loop worth having. He still had the experience after the project ended.

Now run the same loop with an agent.

You can contradict it all day. It takes the correction, apologises and fixes the code. Tomorrow it starts exactly as it started today. There is no Orient step, because there is nothing being oriented. Session one thousand starts from the same place as session one, only the git history is longer.

So the loop stops there. Feedback arrives and there is nothing for it to land on.

What a document assumes

A while back I wrote that a request is not a rule, and that a convention belongs in the linter rather than in CLAUDE.md. The reason I gave was context dilution. Everything in that file competes for attention with everything else, so the agent follows any single instruction only some of the time. That is true, but it is not the main reason.

The bigger reason is that writing a convention down assumes a reader who accumulates. That is a fair assumption about a person. You explain it once, they take it, and six months later they are the one explaining it to somebody new. Writing works with a colleague because the person reading it remembers what they read.

An agent gives you none of that. Every session starts from the same place. Every loop that used to close inside somebody's head now has to close somewhere outside it. A linter rule is that loop written in a form that does not need anyone to remember it. A test that fails when two files drift apart is the same thing. The agent will not learn the rule either way, so sometimes you can skip the loop and apply it to the file once it is written.

That is what the last two posts were about. I did not see it clearly until I read about Highsmith's architect and his two weeks. I thought I was writing about instructions an agent will not follow. But really I was writing about putting the loop somewhere it can survive the end of a session.

The loop that runs through you

The loop can also stop on your side, and the agent is not the reason.

The architect reoriented because he had committed to a prediction. Two months of up-front design would give him the right architecture. Reality disagreed. You cannot be contradicted unless you claimed something first.

Now think about accepting a diff you have not read. It works and the tests pass, so you move on. Nothing contradicted you, because you never made a claim for reality to argue with. You got the output without the experience that would have changed how you think.

Highsmith puts the same question to people, not agents. He asks whether they are building judgment through experience they have to live with, or consuming AI output and calling it insight. He describes the problem in terms of speed. He says AI compresses the timescale until the natural pause points disappear. Going fast is usually how it happens. But short iterations were fast too and you learned plenty from those. What changed is that the work can now arrive without passing through your head on the way. Somebody had the experience of doing the work, and it was not you.

This is why I still read every line before I accept it. Reading is where I find out I was wrong, and skipping it is how quality drifts one accepted diff at a time.

Build both loops

There are two loops to build now, and neither one builds itself. They are not the same job either.

The one around the agent has to live outside anyone's head. Put it in the repository, in tools that run whether or not a person remembers them. The one around you has to make you say where you think the change belongs before the code lands. Then there is a claim on the table for the result to disagree with.

The claim does not have to be elaborate. Before I hand a task over I have a rough view of where the change belongs and how much code it should take. Then I read what came back and see whether it matches. The tests already answer whether the feature works. They say nothing about whether the code came back the way I expected. The times it did not are the ones worth stopping for, because one of us was wrong about the problem.

Neither one is a big project, and you can start either this afternoon.