Talk by Aditya Khandelwal (Amazon AGI Lab) arguing that AI coding agent adoption is a leadership problem rather than an individual contributor one. Drawing on his experience leading a ten-person team, he describes symptoms of a bad agent setup (babysitting runs, runaway context consumption, misattributed harness regressions as model decline), why solo adoption advice fails on teams due to review burden, and the fixes that worked: restructuring the codebase for progressive disclosure, a shared setup, and one high-value "ship it" skill that carries a change from done code to PR-ready (handling descriptions, review comments, and CI failures, often running over an hour). Also covers wiring issues and boards into the repo, agentic reviews, a nightly code gardener, and failure modes such as agents filing against each other and generating roughly 4,500 open issues. The Q&A discusses progressive disclosure strategies, a practical limit of ~100 lines per skill file, and using first-prompt context burn as a test of whether progressive disclosure works. # Channel Identity Observations ## Source Overview - **Video title:** "Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab" - **Format:** Conference talk (speaker references being at "AI Engineer" conference: *"You're at AI engineer, right? Like this conference is all about..."*), followed by audience Q&A. ## Explicit Self-Description Evidence - **Speaker affiliation in title:** "Amazon AGI Lab" appears in the video title, establishing organizational affiliation at the presentation level. - **Leadership claim:** The speaker self-describes team-lead experience: > "I was leading a team of like 10 people over the last few months, and I think we found like a good solution, and I want to share that with you guys." - **Positioning claim:** Speaker differentiates his content from existing individual-focused material: > "There's so much content about... how do you set up your own code base to like work well with agents... But it all seems to break the moment you like actually try to use it with your team." ## Observable Presentation Patterns - **Topic scope demonstrated:** Practical engineering-team adoption of coding agents — harness engineering, progressive disclosure, skills, CI/CD integration, review workflows, and human/organizational adoption dynamics. - **Evidence:** The bulk of the talk covers team playbook items (a "ship it" skill, a nightly "code gardener", wiring issues/boards into the repo) and adoption framing (fear/confidence axes for developers). - **Intended audience:** Engineering leaders and practitioners at AI-focused engineering organizations, inferred from: - Direct address: *"this is the enterprise journey"* and *"It isn't really an IC's job. It's a job for leadership."* - Conference context: *"You're at AI engineer, right?"* - Technical depth assumed (Claude MD files, token/context budgets, grep behavior) without basic explanation. - **Presentation style:** Informal, first-person practitioner talk with personal anecdotes (skiing analogy, Hindi term "gyan") and a Q&A segment where the speaker repeats questions "for the recording." ## Claims vs. Demonstrated Patterns - **Claimed:** A working team-scale solution exists ("we found like a good solution"). - **Demonstrated (with caveats stated by speaker):** The speaker explicitly disclaims completeness — *"I'm not going to... emphasize... this is the exact way to do it"* and *"we faced a ton of issues while doing this"* (e.g., "4 or 500 issues" within weeks, merge hell, slop). - **No channel-wide self-description** (e.g., "about this channel" statement) is present in the transcript; identity evidence is limited to the title, the talk itself, and the conference context. # Delivery Observations — Aditya Khandelwal, "Agents, Codebases, and Teams" ## Tone & Register - **Conversational, informal talk style** throughout, marked by heavy filler words: - "like" appears extremely frequently: *"And like I think for the longest time, like the one thing that's bugged me"* - "you know" recurs constantly: *"And you know, essentially money is being lit on fire"* - **Casual, slang-heavy vocabulary**: "token max," "galaxy brain moment," "AI slop," "slop factory," "long ass sessions," "merge hell," "go full send," "gyan." - Speaker blends informal slang with concrete numbers (500k/750k context, 100-line skill.md limit, 20–25K tokens), giving the talk a practitioner's grounding rather than purely abstract advice. ## Recurring Phrases & Verbal Habits - **"I can't emphasize this enough"** — used repeatedly for emphasis: - *"iterate continuously. And I can't emphasize this enough"* - *"Get people invested and I can't emphasize this enough. You have to win over the skeptics."* - **"Right?" as a rhetorical tag** — extremely frequent, used to check shared understanding: *"something's wrong. Is, you know, one of the things…"*, *"So these are like some really powerful strategies…"* - **"You got to…"** as a recurring imperative form: *"you got to realize that," "You got to do them right," "you got to treat it like a piece of feedback."* - **"Like" as a softener before claims**: *"like clearly life's not that simple and like stuff's messy, right?"* ## Teaching & Structural Habits - **Narrative-journey framing**: opens with a recap of the industry's arc ("So we started, you know, coding agents took off… And then the inevitable happened"), positioning advice as learned experience. - **Numbered, enumerated principles**: *"The first thing is… The second is… And then the third most important thing…"* — repeated across sections. - **Two-axis framing device**: fear vs. confidence/utilization spectrum, explicitly flagged as the key mental model: *"this is the framing that I want everyone to keep in mind."* - **Symptom-then-solution structure**: first lists failure signals ("if you're babysitting your agents… something's wrong"), then pivots to *"how do we solve this correctly?"* - **Rhetorical questions to advance sections**: *"Step one, create a Cloud MD. Step two, add some skills. Is that it? Do we like solve it?"* - **Hedged prescription**: explicitly disclaims his playbook as non-definitive: *"I'm not going to over emphasize on this is the exact way to do it, but this is like roughly how we did it."* ## Personal Anecdotes & Color - Cites direct leadership experience: *"I was leading a team of like 10 people over the last few months."* - Cultural aside: *"enough gyan or as like it's more like the Hindi way to say… I'm kind of giving you sermons."* - Closes with a **skiing metaphor**: *"If you're pizza braking, you're going to crash… you have to go full send and be okay with falling."* ## Q&A Delivery - Restates questions for recording: *"I'm going to repeat the question for the recording."* - Answers with concrete, quantified tactics (100-line limit, thin index in CLAUDE.md, 40–50K token threshold as a "something's wrong" signal). - Ends with an open invitation: *"feel free to find me. Happy to talk about harness engineering."* ## Uncertainty Notes - Repetition of "like," "right?," and "you know" is clearly stable across the talk; the **relative frequency of each** cannot be precisely quantified from the transcript alone. - No timestamps beyond bracketed line markers are available; observations about pacing, pauses, or audience reaction (other than implied Q&A) cannot be made. # Position Record: "Agents, Codebases, and Teams" — Aditya Khandelwal, Amazon AGI Lab ## Speaker - **Aditya Khandelwal**, presenting on team adoption of coding agents, drawing on experience leading a team of ~10 people. ## Core Thesis - Most content covers individual-repo setups for agents; these setups **break when used with a real team in production**. Khandelwal claims to have found a workable team solution and shares it. ## The Enterprise Journey (as narrated) 1. Coding agents took off; a few individuals got **outsized leverage**; people asked "is this AGI?" 2. Companies **mandated** usage and "token maxed" — which he calls "clearly a galaxy brain moment." 3. **AI slop shipped**, causing sev-twos (companies unnamed); people retracted. 4. Model prices climbed; budgets were "bolted on"; "money is being lit on fire." ## Two-Axis Framing of Individual Adoption - **Fear axis**: from "is my job at risk?" to "handy tool." - **Utilization/confidence axis**: low usage (don't know how) to heavy usage. - Trajectory described: high fear/low usage → early-adopter leverage → mandated heavy use with skepticism → slop-era complacency ("I'm still needed") with higher confidence. - Goal: move everyone to **low fear + high utilization**. ## Signals the Setup Is Broken - People **babysitting their agents**. - Complaints that "the latest model is being really dumb today" — he argues the model didn't change; possibly the **hardness changed**, indicating a poorly set-up codebase. - Silently burning context and money (e.g., blowing through 500k–1M context, hitting auto-compact on simple tasks). - Long sessions needing constant intervention; constant "slop factory." - Asking "how are model companies shipping so fast?" — "clearly they have something which we don't." ## Prescribed Principles ### 1. It's a leadership problem, not an IC problem - Making engineers work well with agents is "the most impactful thing" an organization can do. - In a "figure it out yourself" paradigm, high-PR producers look like gods while 1–2 PR/day engineers absorb the **review burden**, see bad code, curse the agents, and never climb the curve. - Codebase-wide changes require **team buy-in** impossible for an IC alone. ### 2. Harness engineering (per codebase) - **Smart prompt injection**: treat the codebase as a map so the model gets the right context at the right time (e.g., documentation living in comments that points to runbook files). - **Close the loop**: slop is inevitable; need a self-healing pipeline to detect and remove it. - **Iterate continuously**: never a one-month-and-done effort. ### 3. Treat it as a human problem - Fear and human emotions are real; mandating alone "is just not going to work." ## The Playbook (as practiced) - **Do the basics**: progressive disclosure is "really, really powerful." Find best ICs' practices and propagate them as a **shared setup** — hard because engineers resist admitting their setup is imperfect. - **One high-value skill**: "ship it" — handles everything from code-done to PR-ready-for-review (PR opening, comments, descriptions, CI failures); sometimes ran **over an hour**, which scared people but built trust once value was seen. - **Close the loop in tooling**: wired issues/boards into the repo, CI/CD, "gigantic reviews," and a nightly **code gardener** checking organization. - **Win over the skeptics**: skeptics must be able to **edit and play with the shared setup** — that's the true sign of investment. - Budget **X% of IC time** on iterating the setup — no meaningful PRs upfront, but "it's worth it." ## Problems Hit (stated honestly) - **Too many issues**: blew up to 400–500 issues within weeks; multiple agents incorrectly creating issues. - **Lack of agreement**: when things weren't perfect, people easily reverted to babysitting; instead, feed their complaints back into the skill. - **Agents taking too long**: reframed as *good* — long thinking means better output in the reasoning paradigm, freeing humans for other work. - **Merge hell**: unavoidable; must be dealt with. - **Experimental slop**: treat prototypes as their own category, opted out of rigorous standards. - **People vary on the spectrum daily**: diagnose whether model hardness changed rather than blaming the model. - Mindset shift: not "the model is so dumb" but "**how can I make it smarter**" — editing the *shared* setup, not "my" setup. ## Q&A: Progressive Disclosure Strategies - Keep **skill.md under ~100 lines**; the skill is really a folder. - Embed **runbooks in code comments** so agents that grep into code find pointers. - **CLAUDE.md / AGENTS.md as a thin index** pointing to the right files, loaded in the first prompt. - Diagnostic: watch the first prompt — is the agent grepping aimlessly or does it know where to go? Baseline ~20–25k tokens; **40–50k+ means something's wrong**. ## Closing Metaphor - Skiing analogy: pizza-braking guarantees a crash; you must commit to speed. **"Go full send, be okay with falling"** — the point is recovery, "and that will allow you to truly feel the AGI." ## Qualifications Preserved - He repeatedly disclaims prescription: "I'm not going to over-emphasize that this is the exact way to do it... take from it what you choose." - "I don't want to say this is perfect — we faced a ton of issues." - Harness engineering is only lightly covered because "there's a lot of smart people" at the conference covering it. # Video Attribution Record ## Video - **Title:** Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab - **Video ID:** `01a15ca7-fd28-76e8-97b2-74f6721e873a` ## Speakers & Roles - **Aditya Khandelwal** — **Sole speaker / presenter**. Identifies affiliation via video title (Amazon AGI Lab). Self-identifies as having led a team of ~10 people; speaks in first person throughout, including a Q&A segment. - **Unnamed audience questioner(s)** — One question is asked off-mic; the speaker repeats it for the recording ("strategies that you found best for progressive disclosure"). Questioner identity not established in transcript. ## Provenance & Source Notes - **Personal experience claims:** Speaker attributes his playbook to leading a ~10-person team "over the last few months." No external data, citations, or named sources are referenced. - **Unverified general claims:** References industry-wide phenomena ("AI slop shipped, and there's a bunch of sev twos. I'm not going to name which companies"), token costs, and enterprise mandates — presented as anecdote, not sourced evidence. - **Named tools/files:** Mentions `skill.md`, "Cloud MD"/"agent's MD" files, CI/CD, PR workflows, and a custom "ship it" skill and "code gardener" from his team's setup. ## Promotional Segments - None detected. No product, service, or sponsorship promotion present. ## Availability Limits - **Curated metadata:** Not supplied beyond title; speaker affiliation taken from title only. - **Comments:** Availability unknown (no metadata provided). - **Q&A:** Only one audience question captured; the questioner's identity and any additional questions are not in the record. \>\> Today, I'm going to be talking about agents code bases and teams. Essentially, how do you get your team to actually ship together with agents? And like, I think for the longest time, like the one thing that's bugged me is like there's so much content about, you know, how do you set up your own code base to like work well with agents, you know, like what skills do you add? You know, this skill's better, that setup's better. But it all seems to break the moment you like actually try to use it with your team in your actual production setup. And like for individual repos, it kind of makes sense. But the moment you actually try to use it with your own like team setup, it tends to break. And like I think over the past few months, I've figured out how to make it work with a team of folks. So like I was leading a team of like 10 people over the last few months, and I think we found like a good solution, and I want to share that with you guys. But before we get into that, I just want to recap like, you know, what's been the journey that we've been on. Right? So we started, you know, code coding agents took off, and a few people got really, really good leverage, right? And I think all of us were kind of asking like, is this AGI? You know, like did we achieve it? Then, you know, companies took that and said, "Well, if one person can do so well, let's just get everyone and let's mandate it." And like token max, right? And that was clearly a a galaxy brain moment, right? And then the inevitable happened, you know, AI slop shipped, and there's a bunch of sev twos. I'm not going to name which companies, but you know, essentially you saw people kind of retracting. They said, "I don't think I don't think this is the best option here." And eventually model prices you know, climbed. We saw, you know, people figured out that tokens have to be paid for. Like you just can't token max your way through life. And budgets got bolted on. And you know, essentially money is being lit on fire, and the money has to come from somewhere. So, given this journey, I want to actually like this is the enterprise journey, right? And what does that do for a single developer? And I think this is an important framing cuz it really talks about people as a part of a team, right? And I want to look at it from like two axes. So, there is the fear axis where people lie on the spectrum, right? They're coming It's like Is it coming from my job? Like am I going to be out of a job? Or is it like a really handy tool? And they're really, you know, they're not that fearful. Versus like the confidence they have in how much they're executing it. So, they can either use it a lot or they can use it, you know, not that much because they don't really know how to use it that well. Now, when we started, like people said, "Oh, you know, what is this? Is this the end? Like am I needed?" And fear was pretty high. Utilization was pretty low cuz people didn't really know how to use it. And then when a few people got outsized leverage, you saw, you know, early adopters basically people saw them and people said, "Okay, well, it looks like I'm still kind of needed if I figure out how to use this thing. So, let me actually try using it, right?" And then we saw, you know, mandates and token maxing, and people kind of got a little skeptical. Like confidence stayed the same, but people tried to use it a lot more, right? And then we realized, uh you know, there's a bunch of slop shipping, there's self-tours, and I, you know, it's like I'm not really that scared cuz, you know, it just slip it just ships slop. Like I'm going to still be needed. And they don't even know how to use it that well cuz like now the confidence is greater, right? And so you got to figure out how to get people from all the way wherever they are on the spectrum to where they're not fearful and they're actually using it a whole lot more. And this is the framing that I want to like I want everyone to keep in mind as they're actually trying to get a team to adopt good like AI usage and good AI patterns, right? And so, the The is, you know, what does it take? Step one, create a Cloud MD. Step two, add some skills. Is that it? Do we like solve it? You know, I think we all know like you guys are here because like clearly life's not that simple and like stuff's messy, right? And I think a few people might ask, you know, why doesn't this work? Like isn't that what like everyone does? And I want to like just talk about a few things you might see that actually indicate that yeah, like this isn't working. So, the first thing is if you're babysitting your agents, it's not the right setup, right? And you got to realize that. If you're seeing people in your team babysitting their agents, something's wrong. Is, you know, one of the things that I heard a lot was is, you know, insert whatever latest model there is being really dumb today. The model didn't change, right? The hardness may have changed underneath. But if it's really like that's that's acceptable to like small changes in the hardness, clearly your own code base isn't set up well. It's silently burning context and money. Like you don't realize it, you know, you go you blow through like 500k context, you might go to like 750k million and hit auto compact even though you're not doing like a really complicated task. Clearly something's wrong. You know, if you have long ass sessions needing constant intervention, there's still something that's wrong. If you're getting a constant slot factory, obviously know like things are things are not good. And if you're asking if you find yourself asking, you know, how are these other companies shipping so fast? Like how are model companies releasing models at like a month and a half two-month cadence? Clearly they they have something which we don't, right? And so, I guess everyone's kind of thinking so, you know, how do we solve this correctly? And so, I think the first thing to realize is we need to frame it correctly, right? It isn't really an IC's job. It's a job for leadership. It's a job for the company, right? Making engineers work well with their agents is truly the most impactful thing you could do as an organization. Because that's going to enable your engineers to ship faster and with confidence and avoid, you know, a lot of incidents. If we live in this figure it out for yourself paradigm, like people are going to get outsized productivity, some people aren't, and like the people who are generating like 10 PRs a day are going to like look like, you know, gods compared to people who are shipping like one to two. And the one to two PR people are actually going to get left with the review burden. And that's actually a really, really bad thing. Cuz now not only can they not ship, they're going to actually see bad code and then curse the agents and hence not be able to get on to the let's ship 10 PRs, right? And so it's really important to do this. If it's a problem facing the team, there's a few things you can do, right? The most impactful things that you can do to set up your code base to like make it work well require team buy-in. You can't just like if you want to change the way your code base is organized, you can't do that as an IC, right? And if you're treated as a leadership problem, then you can do things like this. So, the other thing this needs is harness engineering, right? Per code base. And I think there's a lot of content on this, so I just want to talk about a few principles, but I don't want to like make this talk about that because there's a lot of smart people. You're at AI engineer, right? Like this this conference is all about people telling you how to you best set up, you know, your code base to make things function well. So, I don't want to talk too much about this, but there's a few key principles here. Smart prompt injection is one of them. You want to treat your entire code base as one way to that so that you're able to like smartly prompt inject the model with just the right context at just the right time. Without you needing to do it. And that's the framing. You want to be able to say, "Okay, I've set it off on this task. It has like a map of how to find the things it needs at the time it needs it." If it's looking at some code and that code has, let's say some documentation, it the documentation needs to live in the comments. So, if it ever grabbed into that code, it reads the comment, goes to that file, finds all the information about it. That's just one example. The second is close the loop, right? You got to make a self-healing system cuz slop is inevitable. There is going to be some slop that's going to seep in. But, you need to have a pipeline and a way to close the loop to remove the slop, to detect it, and to be able to like self-heal the system. And then you need to iterate continuously. And I can't emphasize this enough. Like, you can't assume that you do this for a month and you're done. Like, things are going to change constantly underneath. So, you need to keep this as one of the things that you have to do as an organization. And the third most important thing is treat it like a human problem, guys. Like, this isn't It's not, you know, oh, it's this tool. Like, people will figure it out. Let's just mandate our way through life. Like, that's just not going to work. So, treat it like a human problem. Fear is real. Human emotions are real. We should recognize it. So, you know, enough gyan or as like it's more like the Hindi way to say like, you know, I'm enough prof like I'm kind of giving you sermons. But, like, how do you really do this, right? Like, these are all principles. What's the real playbook? So, here's what we did and here's like I'm not going to over like emphasize on this is the exact way to do it, but this is like roughly how we did it and you can take from it what you choose. The first thing is do the basics, right? You got to do them right. Progressive disclosure, I can't emphasize this enough, is really, really powerful, right? Find your best ICs and find what how they are making the code base work for them. Take those practices and pass them or guide. People can't live in their own practices. And this is really hard for engineers to do it. It's basically accepting that my setup is imperfect. And like engineers don't like to hear that. But you got to figure out a way to find those best practices and ship them across. Make sure that that's kind of a shared setup. The second thing we did was there's one high value skill that we invested in. In our case it was this thing called ship it. What it did was the moment you're done with your code, it takes care of everything from code done to PR ready for review. Which means you got to open a PR, figure out your opinions, handle the handle all the comments, you know, handle all the PR descriptions, the merge comments, everything, right? It handles CI failures. It basically runs through these loops. And what this meant was often the skill was running for over an hour. And that scared people, but once you actually figure out once they saw the value, they get invested, right? Because it's one skill which tells them, "Okay, this AI thing can actually work for me. I don't need to constantly baby sit it. I can trust it." The third thing and really important is to close the loop, right? So we wired issues and boards into the repo. Like we added CICD. We added gigantic reviews. We have like a code gardener that actually goes back and looks through a whole bunch of like every night it'll run and look at the code and check if something like not organized correctly. What does correct organization mean will depend on your code base. Get people invested and I can't emphasize this enough. You have to win over the skeptics. It's really easy to say like the skeptic is just someone who's scared. It's really hard to get them to buy in, but if you can get them to buy in, you know you're doing something right. You have to get them to be able to edit and play with the shared setup cuz that's the true way you know that they're actually invested, right? And this is where you got to it ensure you're iterating constantly. If people are like and this is the hardest thing for engineers again cuz you're basically saying I'm never going to like get to perfection in my setup. But you got to be okay with that. You have to do it and you You to treat it like, you know, X% of your IC time is probably going to be spent on it trading on this thing, which is not going to lead to like meaningful PRs like up front, but it's useful and it's worth it. And, you know, I don't want to say this is perfect, right? Like we faced a ton of issues while doing this. And I'm just going to walk you through some of them. But it's an iteration loop, so you got to treat it like a piece of feedback. So, what are the problems we hit, right? There are too many issues. Like when we started like we blew up to like 4 or 500 issues uh without like, you know, just I think within like a couple of weeks, which is a crazy number for like a repo. And then, you know, there are so many like different agents all trying to create issues cuz they've not been wired correctly. There's a lack of agreement. People, you know, as soon as people saw like, "Oh, this isn't working perfectly or the way I expected it." There is super easy for them to say, "You know what? I'm just going to go back to babysitting my agent." You don't want that. You want to actually take their feedback and put it back into the skill and improve the skill. Agents are taking too long. This is actually one of those expectation setting things. 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 the end of the day like the moment we hit this reasoning paradigm, the longer the agent like thought, the better its output. You can treat like it's It's almost like a similar mindset for your entire code base and for your skills. There's going to be merge hell and like we just have to deal with it. We have to figure out a way to deal with this. There is going to be slop when you're going to write experiments. Treat it like it's own thing, right? What we said was okay, people are generating this code, but it's not relevant. It's not going to be shipped. It's just an It's a prototype. So, treat it like one. Get it to opt out of all the rigorous other standards you've got across your code base. And realize people vary on the spectrum, right? And depending on the day, depending on like what they're going through, they're going to vary on the spectrum. You have to be able to talk to them and figure out, "Hey, okay, why why are you facing this? Like is it if the model changed, the hardness changed, again you need to go revisit something. Figure that out. And I think the biggest like the easiest way to say this is instead of saying like the model is so dumb, like we have to ask how can I make it smarter or how can I edit like and not This is where I have like crossed out the my. It's not a personal setup. It's the shared setup that you have to invest in. And it's a mindset, right? You have to go full send. And like I want to end you with I want to end with this. Like, I learned skiing like a couple years back and the first like the hardest thing for me was you actually have to commit to it. If you're pizza braking, you're going to crash. Like, no matter what. You have to commit to the speed in order to actually get and feel like, okay, that's how I can turn and that's how I can truly ski. And so, I'm going to leave you with this. Like, just be okay with be okay with failing. You have to, you know, go full send and be okay with falling. It's fine. The point is to be able to recover from that and that will allow you to truly feel the AGI. Yeah, well, that's that's me and I'm happy to take any questions. Yep. Uh so, the I'm going to repeat the question for the recording. Uh strategies that you found best for progressive disclosure. So, I think a couple things, right? Uh the first thing is even in your skill.md files, don't overload it. Like, we've kind of set a hard limit for like 100 lines in your skill.md cuz your skill is really a folder. So, that's step one. Make sure and I think I spoke about this during the talk, but when you have like some code that requires like a runbook, make sure the runbook is reflected in the comments so that if a code if somehow the code like the agent figures its way into like grapping into the code base and find that file, it knows I need to go look at this for like all the description of how this is relevant. Right? You have to organize and I think this is why I talk about harness engineering because your entire code base can be set up to encourage progressive disclosure. Don't overload your cloud MD or your agent's MD file into like one big thing. You want to make sure that like it's a thin index that can point through the right files and that's what the agent gets in its like first prompt cuz that's what gets loaded when it starts to work. So these are like some really powerful strategies that and the way you know this is working is when you give it a prompt. When you give it the first prompt, see what it's doing. Is it grabbing or does it know where to go? But how much context is it burning when it like immediately? So is it like I think like 20, 25K tokens get taken anyway, but like how much more is getting added? If you're coming to like 40K, 50K, like something's wrong. That's not really progressive disclosure. So you have to figure out these boundaries and then like based on this it's an iteration cycle. All right. Well, if there there aren't any other questions, feel free to find me. Happy to talk about harness engineering in general or like anything else, but yeah, thank you for listening. \>\> \[music\]