I've seen too many similar posts on Hacker News. From 2025 to 2026, I've seen countless articles with titles like 'The Prototype Isn't the Product.'

I think these are defensive mechanisms, a kind of lullaby for the Gen AI era.

Why is this discourse endlessly reproduced? In my view, it's because the industry is still searching for a new methodology to control the waterfall of Gen AI code. The cognitive dissonance that results is being resolved by relying on vague personal virtues like 'craftsmanship,' 'fundamentals of computer science,' and 'human judgment.'

If the goal is to review Gen AI code in its entirety, the way an engineer would review a PR, then honestly, I don't see the point of using Gen AI in the first place.

Yes, models lack judgment and only do pattern matching. But lately, I've noticed that in closed systems, Gen AI often produces more logically coherent code than humans do. If that's the case, maybe programmers should shift toward designing closed systems where algebraic data types ensure the program works correctly.

Because using Gen AI means you're committing to codebases that go beyond individual cognitive limits. Once you start using Gen AI code, there's a subtle mismatch with human written code, a fundamental impedance mismatch, like the one between ORM and SQL.

In that sense, I honestly don't know.

The arguments that have been repeated for nearly a year all sound basically the same. But when I look closer, this isn't Gen AI era coding. It's just old era methodology with 'human' swapped out for 'AI.' If the subject changes, the methodology should change too.

Looking at the countless repetitive posts on HN, it shows what HN programmers are afraid of. They're afraid of the destruction of their overall meta-methodology.

All the arguments being made now are about how to become a good senior engineer in the old days.

But is that analogy really appropriate for the volume of code AI is generating?

The amount of code being generated is exploding. The amount of complexity is exploding. Responsibility is becoming unclear. These aren't issues of individual skill. Saying that drivers just need to be more careful when traffic increases is bad road policy. The core is that the roads and signaling systems need to change.

A new subject requires a new methodology.

In that sense, I think the recent post from Jane Street is more like a new solution. Of course, ADT doesn't guarantee that modeling always holds either.

So honestly, I don't know. When I look at HN, it seems like all I see is what social signals people are most anxious about.

▲

imilev 4 hours ago | parent | next [-]

I disagree tbh, the prototype is not the product not just because of technical abilities but also because of product expertese in a topic.

If it was otherwise outsourcing companies would've dominated the market for a long time, but it is with the exp from clients and many users that you get to build a great product.

It takes a lot of time to understand what is the pain of the user, in many cases we know what the problem is but we have not time to think of a good solution to it.

	▲	jdw64 3 hours ago \| parent [-]
		I agree with the point that a prototype is not technology, but the problem is that the argument limits gen AI code to just prototyping. I also think prototyping and production are different, but the boundary between what is a prototype and what is production is actually quite blurry. That's not the core issue, though. The market itself is demanding heavy AI use, and GitHub has already reported a massive increase in repository creation. In other words, if we acknowledge that there are clearly users who want this GEN AI code, then we should be having a discussion about how to actually push that code into production

▲

gabrieledarrigo 4 hours ago | parent | prev | next [-]

> Looking at the countless repetitive posts on HN, it shows what HN programmers are afraid of. They're afraid of the destruction of their overall meta-methodology.

I think this already happened. What's hard to swallow for us is the countless years spent studying, researching, and investing our time to be the best possible professionals in a very demanding, skill-intensive industry.

Now that software development is starting to be industrialized, I think it's fair to react with fear and uncertainty.

Yep, we are trying to find new strategies and methodologies to still stay relevant, but I think they'll become obsolete soon once the technology reaches a maturity point for full automation and the industrialization of the development process.

What it will look like, I don't know (I have a few guesses), but what I know is that I'll struggle a lot, in the middle of my forties, to reskill myself, especially considering a country of no opportunities like Italy.

> In that sense, I think the recent post from Jane Street is more like a new solution.

