Proton’s CTO, Bart Butler, recently told his engineers their job has fundamentally changed. Writing code is no longer the job. In his words, the job is now to help the LLM “write better code faster.” (Business Insider)

He is right about the first half. The engineer is now a lead of models and agents, not a typist.

But look at the measure. Better code, faster. That is still a throughput metric. If the goal is more code in less time, we have taken the LLM’s biggest weakness, the wall of text, and pointed it at our codebase.

The business never asked for faster code. It asked for a claim settled sooner, a higher yield, an order delivered on time. Code is only the path to that.

Two prompts, two outcomes

Compare two requests to the same model.

The first: generate this service so it runs in Java.

The second: generate this service following our design principles and architecture, against our data model, consuming the services we already expose, and passing the tests written for this requirement.

Both produce code that compiles. Only the second has a real chance of passing review without a single comment.

That is the metric that matters. A pull request that goes through with no feedback goes to production sooner. It is what sets time to release, and time to release is what meets the business objective. Lines of code per hour do not.

I’m not alone in seeing this. Sergey Marchuk, CTO at Oxagile, wrote in Forbes this week that agents have made code cheaper to produce while making ambiguity more expensive. He cites Harvard researchers who found that coding agents increased lines of code by 30%, while the time from pull request to merge rose 49%. More code went in, and it took longer to get out.

His answer is more structure around the agent: a specification checked for gaps before implementation, a context harness kept in the repository, and named human sign-off at each stage. That is the right instinct. But the gap check rests on the spec and on whoever reviews it. In my experience, the gaps that hurt most are the ones nobody thought to write down. When the requirements pipeline carries the organization’s own history (which requirements went missing, which tests were never written, which defects kept coming back), the LLM can flag that white space while the objective is still being defined.

The model is ready. The context isn’t.

Today’s LLMs, and the harness around them, can already do the second prompt well. Capability is not the constraint.

The constraint is knowledge. To write that second prompt, the developer or lead has to know the design principles, the architecture, the data model, every exposed service, and the test intent behind the requirement. Few people hold all of that in their head. Fewer can feed it to a model on every request.

So the model reasons over whatever thin context it is given, and fills the gaps with plausible code. Reviewers catch the gaps. The PR goes back. Release slips. The business objective waits.

What we learned: start with the objective, not the data

We faced this directly when we built SDLC intelligence for a manufacturer and an insurer.

We did not start by collecting data. We started by defining the objective: produce a service whose PR gets no review feedback, goes through to production, and moves a business outcome such as claim processing time, yield, or order processing, in its own context.

Only then did we gather data sources, and we did it structurally:

  • 1. Requirements, user stories and epics
  • 2. Test cases
  • 3. Code and data repositories
  • 4. Published APIs and services
  • 5. Historical defects

The step that made it work came next. We gave the model the objective and the sources, and asked it a different question: is this enough to meet the objective, and where is the white space?

The model came back with gaps. A requirement with no test. A data assumption no one had written down. A localization and currency rule that had never been captured in requirements, and had shown up only as defects.

We closed each gap and ran the loop again. Objective, sources, white space, close, repeat. That loop engineering is what turned “build this service” into an outcome-based, measurable request. The results were fewer requirement gaps, better code quality, bugs eliminated rather than fixed, and shorter time to release.

Objectives build better engineers, and better leaders

This way of working builds better engineers. You cannot set an objective like “no review comments and a faster claim” without understanding the business context and the value at stake. The coder becomes a developer who knows why the service exists.

The same holds well beyond code. A business leader who understands the outcome and its impact can set clear objectives for an agent and run the loop until the output aligns. Leadership stops spending time correcting work that was aimed at the wrong target.

A simple example I heard recently: an order-to-shipment report versus an order-to-delivery report. Shipment tells you the warehouse did its part. Delivery tells you whether the customer got what they ordered, when promised. The second is the status that means something to the business. But if the objective is not set that way, the agent will not know. It will build the first report, accurately and quickly, and it will still be the wrong answer.

The engineer’s real job

So yes, the engineer’s job has changed. But it is not to help the LLM write code faster.

It is to define the outcome, assemble the context, and close the white space the model surfaces. The model’s power is in reasoning over that context to a decision: is this enough, what is missing, what should be built. Generating the code is the easy part.

This is the same point I made in The Missing Objective: a model is only as useful as the objective we train and point it at. Point it at faster code and you get more code. Point it at a PR that ships without comments and a business outcome that moves, and you get release velocity that actually matters.

Sources

Part of the Enterprise Intelligence series.