In mid-2026, a software engineer generating 10 pull requests a day looks like a god compared to a colleague shipping one or two. The slower engineer doesn’t just fall behind on output — they get buried under the review burden of AI-generated code, much of it slop. “Not only can they not ship, they’re going to actually see bad code and then curse the agents,” Aditya Khandelwal of Amazon AGI Lab told the AI Engineer conference. That dynamic, he argued, is not a tooling problem. It’s a leadership problem — and most organizations are solving it exactly wrong.
Khandelwal’s talk inverted the dominant conversation around coding agents. The field is saturated with content about how to set up your own codebase: which skills to add, which context files to maintain. But that playbook, he said, “seems to break the moment you actually try to use it with your team in your actual production setup.” Having just led a 10-person engineering team through months of agent adoption — including a near-disastrous rollout and a subsequent rebuild — Khandelwal offered a diagnosis of what fails and a playbook for what works. His central claim: making agents work inside a team is not an individual-contributor problem. It is an organizational design problem, and the companies that internalize that will be the ones shipping on the six-to-eight-week cadence that AI labs have achieved.
The four-act drama every engineering org is living through
Khandelwal frames the last few years of enterprise AI adoption as a sequence nearly every engineering organization has experienced. It starts with a few individuals getting outsized leverage from coding agents, raising the “is this AGI?” question. Companies look at those outliers and draw the wrong conclusion: if one person can get that much leverage, mandate it for everyone. The result is what he calls token-maxing — “a galaxy brain moment.” Then comes the correction: AI-generated slop ships, production incidents get filed, and organizations retrench. “I don’t think this is the best option here,” becomes the prevailing mood. Finally, model prices climb, budgets get bolted on, and the questions shift to return on investment.
The more useful way to understand what’s happening to individual engineers, Khandelwal suggests, is a two-axis map. One axis measures fear — is this technology coming for my job, or is it just a handy tool? The other measures confidence in execution — do I use it a lot without really knowing how, or do I use it with genuine competence? The goal is the far corner: low fear, high competence. But mandates push utilization up without pushing judgment up. Slop-filled outcomes then evaporate the fear for the wrong reasons — “it just ships slop, I’m still needed” — leaving engineers using the tools a great deal without actually knowing how to make them work well.
StageFear of job lossConfidence in executionWhat shiftsInitial panicHighLowNobody knows how to operate the toolsEarly-adopter leverageFallingRising”I’m still needed if I figure out how to use this thing”Mandate and token-maxingLowUse spikes, judgment flatEngineers use it more without knowing it wellPost-slop retrenchmentLow — “it just ships slop”High but untetheredFear evaporates; tools aren’t used well either
Six symptoms of a broken agent setup — and what they actually mean
The standard answer, Khandelwal observed, is to create a context file, add some skills, and ask whether the problem is solved. It isn’t. The evidence comes in six recurring symptoms, all of which point to the same diagnosis: the harness is broken, not the model. “The model didn’t change,” he stressed. “The hardness may have changed underneath. But if it’s acceptable to small changes in hardness, clearly your code base isn’t set up well.”
When engineers find themselves constantly babysitting their agents, the setup is wrong — agents aren’t trustworthy in this particular codebase. The complaint that “the latest model is so dumb today” is a signal that the harness is too brittle to tolerate small shifts in model behavior. Blowing through 500,000 tokens, then 750,000, then hitting auto-compact at a million tokens on what should be simple tasks, means context is being silently burned and money set on fire. Long sessions that need constant intervention mean the agent simply cannot navigate the codebase on its own. A constant stream of slop means no loop exists to detect and remove bad output. And the final symptom — watching other companies ship astonishingly fast while asking how they do it — has a single answer: “Clearly they have something which we don’t.”
That something is not a better model or a better engineer. It’s a deliberately engineered team setup. “Instead of saying the model is so dumb,” Khandelwal said, “we have to ask, how can I make it smarter?”
Harness engineering: three principles
Khandelwal calls the actual engineering work “harness engineering,” and it rests on three principles that reframe the problem entirely.
First, smart prompt injection. Treat the entire codebase as the prompt. The goal is to inject the right context into the model at the right moment without a human doing it — a map that tells the agent where to find what it needs when it needs it. One concrete pattern: if a piece of code has associated documentation, the documentation lives in the comments. When the agent grabs the file, it reads the comment and finds the fuller description elsewhere.
Second, close the loop. Build a self-healing system because slop is inevitable. The pipeline must detect bad output and remove it continuously. Without this, the codebase accumulates low-quality agent output that erodes trust and creates real operational risk.
Third, iterate continuously. This is not a one-month project. The model landscape shifts constantly, and the harness must be treated as a permanent organizational responsibility.
Above all, Khandelwal insisted on a point that gets lost in technical discussions: “Treat it like a human problem, guys. Fear is real. Human emotions are real. We should recognize it.” Mandating adoption does not work as a strategy. Engineers need to be met where they are on both the fear and confidence axes, and moved toward genuine competence — not just higher utilization.
The five-move playbook that worked for a 10-person team
Khandelwal was explicit that his team’s approach is a rough playbook, not gospel. But it is unusually concrete and sequenced.
Move one: progressive disclosure. Find the best individual contributors, extract the practices that make the codebase work for agents, and ship those practices to everyone as shared guides. This turns individual tacit knowledge into team capability. The hardest part, he noted, is getting engineers to accept that their setup is imperfect and needs iteration.
The mechanics are specific. Skill files have a hard limit of roughly 100 lines — a skill is a folder, not a document, and overloading the skill file defeats the purpose. Runbooks live in code comments: if an agent grabs a file with operational requirements, the comment tells it where the full description lives. The main context file must be a thin index, not a comprehensive document, pointing the agent at the right files rather than loading everything upfront.
The success metric is behavioral and quantitative: watch the agent’s context burn on the first prompt. Roughly 20,000 to 25,000 tokens get consumed regardless. But if the agent climbs to 40,000 or 50,000 tokens on a simple prompt, something is wrong — it is not progressing through disclosure; it is dragging in everything.
Token burn on first promptWhat it indicates~20K-25K tokensNormal; index is working as a thin pointer~40K-50K tokens or higherProblematic; agent is loading everything, not progressing through disclosure500K → 1M tokens, hitting auto-compactContext being silently burned; codebase setup is badly configured
Move two: invest in one high-value skill. Khandelwal’s team built what they called “Ship It” — a single skill that handles everything from code-complete to PR-ready. It opens the pull request, addresses review opinions and comments, writes descriptions and merge comments, and fixes CI failures, all running in loops that often last over an hour. This was the psychological turning point. A single demonstrable artifact proved that “this AI thing can actually work for me, I don’t need to constantly babysit it.”
The long runtime initially scared engineers who weren’t used to letting an agent work unattended. But Khandelwal reframed it entirely. “The moment we hit this reasoning paradigm, the longer the agent thought, the better its output,” he said. A long-running agent isn’t a sign of failure — it’s a sign of trust. “It’s good if agents take too long. That means you can actually go off and do other things and you have confidence that they’re doing the right thing.” Once the team saw the value, they got invested.
Move three: close the loop in the repo. This meant wiring issues and boards into the repository, adding CI/CD and automated review layers, and deploying a nightly agent called “Code Gardener” that scans the codebase for mis-organization. Slop gets detected and removed automatically instead of accumulating.
Move four: win over the skeptics. Get the most resistant engineers to edit and play with the shared setup. The moment a skeptic modifies the harness, they’re invested — and that, Khandelwal said, is the truest signal of buy-in.
Move five: iterate constantly. Budget a percentage of individual contributor time for improving the shared setup itself, with no expectation of meaningful PRs upfront. This accepts that the harness is never finished and is worth direct investment.
What broke — and what the failures taught
Khandelwal was candid that the playbook did not run cleanly. The problems, and the reframes that made them survivable, are as instructive as the successes.
Within a couple of weeks, the repository exploded to 400 to 500 open issues — a staggering number for a single repo — because multiple agents, not yet wired correctly, were all creating issues independently. The lesson: agents need to be pointed at the right boards and issue templates before they’re given autonomy.
When a skeptic saw the setup not working exactly as expected, the easy reaction was “I’m just going to go back to babysitting my agent.” Khandelwal’s rule: don’t fight it. Take the feedback and put it back into the skill. Disagreement is the raw material for iteration.
Merge conflicts were inevitable when agents generated code in parallel. The team had to build ways to manage it rather than hope it would go away. Generated code that wasn’t meant to ship was being held to production standards, so the fix was to let prototypes opt out of the rigorous standards applied to shipping code.
And people vary on the spectrum day to day. The right response is diagnosis, not discipline: talk to the engineer, figure out whether the model changed, whether the harness hardness shifted, whether something needs revisiting in the shared setup.
The deepest reframe came from the agent runtime problem. When agents ran for over an hour, people got nervous. Khandelwal saw it differently. In the reasoning paradigm, longer thinking reliably produces better output. “It’s good if agents take too long,” he said. That mindset, he argued, should apply to the entire codebase and skill setup, not just individual tasks.
What separates the organizations shipping on two-month model cadences from everyone else is organizational commitment: dedicated harness engineering, continuous iteration, and a willingness to let agents run and occasionally fail. Khandelwal closed with a skiing metaphor: “If you’re pizza braking, you’re going to crash. You have to commit to the speed in order to actually turn and truly ski. Just be okay with failing. You have to go full send and be okay with falling. The point is to be able to recover from that — and that will allow you to truly feel the AGI.”
The tensions worth watching are real. The “longer is better” logic cuts directly against the budget-consciousness of the cost-bolting phase. The investment in shared harness engineering requires a percentage of IC time with no immediate PR yield, which many organizations will struggle to justify. Whether the 10-PR-per-day versus one-to-two-PR-per-day divide narrows across the industry — or widens into a permanent chasm between harness-equipped organizations and everyone else — will be the real test of whether Khandelwal’s playbook spreads.