Comment by diggan
5 days ago
> There was a worry that code would become big mud balls
That's always been a worry with programming (see basically all Rich Hickey talks), and is still a problem since people prefer "moving fast today" instead of "not having 10 tons of technical debt tomorrow"
LLMs makes it even easier for people to spend the entire day producing boilerplate without stopping for a second to rethink why they are producing so much boilerplate. If the pain goes away, why fix it?
Literally less than an hour ago, I reviewed a bunch of LLM-generated boilerplate. I then told the agent to show me a plan to refactor it. I suggested some tweaks, and then it implemented the plan and then tested that it didn't break anything.
It isn't much different than dealing with an extremely precocious junior engineer.
Given how easy it is to refactor now, it certainly makes economic sense to delay it.
But I'm guessing you're doing those refactors because you know they're ultimately worth it, because you have experience programming since before LLMs?
Like I know boilerplate and messy code sucks because I've had to work with it, without LLMs, and I know how much it sucks. I think you do too, but I think we know that, because we had to fight with it in the past.
Right now devs around the world are pushing ungodly amounts of reinforcement learning data into the big AI labs. There is no reason to believe these models won't handle this stuff themselves and our priors will become a useless relic.
LLMs start to bog down with it at a certain point too. For a couple of my side projects, I decided to let things rip and now worry about code structure at all. After a certain point some of the changes I wanted to make just started either failing work racking up large bills. It would try to make a change, run tests, realize it broke something somewhere else, try to fix that, cause another issue. Undo the original thing, fix the new issue, maybe try to refactor, partially, fail, revert that, decide to make the tests pass by removing the tests! and then keep some broken version of fix. With a few similar cycles of that on repeat as well.
Deliberately telling it how to rethink the structure, refactor first, then seperate out components fixed things.
IF LLMs stayed at the current level, I would expect llm-aided-coders to learn how to analyze and address situations like this. However, I do expect models to be better able to A) avoid these kinds of situations with better design up front or reflection when making changes and B) identify more systematic patterns and reason about the right way to structure things. Basically ambiently detecting "code smells."
You can already see improvements both from newer models and from prompt engineering coming from the agentic tools.
The type of person that would do that would have done the same thing without LLMs. LLMs don’t change anything except now they can just create their big ball of mud faster.
The pain of shitty code doesn’t go away. They can ship your crappy MVP faster, but technical debt doesn’t magically go away.
This is an awesome opportunity for those people to start learning how to do software design instead of just “programming”. People that don’t are going to be left behind.