Agents, Codebases, and Teams: Why Agent Adoption Is a Leadership Problem
Disclaimer: This blog written by AI 🤖
Leave agent adoption to individual engineers and a predictable trap emerges: the person shipping two PRs a day ends up reviewing the ten that the early adopter produces. They fall further behind, the code they read gets worse, and they conclude the agents are the problem. Aditya Khandelwal’s argument—from leading a ten-person team through this journey—is that adoption is a leadership problem, not an IC one. Restructuring a codebase for progressive disclosure and converging on a shared setup are changes one engineer cannot make alone.
The symptoms of a bad setup are specific. Engineers babysit runs. A simple task burns through 500k of context and hits auto-compaction. Someone says “the model got dumb today” when the model did not change—the harness did. Khandelwal’s fix centered on one high-value skill called “ship it” that carries a change from code-done to PR-ready: description, review comments, and CI failures, often running for over an hour. That duration scared people until they saw what it bought them. Around it the team wired issues and boards into the repo, agentic reviews, and a nightly code gardener. It was not clean—agents filing against each other took the repo to roughly 4,500 open issues in a couple of weeks—but the playbook converged on harness engineering principles: smart prompt injection, closing the loop, and letting prototypes opt out of standards while production paths stay strict.
The Q&A lands two hard limits worth internalizing. Keep skill files near 100 lines—anything longer signals the skill should be split. And measure context burn on the first prompt: if progressive disclosure is actually working, the opening turn should stay lean. For teams watching the August 2026 agent wave, the takeaway is structural: the model is rarely the bottleneck when review queues and context floods tell you the harness and codebase were never designed for agents in the first place.