{
  "video": {
    "id": "aeTb5BdmTTc",
    "title": "Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab",
    "duration": 1017,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": "In person"
  },
  "analysis": {
    "video_id": "aeTb5BdmTTc",
    "title": "Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab",
    "one_liner": "A team lead who ran this with ~10 engineers argues that getting agents to work is a leadership problem, not an IC one — solved by per-codebase harness engineering, one high-value shared skill, and winning over the skeptics, not by a CLAUDE.md plus a mandate.",
    "summary": "Khandelwal traces the enterprise arc from early outsized leverage, to mandates and \"token maxing\", to shipped AI slop and sev-twos, to bolted-on budgets — and maps developers on two axes, fear and utilization, with the goal of moving everyone to low fear and high usage. He argues \"create a CLAUDE.md, add some skills\" does not survive contact with a real team, and that making engineers work well with agents is leadership's most impactful job because the highest-leverage code base changes require team buy-in. His playbook: progressive disclosure done properly, harvesting the best ICs' practices into a shared setup, one high-value skill (\"ship it\": code-done to PR-ready-for-review), and closing the loop with issues, boards, CI/CD, reviews and a nightly code gardener. He is candid about what broke — 400-500 issues in a couple of weeks, merge hell, people reverting to babysitting — and ends on skiing: pizza braking guarantees a crash, so commit.",
    "key_points": [
      "The enterprise journey in four beats: coding agents give a few people outsized leverage → companies mandate usage and \"token max\" → AI slop ships and sev-twos follow → model prices climb and budgets get bolted on.",
      "Two-axis framing for adoption: fear (\"is it coming for my job?\") versus confidence/utilization. Early on fear was high and utilization low; after the slop wave fear dropped but people concluded agents can't be trusted. The job is moving everyone to low fear, high utilization.",
      "Concrete smells that your setup is broken: engineers babysitting agents; \"the latest model is being really dumb today\" (the model didn't change — the harness did); silently blowing through 500k, 750k context and hitting auto-compact on a task that isn't complicated; long sessions needing constant intervention; a slop factory; wondering how model companies ship on a month-and-a-half to two-month cadence.",
      "The \"figure it out for yourself\" paradigm is actively harmful: people shipping 10 PRs a day look like gods, the 1-2 PR people inherit the review burden, see bad code, curse the agents, and never cross over.",
      "Harness engineering principles: smart prompt injection (treat the whole code base as a map so the agent gets the right context at the right time — e.g. a runbook lives in the code comments so an agent that greps into the file learns where to look); close the loop with a self-healing pipeline because slop is inevitable; iterate continuously, because a month of setup is not \"done\".",
      "The one high-value skill they invested in was \"ship it\": from code-done to PR-ready-for-review — opens the PR, writes the description and merge comments, handles review comments and CI failures. It often ran for over an hour, which scared people at first, and then became the proof that agents can be trusted unsupervised.",
      "Closing the loop in practice: issues and boards wired into the repo, CI/CD, reviews, and a code gardener that runs every night checking whether code is organized correctly (what \"correct\" means is per code base).",
      "What went wrong: 400-500 issues within a couple of weeks; multiple agents creating issues because they weren't wired correctly; people reverting to babysitting the moment something didn't work as expected; merge hell; prototypes needing an explicit opt-out from the rigorous standards applied to shipped code.",
      "Q&A on progressive disclosure: a hard limit of ~100 lines in SKILL.md because a skill is really a folder; keep CLAUDE.md/AGENTS.md a thin index that points to files rather than one big blob; measure it — roughly 20-25K tokens get taken anyway, so if the first prompt lands you at 40-50K, that isn't progressive disclosure."
    ],
    "takeaways": [
      "Stop treating agent enablement as each engineer's private hobby. Fund it as a leadership initiative, since the highest-impact changes — how the code base itself is organized — cannot be made by an IC.",
      "Find your best ICs, extract what makes the code base work for them, and ship those practices as a shared setup everyone can edit. Getting a skeptic to edit the shared setup is the signal that they've actually bought in.",
      "Build one skill valuable enough to convert people — the code-done-to-PR-ready loop is the reference example — rather than a broad library nobody trusts.",
      "Audit your first-prompt context burn as a hard metric: thin index files, docs in code comments, sub-100-line SKILL.md, and 40-50K tokens on load means something's wrong.",
      "Reset expectations on duration and on blame: an agent running an hour is good because you can go do something else, and \"the model is dumb today\" should be rewritten as \"how do I make it smarter\" — about the shared setup, not your personal one.",
      "Budget an explicit percentage of IC time to iterating on the harness, accept it produces no meaningful PRs up front, and give experiments an opt-out from the rigorous standards so prototype slop doesn't contaminate the pipeline."
    ],
    "topics": [
      "agents",
      "harness-engineering",
      "progressive-disclosure",
      "team-adoption",
      "context-management",
      "code-review",
      "skills",
      "engineering-leadership"
    ],
    "tools": [
      "CLAUDE.md (\"cloud MD\")",
      "AGENTS.md",
      "SKILL.md / skills",
      "\"ship it\" (their internal PR-automation skill)",
      "\"code gardener\" (their nightly code-organization agent)",
      "CI/CD",
      "Amazon AGI Lab",
      "AI Engineer (conference)"
    ],
    "quotes": [
      {
        "text": "The model didn't change, right? The hardness may have changed underneath.",
        "at": "04:41",
        "url": "https://www.youtube.com/watch?v=aeTb5BdmTTc&t=281s"
      },
      {
        "text": "Making engineers work well with their agents is truly the most impactful thing you could do as an organization.",
        "at": "05:49",
        "url": "https://www.youtube.com/watch?v=aeTb5BdmTTc&t=349s"
      },
      {
        "text": "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.",
        "at": "12:32",
        "url": "https://www.youtube.com/watch?v=aeTb5BdmTTc&t=752s"
      },
      {
        "text": "If you're pizza braking, you're going to crash. Like, no matter what. You have to commit to the speed",
        "at": "14:05",
        "url": "https://www.youtube.com/watch?v=aeTb5BdmTTc&t=845s"
      }
    ],
    "words": 3963
  },
  "summary_url": "/#aeTb5BdmTTc",
  "transcript": {
    "html": "/transcripts/aeTb5BdmTTc.html",
    "txt": "/transcripts/aeTb5BdmTTc.txt",
    "vtt": "/transcripts/aeTb5BdmTTc.vtt"
  }
}