Your new colleague doesn't drink coffee

A new colleague has joined the team, and he never drinks coffee. So he is never at the machine when someone mentions that a particular client actually meant something quite different, or that we deliberately dropped that feature last month. And when something isn't clear to him, he doesn't ask. He simply fills it in himself, with a confidence I occasionally envy as a consultant.

That colleague is an AI coding agent, and more and more teams have one.

This week I read Learn Harness Engineering, an open-source course by WalkingLabs on how to make such an agent work reliably. Their claim is that when an agent makes a mess of a real project, it's usually not the model's fault. It's what surrounds it: the harness. They back this up with an experiment by Anthropic, in which the same model with the same assignment produced something that didn't work after twenty minutes without a harness, and a game you could actually play after six hours with one.

A harness like that consists of instructions, a record of progress, verification, a clear scope and a fixed way to start and end a working session. The same word is also used for the program around the model itself, such as Claude Code, but I'll gladly leave that layer to the engineers. What interests me is what you put around such an agent in your own project, and there I recognised something from my own trade in every lesson.

What the agent can't see doesn't exist

That is how the course phrases its first principle, and it's an uncomfortable sentence to apply to yourself. Everything the agent needs to know has to be in the repository: the product goal, who it's for, which decisions we made and what we deliberately leave alone. For my own products, a fair share of that isn't written down anywhere. It lives in my head, in a Slack thread or in a conversation over coffee. For people that often still works reasonably well, for the colleague without coffee it simply doesn't exist.

You see the same thing in the feature list the course uses: a list of small pieces of work, each with a status, from which the agent always picks up the next unfinished item. That is simply a Product Backlog a machine can read. The agent takes the order literally, so whoever orders the backlog directly steers what gets built.

Done is only done when you can show it

Verification is strict in the course: the agent may only say something is finished when the tests pass. That only works if the acceptance criteria are testable, and that is where it often goes wrong. An agent can't check "it has to be user-friendly", so it just ticks the box. A concrete example of what the user does and what should happen next is something it can check. In that sense an acceptance criterion is user experience too, only now for an agent.

The other rules are old acquaintances too. One feature at a time, with a Definition of Done that actually matters. A log at the end of every session with what's done, what's still unproven and where the next session should pick up. An agent that takes on too much at once does exactly what teams do when they take on too much at once: start everything and finish little. It just does it faster.

What struck me most is how little of this is new. A team of people absorbs vague stories by walking over and asking. An agent doesn't, and that makes visible what we as Product Owners left lying around because the team would sort it out anyway. Perhaps a good harness is mostly the work we should have been doing all along.

And yet the coffee still matters

There is one thing I miss in the course. A harness makes sure the agent reliably builds what we ask for. Whether we are asking for the right thing, it says nothing about. The better the harness, the faster you can also deliver the wrong product.

As building gets cheaper and faster, the difficulty increasingly lies in knowing what is worth building. That makes discovery more important, and you won't get it out of a repository. We make products for people, and ideally together with people. So talking and listening, with users, with customers and with the team, remain at least as important as a well-written feature list.

Write it down for the colleague who doesn't drink coffee, and keep drinking coffee yourself with the people you are making it for.

Which decision about your product currently exists only at the coffee machine?