The Engineer's Job Once AI Writes the First Draft

Many engineers can name the hours that once went to typing: the boilerplate for a new service, the third version of a parser, the test file that repeats the same setup forty times. Those hours have shrunk for many people, because a tool can now produce a serviceable first draft of much of that work in minutes. The typing did not vanish, though. It moved, and the work that replaced it is harder to see and harder to fake.

What moved and what stayed

The mechanical share of software work has become cheaper to produce. Scaffolding an endpoint, converting a function from one language to another, or filling a test suite with obvious cases now takes less effort, and the output is often close enough to use as a starting point. What has not become cheaper is knowing what the code is supposed to do. A draft answers a question, and somebody has to have asked it clearly. When the question is vague, the answer is fluent and wrong in ways that take a while to notice.

Several things stayed where they were. Someone still has to understand the system well enough to say what breaks when a dependency changes. Someone still has to be reachable when the service fails at an inconvenient hour. Someone still has to tell a product manager that a deadline assumes work nobody has scoped. A tool changes what a line of code costs. It does not change who answers for that line once it runs in production.

Specifying before generating

Much of the new leverage sits before any code is written. A specification, in this sense, is a short statement of the behavior wanted, the inputs and outputs, the constraints that matter (latency, data handling, compatibility with an existing interface) and the cases that must not break. Writing that down feels slower than starting to type, which is why many people skip it. It is also the part that makes a generated draft possible to check.

Consider a request to add rate limiting to an API. The draft will arrive quickly. The specification decides whether it is right: which clients are limited, what happens to a request over the limit, whether the limit applies per user or per network address, and what a well-behaved client should see in the response. A model can fill in every one of those choices, but it will not tell you which ones your product needs. Someone has to decide, and the decision has to be written somewhere a reviewer can read it.

A useful habit is to write three things before asking for code: what success looks like in observable terms, one thing the code must refuse to do, and one example input with its expected output. If those three lines are hard to write, the problem is not ready for generation. The difficulty is information. It shows where the open questions are, and that is worth knowing before anything gets built.

Reviewing is now most of the craft

When a draft arrives, reviewing it becomes the central act. A good review reads the code as if a careful colleague had written it, without assuming that colleague checked the edges. Look for the assumptions the code makes about empty values, time zones, concurrent writes and the shape of incoming data. Look for changes nobody requested: a renamed field, a loop rewritten for style, a helper that now swallows an error. Then read the tests and ask whether they describe behavior or simply repeat the implementation back.

Review also trains judgment. Engineers who read a great deal of generated code learn the recurring failure patterns quickly: an authorization check that is missing rather than wrong, an exception that is logged and not handled, a loop that works on small inputs and crawls on large ones. Those patterns used to be learned by making the mistakes yourself. They can still be learned that way, but reviewing with intent is a faster route, provided you keep a note of what you catch.

Owning what ships

Ownership is the least visible part of the job and the part a team notices most when it is missing. If a generated change causes an incident, the explanation that the tool wrote it does not move the responsibility. Engineers who are trusted with more work tend to state plainly what they verified and what they did not. A change description that says the migration was tested against a copy of production data, but the retry path was not exercised, is more useful to a team than a clean diff with no notes.

The time freed from typing can go to the work that builds this kind of trust: reading the system around the code, watching how users and support staff actually hit the feature, writing the runbook before it is needed, and learning how data moves between services. Those activities look slow on a task board. They are where the judgment the role now depends on gets built.

Measuring the shift for a month

A practical exercise is to keep a plain log for four weeks. Each working block gets one label: specifying, generating, reviewing or owning. Nothing elaborate is needed; a text file with a date and a word will do. At the end of two weeks, look at the proportions. If almost everything is generating and reviewing, with little specifying, drafts are probably being accepted faster than they are understood. If specifying is large but you rarely see what happens after release, ask for a way to watch the change in use, even if that means a small dashboard you build yourself.

How these proportions settle across teams is not clear yet. It depends on the product, the tools in use and the way a team measures its own work. The log will not give a universal answer. It will give an accurate picture of your own week, which is the picture you need in order to decide what to practice next.