AI doesn't generate working products, that's still your job • Hacker News Board

Re: AI doesn't generate working products, that's still your job

#211

Post by mortalapeman » Sat, Aug 01, 2026, 1:25 PM UTC

kouunji wrote: post #165

I find the base logic of this post flawed - it can make a prototype, but what about everything after the prototype? Well, um, then you work on those things too? It seems like the premise of articles like this assume that using AI means whatever you can one-shot from a four line prompt. There are obviously a lot of issues with it, but this just sounds like uncritical self-justification rather than any fundamental insi…

That's funny, I found the article to align exactly with my own personal experience of working with LLMs in cobdebases with poor test coverage, uncertain requirements and non standard production deployments. As soon as you are off the happy path, they start making really bad assumptions that break in production. Even the smartest LLMs haven't come close to what I'd consider good architecture for those environments.

Re: AI doesn't generate working products, that's still your job

#212

Post by jpeeler » Sat, Aug 01, 2026, 1:33 PM UTC

jbdamask wrote: post #143

Agentic Engineer: "How'd you solve the icing problem?" Vibe Coder: "Icing problem?"

Heh, reference was not immediately obvious to me (it's from Iron Man):

https://www.youtube.com/watch?v=hHgkVOOTl_Y

Re: AI doesn't generate working products, that's still your job

#213

Post by tonyhart7 » Sat, Aug 01, 2026, 1:33 PM UTC

Yeah but back then we need 10 engineer, now we need only maybe 2 - 4

Re: AI doesn't generate working products, that's still your job

#214

Post by jdw64 » Sat, Aug 01, 2026, 1:39 PM UTC

pmg101 wrote: post #195

jdw64 wrote: post #120

Earlier quoted context omitted.

The real problem is that we forget that there was a lot of bad code in the early days. When I studied books from 10 to 15 years ago, the patterns that were considered 'common practice' back then would be considered low-quality code today. Our threshold has risen. People tend to forget the rings of experience embedded in community codebases and only look at the final results. And they always claim that only the best r…

Can you give an example of a pattern that was considered common practice in a book 10 to 15 years ago that would be considered low-quality code today? My experience is pretty much the reverse: that we seem to just go round and round relearning the lessons that had already been learned in the past.

Right, there were examples like Singleton and baseController. We moved from ambient/global dependency access to explicit constructor injection and Composition Root, didn't we?

Application entry points use Composition Root now, but old general programming books didn't. Errors were handled differently too. In the past, you'd throw new Exception() and wrap it in try/catch at a higher level, but these days we use Result type modeling. Of course, C# still uses try/catch, but the guidance in .NET has long been to return predictable failures as type contracts.

Old .NET documentation used to encourage global access to common features and dependencies. Now it's shifted toward composition at the entry point.

Node.js used to use nested error-first callbacks as a standard pattern, but that's no longer the case, right? It moved to promise/async-await, and these days, as you know, type-based modeling is trending.

C# books also used to return null if something was missing, but now we use nullable reference types to express nullability more explicitly.

Even inheritance—these days it's often advised to avoid inheritance, but it used to be very common.

Just off the top of my head, I can think of quite a few examples. Record keywords and immutability features started appearing about 10 years ago, and Java has started adopting them too.

These are all outdated patterns now, with clearly defined use cases. More precisely, the contexts in which they should be used have become much more granular.

I could probably give about 30 more examples of this.

Re: AI doesn't generate working products, that's still your job

#215

Post by luckylion » Sat, Aug 01, 2026, 1:41 PM UTC

whstl wrote: post #158

havkom wrote: post #129

Earlier quoted context omitted.

They are great instruction followers in general. This is, one single bad instruction during months of work can mess things up.

I would say they're great until they aren't. Which means at some point in a session or in a long-lived-project they will resist very hard being steered like it would be done by another developer, product manager, a designer, or just the market in general. Most people don't find this to happen because the size of projects and the granularity of the expectations are wildly different.

I found that agents help, even if you don't parallelize. Having one agent control another and verify its results against rules you set has worked well for me because the controlling agent has no incentive to cut corners, and the implementor might, but it is being controlled.

My usage might be much simpler than what you do, but it went from "but I gave a list of things to do, you only did 5 of them" - "okay, here are the other 7, oh btw, I skipped the verification rule because nobody has time for that" to good compliance, the orchestrator starts the sub agents, tells them exactly one thing to do, and makes sure they've done it afterwards.

makes sense on planning as well, I think. spend your tokens on the best model to explore the problem and design the solution, but the implementation and testing/verification cycles don't need the strongest model you can get.

Re: AI doesn't generate working products, that's still your job

#216

Post by jdw64 » Sat, Aug 01, 2026, 1:44 PM UTC

pmg101 wrote: post #195

jdw64 wrote: post #120

Earlier quoted context omitted.

The real problem is that we forget that there was a lot of bad code in the early days. When I studied books from 10 to 15 years ago, the patterns that were considered 'common practice' back then would be considered low-quality code today. Our threshold has risen. People tend to forget the rings of experience embedded in community codebases and only look at the final results. And they always claim that only the best r…

Can you give an example of a pattern that was considered common practice in a book 10 to 15 years ago that would be considered low-quality code today? My experience is pretty much the reverse: that we seem to just go round and round relearning the lessons that had already been learned in the past.

And the 'monad' that functional programmers always talk about—same story. In C#, they encourage monadic composition by chaining errors. But about 15 years ago, that wasn't the case.

Back then, if there was no value → null. Now, even the absence of a value is modeled with Option, Maybe, or nullable types. Failures are handled not with throw/try-catch but with Result, Either, or Try.

Overall, we've shifted toward a style where we preserve the computation context and then compose the next computation. Instead of manually branching every time, now we use map, bind, or LINQ-style operations that define the composition rules.

Things that used to be used only by a small group of people eventually become embedded into the language itself.

For example, callbacks have evolved into Task, Promise, and async/await.

So honestly, I don't think quality has declined at all. I think there's just more context to keep track of now. I've seen around 40 different company codebases. I have no idea about US code, but I've seen code from Korean and Chinese large corporations, and the difference between past and present code is quite significant.

Re: AI doesn't generate working products, that's still your job

#217

Post by zulban » Sat, Aug 01, 2026, 1:44 PM UTC

ThePhysicist wrote: post #46

I'm about to throw away multiple months of LLM generated code for one of my side projects. I was really careful writing design specs and it wasn't even a new code base the LLM worked on, but still after several months of AI changes I feel my code degraded more and more into a subtle mess. Hard to explain, each individual change looked good and logical and on the surface the codebase looks fine, but looking at the who…

It's hard to take criticism like this seriously when you didn't say the model you used. It's like someone complaining about a car's performance but they leave out the brand and year. If you don't think that's relevant I just can't take you seriously.

Re: AI doesn't generate working products, that's still your job

#218

Post by zulban » Sat, Aug 01, 2026, 1:47 PM UTC

sdevonoes wrote: post #11

The litmus test is this: do you enjoy consuming AI-generated stuff? I don’t. Whether it’s written text, or video, audio, restaurant menus, clothing pictures, documentation, airport control, ads… I do think there’s value in LLMs but as a sort of better search engines and q/a machines.

People are spending billions of dollars a month in aggregate because yes, they do like it.

Re: AI doesn't generate working products, that's still your job

#219

Post by supriyo-biswas » Sat, Aug 01, 2026, 1:48 PM UTC

microtonal wrote: post #106

ThePhysicist wrote: post #46

I'm about to throw away multiple months of LLM generated code for one of my side projects. I was really careful writing design specs and it wasn't even a new code base the LLM worked on, but still after several months of AI changes I feel my code degraded more and more into a subtle mess. Hard to explain, each individual change looked good and logical and on the surface the codebase looks fine, but looking at the who…

I am more and more just using LLM assistance over fully agentic programming. Even when writing detailed instructions, guardrails, and whatnot, a lot of modern models (e.g. Opus) are optimized to work autonomously. But over time they just make a mess out of code bases, often because they don't truly understand good design, but will just make changes until they reaches their objective, leaving a mess for a human to cle…

If I may ask; what's your experience doing this with smaller models like gpt-5.x mini/luna on the lowest reasoning setting? Does it work well?

I've been thinking of doing the same since the models will often take design decisions that I am not a fan of, or make changes in a way that is easily understood by me, which leads to tech debt and being unable to anticipate what it will take to deliver a certain feature (e.g. whether we should build on top or build from a clean slate, etc.)

Re: AI doesn't generate working products, that's still your job

#220

Post by ModernMech » Sat, Aug 01, 2026, 1:49 PM UTC

KronisLV wrote: post #205

ModernMech wrote: post #196

Earlier quoted context omitted.

It's like a variant of the halting problem though: given N agents in a review loop reviewing a codebase, will it ever terminate and say the thing is done and bug free? It seems to me just from @codex review, given a codebase of any appreciable size, if you ask the agent to find things to fix, it'll find things to fix. And despite N agents agreeing that some code is ready to ship, I've still sat down to try it and not…

> will it ever terminate and say the thing is done and bug free? Will human reviewers, if you ask them to find more bugs? Will it be because there really are no bugs, or because they got tired and just can't see any? How would you even figure out when the thing is done and is bug free? There have been bugs that have been in codebases for years and have only been discovered recently. Would you trust static analysis to…

Yes, I've often mused that the halting problem should have corollary for determining when a faculty meeting will end, if at all.