I was out walking with my dog Dexter, daydreaming on the first properly warm day of the year. I was lost in my own mind mulling over a conversation I'd had with a fellow Game Developer about how we've adapted to the use of AI as software engineers. None of the existing labels fit. "Vibe coding", Karpathy's term, elicits a culture of care-free one-shotting with little to no regard for the code quality, just keep prompting until it runs. "Agentic engineering" has also drifted toward a fire-and-forget autonomy, where you describe a goal, the agent disappears for an hour, and returns with a pull request you merge in the quiet hope that nobody asks you about it later. Neither description fit the experiences that my colleague and I were having.
What we do is closer to editing, so to my mind the term editorial engineering seems a more appropriate fit, and here's why.
Firstly, it's worth being clear about which kind of editing I mean. Not text editing, not the typing itself. Editorial editing, the kind a magazine or book editor does. Commissioning work, reading it, sending it back for revision, holding it to a standard, putting your name on the thing that finally ships.
In practice that means I provide a detailed spec, or I talk through a problem until a spec emerges. I let the agent write code when the stakes allow it, when the implementation is well-trodden, or when I just want a first draft to react to. Then I read what it wrote. I push back. I ask why a particular approach was taken. I request refactors when something offends my taste or violates the standards a piece of code needs to meet. The bar for an internal tool and the bar for client-facing production code are not the same, and the agent doesn't intuit which one we're operating under unless I tell it.
Editing is real work
There's a sleight of hand in a lot of the AI discourse where delegation gets treated as savings. The thinking goes, the agent writes the code, so you save the time it would have taken to write it. That framing misses what editors actually do, and it misses why editorial roles in publishing have existed for centuries despite the writers being perfectly capable of typing.
A good editor reads carefully. They notice what isn't there as much as what is. They push back on structure, on pacing, on the choice of one word over another. They hold the writer to the standards of the publication. A tabloid editor and a literary editor both edit, but to wildly different ends. And they are answerable for what gets published. If something ships that shouldn't have, the editor's name is on it as much as the writer's.
Editorial engineering inherits all of that. Reading the code carefully. Noticing what isn't there. Pushing back on structure, on naming, on the choice of one pattern over another. Holding the agent's output to the standards of the project, and those standards genuinely vary. A personal prototype, a client production system, a public open-source package, and an internal tool all have different bars, and part of the editorial job is knowing which bar applies and enforcing it. And then answerability. The agent isn't going to defend its choices in a code review or a post-mortem. I am.
The cost of this work is real, even when, like me, you are doing it on a phone whilst walking the tow-paths of the Macclesfield canal.
Reading unfamiliar code is expensive
This is the part that gets glossed over in most of the productivity claims. Reading unfamiliar code is genuinely cognitively expensive, and most developers have organised their careers around avoiding it.
Ask any experienced developer about the worst projects they've worked on, and a large fraction will name the same kind of thing. Inheriting another dev's half-finished prototype. Picking up a codebase from a contractor who shipped and disappeared. A "small fix" on a system whose internal logic appears to have been copy and pasted from an ancient Stack Overflow post (remember Stack Overflow? it's seems crazy to ask). We hate this work because reading code written by someone whose taste, standards, and assumptions don't match your own is brutal. You aren't parsing syntax, you're reverse-engineering a mental model from the depths of another developers mind, and you then have to decide whether to adopt it, fight it, or quietly rewrite it. I'll happily charge a client more to turn a previous developer's spaghetti into a masterful bolognaise. The markup is honest because the cleanup is harder than writing every line from scratch.
Editorial engineering shares the shape of all this. Every agent draft is code I didn't write, in a style averaged out of an entire training corpus, with idioms and structural choices that may or may not match how I'd have done it. The cost of reading and judging it is real, and it doesn't disappear just because the agent produced it in thirty seconds. If anything, the speed of generation makes it worse, because the volume of code I'm being asked to evaluate goes up.
So no, this isn't less work than writing the code yourself. It is differently distributed work, and in some respects it's harder.
Where the leverage actually comes from
If editorial engineering isn't less work per task, the gain has to come from somewhere else, and it does. It comes from parallelisation.
When I'm writing code myself I'm locked into one problem for the duration. One model of one system in working memory. The agent breaks that constraint. While one agent grinds on a Unity addressables refactor, another can be drafting middleware for a Next.js auth gate, and a third can be working through a spec for a multiplayer render-streaming architecture. The implementation work parallelises. The editorial work doesn't.
This compounds on a skill professional software engineers already have, because the industry almost never lets us focus on a single thing. The myth of the engineer in the focus cave with their headphones on, building one thing for eight uninterrupted hours, is mostly a myth. What we actually do, and have always done, is context switch. We pick up a problem, load its model into working memory, make progress, drop it, load another, repeat. The good engineers aren't the ones who avoid context switching. They're the ones whose re-entry cost is low. The ones who can pick up a half-finished thread and be productive on it within minutes. Who keep their projects in a state where coming back is cheap. Who write notes, specs, and commit messages that future-them can rejoin without reconstructing the whole picture from scratch.
That's the actual shift. Not "the AI does the work." The AI does the typing. The human does the editing, and the editing happens across the breadth of a project or portfolio of projects rather than a single task.
What gets left behind
There are losses worth naming. I'll never again get to feel like I'm living through a hacking montage. Hood up, energy drinks within reach, cherry-browns clacking at pace, the screen full of code I'm pulling out of my own head in real time. That experience was a particular kind of joy, and editorial engineering doesn't include it. The agent does the typing, and the typing was part of the fun.
There's a quieter loss too. I have a mental lexicon of syntax built up over a decade or so of writing code, the kind of fluency where you reach for a pattern and your fingers already know the shape of it. Most of that lexicon is now going to lie dormant. The patterns are still in my head, the muscle memory is still in my hands, but the agent gets there first and I'm reading rather than writing. Use it or lose it applies to programming languages the same as anything else, and I suspect a few years from now the fluency will be thinner than it is today.
Lending your name
Whether any of this is still something to be proud of is a question I'd rather not duck. A clearly sheltered colleague of mine once told me I was one of the best engineers he knew and that compliment landed and stuck with me, the kind of thing you quietly carry around as part of how you think about yourself. Nowadays most of the keystrokes are an agent's, so what does that compliment refer to anymore?
The editor analogy gets me through this question. A book editor's name goes on the masthead even though they didn't write a word of the text. They commissioned it, shaped it, pushed back, held it to a standard, signed off on it. The book that ships is a product of their judgement as much as the writer's. Nobody seriously asks whether the editor is allowed to be proud of the books they've shepherded into print.
Editorial engineering is the same shape. The agent typed the code. I commissioned it, shaped it, pushed back, held it to a standard, signed off. What changes is what the pride is in. Not "I wrote every line." Something more like "I made every meaningful call about what got kept, and the thing that ships is good because of those calls." That's still worth being proud of. It's just a different thing to be proud of.
So that's the term I'll be using. Editorial engineering. Not because the agent does the work, but because I do. And the work is editing.
Postscript
This article took shape across that walk, ten kilometres of trails in two and a half hours. The article was drafted and redrafted with an agent on my phone as we went. The freedoms were real. I wasn't at my desk, the sun was out, Dexter was happy, I covered ground I wouldn't have covered today otherwise.
The cost was also real, and it wasn't quite the one I'd have predicted. Editorial engineering doesn't just give you time back, it raises the production expectation to match. Having left the desk, I felt the pull to use the time, so I did. Some part of my attention stayed with the prose taking shape on the screen rather than the trail under my feet. Distance dog walking, properly enjoyed, asks for full presence. I gave it about three quarters. Dexter had a better walk than the editor did. Both halves are the point.
Top comments (0)