While I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions
Like real life, you want to accrue debt strategically.
When you're experimenting, vetting ideas, mapping out the requirements, exploring solutions, then technical debt keeps churn cheap.
e.g. You don't want to overly commit to static types that keep "impossible state unrepresentable" too early on since you aren't even sure yet what impossible state looks like in the system.
So we regard debt repayment as some sort of transformation we'll do in the future that never comes because it's hard and expensive, but not to LLMs.
Because we have evidence otherwise, and even the worst code can be refactored by LLMs.
That a high velocity project might accumulate technical debt isn't interesting to me if LLMs can also pay it back or if you can decide to work at a different pace where you polish the architecture as you go instead of accumulating debt.
I'd make the opposite claim to you: people really don't want my claims to be true, probably because it robs us of our value and expertise as software engineers. But it's getting a bit late in the game to still be dancing around that pill to swallow.
the models have gotten very good at doing what you ask. if you ask for changes that will accrue tech debt, you'll get it. if you ask for changes that pay down that debt, you'll get it.
If you're referring to Apple Silicon, my intuition is that the SoC design allows for higher bandwidth between SSD and RAM which reduces the performance impact of paging. I might be totally wrong though
100% also our experience. We have an internal CLI which has grown to almost half a million lines of Go, mostly contributed to by first-time gophers (and agents nowadays), and with relatively little work spent on making sure the core entities and interfaces encourage doing the right thing, the entire codebase is still surprisingly readable and free of unexpected behaviors.
Say you have some code that does a request to an HTTP/1 dependency, and if it get an error response, just closes the connection without reading the response body.
Go 1.26 in practice never re-used that connection, it always established a new one because you can't reuse a connection which has a pending response ready to be read.
Go 1.27 will now consume the body for you, causing your application to re-use connections much more aggressively, bringing in potential edge cases (e.g. dependency is broken, connection is now permanently unusable, your app no longer recovers automatically).
To be clear, I'm very glad for the change and I had equivalent code in our in-house framework to do just that, but yeah it does change the behavior in a way that it could expose undetected issues.
Which is almost guaranteed to be the case for a large org, considering everyone will want auto complete and PR reviews, but on average most will not be making a ton of agent use
This is a pet peeve of mine and I'm glad to see it called out. That said, I haven't seen a comprehensive discussion of "here's the different factors that we think contribute to creating lift" for the general public, is anyone aware of a good source?
Yes, I am in a hybrid role, went through 5 interviews and several more check-ins, and the first time anyone saw me in person was on the first day when I picked up my laptop at the local office (which wasn't even required, I had the option of having it shipped at my home address)
I'm also 37. Two younger colleagues were complaining this week that something like `os.MkDir(..., 0755)` is extremely confusing and that they don't like and can't make sense of octal file permissions. I felt really old :)
reply