The hour before the code

We are mesmerised right now, all of us. Watch someone using tools like Claude Code, or any of the coding agents doing the rounds, and it looks like a magic trick: a description goes in, a working application comes out, and the temptation is to stare at the output and marvel at the tool. I do this too. Lately I’ve built things this way that I would once have needed a developer, or a great deal of patience, to build. It is genuinely astonishing to watch.

I noticed something recently that made me want to write this down before the behaviour is normalised and I stop noticing it at all.

Switching on “autonomous mode”

I recently built a web app in VS using Claude Code and, for the first time, switched on the “auto” mode, where the tool can make its own decisions and run, rather than approving every step. If you have run in “manual” mode before, you know that you have to sit there just to approve notifications so that it keeps working! Whilst “auto” mode removes that inconvenience, it felt a bit frightening as now you are handing over control to the tool. However, this changed how I collaborated with it, before I ever reached for the toggle.

I spent about an hour planning before I let it build anything. Not coding but making the ingredients available, writing the sequencing, defining the flow from screen to screen and any relevant transition logic, how to save the data and what not to save for confidentiality purposes. Only once all of this was thought through and documented, I let it build. Once version 1 is done, the iterative process of review and feedback starts.

Plan, build, review

That’s really the shape of it, once I stopped to look at it properly. Planning is the brief, being as thorough as I could be, every ingredient named before a line of code exists. Build is the handoff: the tool takes that brief and does what it’s good at, fast, without needing me to specify how. Review is back to me, looking at what it produced and deciding what happens next, which can be a small tweak or, sometimes, close to a full rebuild.

I don’t experience the rebuild as failure, and I think that’s because it’s a shape I already recognise from the many trial and error loops I have been through. At work for example, when someone asks me for functionality on a system they don’t fully understand, we explore options together, in that exploration I am assessing if this is only internal development, the complexity of it, if external assistance is needed which normally means longer timelines and budget.

Writing a brief for an AI coding tool is the same. I don’t know all the implications of what I’m asking for until I ask for it. Running autonomously has meant fielding decisions I hadn’t planned for, such as my antivirus software blocking an install the tool wants to make, and me having to decide, on the spot, whether that’s necessary or not. Sometimes I approve it and other times I decline it, if I see that unnecessary complexity is being built. I think that’s less about caution than about keeping tabs and setting boundaries. A solution I land on in one project informs which avenues I block in another, becoming part of transferable instructions, before the tool even suggests them.

None of that is the tool getting smarter. It’s me directing more precisely, project over project. If anything, autonomy has raised the bar on judgement rather than lowered it: critical thinking and discernment turn out to be the most essential skills I bring in.

You don’t thank Excel

In discussion with my supervisor about this: auto mode, the hour of planning, the ingredients, letting it build and then evaluating what came back. He stopped me partway through and said: “This is what goes in your dissertation: your process. Not what the tool did. You don’t thank Excel when it calculates something for you.”

That made it crystal clear that my role is more about directing. Nobody credits Excel for a financial model, they ask the analyst what assumptions went into it and why. The calculation is the easy part; the judgement about what to calculate, and what it needs to mean, is the whole of the work. AI coding tools are no different, except that because it produces something that looks like independent judgement, it’s easy to forget the same rule applies. The interesting question was never what the tool built, it was what I decided before handed it over the brief, and why I decided it that way. Having made that distinction clear, now we can take our respective roles. If we slack on the brief sometimes the output is what is called “AI slop code”, which I have seen and normally prompts a “what are you doing?” to the tool.

Not the solution, part of solving it

The answer is not to be less impressed by what these tools can do: I still am, genuinely. But a tool isn’t the solution to a problem. It’s something that can help you in solving it, and only as well as the thinking you bring to it first. The hour before the code isn’t overhead standing between me and the real work. It is the real work. Everything after that is just execution, however impressive the execution looks.

We are mesmerised by what these tools can do. I’d rather stay mesmerised by how our roles shift to adapt to these technologies.