# The Knowledge Chipper: An Agentic Coding Story > Source: > Published: 2026-08-04 16:43:37+00:00 In my day to day development work, I find that my agents have to build up an incredible amount of knowledge about the problem I set them on. They scan files. They search API docs. They do a lot of work to get their context sufficiently full to be able to squirt out the relatively tiny number of final tokens that go into an actual code change. This is analogous to the way a developer reads a lot of code, builds a very detailed mental model of what the system is doing, and then edits just the files they need to. And (nearly) all that knowledge goes… away. What I’m writing about here (especially the meme) is inspired by [this cartoon strip](https://www.reddit.com/r/ProgrammerHumor/comments/2rmir6/why_developers_hate_being_interrupted/). The difference that I see in today’s world is that it’s less that the programmer is getting interrupted and more that the vast majority of the work that the LLM has done gets lost in every practical sense. Sure, smart programmers often have the LLM write its own commit message. That’s good. And yes… you can resume a session… on your own machine. But this is still miles away from capturing the fullness of the state that the LLM put together. And that’s a **huge loss** of institutional knowledge, session resum-ability, and efficiency if I want to pickup from where that work left off. I recently read ** The Session You Cannot Take With You** ( [HN discussion here](https://news.ycombinator.com/item?id=49118781)) and it really stuck with me. Before reading this, I wasn’t particularly opposed to having proprietary AI tools involved in helping me get my work done. However, this article really distils why agents as black boxes is actually really damaging. Seriously… think about it. Something as simple as one teammate preferring Codex while another teammate is using Claude. One LLM works hard to build a rich picture of the logic. Then another LLM needs to work on the same code… and starts completely from scratch. **I cannot estimate the millions of tokens that are burnt this way.** The whole concept of ‘LLM portability’ sounded a bit high-minded to me, honestly. Like monomorphism. Or gluten intolerance. But in a turn of serendipity, I was on a call with a tech friend based in Dubai earlier this week. He was describing [the carnage at the AWS datacenter in Bahrain](https://www.reddit.com/r/technology/comments/1scgw7u/iranian_missile_blitz_takes_down_aws_data_centers/). The fascinating thing he pointed out is that many companies in that region absolutely *cannot* let their AI use be run in another region because of… well… **war**. So, when a whole region of one service gets massively disrupted because of said war… suddenly LLM portability becomes much more real and urgent. My whole team is using Claude for the most part. I think I’m the eager adopter trying out various LLMs against each other and also in concert. Something *feels* right about having Google’s agent review Claude’s work before I commit. But having the LLMs work together also makes me realize just how much context I’m throwing away every time I startup a new session or run “git commit”. And now let’s talk bleeding edge stuff. What if I want Codex to pick up where Claude got started because Claude has gone offline? Or I want to try out one of the other models on an area of the codebase that Claude and I have already worked in a lot. I really want to be able to pick up where I left off without re-burning tokens in the token fire for the nth time. The problem runs much deeper than this in larger teams. How can code reviewers — human or otherwise — catch up to all the nuance behind a code change? My friend [Philip](https://www.linkedin.com/in/suphilip/) who worked at OpenAI wrote a really interesting piece about [code review in an era of AI drastically outpacing human capabilities](https://molochinations.substack.com/p/no-more-code-reviews-lights-out-codebases). That feels very relevant here. As of today, it’s possible to put up code changes that are sufficiently nuanced and sufficiently large such that it’s very hard to review them. And because so much of the context was left on the developers machine, the only remnant of all that token burn is a commit message and whatever amount of code comments the LLM deemed fit. Being a tech lead for a fast moving project was hard work *before* LLMs. Now, every PR is a freshly minted parcel of (un-|semi-)documented complexity. The junior dev who just vibe coded up a huge amount of new privacy logic shuts his laptop and heads off home. Meanwhile, the senior engineer who *actually* knows how the privacy layer works has to wade through this pile without any of the context. He can’t resume the session that he never started. So… he should… ask his LLM to gin up all the same context that was already ginned up once in order to understand the context-disconnected output? This feels insane. If I come back today to an area of the codebase that just had 250K tokens spent on it yesterday… am I really about to spend many more tens-of-thousands of tokens loading up the context window again? Why yes… yes I am.