Can you please share it?

	▲	bluefirebrand an hour ago \| parent \| next [-]
		> What it will look like, I don't know (I have a few guesses), but what I know is that I'll struggle a lot, in the middle of my forties, to reskill myself, especially considering a country of no opportunities like Italy. Similar thing for me. Canada doesn't have tons of opportunity and I don't even know what I would want to even try And do I want to spend a couple of years reskilling knowing that AI is coming for that work too? And general purpose robotics is nipping at the heels of physical labor too. That's assuming I'm even physically fit enough to attempt a more physical job I don't view AI as a productivity booster. I think it is a human mulching machine.
	▲	Nursie 2 hours ago \| parent \| prev \| next [-]
		Similar situation here, am a senior dev with 26 years in the industry and now some management experience. Some of my guys are getting massively productive, some are not really catching the wave. But me … I feel like the joy of coding has been sucked out from under me, and I see the (very sharp) product guys being more and more able to tell Claude rather than ask a developer. If they can perform 90% of what we were doing and fulfill customer needs, probably faster, who needs us any more? I’ve started wondering if it’s too late to retrain as an electrician.
	▲	jdw64 3 hours ago \| parent \| prev [-]
		Honestly, I'm scared too. I think both of our countries lack opportunities. If you look at intergenerational mobility, we're pretty similar on average. But on the flip side, I also believe that if you catch the new wave well, you can find something new. That's probably just self-rationalization, though. One post I enjoyed reading was this one [1]. [1]https://blog.janestreet.com/formal-methods-at-jane-street-in...

▲

movedx01 4 hours ago | parent | prev | next [-]

The lullaby for the Gen AI era exists, but its for CEOs and it is being played in management meetings, it's main theme is about maximizing EBITDA.

The defensive mechanisms kick in because even though more code is generated than ever, we are not observing an equivalent rise in software quality or usefulness, some would perhaps argue it's even opposite.

If gen ai for code was really what it is being sold as it would all be obvious to everyone, we would be seeing better software all around us everywhere and posts such as the one here would just be laughed off, delusional, but they are not.

The code explosion did happen, the value of software this code makes - not yet. Not to say it won't, its just not here right now, and it never happening is still a possible outcome.

▲

jdw64 3 hours ago | parent | next [-]

I don't think so. GPT CODEX and Claude Code are already saying they use AI in their own codebases, and they have huge numbers of active users. Can that really be called a failure?

In my view, it's just that the existing infrastructure layer is so thick that it's not immediately visible—but AI adoption is already quite widespread across many companies.

People say program quality has declined, but I don't think so. The average quality of programs has improved significantly. You can see this by looking at open-source architecture books from 10 to 15 years ago.

That's why I think we need to first define what we actually mean by 'code quality' before discussing this issue.

Realistically, this discussion could easily drift into a debate about code quality. But if you look at older books on open-source architecture, there were many issues—runtime null references, confusing callback references, diamond dependencies, and so on.

These days, many of those problems are caught by linters and other tools. At the micro level, code quality has definitely risen compared to the past.

The real problem is that programs are getting larger. The minimum requirements for a program to be viable have gone up, while the available workforce hasn't kept pace. But in terms of quality, I think we can confidently say that overall code quality has improved compared to the past.

The issue is the gap between micro-level code hygiene and macro-level semantic coherence. And the key question is how we can maintain that macro-level semantic coherence while using AI-generated code. I think these are fundamentally different problems.

▲

movedx01 3 hours ago | parent [-]

Adoption absolutely did happen, I am not questioning that. What I am questioning is whether it really is the revolution the people selling it want us to believe it is.

Just to disclose: I use those every day, I have two Claude Max 20 subscription myself. I am still in doubt how much more productive professionally it made me. I am having a ton of fun in exploring stuff I never would have otherwise though.

I define software quality in my daily life by this: how often I am delighted by the piece of software I use. Those moment are rare and far between, and it's not getting any better.

▲

jdw64 3 hours ago | parent [-]

Senior, I respect your opinion. I think your skills are so advanced that you don't feel the impact as much. That's a different perspective.

>I am delighted by the piece of software I use. Those moments are rare and far between, and it's not getting any better.

First, regarding how much satisfaction we get from the software we use—I see that part a bit differently.

Because that's more about UX and product design than code quality. I think it's because in the business domain, people only attempt safe things. In the early days of the internet and the web, people didn't have a clear direction, so there were many bold attempts. Those original attempts felt fresh. But now we have a set of 'norms.' Most people just implement those norms. I think the reason you don't feel that freshness anymore is precisely because you're already so skilled.

What I'm focusing on is this: I'm not sure about my own productivity, but I'm finding joy in exploring areas I couldn't explore before. The problem is that most of this code just ends up implementing solutions that already exist. That seems to be the core issue.

In other words, both you and I have our threshold for 'average' set so high that the threshold for calling something 'good' has become too high as well.

	▲	skydhash 2 hours ago \| parent [-]
		> Because that's more about UX and product design than code quality. I think it's because in the business domain, people only attempt safe things. Not really. It’s mainly about the lack of frustration. People will learn the most obtuse way of using a software if it’s important. But they want to spend that effort only once, and then have valuable results as the ROI. Meaning no random crashes, no slow process,… When you can have something that runs without babysitting, or just be able to use the tool and do your tasks, it removes a lot of mental load.

