As an engineering manager, I am witnessing the transition from a world where codebases are mostly handwritten into one in which a majority of codebases are written by agents and LLMs.

During this transition, one of the interesting things I’ve observed this year is that agentic programming creates a LOT of lines of code to solve a given problem. Whilst the code blocks that LLMs produce in isolation look fine to me, the solutions they land on do seem to be verbose and repetitive. In the past, these traits in code were considered anti-patterns and against best practices. Implicit in that idea was the fact that other engineers (and future you) would have to read, understand, and update that code.

Initially I thought the pattern was isolated to more junior engineers. My thinking was that perhaps they were less adept at picking up on these anti-patterns and course-correcting. And perhaps that they were more prone to blindly trusting the output of an LLM without questioning. But the more I’ve seen, the more I’m convinced that this is a common feature of code produced by all engineers that are using LLMs.

Over the course of time, I suspect that this will have multiple consequences.

Long PRs

In the past, the idea of submitting a PR with 50+ file changes would have been eye watering. “There’s no way someone can review 50 file changes and provide good feedback”. Now, I would say 50+ file PRs are not uncommon. I believe this leads to two other problems.

PRs are the bottleneck

If one of the biggest selling points of LLM / agent-driven programming is speed, the bottleneck quickly goes from “how long will it take for an engineer to write the code” to “how long will it take for an engineer to review the code”. And if the speed of the review is the bottleneck, the next question is: do you still bother with human code review? If the answer to that question is “no”, in the short term, there are speed gains to be made, but in the long term I believe there will be other consequences.

Loss of tribal knowledge

As sophisticated as software engineering can be, I’ve always been astounded at how much that effective engineering teams rely on tribal knowledge. Each engineer in an org holds a mental model of how systems in their domain are pieced together. This model is rarely the entire picture, and teams instead rely on individuals with overlapping models being able to communicate to produce a desired outcome.

So if engineers are spending less time programming by hand, and less time reviewing other people’s code, the net effect, I believe, will be a degradation of these mental models. And at that point, your reliance on LLMs, agents, and harnesses will increase.

So what’s all this got to do with tech debt?

If you’re right code with LLMs right now, for any task that you want to complete, as of right now, there’s a token cost. Input tokens (the prompts and code that the LLM needs to consume to understand the problem) and output tokens (the instructions and code the LLM returns). It stands to reason that the number of input tokens grows with the size of a codebase. The bigger the codebase, the more the LLM might need to read in order to understand the problem. And we already know that LLMs are producing a high number of lines of code. Added to that, LLMs currently have fixed context window sizes. So it would stand to reason that there are limits to how big a codebase (or set of codebases) can grow before becoming difficult for an LLM to be able to understand. My question is: long-term, what will be the impact of that?

From my personal experience, we’re not at a stage where this is a problem. Yet. But for these reasons, neither the verbose number of lines of LLM-produced code nor the loss of tribal knowledge feel like good problems for engineering teams to have.

I could see a world where, at a code level, tech debt stops being the way code it written and starts being, the sheer size of the codebases themselves.