Agent adoption is a leadership problem because shared codebase structure and agent setup require team-wide changes.
2
A good harness gives agents the context they need when they need it, closes the loop on slop, and keeps improving over time.
3
A shared "ship it" skill can take code from completion to a review-ready pull request, including descriptions, review comments, and CI failures.
Summary
Aditya Khandelwal explains why advice for making one repository work well with coding agents often fails when a whole team adopts it. Individual adoption creates uneven output, which leaves less productive engineers with more review work and worse code to read. Khandelwal argues that leadership has to create a shared setup, restructure the codebase for progressive disclosure, and keep improving the harness. His team built a high-value "ship it" skill that handled the path from finished code to a pull request ready for review. They also connected issues, boards, CI/CD, agentic reviews, and a nightly code gardener to the repository. The approach had failures, including hundreds of issues created by agents and disagreements about how the setup should work. Khandelwal says teams should treat experiments differently, expect long agent runs, and stop blaming the model when the harness is the real problem. In the Q&A, he recommends thin skill files and measuring context use on the first prompt.
Team adoption follows a cycle from mandates to skepticism
Khandelwal describes an enterprise pattern that began with a few people getting unusually strong results from coding agents. Companies responded by mandating use and pushing token consumption, after which AI-generated slop and incidents appeared. Teams then pulled back, added budgets, and saw that tokens had a cost. He maps individual reactions on two axes: fear about losing a job and confidence in using the tools. Early on, fear was high and use was low. After seeing early adopters, people used agents more. Mandates increased usage without increasing confidence, while shipped slop reduced fear because engineers still felt needed. The goal is to move people toward lower fear and greater confidence.
Babysitting and context waste show that the setup is failing
A repository is not working well when engineers have to watch agent runs constantly. Khandelwal says teams often blame the latest model for being dumb when the model has not changed and the harness has. Other symptoms include silently burning context and money, using 500k tokens or more on a simple task, hitting auto-compaction, and maintaining long sessions that need constant intervention. A constant slop factory is another warning. He also points to the gap between a team that wonders how other companies ship quickly and organizations that have built a setup that lets agents work with less supervision.
Khandelwal says making engineers work effectively with agents is a company responsibility, not something each individual contributor can solve alone. A team that leaves everyone to figure it out will get uneven productivity. Engineers producing ten pull requests a day can leave colleagues who produce one or two with the review burden. Those colleagues then encounter worse code, struggle to ship, and blame the agents. Codebase organization and shared agent practices require team buy-in, so leadership can make changes that one engineer cannot. The work also requires time from engineers even when it does not immediately produce a product pull request.
The harness should inject context, repair mistakes, and keep changing
Khandelwal gives three principles for harness engineering. First, the codebase should provide the right context at the right time without requiring the engineer to prompt for it manually. Documentation can live in code comments so an agent that reaches a file can find the relevant runbook. Second, teams need a loop that detects and removes slop because some bad code will enter the system. Third, the setup needs continuous iteration. The repository, tools, and expectations will change, so a team cannot configure the harness once and consider the work finished. He also says teams should treat fear and other human reactions as part of the adoption problem.
Progressive disclosure starts with a shared setup built from strong practices
The team's playbook began with the basics, done consistently. Khandelwal calls progressive disclosure very powerful: agents should receive an index and follow pointers to more detailed material as the task requires it. The team studied how its strongest individual contributors made the codebase work for them, then shared those practices. This required accepting that each person's setup was imperfect and giving up private conventions. The result had to be a shared setup that people could edit and improve. Khandelwal presents this as a rough approach rather than a fixed recipe, because the right organization depends on the repository.
A long-running ship-it skill carries work to a review-ready PR
The team's highest-value skill was called "ship it." Once an engineer finished coding, the skill handled the work needed to make the change ready for review. It opened the pull request, prepared the description, handled review comments and merge comments, and worked through CI failures in repeated loops. Runs often lasted more than an hour, which initially worried people. That concern changed when engineers saw that the skill let them stop babysitting the agent and gave them confidence that it could complete the process. Khandelwal uses this one shared skill as evidence that a focused workflow can build trust more effectively than many disconnected instructions.
Closing the loop exposed failures that the team had to absorb
The team connected issues and boards to the repository, added CI/CD and agentic reviews, and created a nightly code gardener that examined the code for organization problems. The setup was messy during development. Agents created issues against one another, and the repository reached roughly 400 or 500 open issues within a couple of weeks. When people found that the system did not work as expected, some wanted to return to babysitting agents. Khandelwal says their feedback had to go back into the skill instead. He also argues that long agent runs can be useful because more reasoning time can produce better output, even though the team must deal with merge conflicts and other costs.
Experiments need a separate path from production standards
Khandelwal says teams should let prototype code opt out of the strict standards applied to code that will ship. Experiments can generate code that is not relevant to production, so treating every prototype as if it must meet all production requirements creates unnecessary friction. He also says people's position on the fear and confidence axes changes with circumstances. When an agent performs badly, the team should investigate whether the model changed or whether the harness needs work. The useful question is how to make the shared setup smarter, rather than treating the problem as a flaw in one person's private configuration.
A thin index and first-prompt context use test progressive disclosure
In the Q&A, Khandelwal says a skill file should not be overloaded. His team set a hard limit of about 100 lines for a skill.md file and treated the skill as a folder containing more material. Runbooks should be referenced in code comments so an agent can find them after reaching the relevant file. CLAUDE.md or another agent instruction file should remain a thin index that points to the right files. He recommends testing the first prompt: watch whether the agent knows where to go and measure how much additional context it loads immediately. If the initial load grows to 40,000 or 50,000 tokens, he says progressive disclosure is not working.
"You want to treat your entire code base as one way to smartly prompt inject the model with just the right context at just the right time."07:22
Who should watch
You lead a team where a few engineers get strong agent results while others inherit the review burden and worse code.
Your repository has long agent sessions, frequent intervention, high context use, or repeated complaints that the model has become dumb.
You are designing shared skills and repository conventions and need practical limits for progressive disclosure.
