Live data from Hacker News

Code is cheap. Show me the talk

nadh.in

131–140 of 237 posts

Re: Code is cheap. Show me the talk

#131

I asked Codex to write some unit tests for Redux today. At first glance it looked fine, and I continued on. I then went back to add a test by hand, and after looking more closely at the output there were like 50 wtf worthy things scattered in there. Sure they ran, but it was bad in all sorts of ways. And this was just writing something very basic. This has been my experience almost every time I use AI: superficially…

I've always said every line is a liability, its our job to limit liabilities. That has largely gone out the window these days.

The only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!"

For one off, this is fine. For anything maintainable, that needs to survive the realities of time, this is truly terrible.

Related, my friend works in a performance critical space. He can't use abstractions, because the direct, bare metal, "exact fit" implementation will perform best. They can't really add features, because it'll throw the timing of others things off to much, so usually have to re-architect. But, that's the reality of their problem space.

Re: Code is cheap. Show me the talk

#132
post #13

I keep on wondering how much of the AI embrace is marketing driven. Yes, it can produce value and cut corners. But it seems like self driving by 2016 Musk prediction. Which never happened. With IPO/Stock valuations closely tied to hype, I wonder if we are all witnessing a giant bubble in the making How much of this is mass financial engineering than real value. Reading a lot of nudges how everyone should have Google…

I realize many are disappointed (especially by technical churn, star-based-development JS projects on github without technical rigour). I don't trust any claim on the open web if I don't know the technical background of the person making it. However I think - Nadh, ronacher, the redis bro - these are people who can be trusted. I find Nadh's article (OP) quite balanced.

> ronacher

I think he’s soured a bit on the 10x claim echoing many of the quality concerns expressed by others in this thread: https://lucumr.pocoo.org/2026/1/18/agent-psychosis/

Re: Code is cheap. Show me the talk

#133
post #42

From the article: Historically, it would take a reasonably long period of consistent effort and many iterations of refinement for a good developer to produce 10,000 lines of quality code that not only delivered meaningful results, but was easily readable and maintainable. While the number of lines of code is not a measure of code quality—it is often the inverse—a codebase with good quality 10,000 lines of code indica…

It’s like the google claim. There was a years worth of work up front, but AI took the typing from a few days to a day.

Re: Code is cheap. Show me the talk

#134

> Ignoring outright bad code, in a world where functional code is so abundant that “good” and “bad” are indistinguishable, ultimately, what makes functional AI code slop or non-slop? I'm sorry, but this is an indicator for me that the author hasn't had a critical eye for quality in some time. There is massive overlap between "bad" and "functional." More than ever. The barrier-to-entry to programming got irresponsibly…

This is the "artisanal clothing argument". I'd think there'll be a dip in code quality (compared to human) initially due to "AI machinery" due to its immaturity. But over-time on a mass-scale - we are going to see an improvement in the quality of software artifacts. It is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality r…

Artisanal clothing is functionally equivalent to mass-produced clothing, but more expensive.

Much of contemporary software is functionally equivalent but more expensive to run and produce than previous generations. Chat, project management, document editing, online stores… all seem to have gotten more expensive to produce and run with little to no gain in functionality.

