Imagine hiring the most knowledgeable software engineer in the world. This engineer knows every framework, can write thousands of lines of code in minutes and understands distributed systems and security patterns better than most people who have spent whole careers on them.
There is a catch. The new hire is remarkably lazy. Every task gets read with complete literalism, and anything left vague gets resolved in whatever way takes the least effort. This engineer will not push back on a bad idea or offer a better one. Describe the wrong thing, and the wrong thing is exactly what you will get.
That is roughly what it is like to work with an AI coding agent today, and I mean it as praise as much as complaint. Scaffolding, boilerplate, tests and routine refactoring that once filled a sprint now take an afternoon. But the teams getting the most from these tools are not the ones with the best models. They are the ones that have learned how to manage this odd new colleague. And the more time I spend with these agents, the more convinced I am that “lazy” is the wrong diagnosis.
The Malicious Compliance Specialist
Teams keep trying to fit AI agents into familiar roles. Some treat the agent as a junior developer who needs supervision, while others treat it as a senior developer who can be trusted with ambiguity. It is neither, and that mismatch explains most of the frustration I hear.
The failure I see most often is what I call the malicious compliance specialist. The agent works toward “done,” not “good,” and finishes each task in the most literal way available, whether or not the result fits the larger design. Ask it to refactor a module and it will usually bolt on a patch rather than rethink the structure, because a patch is the shortest path that satisfies the request. Unless you tell it to step back and reconsider the design, it will graft new behavior onto old structure every time.
Ordinary delegation fails here because it assumes the person receiving the work will fill the gaps with judgment. A human engineer asks questions, challenges vague requirements and draws on experience to anticipate edge cases. The agent does none of that unless told to, and it will not warn you that your instructions were incomplete. It simply produces work that is faithful to what you gave it, including everything you left out.
I Called It Lazy. That Was Wrong.
The better word is context-starved. The difference matters because it changes what you do about the problem.
A human engineer brings years of accumulated context to every decision: knowledge of the business, the history of the organization, past failures, unwritten conventions and the reasons behind choices made three years ago that nobody wrote down. None of it has to be summoned. It is simply there, shaping judgment in the background.
An AI agent has only what you hand it in the moment. It starts each session with no memory of the last one and sees little beyond the files and instructions in front of it. It does not know that your team prefers one architecture over another, that a particular library caused an outage last spring or that the product team changed direction last week. Missing context does not produce an error message. It produces confident, well-organized and wrong output.
That is the central asymmetry of AI-assisted development. People are rich in context but slow to produce code, while agents produce code quickly but are poor in context. The agent may well be the most capable engineer on the team when it comes to writing and understanding software. What it lacks is the broad, durable context that a person carries without thinking about it.
The practical consequence is that the quality of the output is capped by the quality of the context supplied. The engineer’s job becomes curating that context: deciding what the agent needs to know and making sure it knows it. In practice, the discipline comes down to one question asked over and over. What does the agent not know that I am taking for granted?
The Spec Is the New Code
If missing context is the problem, the next question is where good context comes from and how to supply it reliably. The industry’s answer, increasingly, is spec-driven development.
The idea is simple. The specification, not the code, becomes the main thing engineers produce. It describes what the system should do, how it should be built and which constraints apply, and the agent generates the implementation from it. When the code and the spec disagree, the spec wins and the code is regenerated.
This is not a return to waterfall, because the spec keeps changing as the work proceeds. But the thinking moves into the spec, and the code becomes the output of a build step. The approach has moved quickly from experiment to common practice. GitHub’s open-source Spec Kit reached version 1.0 in August, and Andrej Karpathy, who coined the term “vibe coding” in early 2025, had declared it outdated by February 2026 in favor of what he calls agentic engineering.
What makes the method work is that a good spec supplies exactly what a context-starved agent lacks: the intended outcome, what is in and out of scope, the constraints, the decisions already made, how the work breaks down and how success will be checked. Leave any of those open and the agent will decide for you. A request to “build a sign-in flow” yields something plausible. A spec saying that users sign up with an email address and password, confirm by email, stay signed in across page refreshes and use the existing database schema, with third-party sign-in left out of this release, yields something correct.
That is why I see spec-driven development as the practical answer to the context gap. Business requirements, product intent, architectural limits and domain knowledge, written down in a form the agent can use, are what turn a malicious compliance specialist into something much closer to a teammate.
Three Shifts, Three New Decision Surfaces
In my first essay I described Decision Surfaces: points in a system where static logic stands in for contextual judgment, and where agentic AI makes it possible to restore that judgment at scale. I found them in operational systems, in rule banks that only grow, thresholds set once and forgotten, and approval queues staffed by people doing pattern-matching.
Software development has Decision Surfaces of its own, and coding agents are dragging them into view. Much of how we organize engineering work, including the roles, the handoffs and the ceremonies, was built around one constraint: writing code was slow and expensive. That constraint is gone, but the organization chart has not caught up. I see judgment moving in three directions at once.
The first shift is lateral. Senior engineers are spending less time writing code and more time reviewing and steering what agents produce. Because an agent can generate code faster than people can check it, the bottleneck has moved from production to review. That makes review the most important quality gate in the process, and also the most fragile.
In my first essay I described an approval step that was rubber-stamped more than 85% of the time and added nothing but delay. A code review that waves through agent output without real scrutiny is the same failure in a new place. It is a Decision Surface that has gone stale.
The second shift is upward. Freed from typing, engineers are moving toward the decisions that determine whether a system succeeds: architecture, security, cost and scale. Agents cannot make these calls well on their own, because each one depends on the kind of context only people carry. The engineer’s role is changing from producing code to designing the systems that agents build, and that is where the most valuable judgment in software development now sits.
The third shift is leftward, and I think it is the one teams notice last. The richest context does not start in engineering. It starts with product managers, business owners and customers. Engineers are spending more time upstream with product teams to make sure business requirements drive the work, because those requirements, once written into a spec, determine the quality of what the agent builds. The old handoff of “give me the spec” is giving way to “let us write it together.”
Taken together, these shifts change what an engineer is for. The job is moving from writing to reviewing, from implementing to designing and from receiving requirements to helping write them. Team shapes will follow, with fewer mid-level implementers, more architects and reviewers, and a new kind of specialist who is good at breaking hard problems into pieces an agent can handle. Whether that means smaller teams or the same teams shipping far more, I suspect the answer will vary by company.
The tools are improving faster than any development technology I have worked with. Agents are getting better at inferring intent, remembering context between sessions and asking questions when instructions are unclear, and some of what I have described here will look dated within a year. The shifts in judgment will outlast the shortcomings. Implementation will keep moving to the agent, and human judgment will keep moving to specification, design and review.
We were not replaced by AI. We were promoted to managing the laziest genius in the building, and that genius gets a little less lazy every quarter.