What Employers Pay For When Code Itself Is Cheap

If producing code approaches free, the question worth answering is what a company is buying when it employs engineers. The answer was never purely code, but code was a large enough component that the distinction rarely mattered. It matters now.

What's actually being purchased

Strip out production and what remains is five things, all of which were always there and were partly bundled into the price of implementation.

Deciding what to build. Which of forty possible things is worth doing, in what order, at what fidelity. This has never been automated and isn't close, because the inputs are business context, customer knowledge, and strategy that mostly isn't written down.

Judging whether output is right. Not whether it compiles — whether it solves the actual problem, whether it will hold under conditions nobody specified, whether it's the change that should have been made. As generation gets cheap, this becomes the constraint, and it requires having built things to do well.

Holding context nobody wrote down. Why the system is shaped this way, what's fragile, what was tried and failed, which customer this decision affects. This is the input agents lack most completely, and it appreciates as everything else gets cheaper.

Being accountable. Someone has to own whether it worked. Accountability can't be delegated to a model — not for regulatory reasons alone, but because accountability requires someone who can be asked to explain, and who bears the consequence.

Integrating across boundaries. Making a change that touches three teams, negotiating what's possible, understanding what's politically feasible this quarter. This is a large share of senior engineering work and is almost entirely invisible in artifacts.

What this changes about how value is demonstrated

If those five are the product, then several proxies that used to work stop working.

❌ Volume of output. Was always a rough proxy; becomes actively misleading when output is cheap. An engineer producing three times as many PRs may be producing three times as much review burden.

❌ Technology breadth. Knowing many frameworks was valuable when that knowledge was scarce. It's the most thoroughly replicated kind of knowledge there is.

❌ Speed of implementation. The specific thing that got automated.

✅ Decisions that turned out well. Harder to point at, and it's the actual product. Worth tracking deliberately — what you decided, why, and how it turned out.

✅ Problems that didn't happen. The change you stopped, the design that avoided a whole class of failure. Chronically undervalued because it's invisible, and increasingly the substance of the job.

✅ Being the person who knows. Institutional knowledge as a stated asset rather than an accident.

⚠️ The uncomfortable second-order effect

If what's paid for is judgment, context, and accountability, those are harder to assess in hiring than implementation skill was. Coding interviews tested the exposed skill, precisely because it was measurable.

Expect hiring to lean more on track record, references, domain background, and how someone reasons about ambiguous problems — all of which are noisier, more subjective, and more prone to bias than a technical screen. That's a real cost of the transition, borne mostly by people without an established network or a legible track record, which usually means people early in their careers or switching domains.

Nobody has a good answer to this yet. It's worth naming rather than pretending the transition is clean.

💡 What to do about it now

• Keep a decision record. What you chose, the alternatives, the reasoning, the outcome. This is the artifact of judgment work, and without it the work is invisible.
• Make your context legible. Write the "why is it like this" documents nobody asks for. It both increases your value and, slightly, transfers it — which is fine; the person who wrote it is still the one who understands it.
• Get named on outcomes. Being accountable for whether something worked, not just for delivering a piece of it.
• Learn the business. Domain knowledge is the least replicated input and the hardest to acquire from outside.

The takeaway

Employers were buying five things and paying for them through implementation, because implementation was the visible part. With that part cheap, the purchase becomes explicit: decide what to build, judge whether it's right, hold the context, own the outcome, work across boundaries. Demonstrate those directly — through decision records, prevented problems, and accountable ownership — because the proxies that used to carry them no longer do.