What the humans actually do all day

A friend asked me over dinner a few weeks ago what I actually do now. He asked it carefully, the way you ask about a job you suspect is going away.

It’s a fair question. The four previous posts in this series describe a system that writes code, reviews it, validates it in a browser, and promotes it to production while I’m asleep. If that’s all true, and it is, then the obvious follow-up is what’s left for me.

More than I expected. Just not the parts I would have guessed.

Deciding where the seams go

The most valuable hour of my day is the one where I turn something vague into tickets.

This sounds like project management and it isn’t. It’s the design work of choosing boundaries: what’s one change, what’s three, what has to land first, where the interface between two pieces should sit so they can be built independently. Get those cuts right and work flows through the pipeline with almost no friction. Get them wrong and no amount of capable agent rescues it.

I’ve already written about the internationalization ticket that wasn’t a ticket. The more useful example is one we got right. Importing bank documents is a single sentence to a user and seven tickets to us, and their order was the whole game: the shared contract that every parser returns had to exist before any parser did. That meant the first ticket shipped nothing a user could see, and the four that followed could be built in any order without touching each other.

Choosing that sequence took an afternoon and saved a week of rework. It also isn’t a judgment anything in the repository could have made, because it depends on which formats we intend to support next year, which is a fact about our plans, not our code.

Saying no

No agent has ever told me a feature shouldn’t exist.

They’ll tell me an approach is risky, that a schema is wrong, that a plan has a gap. Ask for a feature and you get the feature, competently and with tests. The judgment that a thing is a bad idea, or right but not now, or a symptom of a design problem that a different change would dissolve, has stayed entirely on my side of the line. So has taste. We spent a while last month making our alerts quieter with thinner rules, less colour, and fewer boxes. Not one line of that was a correctness problem. The old version worked. It just shouted.

I think this is durable, and not because of some limit on what models can do. It’s that these questions have no answer derivable from the repository. They depend on who our users are and what I’m willing to maintain for the next five years.

The tickets that sit

The most instructive part of my week is the small pile of tickets the pipeline refuses to build.

They come back, batch after batch, escalated rather than attempted. When I read them, the agents are right every time: each one is blocked on a product decision nobody has made.

The one that’s sat longest is a loan statement that shows a payment without saying which account paid it. We could invent the matching transfer, which makes the books balance and might be a lie. We could leave the payment sitting there unattached, which is honest and looks broken. We could go looking for a transaction that seems to match and link it, which is usually right and occasionally very wrong. All three are defensible. None of them is in the codebase.

An agent that guessed at those would produce working code implementing an unexamined choice. That is the most expensive kind of output because it looks finished and quietly commits you to a decision nobody made deliberately. Sitting there is the correct behavior. But those tickets don’t unblock themselves, and a pipeline that can build anything is worth very little if the queue is full of work waiting on a decision only I can make. Some weeks the bottleneck is entirely me.

The second thing the pile teaches is patterns. One ticket bounced three times isn’t a ticket problem. It’s usually my scoping problem, and the fix is upstream in how I wrote it.

Go, no-go, and reading the room

Before anything reaches production I decide whether it goes. Most days that’s quick, because the gates have already done the work and I’m reading a summary. Some days it isn’t quick at all: a change that passed every gate and that I’ve gone off, or a release that’s technically fine and badly timed. That call has never felt automatable to me, and I notice I don’t want it to be. Someone should be accountable for what our users receive, in a way that a check run can’t be.

What actually changed

My commit count went to roughly zero. My open-tab count did not.

I write much less code and read much more. The typing is gone. The deciding is heavier and there’s more of it per hour, because the machinery downstream is fast enough that my decisions are now the rate limit. I’ve also had to get far more explicit about what I want. A vague brief no longer produces a stalled afternoon. It produces a great deal of confidently wrong work, delivered on time.

The uncomfortable part is that it’s exposed how much of my old day was displacement activity. Writing the obvious version of a function I’d already designed felt like work. It was typing. Removing it left a schedule with fewer places to hide, filled with the parts of the job that are actually hard.

About this series

These five posts were scoped as tickets, drafted with an assistant against a written standard for what our writing should sound like, and shipped through the same pipeline as our product code. A separate reviewing pass went hunting for the tells of machine-written prose and came back with a long list, including a number I’d have defended.

What the series should say, which stories were worth telling, and where it was being too pleased with itself: that part was mine. Same division as everywhere else here.

If you’ve read this far and want to argue with any of it, I’d genuinely like that.