Well said. People love to make everything black and white / good and bad. But things are rarely that simple.

We would need a lot of anecdata. Would we trust a doctor/pilot/engineer of 25 years more with the tried and tested (but now aging) kit of their time, or the acolyte that has been fully absorbed by the latest and greatest and has now more than doubled their productivity?

While code quality may go up on a case by case basis, we should be mindful whether we are comparing it to our own personal baselines, or to the average code quality across the board. I.e. will the baseline regress to the mean, or raise the floor for the average coder?

Even if the jury is still out, I would still say you are both right already.

The amount of slop produced even in company setting is staggering and I don't like it one bit that neither the submitter nor the reviewer of the PR paid due dilligence. And I am only complaining because it then becomes my problem. So, then I have to start nagging people to clean that up. I can say with 100% certainty that the problems I face now would not have happened without LLMs.

That said, used with care, with proper supervision, with dilligence to review what LLMs did, I still think they can be and are beneficial.

I think that we are just not used to getting results of questionable quality from the tools we use. So, I am hopeful that we will learn and it will improve with time but still find myself dreading the age of the vibe coder.

It's a bit weird when the article in question is predominantly about software development in a professional setting and the top comment is about how some people in thread are disregarding this context and opining unrelatedly about their unique solo development or personal project development experiences, to then respond to said comment by insistently going on about how AI is great for your personal projects, when people are unable to assess the value of your AI-assisted personal projects and whether they would concur with the high opinion you have of them. A turd with a CI pipeline is still a turd, I think we can all agree on that. IF someone said AI is great because they can now expand test coverage and build a CI pipeline for their todo app in rust, it wouldn't exactly be the proof you're looking for I don't think.

But I agree fully with your last paragraph, and said something similar in a comment elsewhere where I stated my tangible bar as being a Ladybird like browser built from scratch achieving Chrome parity in six months while doing continuous stable releases with coding agents in tow. Otherwise, as you said, the jury is still out.

>And for some use cases, some crappy software is better than no software

The best use case i've seen for AI is people generating random one shot projects for themselves, which is honestly so cool. You can make some basic app that does something very specific, that would have taken objectively a lot longer to make by hand. This is when 'crappy' software is more than good enough for a specific problem

In the DORA group's reporting on AI-assisted software engineering, they indeed state that across industries, quality goes UP with the use of AI assistants like Claude and others.

Moreover, in my experience helping businesses on this topic; They never defined or made measurable what quality meant in the first place. Then when they finally do figure it out, it turns out that the average repository is a total disappointment in terms of absolute quality.

Same for me. I have not yet successfully used an LLM to generate code to produce a feature, though to be fair, it might just be because I don't have the patience to go back and forth with it (will readily admit that I am using it wrong).

Also, while some code review comments are just plain wrong, LLMs did produce some damn good comments, on the same level as a different senior engineer might note had they taken the time to study the code carefully.

Same here, it's been catching a lot of bugs that would have been very hard to trace or discover, often just in the process of doing something else.

> The fact that these "stochastic code extruders" can solve Erdos problems is sort of the proof in the pudding.

This claim is very misleading and not really true. It reflects the kind of exaggeration and spin made by corporate marketing. I would not call this a fact at all. Like many claims made by for-profit marketing, if one looks into the details and think critically about what is being claimed, one can see that consumers are jumping to false conclusions.

That said, it is very cool how an LLM helped human mathematicians in the recent specific Erdos problem solution announced by OpenAI. Just don't jump to the conclusion that anybody can input any Erdos problem into an LLM and a solution will come out the other end.

It's like people complaining about "poor quality plastic trinkets" that replaced well-made household items. Of course high-quality things can be (and are) made of plastic. The problem is that you can still make a very cheap passable thing out of plastic, that would be uneconomical to make out of metal or wood.

Same with code: by using AI, one can produce passable software trinkets very cheaply, that would be uneconimical to produce by paying poor-quality human developers.

The floor has moved downwards, allowing to produce a flood of new, trash-quality, disposable code very cheaply. It does not mean that we'll have to use only that code. But unfortunately we'll have to live with it, too.

> Also I wonder how many folks honestly look in the mirror and think: how does the median programmer differ from an LLM.

Once you step out of pure-software orgs, it becomes clear that most would benefit from having AI write code. There's a huge moat between most people and the point where they can afford/find the effort of someone that can write software.

These people, that only care about practical results rather than somewhat tangential things like "elegance" and "maintainability", are going to benefit tremendously.

>> Shipping poor quality and user hostile software actually hurts people.

> Could not agree more. So why do you think humans are inherently better at this?

Because humans are capable of empathy

> to the same derisive comment of these models being, in your words "stochastic code extruder"

So many excited and insulted LLM adopters on this thread. There is nothing derisive in that comment, it is simply the purest possible definition of how they work. Stochastics is a branch of maths you know.

> can solve Erdos problems is sort of the proof in the pudding

For the non-engineer, non-mathematician it may sound authoritative, but you'd probably be surprised to learn that most of Erdos problems are not at all complex - they are just not very interesting or relevant. So it is a proof in the pudding, provided the pudding is made of shit - the kind of stuff LLMs produce most of the time.

> I just don't quite understand this, is it that: (1) agentic code is inherently inferior to human code and thus (2) shipping agentic code is actively harmful?

Yes and yes - have you not heard of that AWS incident with Kiro when the "agentic" shit deleted an entire infrastructure environment, complete with data, config, etc.?

> Also I wonder how many folks honestly look in the mirror and think: how does the median programmer differ from an LLM

Apart from the obvious absurdity of this statement - I know a lot of you non-engineer types feel "empowered" by the LLMs, in the sense of how they immediately seem a genius when you ask them on a topic you are not expert in, but you may want to read a book on programming first - maybe you'll get a clue then.

I've always felt we somewhat failed as engineers (I included, of course) when I was doing boilerplate by hand. We should have taken the time to get those autogenerated. But... it takes time and the generator is always more complex than the produced code, sometimes even by a few factors, so it also takes an expert to maintain.

As for tests, I've seen LLMs produce good ones as well as useless ones. I guess it's all about instructions... sorry, prompts... no, sorry, prompt engineering to get it right and done properly.

That said, I am also very concerned with brain rot. Engineers nowadays can commit code they don't understand without a blink of the eye. Slowly, the knowledge may get sparse if we are not careful about it.