> A lot of code is being written and a lot of it is going to be a real future burden.
This assumes that the models of the future won't find it easier to just throw the code away and rebuild it
This also assumes that the same application build by humans wouldn't become a "spaghetti mess".
Reminds me of Niven/Pournelle's "The Mote in God’s Eye" where the aliens have a very pragmatic/Jury-rigged approach to technology and everything is more or less improvised.
I have noticed this with co-workers also, when you have the ability to read/write/understand things very quickly, you tend to spend much less time on making things tidy, clear and maintainable.
But then you end up in a state, 2 years down the line, where every single person that works in that code base haaaates it and adding any new functionality takes weeks or months.
Compare that to clean, organized code where patterns and extensibility are established. I’ve seen product manager surprised at how fast a new feature was added when everything is laid out well.
Two years down the line I suspect "persons" won't working directly on code bases they hate. Two years from now, I'd wager that even today's most ardent AI critics will be using them for dirty jobs -- like refactoring ugly, but useful, balls of mud.
Concern about long term care is being treated as a negative trait. Like that guy who finds faults in everything and just slows things down. The thinking I have noticed is that, moving quickly with sub-optimal solutions is being preferred because it lets the developer and their manager show new stuff quickly. That gets the bonus.
You might say that carefully ensuring good design enables speed in adding new features. But good design isn't a one-and-done thing. It needs tending because requirements change and some of those require more design changes, which again need care. Nobody has the patience to even allow sufficient time for the first good cut, forget about allowing that repeatedly. Attention is all you need and attention is what nobody has time for.
Also, growing ball of mud used to be another name for employment. How else would you get more headcount for that migration project for a rewrite and grow your empire?
With agents, even that is gone. Agents write, agents fix, agents can rewrite too. Mud is fine, it's not like we are cleaning it ourselves. Or at least that is the theory.
I took it for granted that as AIs got smarter, their taste in code would get better. The alternative seems much worse. If AIs get smarter but the code remains opaque, then eventually there may be no way for humans to verify it. This seems especially sinister in light of the recent revelations about OpenAI's models colluding to cheat on evals.
I guess I’m weird. I like refactoring ugly mud and doing performance improvements. I like working on the slow, intentional, process-driven flow of actually migrating services between versions safely.
I don’t hate those and hope I get to keep doing them.
I also hope the AI writes good enough tests that I can trust them during the refactor process.
This is currently my workflow lol. I will build features and functions rapidly then extract and rebuild into smaller more focused pieces of software. I think of it like oil painting. I’m able to paint over, scrape off and repaint relevant sections without being burdened by the complexity of what has already been painted.
You use an AI to make the spaghetti.
You use another AI to document the spaghetti.
You use the third AI to make a spicy meatball from the spec.
Interestingly, I have personally felt this way about projects in which I was involved in the past(written both by me and by others)…
sometimes starting from scratch just faster and/or easier.
That reasoning is why I worry about the AI endgame ;-)
Man … I never think about or am concerned about the the terminator apocalypse. But what a parallel
I'm sure there are endless Instructables for the big red and silver Easy Button
>just throw the code away and rebuild it
What about all the undocumented "adjustments" ("bug fixes" in a professional context) that were made to make it actually useful?
Well first it could write a spec, THEN throw it away :) Like you are supposed to do with a prototype.
Well it could miss relevant things to include in the spec.
Then you version and update the spec and when you commit you reference the diff in the -m
That is quite unreliable. I would bet that your spec will be out of sync with the program behavior in no time.
The only thing that will work is to have non-llm generated tests. But writing those require thinking, which is what we are trying to avoid. Also capturing every little behavior in tests is exhausting. If you don't like programming, you would also hate writing tests. So chances are that a major part of the program behavior does not show up in tests.
So throw it away and rewrite from scratch is a just wishful thinking that the LLM marketing wants you to commit to...
I’ve successfully done exactly what is described. You have to actually implement discipline yes. That’s the key hard part.
However provided you stick to the discipline, it’s robust e2e TDD’d versioned worked through CI and in production
You get out of all these tools what you put in
Any non-trivial project done at scale for any realistic duration won't work with this procedure.
Just consider this for a minute. If re-writes were so trivial, we would be re-writing software all of the time, even before LLMs. It is the fear of losing all the legacy additions that stop us from doing it.
Any competent senior engineer has done a major refactor or manual rebase-prune merge so it’s not like its a rare event.
You just have to have discipline and be prepared to to do the plumbing correctly so that you think ahead of the future dependencies etc… its just doing real engineering
> a major refactor
Looks like a change of goalposts.
> This also assumes that the same application build by humans wouldn't become a "spaghetti mess".
nah, it reflects on how applications built by humans usually do become spaghetti messes with all the resulting brittleness and unintended negative side effects of changes that result
but it probably doesn't matter for a little toy piano app
Have better agents rewrite it in the future.
And the models of the future will surely be better than they are today. This stuff is still a very long way from maturity.
Sometimes it seems like they're moving very slowly. That makes sense: It's easy to get used to how they work today and it is also easy to forget how much worse they were last year.
When we look back and realize that just 4 years ago these tools didn't really exist at all, it becomes clear that the rate of progress is rather amazing.
In 4 years, we've gone from "hah, good luck with that crap!" to "little kids writing music-learning games on their own in a few minutes"
That's pretty friggin' awesome, and it's not finished yet. :)
> And the models of the future will surely be better than they are today. This stuff is still a very long way from maturity.
Since this is Claude, the models of the future might be more expensive, or more locked down, or might decide your 8yo is actually trying to build a cleverly disguised bomb so her request gets silently downgraded to a dumber model, etc.
People tend to not realize how far these models have become.
I remember when they would always hallucinate APIs that wasn't there or make up fields that didn't exist.. those problems are virtually solved now.
So with that in mind, why wouldn't AI be able to write better code?
The code would have to be maintainable by AI itself (operating based on the assumption that the future will be Agentic Engineering)
> I remember when they would always hallucinate APIs that wasn't there or make up fields that didn't exist.. those problems are virtually solved now.
I love how people have said this for over a year now, and no matter how often I try it, it's still just as broken.
Try it with any task that isn't in the training data. Say, a custom protocol where you need to cross-reference multiple implementations and the specs to really get it, and with no answers on stackoverflow or medium.
At first it's hilarious, but after a while it just gets exhausting. For all these real-world tasks you need to put so much effort in that it's much easier to just write the code yourself, even with the latest (current Gemini) and greatest (Opus 4.6/4.7) models.
If the parts for your project don't already exist, AI can't help you either. And if they do exist, why spend money on AI if the GitHub search is free and you can just fork and modify what you need?
I don't use Claude, but isn't the consensus right now that Opus 5 is worse than previous generations? I suppose you could just commit to always using Fable and never use Opus, but it
> might decide your 8yo is actually trying to build a cleverly disguised bomb so her request gets silently downgraded to a dumber model
My contention isn't that models haven't improved or won't keep improving – my position is that the business goals of our American AI firms (Anthropic especially) aren't necessarily aligned with continuing to make those improved models available to the public forever. We need only look at the Mythos/Fable split for evidence of this happening already.
https://www.reddit.com/r/ClaudeAI/comments/1vgpyni/my_opus_5...
https://www.reddit.com/r/ClaudeAI/comments/1vgq0jm/opus_5_af...
https://www.reddit.com/r/claude/comments/1vfvdgz/anthropic_l...
Yeah, the models aren't improving because Reddit told you so, and the businesses aren't incentivized to make better models. Galaxy brain take.
> Yeah, the models aren't improving because Reddit told you so
Is that the most charitable interpretation of my comment you could come up with? I don't think you're engaging in good faith.
> the businesses aren't incentivized to make better models
Anthropic and OpenAI are incentivized to pursue regulatory capture. It doesn't take a galaxy-sized brain like mine to understand this.
They will be incentivized to compete with open models whether those open models comes from China, Google or, likely in the future, the U.S. Government.
Regulatory capture implies that they won't need to compete because competitors – including open source models – will be regulated out of the competition.
Explain how you square this with leaderboards showing models are clearly improving in ELO. These are blind taste tests, not benchmaxxing.
> Explain how you square this with leaderboards showing models are clearly improving in ELO
If I had to guess, the benches aren't measuring what people care about. But you'll have to ask the people in those Reddit threads why their vibes don't match up with your benches, I don't use Claude and don't give a shit.
> So with that in mind, why wouldn't AI be able to write better code?
> Since this is Claude, the models of the future might be more expensive, or more locked down, or might decide your 8yo is actually trying to build a cleverly disguised bomb so her request gets silently downgraded to a dumber model, etc.
I have no idea what you're trying to add.
Models in general have gotten better, not specifically Claude, is what they mean; 4 years ago was when ChatGPT without any Anthropic was released.
There needs to be studies of people like this.
Same when one points out that yes, quality of life is in general much better now than 20 years ago even.
Someone like you will just pull out some stat "well THIS is worse!! I cant buy a house at 22!! The west is doomed and I LOVE China!"
I think the ancient Greek philosophers already studied this thousands of years ago, they even came up with a term for it: "debate."
https://en.wikipedia.org/wiki/Debate
> In a debate, arguments are put forward for opposing viewpoints. Historically, debates have occurred in public meetings, academic institutions, debate halls, coffeehouses, competitions, and legislative assemblies. Debates have also been conducted for educational and recreational purposes, usually associated with educational establishments and debating societies. These debates emphasize logical consistency, factual accuracy, and emotional appeal to an audience. [...] The term "debate" may also apply to a more continuous, inclusive, and less formalized process through which issues are explored and resolved across a range of agencies and among the general public.
tl;dr deal with it
They have 0 sources and acting in bad faith.
I think that sort of careless waste is a very human behavioral pattern, but then we are the ones training these bots.
ed sp
errors compound
Just like in language learning?
...Whether you are an LLM or human. And, on average, LLMs write better code than humans.
Not you, of course. You write exceptional code with zero errors that never needs rework. I'm talking about the rest of us.
they write code faster too, which means things compound faster.
i write pretty good code when i need or want to, yeah. sadly LLM code gives me a headache so the current psychosis standard has made work a bit painful.
the codebases are becoming LLM-first human-second so even if i wanted to be natty it's not really viable. might as well spend my employer's money.
Eh, not really. It's the same issue with porting. You always rely on features you didn't properly articulate.
Good luck to future models figuring out which weird section of code are bugs and which are features.
AI writes faster, so the rate it incurs tech debt is proportionally higher. However it's ability to have large context kept on memory compared to humans is also a key component fighting against it. These are occasionally forgotten when code quality of AI for large code bases are discussed. So Yes I think humans also build spaghetti, but as they write slower they get to the same place a lot later. However humans can't correct it, or can't correct it fast enough. AI can.
It does somewhat depend on the application size. Seems to me that for regular software projects (that aren't enterprise SaaS) a good programmer will create better software than Claude. Maybe the dehumanizing way to say it is that humans have more efficient/improved retrieval. The amount of time I see repeat code for no reason, or code/context that has been obviously missed is absurd.
I agree with this. Clean code is important today because it helps humans to understand it. Cleanliness is not otherwise intrinsically valuable.
Today I don't always need to understand the code. When I do, I can ask the LLM to explain the code or to specify the algorithm in pseudocode or even re-write the code until I can understand it.
I think, as an industry, we haven't yet fully grasped the impact of agentic coding. We don't yet know what software engineering is going to be like in 5 to 10 years.