Post

You're Not Being Replaced. You're Being Promoted to Editor

Alex Garrett-SmithSep 244 min read
You're Not Being Replaced. You're Being Promoted to Editor

What's actually changed

A couple of years ago, an AI assistant could autocomplete a line or write a function if you asked nicely. Now agents take a feature from a description to a working branch. They plan, write the code, run the tests and fix their own mistakes along the way.

So the writing part of the job is increasingly handled, and research into how developers actually use these agents points the same way: less time writing, more time directing and reviewing what comes back. But here's the thing I keep coming back to: the typing was never the valuable part.

Think about the last proper feature you shipped. How much of that time was spent physically writing code, and how much was spent working out what to build, how it should fit into the codebase, and whether what you had was actually correct? For me, the writing was always the smallest slice.

The editor job

An editor at a publication doesn't write most of the words, but nothing goes out without them. They commission the piece, set the angle, push back on weak arguments, and take responsibility for what gets published. That's a surprisingly accurate description of my day now.

I write the brief: what we're building, the constraints, and what done looks like. I review what comes back, and the earlier I catch a wrong turn, the cheaper it is to fix. And before anything ships, I check it actually works rather than taking the agent's word for it.

None of this is new, by the way. It's what senior engineers have always done with their teams. The difference is that now everyone gets a team.

The skills that are worth more now

Knowing what good looks like

An agent will happily produce code that works but is wrong for your project: the wrong abstraction, a pattern you moved away from a year ago, a dependency you didn't want. If you can't tell the difference between code that works and code that's right, you won't spot when the agent picks the wrong option. That judgement is now the most valuable thing you bring.

Reading code quickly

You'll read far more code than you write from now on, so being able to review a diff properly without glazing over is a real skill. And it matters, because if you approve everything without really reading it, you're not reviewing at all. You're just passing problems along to production.

Debugging and verifying

The agent tells you the feature works and the tests pass. Your job is knowing whether that's true. Being the person who runs the thing, reads the test to check it asserts something meaningful, and asks "what happens when this list is empty?" is worth more than ever.

Explaining what you want

A vague brief gets you a feature that's almost right, and you'll spend as long steering it back as you would've spent describing it properly up front. Writing down what you want clearly enough that someone else could build it has always been a skill, but it's no longer optional.

The skills that are worth less

This is the part that stings a little. A lot of what we've traditionally valued (and interviewed for) is exactly what agents are best at: memorising syntax and APIs, churning out boilerplate quickly, and knowing every option of a framework off by heart.

That knowledge isn't useless. It still helps you review faster and spot when something's off. But it's worth letting go of the idea that being quick at writing code is what makes you a good developer, because it isn't any more.

If you're just starting out

The awkward question: if agents write the code, should you still learn to? Yes, and I mean properly. You can't review what you couldn't have written yourself. An editor who's never written can't tell good writing from bad, and a developer who can't code can't tell working code from code that just looks plausible.

What I'd change is how you learn. Build things by hand, absolutely. But also spend real time reading agent output critically: ask why it chose that approach, whether you'd have done it differently, and what you'd send back if a colleague opened that pull request. Reviewing is a core skill now, so practise it as deliberately as you practise writing.

You weren't hired to type

If your value was measured in lines of code, this shift would be scary. But it never was. You were always paid for judgement: knowing what to build, what good looks like, and whether the thing in front of you is right. Agents haven't touched any of that. They've freed you up to spend more of your day on it.

So no, I don't think you're being replaced. I think you're being handed a team, and asked to edit.