For most code, this never happens in the real world.

The vast majority of code is garbage, and has been for several decades.

pharrington 6 hours ago | parent | next [-]

So we should all work to become better programmers! What I'm seeing now is too many people giving up and saying "most code is bad, so I may was well pump out even worse code MUCH faster." People are chasing convenience and getting a far worse quality of life in exchange.

▲

fooker 5 hours ago | parent [-]

I disagree, most code is not worth improving.

I would rather make N bad prototypes to understand the feasibility of solving N problems than trying to write beautiful code for one misguided problem which may turn out to be a dead end.

There are a few orders of magnitude more problems worth solving than you can write good code for. Your time is your most important resource, writing needlessly robust code, checking for situations that your prototype will never encounter, just wastes time when it gets thrown away.

A good analogy for this is how we built bridges in the Roman empire, versus how we do it now.

▲

pharrington 5 hours ago | parent [-]

Have you ever been frustrated with software before? Has a computer program ever wasted your time by being buggy, obviously too slow or otherwise too resource intensive, having a poorly thought out interface, etc?

	▲	fooker 4 hours ago \| parent [-]
		Yes. I am, however, not willing to spend money to get it fixed. From the other side, the vast majority of customers will happily take the cheap/free/ad-supported buggy software. This is why we have all these random Google apps, for example. Take a look at the bug tracker of any large open source codebase, there will be a few tens of thousands of reported bugs. It is worse for closed corporate codebases. The economics to write good code or to get bugs fixed does not make sense until you have a paying customer complain loudly.

▲

bdangubic 7 hours ago | parent | prev [-]

This type of comments get downvoted the most on HN but it is absolute truth, most human-written code is “subpar” (trying to be nice and not say garbage). I have been working as a contractor for many years and code I’ve seen is just… hard to put it into words.

so much discussion here on HN which critiques “vibe codes” etc implies that human would have written it better which is vast vast majority is simply not the case

▲

fooker 6 hours ago | parent [-]

I have worked on some of the most supposedly reliable codebases on earth (compilers) for several decades, and most of the code in compilers is pretty bad.

And most of the code the compiler is expected to compile, seen from the perspective of fixing bugs and issues with compilers, is absolutely terrible. And the day that can be rewritten or improved reliably with AI can't come fast enough.

▲

jacquesm 4 hours ago | parent [-]

I honestly do not see how training AI on 'mountains of garbage' would have any other outcome than more garbage.

I've seen lots of different codebases from the inside, some good some bad. As a rule smaller + small team = better and bigger + more participants = worse.

▲

fooker 4 hours ago | parent | next [-]

The way it seems to work now is to task agents to write a good test suite. AI is much better at this than it is at writing code from scratch.

Then you just let it iterate until tests pass. If you are not happy with the design, suggest a newer design and let it rip.

All this is expensive and wasteful now, but stuff becoming 100-1000x cheaper has happened for every technology we have invented.

▲

jacquesm 32 minutes ago | parent [-]

Interesting, so this is effectively 'guided closed loop' software development with the testset as the control.

It gives me a bit of a 'turtles all the way down' feeling because if the test set can be 'good' why couldn't the code be good as well?

I'm quite wary of all of this, as you've probably gathered by now: the idea that you can toss a bunch of 'pass' tests into a box and then generate code until all of the tests pass is effectively a form of fuzzing, you've got some thing that passes your test set, but it may do a lot more than just that and your test set is not going to be able to exhaustively enumerate the negative cases.

This could easily result in 'surprise functionality' that you did not anticipate during the specification phase. The only way to deal with that then is to audit the generated code, which I presume would then be farmed out to yet another LLM.

This all places a very high degree of trust into a chain of untrusted components and that doesn't sit quite right with me. It probably means my understanding of this stuff is still off.

	▲	fooker 27 minutes ago \| parent [-]
		You are right. What you are missing is that the thing driving this untrusted pile of hacks keep getting better at a rapid pace. So much that the quality of the output is passable now, mimicking man-years of software engineering in a matter of hours. If you don’t believe me, pick a project that you have always wanted to build from scratch and let cursor/claude code have a go at it. You get to make the key decisions, but the quality of work is pretty good now, so much that you don’t really have to double check much.

▲

simonw 4 hours ago | parent | prev [-]

That's why the major AI labs are really careful about the code they include in the training runs.

The days of indiscriminately scraping every scrap of code on the internet and pumping it all in are long gone, from what I can tell.

	▲	jacquesm 4 hours ago \| parent \| next [-]
		Well, if as the OP points out it is 'all garbage' they don't have a whole lot of choice to discriminate.
	▲	fooker 4 hours ago \| parent \| prev [-]
		Do you have pointers to this? Would be a great resource to understand what works and what doesn't.