The Engineer Is Dead. The Builder Is What Comes Next.

The job title said Engineer. The actual work, for most of my career, was coordination: parsing requirements, translating them into tickets, distributing the tickets across a team, reviewing the output, integrating the pieces. The writing of code was a fraction of the day. The rest was human middleware — moving information from one context to another, making decisions that could have been made earlier if the system had been designed to surface them earlier. I was not complaining about this. It is just what the role was. When I say the engineer is dead, I am not describing a loss. I am describing a job description that no longer maps onto what the actual work is.

Groupon in 2023 had a large engineering organization built around a different constraint: human throughput. The team was structured to maximize how much code a group of people could produce in a sprint. That meant specialization by layer — frontend, backend, infrastructure, QA — and a delivery pipeline designed to keep each specialization busy. Tickets moved from product to engineering, from engineering to QA, from QA back to engineering, from engineering to release management. Each handoff introduced latency and a small amount of information loss. Over hundreds of tickets, the latency compounded into months of drag. The system was optimized for the wrong thing, because the wrong thing was the only thing available. You can only organize around human throughput when human throughput is the bottleneck.

It stopped being the bottleneck. By late 2024, the tasks that had consumed most of a junior engineer's week — boilerplate generation, test writing, documentation, migration scripts, API scaffolding, dependency upgrades, first-pass code review — were default AI work. Not gone. Happening faster and at higher volume than before. But no longer requiring a human hand at each step. What changed is who is responsible for them. The agent is responsible for execution. The human is responsible for problem definition, the constraints, the evaluation criteria, and the call about whether the output is good enough to ship.

The daily work looks different now in specific ways. A Groupon engineer in 2023 would spend a morning implementing a new API endpoint: writing the handler, the validation layer, the tests, the documentation, updating the OpenAPI spec. In 2025, that same engineer spends twenty minutes specifying the endpoint precisely — what it should do, what it should reject, what the failure modes are, what the contract guarantees — and then evaluating what the agent produced. The evaluation is not passive. It requires reading the generated code carefully enough to spot wrong assumptions, checking that the edge cases in the spec are actually handled, running the tests and asking whether the tests cover the right behavior or just the happy path. That is harder than writing the code was. It requires more understanding of the system, not less. A junior engineer who is good at syntax but does not understand why the endpoint exists will not catch the agent making a plausible but wrong architectural decision.

The layer shift is the thing people miss when they talk about AI replacing engineers. The replacement is happening at the execution layer — the layer where syntax and boilerplate lived. The judgment layer is expanding, not shrinking. Someone has to decide when a migration is the right call versus a schema change versus leaving the data model alone. Someone has to evaluate whether the query the agent produced will hold up under production load or will scan the full table at three in the morning when a batch job runs. Someone has to read the security implications of the authentication pattern the agent chose. Those calls require deeper system knowledge than the work they are replacing. The barrier has not gone down. It has moved.

What the skill shift actually requires is specificity: the ability to describe a problem precisely enough that an agent can execute it without filling the gaps with plausible-but-wrong assumptions. That sounds simple. It is not. Most engineers are not trained to write precise specifications because they never had to — they could resolve ambiguity as they wrote the code. Now the resolution has to happen before the code. A builder who says "add a caching layer" and expects the agent to figure out the rest will get a caching layer that is technically correct and operationally wrong. A builder who specifies the invalidation strategy, the TTL reasoning, the failure behavior when the cache is cold, the monitoring signal that indicates the cache is not helping — that builder gets something shippable. The discipline of specification is different from the discipline of implementation. It requires you to think through the problem before touching it, not while you are touching it.

The second skill is evaluation. Not reading code for style, but reading it for correctness and fit. The agent will produce code that looks right. It will be well-formatted, reasonably structured, syntactically valid. The defects will be in the logic, in the edge cases, in the assumptions about how the system is actually used. Catching those requires context about the system that the agent does not have and cannot acquire from the prompt alone. A builder who rubber-stamps agent output because it passes the linter is not adding value. A builder who reads the output the way a senior engineer reads a junior's PR — looking for what is missing, what is assumed, what will break under conditions the author did not consider — is doing the hard work.

The hiring implications are real and we have adjusted for them. The job descriptions we ran in 2023 were largely about technology depth: years of experience with specific frameworks, familiarity with specific tools, demonstrated output in specific languages. Those signals correlated with execution speed, which was the constraint. They correlate less well with what we need now. We now look for evidence of judgment over evidence of output. In interviews, we give candidates a generated codebase with defects and ask them to find the problems. We ask them to specify a feature — not implement it, specify it — and we evaluate how precise and complete the specification is. We ask them to explain a past decision where they had to choose between options that each had real costs, and we push on the reasoning behind the choice. We are less interested in what they built and more interested in how they think about what should be built and whether the output is correct.

The people who have struggled with the transition are not the ones who lack technical skill. They are the ones who derived meaning from the execution — who liked the craft of writing code, who found satisfaction in the act of building line by line. That satisfaction is real. It is not available in the same form anymore. The craft has moved up the stack. Builders who have made the transition describe it as harder and more interesting, not easier. They are operating on larger problems with better tools. The ones who have not made it tend to keep reaching for the keyboard when the right move is to specify more precisely and evaluate more carefully.

Groupon is not building toward a smaller engineering team. We are building toward a team where every engineer is operating at a level of impact that was not possible before — where the ratio of decisions per person per day has gone up, where the surface area any individual can cover has expanded, and where the quality bar is higher because the floor has been raised. The old structure was a compression algorithm: break the work into small enough pieces that it can be distributed across many hands. The new structure assumes that each hand can cover more, which means the work that reaches those hands is larger and more consequential. That is a better problem to work on. It demands more of the people doing it, which is the point.