|
|
|
|
|
|
by tsvetkov
21 days ago
|
|
|
Why do you think the cap has anything to do with the quality of their codebase? Employees could've been tokenmaxxing for various reasons: learning, experimenting, trying to impress the management, ...
Naturally, this leads to AI spending skyrocketing while the business value may not be totally clear. Which leads to caps being introduced to keep the budget under control and discourage/limit tokenmaxxing. |
|
|
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.