4 ms·
By lines of code, almost by an order of magnitude. Some of the code is janky garbage, but that’s what most code it. There’s no use pearl clutching. Human engi
by fooker 9mo ago
By lines of code, almost by an order of magnitude.
Some of the code is janky garbage, but that’s what most code it. There’s no use pearl clutching.
Human engineering time is better spent at figuring out which problems to solve than typing code token by token.
Identifying what to work on, and why, is a great research skill to have and I’m glad we are getting to realistic technology to make that a baseline skill.
- jacquesm 9mo agoWell, you will somehow have to turn that 'janky garbage' into quality code, who will do that then?
- behnamoh 9mo ago> who will do that then? the next version of LLMs. write with GPT 5.2 now, improve the quality using 5.3 in a couple months; best of both worlds.
- fooker 9mo agoFor most code, this never happens in the real world. The vast majority of code is garbage, and has been for several decades.
- bdangubic 9mo agoThis 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 9mo agoI 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 9mo agoI 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.
- simonw 9mo agoThat'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.
- fooker 9mo agoDo you have pointers to this? Would be a great resource to understand what works and what doesn't.
- simonw 9mo agoNot really, sadly. It's more an intuition knocked up from following the space - the AI labs are still pretty secretive about their training mix.
- jacquesm 9mo agoWell, if as the OP points out it is 'all garbage' they don't have a whole lot of choice to discriminate.
- 9mo ago
- pharrington 9mo agoSo 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 9mo agoI 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 9mo agoHave 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 9mo agoYes. 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.
- ben_w 9mo agoI've seen all four quadrants of [good code, bad code] x [business success, business failure]. The real money we used to get paid was for business success, not directly for code quality; the quality metrics we told ourselves were closer to CV-driven development than anything the people with the money understood let alone cared about, which in turn was why the term "technical debt" was coined as a way to try to get the leadership to care about what we care about. There's some domains where all that stuff we tell ourselves about quality, absolutely does matter… but then there's the 278th small restaurant that wants a website with a menu, opening hours, and table booking service without having e.g. 1500 American corporations showing up in the cookie consent message to provide analytics they don't need but are still automatically pre-packaged with the off-the-shelf solution.
- tokioyoyo 9mo agoYou don't really have to.