Why AI Won't Steal Your Coding Job

The dominant narrative right now is that AI is coming for your coding job. Tools like Replit can spin up entire apps from a prompt. LLMs can pass interview questions that used to be the gatekeeping screen for a six-figure salary. The conclusion, breathlessly repeated, is that software engineering — as a career — has months, maybe a couple of years, before the wheels come off.

I think that take is wrong. Not "AI is fine, relax" wrong. Wrong in a more specific way: it conflates two jobs that engineers do, and only one of them is in the firing line.

I've been reading Daniel Priestley's Key Person of Influence lately, and he draws a distinction I've been chewing on. He splits people into two camps: the functional and the vital. Functional people execute. They turn up to the meeting, ask sensible clarifying questions, take the plan that's been laid out, and ship the work competently. Diligent, reliable, valuable — and almost entirely downstream of someone else's thinking. Vital people are the ones generating the thinking. They're the ones in the meeting asking why we're doing this at all, whether the goal is the right goal, whether the assumption everyone has been quietly nodding along to actually holds up.

If you've worked in software for any length of time, you've met both. Most teams need both. But these are two very different jobs, and AI affects them very differently.

Functional output is the easy half

The functional half of engineering is exactly what current AI is best at. A clear specification, well-understood patterns, a defined set of inputs and outputs — that's the bullseye for an LLM. If your contribution to a team is "give me a ticket and I'll implement it cleanly," then yes, the writing is on the wall. Not tomorrow, not necessarily next year, but the trajectory is unambiguous. The functional output of an engineer — the actual code that comes out the other side of a well-scoped problem — is becoming a commodity at a speed I don't think the industry has fully absorbed.

This is the half of the job that the panic narrative is correct about. If your value to your team collapses to functional output, you should be worried. Not because AI is going to walk in tomorrow and fire you, but because the market rate for that work is already starting to bend, and the bend will continue.

Vital work is the hard half — harder than people think

Here's the bit the discourse glosses over. The vital half of engineering — deciding what to build, deciding whether to build it at all, noticing the load-bearing assumption nobody questioned, choosing between three plausible architectures based on which one fits a business reality the spec doesn't mention — that work is genuinely difficult to automate, and I think it's more difficult than the current AI conversation acknowledges.

Replit is the cleanest example. It's an extraordinary tool. You type "build me an app that does X, Y and Z" and it goes away and builds something startlingly close to what you asked for. But the magic in that sentence isn't the building. The magic is the X, Y and Z. The prompt is the product. The person who knows what to ask for is the person who captures the value. The tool collapses the cost of implementation toward zero and, by doing so, makes the upstream judgment — what's worth implementing — more valuable, not less.

Daniel Priestley uses an analogy I like. Before the microphone was invented, a singer could perform for a room. After the microphone, the same singer could perform for a stadium. The microphone didn't replace singers; it magnified them. Great singers got more reach. Terrible singers got more reach too, and a lot more people found out they were terrible. AI is the microphone. It magnifies what you bring to the table. If what you bring is sharp judgment about what to build and why, the amplification is in your favour. If what you bring is the ability to faithfully implement someone else's plan, the amplification is somebody else's leverage over you.

The reason vital work is harder to automate than people think is that it doesn't sit inside a prompt. It sits in the messy stuff around the prompt — the conversations with users, the half-articulated business constraints, the institutional history of why the last attempt failed, the political read on which stakeholder will block the change you're about to ship. None of that is in the codebase. None of it is in the ticket. An LLM can write the code, but it cannot, today, be the person in the room who notices that the entire premise of the ticket is wrong. Maybe one day. Not yet, and not soon.

The lesson

If your career runway depends on functional output, the panic narrative isn't wrong, it's just early. Start adjusting. The skill to lean into isn't "prompt engineering" in the LinkedIn-influencer sense. It's the older, harder skill of asking the awkward question in the meeting — what are we actually trying to achieve, is this the right goal, what happens if we don't build this at all. That muscle is trainable. Most engineers who consider themselves "purely technical" have just never been given air cover to use it.

If you already lean vital — the kind of engineer who irritates product managers by questioning the brief — then AI is genuinely good news for you. It strips out the part of the job that was taxing your time without using your judgment, and it lets you operate at a scope that used to require a whole team behind you.

I'm not particularly worried about my own coding job. Not because I think AI won't change anything — it's already changed how I work, daily — but because the part of the role I actually get paid for has never been the typing. The typing was the bottleneck. AI is removing the bottleneck. The job underneath was always the harder one.

The engineers who'll struggle are the ones who built a career on being the bottleneck.