So much "bad" enterprise code evolved into that state over years or even decades of small changes. Meanwhile, last year I got to watch an LLM-authored codebase speedrun itself into a similar state in only a couple months. And I would say that the enterprise code was actually better. It at least did its job fairly reliably. The LLM codebase was riddled with defects, so much so that it ate up all our time and our feature delivery rate ground to a halt.
There are two observations that really eat at me:
1. Studies seem to indicate that agentic coding uses 2-10x as many lines of code to accomplish the same task.
2. One of the only really well-established empirical results in software engineering is the strong association between LOC and defect rate.
This is happening all over the place right now. There is a ton of greenfield happening, which further adds to the illusion of speed. Eventually you produce a big old pile of shit that even with the help of the LLM is weird to reason about, and it slows way down. Many such cases.
I am actually rather fond of caveman. I haven't evaluated it for token cost, in part because frankly I think that part of the pitch is a load of malarkey. Output that's shown to the user is such a small percentage of overall tokens these days.
But anecdotally I do think it saves me quite a lot of time on reading LLM outputs. And that, if nothing else, is good for my sanity.
The caveman gimmick makes sense to me as a clever hack. Caveman talk is a longstanding meme that's presumably well-represented in the models' training data. So just asking it to do that is just an ultra-concise way to tell the LLM to be ultra-concise. Which, in turn, is theoretically good for accuracy because putting too many instructions in the prompt is bad for task performance.
Similar for ponytail, I don’t know if it saves tokens, but there is less output to read (and usually less over engineering). Occasionally I have to push for more complex code, but that is much nicer than constantly asking for simpler code.
That's also a good point. When I'm using caveman (and especially cavekit), I don't have to spend quite so much energy on dealing with it building features I didn't ask for and don't want.
It's possible to step out of your area of expertise in a way that's confident but also humble. Arrogance is not necessary. The person who signs everyone's paychecks might be making it mandatory, but that's not quite the same thing.
I've experienced it in industry, too. I recently got out of data science in part because I got tired of working with people who, emboldened by their PhDs in some completely other field, liked to patiently but condescendingly mansplain common, basic misconceptions about my area of expertise to me.
(And it got so much worse once they started using LLMs to aid them in their efforts. Glazing as a service is a hell of a drug.)
So much easier, now that I am a lowly software engineer and can't be held responsible for a certain class of decisions, to just step back and let them be wrong.
I think that quantitative researchers have known this for a while, too.
My perennial experience as a machine learning practitioner working in industry is that the ML and statistics folks raise concerns about the models learning social biases that could case real harms, the business folks make sure that this is a career-limiting move, and so the quantitative folks learn not to rock the boat.
I disagree with the claim that "AI agents don't get lost." What I've observed instead is that they don't experience the sensation of feeling lost. Which is quite different.
This summer I spent quite a while using a coding agent to help me untangle a deep and complicated data processing pipeline. It had itself been built by agents, in a remarkably short amount of time. But it had also become clear that it was riddled with errors and was producing lots of bad data.
What I quickly discovered was that upwards of half of my questions would receive very confidently wrong answers. And even once I had finally diagnosed whatever problem I was currently working on, it was difficult to trust the agent with any bug fixes. Since it was having an even harder time tracing data flows than I was (I'll take this chance to submit for your consideration that faster is not necessarily better), it was proving to be a bit of a monkey's paw. Yes, it would fix the exact bug I asked it to fix, but typically introduce new defects in the process. And yes, I was having this struggle with all of the latest & greatest models.
I ultimately concluded that, in this codebase, the agent was indeed deeply, hopelessly lost. (edit: And probably this code got so bad in the first place because the agents that were used to build it had been lost for a while, but unable to recognize this problem and call their operators' attention to it.)
"Confidently wrong" is definitely a standard behavior model for LLMs.
I agree with the other reply that you're likely to get better results if it has some kind of test case to run that's more authoritative than its own reasoning.
Yes, I've also noticed a few occasions when Claude would get it wrong, but in most cases it's able to find issues I didn't even consider because of a very deep analysis in a confusing (to humans) code. It detects some rare situations where a defect could exist. This happens when I explicitly ask Opus to review a PR and there's some harness around this ability, but I'm really impressed at how deep their analysis can be and correct as well. Of course, sometimes they're going to fail, but I don't see them getting lost often.
I'm curious about your exact case. In my experience I often had luck with evidence based approaches where the agent had to prove something first in order to make a statement (or write/do some tests first before making claims).
I agree though that one has to be very careful when trying to "fix" things with agents in a big codebase without it introducing new defects.
I spent some time working with that approach of using LLMs to generate synthetic labeled data for use in training more specialized models. It mostly didn't work.
The problem was that getting the LLM to generate training data that sufficiently resembled real-world data was labor intensive and expensive. More labor intensive and expensive, it turns out, than just using real data.
What worked better was using the LLM to label the training data. But even there we had to be careful about introducing weird biases.
I almost wonder if it's even possible now that so many of us get our information through algorithmic feeds.
I listened to one Zitron interview on YouTube and my home page was immediately crammed full of similarly foamy-mouthed AI critics. (As well as plenty more Zitron.) And it's suggested some people with un-nuanced pro-AI takes, too. But what the algorithm has never, not even once, given me is a sober voice that calls attention to the nuances.
IANAL, but it seems like the wording in the public-facing version of the policy is a little muddy. As far as I'm aware, "tax exempt donation" not a thing that actually exists in US tax law. It seems to be a conflation of "tax deductible donation" and "tax exempt organization".
Knowing how big corporations do things, that document was likely written by someone who doesn't fully understand the jargon or even how pedantic you have to be about words when dealing with legal concepts, who didn't set the policy themself, and who is not responsible for enforcing the policy. So we should take its specific choice of words with a grain of salt.
So much "bad" enterprise code evolved into that state over years or even decades of small changes. Meanwhile, last year I got to watch an LLM-authored codebase speedrun itself into a similar state in only a couple months. And I would say that the enterprise code was actually better. It at least did its job fairly reliably. The LLM codebase was riddled with defects, so much so that it ate up all our time and our feature delivery rate ground to a halt.
There are two observations that really eat at me:
1. Studies seem to indicate that agentic coding uses 2-10x as many lines of code to accomplish the same task.
2. One of the only really well-established empirical results in software engineering is the strong association between LOC and defect rate.
reply