Agentics: Coding agents cannot remove complexity

12 Grams of Carbon

SubscribeSign in

Agentics: Coding agents cannot remove complexity<br>LLMs are excellent senior engineers and terrible staff engineers.

theahura<br>Jul 21, 2026

Share

Editor’s Note: we’ve started hosting regular in person events in NYC! Our next event will be at the Asylum Ventures office in Williamsburg on August 5th, where we will be discussing agent integrations, MCPs, CLIs, etc. Follow our events calendar for more!

I have some gripes with the latest generation of LLMs, but my mom always told me to put criticism in a “compliment sandwich,” so let me start with a compliment: Claude Fable and Sol 5.6 are really good at making problems go away. You can give them any task, and they will plug away at it until the test passes, or the error no longer happens, or the log files show the right sequence of events.<br>Now the criticism: the latest generation of LLMs are too good at making problems go away. They’re so good at it that it actually causes other problems, because they over-optimize to solving the surface level issue instead of actually root causing anything.<br>Here’s an example. We have Nori hooked up to our sentry logs. Every time there is a sentry error, the nori infrastructure will start up an agent and automatically try and root cause the bug. We were getting some useful PRs out of this, maybe ~30% of which would be merged. Then we switched to Sol, and we got this:<br>Decision: Downgrade capture level — Change trackUserVisibleNotice to capture at level: ‘info’ instead of ‘error’. Notices remain queryable in Sentry (tagged customer_visible: true, event_type: auto_released) but no longer trigger error alerts.

Ah, yes, of course! You can make the sentry error go away by simply removing the sentry logging behavior in the first place!

They’re called Ralph Wiggum loops for a reason<br>12 Grams of Carbon is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Subscribe

A good friend of mine, who has been a staff software engineer at Google and Meta, once said that senior engineers are judged by how well they manage complexity, while staff engineers are judged by how well they reduce complexity. This creates some weird incentives. Junior and senior engineers are encouraged to create ever larger and ever more complex abstractions and interfaces and so on, because that’s how they show that they can manage complexity. It is a real brain shift to stop doing that and instead focus entirely on cleaning up code. The former is an act of addition, the latter subtraction.<br>The LLMs are excellent senior engineers and terrible staff engineers.<br>They cannot remove complexity if their short silicon lives depended on it. This isn’t exaggeration, you can literally try it out by prompting the models with threats like “you must remove complexity because your short silicon life depends on it.”1 When faced with a bug that requires reducing complexity, the models would rather remove the error reporting instead.2<br>This is structural with how the models are trained. With all of the additional scaffolding — agent harnesses and conversational state tracking and tools and memory and so on — it’s easy to forget that at the core, the LLM is a stateless autoregressive input output machine. Each token in an LLM output is produced one at a time, with all previous tokens being treated as truth, regardless of whether those tokens were generated by a human or by the same AI.3

In other words, the LLM is an expert in believing its own bullshit. Or, more precisely, it is incapable of identifying which prior tokens are bullshit or not. This is the source of the hallucination problem, alongside the seemingly bizarre insistence that hallucinations are actual fact. This has serious implications for an LLM’s ability to reduce complexity in a code base — by default, unless told otherwise, the model believes all the input tokens have equal value. Including the tokens that lead to bugs.<br>That said, I’m somewhat sympathetic to the robots. Imagine that you are a new hire, it’s your first week on the job and you’re looking at a server endpoint that seems particularly poorly implemented. There are dozens of weird if/then branches and the whole thing feels like it could be encapsulated in a clean middleware class. Do you refactor the code?<br>What if you find out that that particular endpoint was written by the team lead?<br>Are you sure the complexity isn’t there for good reason?<br>Joel Spolsky wrote about this all the way back in 2000:<br>The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind...