Engineer vs AI | It won't replace you, the throughput will

For a couple of years I gave guest lessons at a college and later at a university, and the topic was always some version of the same question: will AI replace us? Students asked it the way you ask about weather — something that happens to you, that you have no part in.

I had a comfortable answer. Models don’t understand systems, they don’t hold context across a codebase, they can’t tell you why a decision was made two years ago. All still true, more or less. What I got wrong wasn’t the answer. It was the question.

I didn’t want to use Cursor

At the company I was at then, we adopted Cursor. I didn’t like it.

Not for any principled reason I could defend in a design review. I liked writing code. I had spent years getting to the point where I could hold a NestJS module in my head and type out the whole thing — the service, the DTOs, the tests — without stopping to think about the mechanics. That’s a real skill and it took a long time to build.

And now the editor was finishing my sentences. Usually correctly, which was somehow worse.

I kept the tab-complete off for weeks. I told myself it was about code quality. Honestly it was about the feeling: I’d sit down to a task I knew how to do, and there was no sitting down to it anymore. The part I enjoyed had been compressed into accepting or rejecting someone else’s guess.

That’s the strange feeling I want to name properly, because I don’t think it gets said out loud much. It wasn’t fear of being replaced. It was that the work stopped being fun. No excitement anymore. The craft part — the bit where you’re actually making the thing — got thin.

What actually changed

Here’s what took me too long to see.

While I was deciding whether I liked this, the expectations moved. Not dramatically, not in a memo. Estimates got tighter. The scope that fit in a sprint grew. Nobody announced a new baseline; it just became normal that a feature which used to take a week takes two or three days now.

And the client doesn’t care how the two or three days happen. Nobody outside the team has ever cared about that. They care that the amount of work they need done gets done, and that someone else isn’t offering to do it faster.

So the sentence I’d been saying in lectures — AI won’t replace you — turned out to be true and useless at the same time. No model was going to take my job. But an engineer shipping at the new baseline would, eventually, and it wouldn’t feel like a dramatic event. It would feel like being slightly slower than everyone else for long enough that it got noticed.

That’s the whole thing. It isn’t AI versus engineers. It’s engineers who use it versus engineers who don’t, competing for the same finite amount of work, and only one group is being measured against the old baseline.

The part where I was right

I want to be careful here, because “just use AI” is the take of someone selling something, and that’s not what I’m arguing.

The resistance had real content in it. When I did start using Cursor properly, everything I’d been worried about showed up:

• It writes code that looks like the codebase but violates invariants the codebase’s shape doesn’t encode. Transaction boundaries, mostly. Locking. The things that only break under load.
• It’s confident in exactly the same tone whether it’s right or wrong, which is a genuinely new problem in review. A colleague who is unsure sounds unsure.
• If you accept enough of it without reading, you end up maintaining a codebase you didn’t write and don’t understand. That bill arrives later, but it arrives.

None of that is a reason not to use the tool. It’s a description of where the work went. I write less code now and I specify and review much more, and the reviewing is harder than the writing ever was — because the failure modes are subtle and the volume is high and nothing announces itself as wrong.

The skill didn’t get deleted. It moved. Knowing that a distributed lock needs fencing is worth more now than it was when I had to type the implementation myself, because typing it is no longer the scarce part. Knowing it’s needed is.

What that adds up to, in practice, is that the job drifted toward architecture. Not the job title — the actual daily work. Most of my day is now deciding what should exist, where the boundaries go, which invariants must hold, and then checking the output against that picture and steering it back when it drifts. The model will happily produce a service that works and sits in the wrong layer, or a query that returns the right rows and holds a transaction open across a network call. You only catch that if you’re holding the system in your head — which means the thing that used to be the senior half of the job is now most of the job, and it starts much earlier in a career than it used to. That’s a real problem for how people learn this work, and I don’t have a good answer to it.

What I tell students now

I changed the lecture.

The question “will AI replace me” puts you in the passenger seat, and the honest answer to it — probably not directly — is comforting in a way that’s actively bad for you. It lets you not decide anything.

The better question is: what is the market rate of output for my role, and where am I against it? That one has an actual answer, and things you can do about it.

The other half I tell them is the part I got wrong personally: the discomfort is real and you should not talk yourself out of it. Something did get lost. I used to enjoy the long uninterrupted stretch of building a thing by hand, and I get less of that now, and calling it nostalgia doesn’t make it untrue. But “I liked the old way” and “the old way is still viable” are two different claims, and I was quietly treating the first as evidence for the second for about six months.

They’re not the same. That’s the whole lesson, and it cost me a year of being annoyed at an editor.

So

Use it. Not because it’s magic — it isn’t, and half my job now is catching what it gets wrong. Use it because the amount of work expected from one engineer has already changed, whether or not you agreed to it.

And don’t be afraid of it. This is the shape of the work now — it isn’t a phase we’re going to come out the other side of, and it’s not going back to what it was. That’s worth saying plainly, because a lot of the anxiety around this is really the hope that it’s temporary.

The framing that finally made it sit right for me: treat it as an intern who writes most of the code instead of you. A fast one, well-read, no ego, and no judgement whatsoever about what matters. You don’t hand an intern the architecture and you don’t merge their work unread — but you also don’t insist on typing everything yourself to prove a point. You give them the well-specified pieces, you check what comes back, and you keep the decisions that are expensive to get wrong.

That’s the job. See the whole picture, own the big calls, verify everything below them.

And keep the part you like. I still write the hard things by hand — the concurrency, the parts where being wrong is expensive. Not out of principle. Because that’s where I’m actually better, and because if none of it is fun anymore you won’t be good at it for very long either.