2 min readaiengineeringworkflow

I don't write the code anymore. I write the brief.

Somewhere in October I noticed I hadn’t typed a function in weeks. Not because I was slacking. I was shipping more than I had in years. I just wasn’t the one typing.

Here is the setup, and it is embarrassingly simple. One expensive model sits with me and plans. It reads the repo, argues with me about the approach, and writes a brief. A cheaper, faster model takes that brief and does the work: writes the code, runs the build, fixes what breaks. Then the expensive one reviews the result and tells me what to look at. I look. I merge or I don’t.

I put this rule in my config file because I kept forgetting it. Left to its own devices the expensive model wants to do everything itself, and it is very good at it, and it costs about five times as much per line. So the rule reads, more or less: you plan, you review, you do not type.1

What surprised me is where the difficulty moved. It used to live in the function. Getting the edge case right, remembering the API, naming the thing. Now it lives in the paragraph that describes the function. A vague brief comes back as confident, well-tested, wrong code. A sharp brief comes back done. The whole job has become: can I say exactly what I want, in a way that survives being read by something that will not ask follow-up questions?

That is not a new skill. It is the skill I was supposed to have as a senior engineer and mostly faked. Writing the ticket properly. Stating what “done” means before starting. Saying which files are in scope and which are not. I used to skip all of that because I was going to write the code myself anyway, so why explain it to anyone. Now there is someone to explain it to, and they are literal, and they are fast, and they are cheap enough that I can afford to get it wrong twice.

I don’t miss typing the code. I thought I would. I liked the feeling of a tidy function coming together under my hands, and some evenings I still open a file and write one by hand just to check I can.2 But the thing I actually cared about, it turns out, was never the typing. It was knowing the system well enough to say what it should do next. That part got harder and more interesting, not less.

It feels a bit like becoming the manager I never wanted to be, except the team doesn’t mind being told exactly what to do, and nobody needs a one-to-one.

Footnotes

  1. The actual wording is longer and slightly grumpier, because I wrote it after the third time I caught the expensive model happily rewriting a build script. ↩

  2. I can. It’s slower than I remember. ↩

← All posts