The friction was the control

I have been reading a lot of code these days. Not because I need to write some feature. Claude Code does that perfectly. But I have spent a lot of time reading Claude’s output because it is the only way I feel like I am in control. And even then, I do not feel the same way as I did back in the days. I think one of the reasons is the sheer amount of text you need to read. We as humans are designed to be lazy, and only discipline and professional pride stops us from shipping code where we have lost control completely.

I saw a great talk by Yngve Bakken Nilsen at NDC AI in Oslo this year that put words on that feeling. He had been building a solution where he wanted AI to build everything. And it worked great. But something felt off. It wasn’t that there were bugs or anything. The issue was that he sort of lost control. His point was that whenever we write code ourselves, we pause and reflect on details, and those details may make us question the design as a whole. All that friction along the way was where the feeling of control came from. All these small decisions are now taken by AI, and that leads to a feeling of lack of control.

Outsourcing to someone who forgets

That said, developing with lots of AI agents really isn’t that different from being an architect with many developers on the team. As the architect you may not always have the time to dig into all the corners of a code base to understand the inner workings. The difference now is that I outsource my work to Claude Code instead of a more junior developer (I may still do both, but that is another matter).

Except there is one difference, and it matters. When I delegate to a developer, the understanding lives somewhere. They are in the standup tomorrow, and they can answer questions when an error happens in production. When I delegate to an agent, the understanding evaporates the moment the session ends. If we don’t stay close to the decision making and lose control like vibe coders, then we have truly outsourced everything, which effectively means that we have zero ownership over the product we are developing. Even worse, it leaves us vulnerable. What happens the day Claude Code or Codex is unavailable? Who will then be able to answer questions about the inner workings of the system?

Proactive isn’t enough

All these thoughts made me think about how I could get back in control. I was already familiar with skills like grill-me (a skill that interviews you about your decisions before the agent starts building) and it truly does help with a proactive take on being the decision maker. But those decisions can still easily be bypassed, or conflict with other choices you made, which then lets the model decide anyway.

I also think this way of developing carries a large risk of building above your capacity. What I mean by that is that you end up building a too complex system with possible unknown components, that is too hard for you to reason about. The system grows faster than your understanding of it, and the gap is exactly the control you have lost.

What I was missing was a more reactive approach. How would I be able to improve the review process?

The wall of text

As mentioned, one of the large issues with AI is how damn good it is at producing text — and by that also lines of code that I have to review. If I have an agent working and it makes a 1000-line PR, there is a real risk that I do not catch the things that make the solution drift such as weird assumptions that affect business rules, but frankly anything that can easily drown in the wall of text.

Instead of having to read all the code, I was thinking that maybe the AI agent should state its intent along with the lines. After all, that should be fewer characters, and hopefully make bad assumptions about the business rules more clear. A wrong assumption stated in one plain sentence is catchable. The same assumption smeared across 1000 lines is not.

Reviewing intent instead of lines

So I built a small tool called review-intent. The name could be better since it does a bit more than just reviewing the intent. Hell, it may even get a new name one day. Nevertheless, it renders your branch’s diff as a review page in the browser, but with one twist: next to every hunk sits the author’s stated intent. In other words, it forces the agent to write why this change exists, what alternatives were rejected, and which assumptions it rests on.

The obvious objection is that the model that made the bad assumption is also the one writing the intent. Why would it confess? Honestly, I cannot be sure. But I do think that keeping the intent short will help me spot what is wrong faster. So when an agent writes “assuming discounts never apply to bundled products”, I can spot that it is wrong in two seconds, even though I would never have caught it inside a 400-line refactoring of some module. This is of course based upon the idea that the model isn’t hiding the assumption but simply does not “know” it is wrong.

My experience so far is that reviewing this way makes it easier to “distribute” my attention to the important details more evenly. The fatigue still comes (it always does when reviewing AI output) but it comes later. Ideally not until I am through the entire pull request, instead of halfway into it. This means that the review changes character. I am no longer spending all my energy on reading lines to verify the agent’s code output, but instead I am evaluating decisions that are laid out in front of me.

Am I in control now?

Honestly? Not like back in the days. The friction that Yngve talked about is gone, and no tool brings it back. The small decisions are still being made without me. But there is a difference between not making the decisions and not knowing what they were. Review-intent does not make me the author again. But it does at least give me the illusion of me regaining more control. For now, I think that is what being in control looks like.

/Mørup