Engineering Intelligence
The Work That Remains: What a New Book on AI and Judgment Means for Engineering Leaders
Daniel Dines spent twenty years automating enterprise work. His new book argues that the hardest thing to automate was never the code. It was the judgment. For engineering organizations racing to adopt AI, that argument reframes the entire question of what to measure.
Most conversations about AI in engineering start with capability. Which model, which agent, how many seats, how much of the backlog it can close. Daniel Dines, the founder of UiPath, opens his new book The Work That Remains from the opposite end. He starts with the question every executive is actually asking behind closed doors, and almost no vendor answers honestly: why can I not just plug an agent into my business and let it learn and act like a person?
His answer is not a hedge, and it is not hype. It is architectural. And for anyone running an engineering organization right now, it lands close to home, because software teams are further into agentic adoption than almost anyone else. We are the test lab. So it is worth taking the argument seriously and asking what it means for how we build, and for what we hold ourselves accountable to.
The thesis, stated bluntly
Dines compresses the entire operating model into a single line. Once you see it, you cannot unsee it in your own delivery pipeline.
AI proposes. Humans decide. Automation executes.
Daniel Dines, The Work That Remains (2026)
Read it against a modern engineering workflow and it maps almost exactly. The agent reads the ticket, pulls the context, drafts the change, runs its own checks, and carries multi-step work all the way to a finished proposal. What it cannot carry is the call. A human owns the decisions where consequence, trust, and commitment live: the merge into a system real customers depend on, the architecture choice the next two years inherit, the exception that looks routine until one detail changes everything. And deterministic systems execute what must be exact every single time: the deploy, the migration, the permission check, the audit line.
The agent brings speed, reach, and synthesis. The person brings judgment and accountability. The automated process brings exactness. Dines makes the point that matters most for how we govern this: their capabilities overlap, but the institution needs each duty held where it is strongest and where someone can answer for it. A machine cannot own an outcome. A person with a name does.
Four limits that survive scale
The heart of Part I is a claim that will annoy the maximalists and reassure nobody who wants a comfortable status quo: there are structural limits to what today’s AI systems can be trusted with, and they do not dissolve just because the next model is bigger. Dines names four.
It does not learn on the job
A person learns from everything that happens around her, recorded or not. An agent searches whatever was written down and handed to it, fresh on every request. Most of what runs your business, and most of what a senior engineer knows about your codebase, was never recorded.
It has no self that persists
Give a model an account, email, and permissions and you have given it access to the company, not membership in it. It can read the docs and draft the memo, but it does not become senior, absorb the culture, or develop the taste that notices the dashboard is green while the customer is at risk.
Actions have consequences
A proposal is safe to be probably right. A payment, a production deploy, a permission change must be exactly right. Consequence is where authority has to answer to a named person, and no amount of model fluency changes that.
Good enough is not good
For execution, “probably right” is simply wrong. Some of the work has no acceptable creative variance, and treating it as a place for improvisation is how organizations manufacture incidents.
The one Dines calls the keystone is execution. The others may soften as agents gain better memory and more of the room gets translated into something a model can read. But when the work must be right, the model should not be the thing you trust to make it right. Engineers have known a version of this for a long time. It is why we have tests, CI gates, and rollback. The book’s contribution is to make that instinct into an operating principle for the whole enterprise.
Why your best engineer beats a genius model in your codebase
There is a passage in the book that every engineering leader should sit with. Dines describes what happens when a good operator joins a new company. For a few weeks she is careful and slightly wrong. Then something shifts, and she starts making calls that fit: this complaint is noise, that quieter one is trouble, this deadline will bend, that one will not. Ask her how she knows and she shrugs.
People read the room. Models need the room translated.
The Work That Remains, on the first structural limitThe model has read more than any human who ever lived, and wherever the world has been described a million times it is dazzling. The difference appears in exactly one place: the parts of the world nobody ever wrote down. Your architecture decisions. Why that service is fragile. Which “temporary” workaround is load-bearing. Which review comment is a preference and which is a warning. That knowledge was never secret. It was just never worth the cost of writing down.
One of the sharpest builders in the field says the same thing from inside the lab. Dines quotes Liang Wenfeng, the founder of DeepSeek, from a 2026 interview:
Humans keep learning over time. But with AI, you have to provide all the relevant context every time you ask it to do something. That’s almost impossible. This is why AI can’t truly replace employees yet.
Liang Wenfeng, DeepSeek, quoted in The Work That Remains
Here is the inversion that turns this from a limitation into a program. The same AI that arrives at the door needing the manual is the first technology cheap enough to help write it. Every time an experienced engineer corrects an agent, rejects a proposal and says why, or fixes a draft before merging it, a piece of previously unwritten knowledge just got written down, attached to a real case. A wave-through writes nothing, which is why it teaches nothing. A correction with a reason writes a line of the manual that never existed.
The handover runs in stages, and they are earned in order
Dines is emphatic that you do not leap from chat assistants to full autonomy. The role of the person narrows in stages, and each stage is earned with evidence of the agent’s proven capability on that specific kind of work.
The person orchestrates. She asks the assistant, carries the answer, and runs automations as separate instruments. Most teams are here.
The person supervises. She hands an agent a task with a clear goal inside a controlled environment, then watches, redirects, and accepts. The agent works attended.
The person reviews proposals. A business event starts the work, the agent proposes unattended, the person validates at the gate, and automation executes what was approved.
The person handles exceptions. Routine cases run under audit. The person sets the policy, owns the thresholds, and decides the long tail. The gate does not disappear. It concentrates.
Companies that try to jump from stage one to stage four fail predictably. The reason is the thing that does not change across the whole ladder: consequential action answers to a person at every stage, and the audit trail always runs back to a name.
The line that should reorganize how engineering leaders measure AI
This is where the book stops being interesting and starts being operational for those of us who build measurement tools for a living. In his proposed constitution for the AI-native enterprise, Dines opens with an article that reads like a direct rebuke of how most AI adoption is reported today.
Outcomes are the unit of value. Judge an AI program by what happened to the work. Do not count agents deployed.
Article 1 of the constitution, The Work That RemainsHe calls agent count the vanity metric of this era, and predicts it will read in retrospect the way “number of apps” read in the mobile era. The measures that actually matter can be compared before and after a program: faster delivery, fewer errors, lower cost, less human effort, and control that holds. Comparability is what turns improvement from a claim into a fact.
The numbers back the caution. Dines cites MIT’s NANDA research putting enterprise generative AI spending at thirty to forty billion dollars, with roughly 95 percent of the integrated pilots examined showing no measurable return, and a Gartner forecast that more than 40 percent of agentic AI projects will be canceled by the end of 2027. The pattern underneath the numbers is the one that should worry any engineering leader: individual productivity can rise while organizational productivity does not, because the work around the output never changed.
Where this meets engineering intelligence
This is the exact problem Waydev was built to solve, and reading Dines articulate it so precisely was a reminder of why the category matters now more than it ever has. When teams measure AI adoption by seats purchased or lines of code suggested, they are counting agents deployed. They learn nothing about whether the work actually got better.
Engineering intelligence exists to answer the harder question: what happened to the work? Did the AI-assisted change ship faster and survive contact with production, or did it just move effort downstream into review and rework? Is a team’s throughput rising because the system improved, or because a few people are quietly absorbing the cost of unreliable output? Those answers do not live in an agent’s dashboard. They live in the outcomes, measured before and after, with control held beside speed.
Dines writes that efficiency bought with weaker control is not improvement. We could not agree more. Measuring AI’s real impact and ROI across an engineering organization is not a nice-to-have layer on top of adoption. It is the thing that tells you whether adoption is working at all.
Rent the models, own the memory
The article of the constitution that stays with me longest is the ninth. Rent the models. Own the memory. Switch models by capability, cost, and data requirements without rewriting the work, but own the record of decisions and corrections, the map of how the work runs, and any model trained on your validated work.
The reasoning is that you pay for intelligence twice: once with money, and once with the know-how your people reveal to make it useful. The corrections your senior engineers make while breaking in an agent are institutional knowledge no competitor can buy off a shelf. If those corrections do not land in your own governed record, they compound for no one. Models come and go. The governed memory of your work is what remains when one is replaced.
For engineering organizations, this is a direct argument for treating your delivery data, your review decisions, and your measured outcomes as owned strategic assets, not as exhaust from tools you rent. The teams that win, in Dines’s framing, will compete on loop speed: the time from an event to verified institutional learning. A case arrives, the agent proposes inside the map, a person validates, the decision is captured, the system improves, and the next similar case moves faster. Approvals are not data. Verified decisions are.
What engineering leaders should take from it
Dines is careful to say the argument depends on AI being powerful. If it were not, none of this would matter. That is what makes the book worth reading rather than dismissing. It is not a defense of the old way and it is not a plea to slow down. It is a case that the real project of enterprise AI is not procuring agents. It is producing a governed description of how the work actually runs, building the deterministic rails that execute the stable parts exactly, and growing on purpose the human capacities the architecture still needs.
The biggest mistake he warns against is moving first on headcount, cutting the visible work product before understanding what else a role produced: the culture it held, the people it trained, the trust it carried. The better path is to redesign the operating model, and let its shape be the consequence, never the substitute.
Human work is being redefined, not eliminated. For engineering organizations, the advantage will belong to the teams that can see clearly what their AI is actually doing to the work. Not agents deployed. Outcomes measured, controlled, and owned. That is the work that remains, and it is the work worth measuring.
The Work That Remains: Human Judgment, AI, and the Architecture of the Next Enterprise, by Daniel Dines, was published in 2026 and can be read and downloaded for free from UiPath. Quotations and figures referenced here are drawn from the book. The views summarized are the author’s; the connections drawn to engineering intelligence and to Waydev are my own.
