AI Writes the Code Now. Here Is What You Actually Hire For

Yes, you still need to hire engineers. What changed is the part of the job you are paying for. A model can now produce a working first draft of most features in minutes, so the expensive work moved to the decisions wrapped around that draft: what to build, what the system must never do, and whether the generated version actually does it. In the worked example below, that difference is 13 hours and $1,560 on a single feature, at the same hourly rate, with the same person.

This guide is written for whoever signs the contract. It puts a price on a vague request, names the four skills that got more expensive rather than cheaper, splits the work into steps you can safely hand to a model and steps you cannot, and gives you a 40-minute probe that tells you within one call whether a candidate has the skill you are now paying for.

The bottleneck moved from typing to deciding

For two decades, what a software team lacked most was the ability to write and review code fast. Hiring grew up around that scarcity. You screened for syntax fluency, framework depth and algorithms because those were the hours you bought.

Code generation flipped the ratio. A plausible implementation of a login flow, a CSV importer or a reporting endpoint now takes a few minutes. What has not moved at all is the ability to say precisely what the system should do, which cases it has to refuse, and how anyone will know the result is correct. Models are literal. They are also confident: give one an underspecified request and it will choose a reasonable interpretation out of a hundred, ship it without hesitating, then choose a different one tomorrow.

So the shortage moved one step upstream. You are not short of people who can produce code. You are short of people who can decide which code is worth producing and prove the generated version does the job. That is a different screen, a different interview, and for most teams a different seniority mix.

What a vague request costs on one feature

Arguments about this go in circles until somebody writes the arithmetic down. What follows is a worked example rather than a survey. Every input is an assumption you should replace with your own numbers, but the shape of the result holds.

Take one senior contractor at $120 an hour, mid-band for a vetted US marketplace. If you want to set your own figure, our breakdown of freelance developer hourly rates has the full ranges by channel. Then give that person one feature: customers should be able to request a refund.

Prompt first, fix later. Six hours are spent prompting, reading the output and accepting it. The build looks done. Then QA discovers that a refund can exceed the amount actually captured, support discovers that a double click refunds twice, and finance discovers there is no audit trail anywhere. Three rework rounds of eight hours each come to 24 hours. Total: 30 hours, or $3,600.

Spec first. Five hours are spent writing down what the endpoint accepts, what it must refuse and what the acceptance tests check. Generating against that spec and reviewing the diff takes another four hours. Specs are never perfect either, so one rework round of eight hours covers what this one missed. Total: 17 hours, or $2,040.

Same person, same rate, same tooling, same feature. The gap is 13 hours and $1,560. On top of that, the three rework rounds in the first path burn calendar time nobody put in the plan.

One feature is a rounding error on any real budget. A quarter is a line item. Put thirteen features through the same engineer at the same rate and the prompt-first path costs $46,800 against $26,520 for the spec-first path. The specification time buried inside that second number is $7,800. You are spending $7,800 on thinking to avoid $20,280 of rework, and that trade is the entire argument for changing what you hire for.

The four skills that got more expensive, not cheaper

If the model handles the typing, four things rose in value. Each one is observable in a single conversation, and none of them appear anywhere on a resume.

• Writing a specification something else can execute. Behavior, constraints, failure cases and acceptance criteria, in that order. On large teams this was a product manager's job and on small ones it was nobody's. It is now the input that determines the output.
• System judgment under ambiguity. That means choosing the data model, deciding what the system must never do, and deciding what not to build at all. A model will happily build the feature you described, even when the right answer was a configuration flag and a support macro.
• Reading a diff you did not write. Generated code is clean, consistent and confident, and that defeats the instincts reviewers built on human code. The warning signs have changed: a missing idempotency key, a swallowed error, a test that asserts the implementation rather than the requirement. For the mechanics, see our guide to reviewing a pull request.
• Debugging code nobody remembers writing. When a generated path fails in production at two in the morning, there is no author to ask what they were thinking. The engineer has to rebuild the intent from the code itself, which needs stronger fundamentals than writing it would have, not weaker ones.

Look at what that list leaves out. Typing speed, framework trivia and whiteboard algorithms were always weak proxies for engineering judgment, and today they actively mislead, because the thing they stood in for is the part you can generate.

Who should own each step of the work

Not every step moved, and the useful question is never whether AI replaces developers. It is which steps are safe to hand over and which ones you are still paying a person to own. This is the split we use when scoping work.

Most of the risk sits in two rows. Reviewing the diff is where a confident wrong implementation either gets caught or does not. Deciding what not to build is where a large share of wasted engineering ends up, and it never appears in a ticket, which is exactly why it stays invisible until the quarter is over. Our guide to scoping an MVP has the same conversation at project level.

The artifact to ask for before you sign anyone

There is a simple way to test for all of this without sending a take-home exercise nobody wants to do. Ask the candidate to write the spec for a feature you have already shipped. Not the code, the spec. Fifteen minutes, in writing, while you watch.

You are looking for four parts: the behavior, the constraints, the failure cases and the acceptance criteria. The failure cases are the tell. Weak specs describe the happy path and stop, which is precisely the input that produces three rework rounds. Strong specs name what the system must refuse before they name what it should do, and they are short.

A 40-minute probe that separates the two kinds of engineer

A spec on demand tells you a lot. The rest comes from a live probe. Hand the candidate one deliberately vague ticket and 40 minutes, then watch which direction they move first.

The first ten minutes are for questions only, no code. Strong candidates ask who initiates the refund, how far back the window goes, whether partial refunds are allowed, and what happens when the payment gateway times out halfway through. Weak ones open with a framework choice, since every previous interview rewarded them for answering that question fast.

The middle fifteen minutes go to the written spec, and the last fifteen to a review. Bring a generated diff you have already broken in one specific way, then ask them to find the problem. Our version has no idempotency key, so a double click refunds twice and the second refund leaves no trace. If a candidate comments on naming and formatting but misses the double refund, they have just shown you how they will review every generated diff on your team for the next year.

This structure works for contract and permanent roles alike. How to run the session itself without coaching the answer is covered in our broader guide to running a technical interview.

Where to start this week

You do not need to restructure the team to act on this. Change two things on the next role you open.

First, swap the take-home for the spec exercise above. It costs you fifteen minutes instead of costing them five hours, and it tests the skill that now determines the cost of every feature. Second, write the job description around the four skills rather than the stack. A posting that lists eight frameworks selects for what you can generate. One that asks for someone able to turn an ambiguous request into a spec with failure cases selects for what you cannot.

Then price it honestly. The engineer who writes the spec that saves $20,280 a quarter is not the cheapest hour on the market, and the gap between a $90 hour and a $120 hour disappears inside the first two rework rounds you avoid. If the work is AI-heavy by nature, our AI engineers are vetted on exactly this split between generating and deciding. Send us the vague ticket you have been arguing about internally, and we will match you against people who ask the right four questions about it first.

If you would rather build these habits inside the team you already have, our AI training for engineering teams covers AI-assisted code review, testing and prompting with ChatGPT and Claude.