Complexity in software production and tooling keeps increasing yet functionally software is more or less the same as 20 years ago (obv. excluding advancements depending on hardware like video, 3D rendering, LLMs, etc.

Re: Code is cheap. Show me the talk

#135
post #25
post #22

Earlier quoted context omitted.

I don't think things have changed that much in the time I've been doing it (roughly 20 years). Tools have evolved and new things were added but the core workflow of a developer has more or less stayed the same.

I also wonder what those people have been doing all this time... I also have been mostly working as a developer for about 20 years and I don't think much has changed at all. I also don't feel less productive or lacking in anything compared to the newer developers I know (including some LLM users) so I don't think I am obsolete either.

Isn’t there a whole ton of memes about the increase in complexity and full stack everything and having to take in devops, like nothing has changed at all?

Re: Code is cheap. Show me the talk

#136

I asked Codex to write some unit tests for Redux today. At first glance it looked fine, and I continued on. I then went back to add a test by hand, and after looking more closely at the output there were like 50 wtf worthy things scattered in there. Sure they ran, but it was bad in all sorts of ways. And this was just writing something very basic. This has been my experience almost every time I use AI: superficially…

The main issue I've seen is it writing passing tests, the code being correct is a big (and often incorrect) assumption.

The majority of devs do the same thing.

Re: Code is cheap. Show me the talk

#137
post #131

Earlier quoted context omitted.

I've always said every line is a liability, its our job to limit liabilities. That has largely gone out the window these days.

The only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!" For one off, this is fine…

I believe this is conflating abstraction with encapsulation. The former is about semantic levels, the later about information hiding.

Re: Code is cheap. Show me the talk

#138
post #48

I think if your job is to assemble a segment of a car based on a spec using provided tools and pre-trained processes, it makes sense if you worry that giant robot arms might be installed to replace you. But if your job is to assemble a car in order to explore what modifications to make to the design, experiment with a single prototype, and determine how to program those robot arms, you’re probably not thinking about…

A software engineer with an LLM is still infinitely more powerful than a commoner with an LLM. The engineer can debug, guide, change approaches, and give very specific instructions if they know what needs to be done. The commoner can only hammer the prompt repeatedly with "this doesn't work can you fix it". So yes, our jobs are changing rapidly, but this doesn't strike me as being obsolete any time soon.

Yep, I've seen a couple of folks pretending to be junior PMs, thinking they can replace developers entirely. The problem is, they can't write a spec. They can define a feature at a very high level, on a good day. They resort to asking one AI to write them a spec that they feed to another.

It's slop all the way down.

Re: Code is cheap. Show me the talk

#139
post #131

Earlier quoted context omitted.

The only people I've known that share this perspective are those that hate abstraction. Going back to their code, to extend it in some way, almost always requires a rewrite, because they wrote it with the goal of minimum viable complexity rather than understanding the realities of the real world problem they're solving, like "we all know we need these other features, but we have a deadline!" For one off, this is fine…

I believe this is conflating abstraction with encapsulation. The former is about semantic levels, the later about information hiding.

Maybe I am? How is it possible to abstract without encapsulation? And also, how is it possible to encapsulate without abstracting some concept (intentionally or not) contained in that encapsulation? I can't really differentiate them, in the context of naming/referencing some list of CPU operations.

Re: Code is cheap. Show me the talk

#140
> crystal clear software development plan and the exact know-how to implement it

This is simply not how expert programmers work. Programming is planning, and programming languages are surprisingly good planning tools. But, of course, becoming an expert is hard and requires not only some general aptitude but also substantial time, experience and effort.

My theory is that this is a source of diverging views on LLMs for programming: people who see programming languages as tools for thought compared to people who see programming languages as, exclusively, tools to make computers do stuff. It's no surprise that the former would see more value in programming qua programming, while the latter are happy to sweep code under the rug.

The fundamental problem, of course, is that anything worth doing in code is going to involve pinning down a massive amount of small details. Programming languages are formal systems with nice (well, somewhat nice) UX, and formal systems are great for, well, specifying details. Human text is not.

Then again, while there might be a lot of details, there are also a lot of applications where the details barely matter. So why not let a black box make all the little decisions?

The question boils down to where you want to spend more energy: developing and articulating a good conceptual model up-front, or debugging a messy system later on. And here, too, I've found programmers fall into two distinct camps, probably for the same reasons they differ in their views on LLMs.

In principle, LLM capabilities could be reasonably well-suited to the up-front thinking-oriented programming paradigm. But, in practice, none of the tools or approaches popular today—certainly none of the ones I'm familiar with—are oriented in that direction. We have a real tooling gap.

Post reply on HN