[socketcluster]

It's based on my experience as a software engineer who has worked on both clean and messy codebases with AI.

It's a very different experience with a messy codebase. In this case, the agent spends most of its time trying to gather the relevant context and it's like a game of whac-a-mole. The agent burns through tokens and can take a long time to resolve the issue with a lot of human intervention required. I would say it takes possibly just as long or longer than a human engineer would. Also, psychologically, the temptation for the engineer to trust the AI is massive because they don't want to load themselves up with all that ugly, complex context. They are more likely to let the agent create more hacks on top.

On a relatively well-structured codebase with loose coupling and high cohesion, the experience is usually very positive, mind-blowing, even; because it feels like the agent is reading your mind and fast-forwarding you. You don't need to correct it as much. And when you do, it's usually minor things.

The first case represents a net loss of value because tech debt is being added and compounding the complexity each time a problem is 'solved'. On the other hand, the second case is a significant speedup, for me, I would say it's at least a 5x speedup. I love using AI in this way. I'm in control and not at the mercy of the agent.

[tsvetkov]

I don't argue against the fact that codebase complexity increases token consumption on building context. My main point was that there are other factors affecting token consumption beyond just codebase complexity. Some of them may be related to engineering culture (verbose logs, flaky tests, lack of docs, weird hacks all over the place, etc.), some of them are organizational/social.

[socketcluster]

Sure. A lot of these things tend to go together. Weird hacks is a bad one. Those AI agents love to cheat and if they see highly elaborate hacks in the code, they won't hold back either.