Your Job Was Never Writing Code: It's Translating Intent Into Value

If your job was writing code, AI just took it.

That sentence has been running through engineering org charts for three years now. It's the wrong sentence. The right one is harder to swallow: writing code was never your job. Translating ambiguous business intent into something that adds value to users — that was your job. Code was the byproduct. The byproduct just got commoditized. The job didn't.

This is uncomfortable because the entire industry has spent thirty years measuring engineers by the byproduct. Lines per day. PRs per week. Story points per sprint. Hours at the keyboard. The metrics are about the typing. The interviews test the typing. The job descriptions list the typing. We built an identity around the typing and now the typing is cheap.

The translation, though — the translation is more valuable than it has ever been.

The Misread

Here is what we collectively misread. We watched engineers spend forty hours a week converting business problems into working software, and we labelled the activity by what we could see: characters appearing in an editor. We measured what was easy to count. We hired and promoted against what we measured. After enough cycles, an entire profession defined itself by the artifact rather than the activity that produced it.

The artifact is code. The activity is translation.

Translation is the unglamorous work of taking a sentence like "users should be able to upgrade their plan" and turning it into a hundred concrete decisions: what counts as an upgrade, who's allowed to perform one, what happens to the prorated charge, how the system behaves when the payment fails halfway through, what the user sees, what the audit log records, what the rollback path looks like, how we know it worked. Every one of those decisions is a tiny act of translation — from ambiguous human language into a specific, testable, reproducible behaviour. The code is what records the translation. The translation is what produces the value.

Pre-AI, the typing took so long that the translation work happened in the cracks. You read the ticket, started coding, hit an ambiguity, walked over to the PM's desk, asked, walked back, kept typing. The translation happened — you just couldn't see it because the typing absorbed it. We invoiced for forty hours of "engineering" and hidden inside those forty hours was maybe fifteen hours of translation and twenty-five hours of typing. We saw the typing. We paid for the typing. We thought the typing was the job.

It wasn't.

Figure 1: The misread. Code production was easy to see and measure, so we treated it as the job. Translation was the actual work the entire time.

What Translation Actually Means

Translation, in the engineer's sense, has four moves.

First, you make the intent specific. A PM hands you "let users apply discount codes at checkout." That sentence is the ambiguity. The translation work is asking the dozen questions the PM didn't think to answer — what about expired codes, stacking, minimum cart values, partially-eligible items, currency rounding, codes that exist on a shared cart between two users. Each question is a decision point that lives in the gap between intent and behaviour. Closing the gap is the work. We've written about the discipline that produces these conversations — call it specification-driven development, call it example mapping, call it Specification by Example. The label matters less than the activity. The activity is translation.

Second, you pick a hypothesis worth testing. Not every question has a single right answer. Many of them are bets. Should the upgrade be immediate or apply at next billing cycle? That's not a feature decision — it's a hypothesis about what the user will prefer, a guess about what behaviour change you're trying to cause. Naming the hypothesis explicitly is part of the translation. We've made the case for hypothesis-driven development for the same reason: code that ships against an unstated hypothesis is code that nobody can falsify.

Third, you build the contract. The contract is the spec, the tests, the telemetry — the artifacts that record the translation in a form a machine can verify. This is the part of the work that survives. The code under the contract gets refactored, replaced, regenerated, rewritten. The contract is what defines what was supposed to happen. If the contract is clean, the code can be regenerated tomorrow without losing the translation. If the contract is murky, the code is the only record — and the next person to touch it has to retranslate from scratch.

Fourth, you close the loop. You ship, you watch the telemetry, you find the gaps between what you translated and what users actually do, and you translate again. Translation is iterative. The first version is a hypothesis. The second version is a correction. The tenth version is a feature that fits the user's actual behaviour rather than the team's first guess at it.

None of this is typing. All of it is the job.

Why AI Sharpens the Role Instead of Replacing It

The code-generation tools are good now. Not perfect — they hallucinate, they pick wrong interpretations, they ship plausible bugs. But for the typing layer, they are very good. They can take a clean specification and produce code against it faster than any human keyboard. That layer of the work is structurally cheaper than it used to be, and it's not getting more expensive.

