I still write the code

Claude Code or Codex writes ninety-five to ninety-eight percent of what ships from me now. I review it, or I hand review to CodeRabbit or to Claude Code itself. What has not moved is the core decision-making. Architecture, tradeoffs, what we are actually building and why. I expected to enjoy the job less once I was not typing most of the characters. I do not.

The conventional view is that a CTO should not be coding, and in normal times I would agree with it. These are not normal times for this particular question. There is a paradigm shift happening in how engineering gets done, and almost every CTO was a developer at some point. Without getting back in the saddle you cannot make correct decisions about how to restructure your organisation to take advantage of it.

For decades everyone sat in an IDE, wrote code, and shipped it to a compiler. The workflow barely changed for years. That changed in roughly the last two or three. You cannot keep managing people who rode horses the same way now that they are driving cars. Get behind the wheel yourself. Understand how the car drives, what is going to be hard for people who spent fifteen years on horseback, and what is genuinely different rather than just faster.

Here is the concrete thing that came out of it, and it is the reason I am writing this rather than a defence of coding for fun.

Our writing culture was the standard one. Write a PRD, write a technical design doc, assign it to an engineer, engineer writes the code. Those documents lived where product documents live, which is to say in a wiki somewhere.

I moved PRDs and technical design docs into the repository as markdown files. Not for tidiness. Because the coding agent can only read what is in the repo, and with the documents in there it makes materially better decisions about what to build.

Then the same insight one step further: an external memory file, also in the repo, recording key decisions, architectural changes and the reasoning behind them. So context survives across sessions, across machines, and across engineers.

That is the point. The location of your documentation became an engineering decision the moment agents became a primary reader of it. I would not have understood that this needed doing if I had never jumped into the code. And I am fairly confident my engineers would not have raised it upward either, because from inside the work it looks like a filing preference rather than a decision about system inputs.

None of this is an argument that executives should code for the joy of it. It is narrower and I think harder to dismiss. This particular shift changes where information has to live in order to be useful, and you cannot see that from a status report.

“You cannot keep managing people who rode horses the same way now that they are driving cars.”