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.

But it goes further than the code. Every UI, every report, every dashboard you interact with was designed for the process to stop and wait for a human to make a decision. The screen exists so a person can look, judge, and act. The workflow pauses until someone clicks “approve,” reads a chart, picks a priority from a list. This is the architecture of modern work: systems that present decisions but cannot make them.

These are not features. They are frozen judgment. And for the first time in the history of software, we have the technology to thaw them.

“But This Is a Deterministic Workflow”

That sentence gets said in every engineering room, every product review, every architecture discussion. It sounds like a statement of fact. It is actually a confession.

Deterministic execution was never a design goal. It was a constraint we accepted because we could not encode expert judgment at scale. When you could not give a system the ability to reason about context, you did the responsible thing: you froze the decision. You set a threshold. You wrote a rule. You built a queue and staffed it with people. You designed a dashboard so someone with experience could look at the situation and choose.

That was correct then. It is a limitation now.

I run workshops with engineering and product teams where we take apart one real workload and hunt for the places where judgment was frozen. I have done this with teams building workforce operations platforms, identity verification systems, financial settlement engines, and multi-tenant SaaS infrastructure. The consistent pattern is not that teams lack AI ambition. It is that they are looking in the wrong place. The biggest Decision Surfaces tend to hide in operations, not in customer-facing features. Once you know how to spot them, the opportunity multiplies.

What Is a Decision Surface?

A Decision Surface is a structural point in a workflow where one of the following is true:

• A threshold was set once and never revisited.

• A queue is staffed by people doing pattern-matching.

• A rule bank grew reactively to handle edge cases.

• An approval step exists that gets rubber-stamped more than 85% of the time.

• Rich context is available but unused in the decision path.

Here is the distinction that matters: Decision Surfaces are not bugs. They are not technical debt. They are design constraints from an era that has ended. When these systems were built, encoding contextual judgment at scale was impossible. Static rules were the only responsible option. That technological constraint has been lifted. The architecture has not caught up.

The Intervention Queue I worked with a workforce operations platform that manages hundreds of thousands of field employees. Their intervention specialists receive a queue of people to contact each month, prioritized by a static scoring system that weights event severity the same way for every person in every context. A first-year employee with two incidents is different from a 15-year veteran with the same two incidents. The specialist knows this. The system does not. The queue presents data and waits for the specialist to exercise judgment: who to contact first, what to say, how to follow up. That pause, that forced human intervention where the system could reason but does not, is a Decision Surface.

Think about the transition from candlelight to electricity. It did not just make rooms brighter. It restructured how buildings were designed, how cities were planned, how work was organized. Decision Surfaces represent the same kind of inflection for AI. The question is not “where can we add AI?” The question is “where has frozen judgment been limiting what is possible?”

How to Spot a Decision Surface

Decision Surfaces hide in plain sight. They are so embedded in how systems work that the people who operate them have stopped seeing them as decisions at all. Five structural patterns reveal them.

1. Rule Banks

If/then/else chains that grow and never shrink. The tell: “We need to add another rule for that edge case.” The rules are not intelligence. They are a proxy for intelligence that could not exist when the system was designed.

From the field I watched a multi-tenant SaaS platform hit 1,000 data replication rules, one for every edge case they had encountered over years of growth. Each rule was someone’s careful judgment at the time it was written. Together, they formed a system so brittle that no one could confidently add the 1,001st. The rule bank itself had become the constraint. Not a decision engine. A monument to every past decision.

2. Hardcoded Thresholds

Static values embedded in logic that no one can explain. The tell: ask “why this number?” and hear “that is what it has always been.” Every hardcoded threshold is a judgment call that was made once and frozen.

From the fieldA multi-tenant platform I worked with had a rate limiter set to the same ceiling for every customer. A $2M enterprise running end-of-month batch processing and a free-tier user running a poorly written script hit the same wall at the same time. The system could not tell the difference because the threshold was set once, uniformly, and never revisited. The platform had the data to differentiate: customer tier, SLA terms, usage trajectory, time-of-day patterns. It just never consulted that data at the point of enforcement. One static number was making the wrong call in both directions. Too strict for the enterprise. Too lenient for the abuser.

3. Rubber-Stamp Approvals

Human review steps with approval rates above 85%. The tell: the human is not deciding. They are adding latency. The patterns the approver uses can be learned. The approver’s time can be freed for cases that genuinely require judgment.

From the fieldA security team I worked with required manual approval before any new deployment could proceed to production. They approved 90%+ of submissions without meaningful modification. The approval existed because once, years ago, it was the only way to enforce a policy. The dashboard that presented deployments for review was designed to make the human stop and look. But the policy could now be expressed as intent: no secrets in code, no untested dependencies, no breaking changes to shared APIs. And enforced continuously, without the pause. The approval was not adding safety. It was adding days.

4. Exception Queues

“Manual review.” “Needs attention.” “Escalation.” “Other.” The tell: your most expensive people spend their time working the queue. Institutional knowledge is being consumed as a resource instead of encoded as an asset.

From the field A fintech platform running automated settlements had a reconciliation queue where every mismatch between their internal ledger and their payment processor landed for manual investigation. Their senior ops analysts, the people who understood settlement timing, processor quirks, and currency edge cases, spent 60% of their week working that queue. Each resolution was expert judgment exercised once and discarded. When the analyst left, the knowledge walked out with them. The queue was eating institutional intelligence instead of building it.

5. Data Available but Unused

The workflow has access to rich context it never consults. The tell: ask “what would your best person do differently?” and they describe pulling up three other screens. The gap between what the system sees and what the expert sees is the Decision Surface.