The translation layer is the opposite. It is structurally more valuable than it used to be, for three reasons.

The 2024 and 2025 DORA research kept finding the same thing in different framings. The teams that pull ahead don't ship more code. They ship the right code with less rework. The 2025 report's archetype clustering and the elevated focus on Rework Rate as a leading indicator both point at the same underlying truth: throughput rewards teams that translated cleanly the first time. The teams that throw code at problems and hope something sticks generate more rework, more incidents, more retrospectives that conclude "the spec was unclear."

The translation work is what produces the right code on the first try.

When you remove the typing tax, the rework tax becomes the dominant cost. A team that types twice as fast but rewrites half its work shipped no faster than the team it started racing. A team that translates cleanly and types at AI speed is operating in a different regime. The leverage point moves upstream. The bottleneck stops being can we produce code fast enough and starts being do we know what code we should produce.

That second question is the translation question. It always was.

There is also a quieter shift. With humans typing, ambiguity in a spec produced friction — the engineer hit it, paused, asked. The friction was annoying but it was useful: it forced a conversation that fixed the translation. With AI typing, the friction is gone. The agent picks an interpretation and ships. The translation is now done by the agent, badly, with no human in the loop. If the engineer is no longer the typist, the engineer's job is to be the translator that the agent isn't. The discipline shifts from writing code carefully to writing specifications carefully — from what should this code do to what should this system behave like, in every case I can name.

Figure 2: The translation loop. Intent enters as ambiguity; the engineer translates it into a contract; code generation is a tool inside the translation, not a replacement for it; user behaviour feeds back into the next iteration.

What This Looks Like Monday Morning

If you accept the premise — that translation is the job, code is the byproduct — there are five concrete shifts to make this week. They're small. They compound.

Change the first question you ask. Before you start any task, write down the user outcome you're trying to cause and how you will know you caused it. If you can't write that sentence, stop. Go ask. The act of writing the outcome is the first move of the translation; skipping it is the failure mode that no amount of typing speed will fix.

Push back on prose tickets. A ticket that describes a feature without describing the user behaviour change is decorated assumption. Ask for the behaviour change. Ask what's true about the user before the feature exists, and what's true after. If the PM can't answer, that's the conversation that needed to happen. Have it. The output of that conversation is the spec — and increasingly, the spec is the input the AI agent will build against.

Treat the contract as the deliverable. When you finish work, what survives is not the code — it's the specification, the tests, and the telemetry. Those are the artifacts that record what you translated. Invest in them. Reviewers should be able to read the contract and tell you whether you translated correctly without reading a single line of implementation. If they can't, the contract is murky and the translation isn't done.

Audit your week by activity, not output. At the end of each week, estimate how many hours you spent on translation activities — clarifying intent, mapping examples, picking hypotheses, building feedback loops — versus typing characters. The ratio is the diagnostic. Teams trending toward zero translation hours are teams that are about to be commoditized. Teams trending toward more translation hours are teams that are about to compound.

Build feedback loops aggressively. The translation isn't done when the code ships. It's done when you can see whether users behaved the way the translation predicted. If you don't have telemetry that closes that loop, the translation work is incomplete — and the next iteration is going to be a guess instead of a correction.

The Bottom Line

The fear in the industry right now is that AI is replacing engineers. The reality is more uncomfortable than that. AI is replacing the part of the work that engineers had been pretending was the work. The translation — the part that was always the actual job — is now the only part left. There is nowhere to hide behind typing speed.

This isn't a downgrade. It's the role coming into focus. Engineers who define their value by code production are being commoditized at the same rate code production is. Engineers who define their value by intent-to-value translation are being amplified at the same rate code production is — they can ship more translated value per hour because the typing tax has collapsed. Same person, same skills. Different self-conception.

Your job was never writing code. It was always translating ambiguous business intent into something that adds value to your users. The translation is the work. The code is what falls out of the translation. The artifact got cheap. The activity got essential.

That was always true. AI just made it impossible to pretend otherwise.