The skills that didn't go anywhere

A while back I wrote about AI anxiety, and I ended it with a line I still believe: your value isn't in writing every line of code, it's in knowing which lines should exist at all.

It's the kind of thing that's easy to agree with but much harder to actually feel on a Tuesday afternoon, when you've spent the day describing problems and reading diffs and you're not sure you've built anything. So this is the follow-up. What does that value actually look like when the code isn't coming from you?

The first thing I noticed is how much of the work is actually deciding what the problem is.

An agent will solve the problem you give it, which sounds obvious until you've handed over a badly framed one and got back exactly what you asked for. A user reports that the export is missing rows. That could be "the export is missing rows", or "we paginate over a result set that's being written to while we iterate", or "this shouldn't be synchronous at all". Three completely different pieces of code. Only one of them is right, probably.

I've done this to myself more than once. The output is fine. The problem was wrong.

That skill hasn't gone anywhere. If anything it's been concentrated, because it used to be spread thinly across a day of typing and now it's most of what I do.

The second thing is context, and this is the one I think gets undersold.

An agent can read the entire codebase and come away with a genuinely accurate description of what the code does. But what the code does is only a snapshot. You're the one who lives in the thing. You know the payments module looks over-engineered because of an incident two years ago. You know the class marked deprecated is still load-bearing for one customer. You know the abstraction everyone hates is getting deleted next month, so there's no point extending it.

None of that is in the repository, and the parts that are written down somewhere are usually out of date.

And it keeps moving. The codebase is a fixed input, but everything around it changes weekly. Priorities shift, a customer churns, someone makes a decision in Slack that quietly invalidates the plan from a fortnight ago. You're carrying a model of the system that updates continuously, and the agent starts every session with none of it.

So you're not just handing over a problem. You're handing over the conditions that make one solution correct and another one technically fine but wrong for you.

Then there's reviewing the code, which is the part I was least surprised to find I was already good at.

You've been reading other people's diffs for years. You know what it feels like to read something that works but is wrong. Wrong shape, wrong place, wrong name, an abstraction one layer too deep, three lines where none were needed. That instinct doesn't and shouldn't care who (or what) wrote the code.

The mistake is treating agent output differently to a colleague's PR. Someone will review it after you, but they don't know what you asked for or what you ruled out, so if you skim it you've quietly made it their problem.

Which is really the frame that made all of this click for me. Treat the agent like a colleague whose code you're reviewing. Not a tool, not an oracle. A capable colleague who is fast, knows the language better than you do, has no idea about the meeting you had last week, and will never once tell you they're unsure.

That tells you how to brief. You wouldn't drop "fix the export bug" somebody who started last week and walk away, you'd give them some context and point them in the right direction. Most of the disappointing output I've had from an agent turned out to be a disappointing prompt.

And it tells you how to review. You'd request changes on a PR that works but is wrong, so request changes. There's no ego to bruise, which makes it the easiest review relationship you'll ever have. You can reject the same thing four times in a row at no social cost.

The one place the analogy breaks is that a colleague learns. Tell them once about a convention and they carry it forward. The agent doesn't really do that, so anything you'd say once to a person has to live somewhere permanent instead: guidelines, docs, skills, the shape of the codebase itself. That's a real cost, and it's also just documentation, which we've all agreed is a good idea at some point and mostly didn't do.

I won't pretend I've got all of this figured out. I still don't know whether I'll understand these systems as well in five years, having read my way through them rather than typed my way through them. Ask me again then.

But framing the problem, holding the context, knowing when something is wrong despite being correct. Those were always the expensive parts of software engineering. They were just buried under a lot of typing.