▲

watwut 3 hours ago | parent | prev [-]

> even though more code is generated than ever, we are not observing an equivalent rise in software quality or usefulness

More code produced by a company that has history of low quality ... means more low quality.

A company that is unable to ship useful features will produced useless features whether they generate code or not.

▲

mikojan 3 hours ago | parent | prev [-]

> Because using Gen AI means you're committing to codebases that go beyond individual cognitive limits.

Sure, the amount of code generated is exploding but where are these successful production applications that have "[gone] beyond individual cognitive limits"?

It's been some time now. Half a year ago I was concerned with the impact Gen AI might have on this profession. Today I am primarily tired of Gas Towns, Loops and the next fad.

Why do I have to still debug complex problems myself. Why do I have to still do detailed examinations.

Gen AI helps building big software. But the only thing it has truly replaced me in is building small software that in most cases I wouldn't have bothered building in the first place.

▲

jdw64 3 hours ago | parent [-]

In today's massive applications, the number of people who can see the entire structure is very limited—yet commercial applications still work.

And I think GPT Codex and the products from AI companies are, at least for now, working reasonably well.

Of course, it depends on your baseline for quality.

But here's what I think is the core point:

Modern SaaS applications have become significantly more complex compared to older codebases. If you look at old books on open source architecture, the lines of code and overall size were much smaller. But today's commercial applications require a much higher level of complexity just to be marketable. In that kind of complexity, there are bound to be many bugs. But I think AI has significantly reduced that complexity burden

▲

mikojan 3 hours ago | parent [-]

We have been building complex software before and we continue to do so. The question is where is this mythical codebase 10 times more complex then the Linux kernel that we were previously unable to produce? Or let it just be complex software. Where is it? What are the names?

▲

jdw64 2 hours ago | parent | next [-]

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 results represent their community.

But the 'bad results' were also produced by the same community.

From that perspective, I think the floor has risen significantly. You might disagree. People with name recognition in open source usually only see the 'best' code.

But I mostly see the 'worst' code.

This is an issue of accessibility depending on your environment. I work for $15 an hour, as a freelancer doing subcontracting work in Korea, so I mostly see the worst of the worst. In that context, AI code quality feels like a huge improvement.

Because in closed source codebases, there's plenty of low quality code.

In contrast, open source projects tend to curate only the best code, driven by visibility and reputation. I think that difference is significant.

You might not agree with me. And that's fine. We all have our own value systems. I don't agree with you, and you probably don't agree with me. That's a natural consequence of us being different people.

But here's what I think: I respect you, but our views can differ. I think your point is valid in certain contexts, but I stand by mine.

▲

pmg101 42 minutes ago | parent [-]

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.

	▲	ModernMech 22 minutes ago \| parent [-]
		I feel like the industry has learned a lot of good lessons from functional programming, and that has been reflected by functional features being baked into almost every popular imperative language.

▲

jdw64 2 hours ago | parent | prev [-]

I think this is a complex issue.

If there were a need for a new open-source OS to replace Linux, it would be used then. Once infrastructure becomes entrenched, the cost of dismantling or replacing it becomes enormous.

So you might argue:

'If AI is so great, shouldn't it be able to directly modify Linux's millions of lines of code right now?'

My answer is different:

'Why break something that already works? It only makes sense to change it when a problem actually arises.'

The example of Bun, originally written in Zig and later ported to Rust, illustrates this. Zig is a relatively new language, but whether for political reasons or not, Bun was eventually ported to Rust. And after the rewrite, Bun still works just fine.

And rewriting infrastructure from scratch is fundamentally a cost issue.

I can handle up to 60,000 lines of code on my own. With AI, I can handle up to around 200,000 lines. But building new infrastructure from scratch is an entirely different matter.

Why would you replace something that already works with AI? That's a separate question. If the current OS were no longer viable and a new one were needed, then the situation would be different.

In other words, I don't think your argument is wrong—I just don't think there's enough motivation for it.

In that sense, codebases that heavily use AI are already appearing in abundance.

There were issues with Open CLAW, but it was purely AI-written and still boasted a huge number of active users, right?

Same goes for Codex.

So my conclusion is this: AI is currently being used in layers above the infrastructure. But if a new infrastructure needs to be built, that's when AI will come into play.

In other words, it's a matter of motivation. Using AI for coding doesn't eliminate maintenance costs. And to be extreme, both maintenance and generation now require spending 'tokens'—you're paying money instead of the developer's time. We need to think about that cost.

In other words, there's no reason to break something that's already working.

I'd summarize it as: there's no reason to reinvent the wheel.