Certain types of code are cheap. Proof of concept is cheap. Adding small features that fit within the existing architecture is cheap. Otherwise, I'm not so sure. Coding agents are fantastic at minutiae, but have no taste. They'll turn a code base into a ball of mud very quickly, given the opportunity.

▲

pell 4 hours ago | parent | next [-]

While I agree with you that agentic coding still has quite a way to go and is not always producing the quality that I would want from it, I can say quite confidently that its baseline is way above some of the production code in many applications many people use today. It really isn’t that code before agents was primarily written with taste and beautiful structure in mind. Your average code base is a messy hell full of quick fixes that turned into all kinds of debt over the years.

▲

jmull 3 hours ago | parent | next [-]

I took the previous post, with its mention of the ball of mud, to be about complexity.

“Taste”, is used in many cases, I suspect, to give a name the collection of practices and strategies developers use to keep their code and projects at a manageable level of complexity.

LLMs don’t seem to manage complexity. They’ll just blow right past manageable and keep on going. That’s a problem. The human has to stay in the loop because LLMs only build what we tell them to build (so far).

BTW, the essay that introduced the big ball of mud pattern to me didn’t hold it up as something entirely bad to be avoided. It pointed out how many projects — successful or at least on-going projects — use it, and how its passive flexibility might actually be an advantage. Big ball of mud might just be the steady state where progress can be made while leaving complexity manageable.

▲

noelwelsh 3 hours ago | parent [-]

I think there are at least two factors behind ye olde ball of mud that LLMs should be able to help with:

1. Lack of knowledge of existing conventions, usually caused by churn of developers working on a project. LLMs read very quickly.

2. Cost of refactoring existing code to meet current best practices / current conception of architecture. LLMs are ideal for this kind of mostly mechanical refactoring.

Currently, though, they don't see to be much help. I'm not sure if this is a limitation in their ability to use their context window, or simply that they've been trained to reproduce code as seen in the wild with all its flaws.

	▲	skydhash 3 hours ago \| parent [-]
		Keeping complexity down is always a conscious act. Because you need to go past the scope of the current problem and start to think about how it affects the whole project. It’s not a matter of convention, nor refactoring. It’s mostly prescience (due to experience) that a solution, even if correct and easy to implement, will be harmful in the long term. Architecture practices is how to avoid such harmful consequences. But they’re costly and often harmful themselves. So you need to know which to pick and when to start applying them. LLM won’t help you there.

▲

noelwelsh 3 hours ago | parent | prev | next [-]

I agree. I do wonder if what I'm seeing is a limitation of the reasoning power of LLMs or if it's just replicating the patterns (or lack thereof) in the training data.

▲

anilakar 3 hours ago | parent | prev [-]

[dead]

▲

2ndorderthought 3 hours ago | parent | prev | next [-]

Preproduction code was always cheap or even free. Sales people have been selling software that didn't do what was on the tin since the dawn of time. Those features cost 0 dollars to write!

Production code. Especially production code with bugs is expensive. It can cost you customers, you can even get negative money for it in the form of law suits.

Coding agents are great for preproduction and one offs. For production I really wouldn't chance it at any scale above normal human output.

▲

zjaffee 2 hours ago | parent | prev [-]

Except here's the thing, that's the sort of code that was extremely expensive before, in large part because of our day jobs (which still to this day require mindfulness and can't just be vibe-coded).

However, an extra script here or there to make your life easier, adding extra UI features based on some datapoint to your internal dashboard, ect, these were things that could've taken a few days you didn't have before to get exactly right and now they can be done with only a few minutes of attention.

	▲	melvinroest 2 hours ago \| parent [-]
		Yea, the amount of dev tools I'm creating per project is astounding. Usually tools that help me to debug certain things better.