From the field An identity verification company I advise was building a fraud detection tool. Their scoring system evaluated each identity transaction against a universal threshold. The same one for a consumer banking app and a B2B payments platform. But they had the data to differentiate: transaction patterns, customer segment risk profiles, historical false-positive rates per category. The data was in the system. It was not in the decision path. Their best analyst did this differentiation intuitively. Their system did not.

Why Now

For decades, the only way to handle complexity in software was to reduce it. Flatten the decision into a rule. Freeze the threshold. Queue the exception for a human. This was not a failure of imagination. It was a rational response to real limitations. You could not ask a rules engine to evaluate tenant history, market conditions, seasonal patterns, and domain expertise simultaneously for every transaction.

Large language models and agentic architectures changed that equation. For the first time, it is feasible to evaluate rich, multi-dimensional context at the point of decision, at scale, in real time. The cost of contextual reasoning dropped from “one expensive human per case” to “one API call.”

But the economics are specific. This is not free and it is not universally sensible. If a deterministic function costs two cents per invocation and an LLM-based judgment costs fifteen cents, you do not thaw every threshold. You thaw the ones where being wrong costs more than thirteen cents. That turns out to be most of them. A wrong fraud decision costs hundreds of dollars. A wrong settlement routing costs thousands. A wrong intervention prioritization costs a preventable incident. The economics favor judgment restoration wherever the cost of being wrong exceeds the cost of reasoning. And the cost of reasoning is falling monthly.

The locus of judgment is migrating. That migration is the transformation.

How Decision Surfaces Are Reshaping Software

The traditional architecture looks like this: design the happy path, handle exceptions with rules, escalate what does not fit, build a dashboard to make the human look at it.

The emerging architecture looks different: identify the Decision Surfaces, give them context, let them reason, learn from outcomes, surface only what genuinely requires human judgment.

Three structural shifts are already underway.

Rules Become Intent

Instead of 1,000 replication rules trying to approximate a goal, a Decision Surface agent receives the outcome statement and reasons toward it. “Ensure data consistency across tenants with minimal latency, respecting each tenant’s isolation requirements.” Rules expressed intent through syntax. Decision Surfaces express intent through context.

Lived exampleThat workforce operations platform did not need better prioritization rules. They needed an agent that could receive the intent: “identify the three highest-impact interventions for this team this month.” An agent that reasons across employee history, incident patterns, outcome data, and team-specific context to produce a ranked recommendation. They are building it now. It tracks outcomes over time. It learns which interventions actually change behavior. The queue becomes a recommendation engine that gets measurably better every month.

Queues Become Learning Systems

Every item in an exception queue is a decision the system failed to make. When a Decision Surface agent resolves that item, it captures the resolution pattern permanently. When the senior analyst leaves, the knowledge stays.

Lived exampleThe settlement reconciliation team did not need faster analysts. They needed a system that classified each mismatch against historical patterns: timing lag, duplicate submission, processor-side error, currency edge case. A system that either auto-resolved with confidence or escalated with a diagnosis attached. The queue transforms from a drain on expertise into a source of compounding institutional intelligence. Each resolution teaches the next one.

Static Thresholds Become Adaptive Judgments

A single threshold applied uniformly is a one-size-fits-none decision repeated at scale. A Decision Surface evaluates each case against current conditions and adjusts.

Lived exampleThe identity verification company realized their universal scoring threshold was simultaneously too strict for low-risk segments and too lenient for high-risk ones. It was blocking legitimate transactions in one bucket while missing fraud patterns in another. The Decision Surface was not the score itself. It was the threshold applied to that score. Different segments warranted different lines, drawn fresh for each transaction based on current context. One static number was making the wrong call thousands of times a day.

What to Expect

In the near term, organizations that audit their systems for Decision Surfaces will discover they have far more agentic opportunity than they assumed. And almost none of it will be where they were looking. The provisioning pipeline, the reconciliation queue, the cost allocation model: these internal workflows are the hidden gold because they multiply across every customer, every transaction. The companies that move first will compound their advantage because captured judgment improves over time. Delayed competitors face a widening gap.

The pattern I keep seeing: teams walk into these workshops wanting to “add AI to the product.” They walk out realizing the biggest opportunities are in their platform operations. The provisioning logic. The scaling decisions. The routing algorithms that nobody ever thought of as AI-worthy. That internal-first discovery is the most consistent surprise.

In the medium term, agent-aware architectures become the expectation, not the experiment. “Deterministic by default” gives way to “judgment-capable by design.” Software systems become learning organisms in a structural sense, not a marketing-copy sense. Every resolved exception enriches future resolution. Personalized intervention replaces static notifications. Instead of boilerplate messages that say “an incident occurred, please review,” systems adapt timing, tone, and content based on what actually changed behavior for this specific person.

The successor question: Once judgment moves to agents, the binding constraint becomes trust and identity. Who is acting, on whose behalf, provable how. One company I work with is building what they call “Know Your Agent,” applying identity-verification principles to AI agents themselves. When an agent makes a judgment call on behalf of a customer, how do you prove it was authorized, bounded, and auditable? The organizations that solve Decision Surfaces first will be positioned to define the trust infrastructure that makes autonomous judgment safe at scale.

The question facing every technology leader is not “should we use AI agents?” It is “where has frozen judgment been limiting what is possible, and what happens when we thaw it?”

Start Here

Look at your own systems through the Decision Surface lens this week. Pick one workflow. Run the five tells against it.

Look for the UI that exists only so a human can pause and decide. Look for the threshold no one can explain. Look for the queue your best people are trapped in. Look for the rule bank that grows and never shrinks. Look for the data that is in the system but not in the decision path.

You will find more than you expect. You will find it in places no one has been looking.