And another corollary is the formerly golden lazy and clever are also transformed into lazy and productive because they no longer need to apply their cleverness to get results...

We developed languages that removed GOTO so that developers don't shoot themselves in the foot. We will surely develop harnesses that will ensure that majorly occurring problems are solved before they hit production.

I'm going to have to remember this, gold comment

https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cl...

Yes, they're certainly squeezing 500 lines of functionality into 250,000 lines of code. Agents are great at this.

So where is all that new software? My laptop and phone run essentially the same software as 2 or 3 years ago. Yes there were some minor updates to some apps, but nothing faster than in the years prior.

Where does all that supposed productivity go?

I mean these guys are not even pretending to be reviewing the code.

It just gets “reviewed” by an LLM, which will find a nitpick while ignoring the huge fire in the core of the design, force the planner to make even more sloppy code to cover for an irrelevant test case. Rinse old tokens and repeat until you hit limits.

What kind of applications are people building that involve 250k loc a week? Genuinely trying to understand this.

Can the users of the software even keep up at that point? We may have reached diminishing returns on software production, and not enough impact on the rest of the process.

> All humans would need to do is communicate clearly what needs to be made and flag problems as they come up.

Kinda what i'm doing already, but for the young startup I'm at that's surprisingly tons of work. I miss the days we wrote code by hand boy those were fun 8.5 hours workdays.

"A couple more step functions" is doing a lot of heavy lifting here

> All humans would need to do is communicate clearly what needs to be made and flag problems as they come up.

Sounds like the easiest thing in the world: I wonder why did we not think of it earlier?

Neither will LLMs. That's not how their nondeterminism works.

> Someone who knows that 1 + 1 = 2 will not decide that it's suddenly 3 unless we start accounting for health problems.

And?

The p(that kind of error) is pretty small now. At what point does a probability coming out of an LLM look like "knowing", such that spitting out the wrong answer despite that probability looks like a health problem, a typo, or even just boredom? (Thinking of the Lizardman constant here: https://en.wiktionary.org/wiki/Lizardman%27s_Constant)

It's a continuum for both them and us, even if the mechanism is wildly different.

> Making mistakes is not the same as non-deterministic.

i.e. when the dismissal is "non-deterministic" when it should be "Making mistakes", is itself a mistake.

Lol, humans make such absurd mistakes (and worse) all the time through simple typos, which is effectively random. The key for 2 is right next to the key for 3, after all.

> Someone who knows that 1 + 1 = 2 will not decide that it's suddenly 3 unless we start accounting for health problems.

But this is plainly false. This kind of unforced error occurs all the time.

For example, once when I was in high school I traced an error in my math homework to an intermediate calculation of "2 + 2" as being "3". There was no reason.

What we can say about humans is that, if they know that 1 + 1 = 2, (a) they are unlikely to change their mind about this in any kind of lasting or permanent way, and (b) the rate at which they will mistakenly produce other values for 1 + 1 is very low. But it will happen occasionally, and when it does happen, "they just suddenly decided on the wrong value" is an extremely accurate description of what that looks like.

That is very much a similarity.

> I've seen LLMs do something correct 98% of the time then randomly do something crazy that a human would never do because we have continual learning

I've seen humans vote for Brexit, re-elect Trump, ask questions clearly already answered in an FAQ, try to pull on a door labelled "push", and insist on giving me homeopathic silicon dioxide pills* that cost £5** for a 10-12 gram packet.

Continual learning is a difference, but not by itself a reason to care about "deterministic results".

Nor, indeed, correct results.

> As humans we don't have our memory reset multiple times per day

Humans need sleep well before they can read a million tokens' worth of written text. We're more like 300k tokens if you're actually reading and not skimming for 16 hours straight.

Again, different (in soooo many ways), but this isn't a relevant difference when the topic is "deterministic results".

* yes, sand: https://dailymed.nlm.nih.gov/dailymed/fda/fdaDrugXsl.cfm?set...

** and that was what it cost in the 90s

> Is that the fault of AI or management for not firing them?

How does the system behave in a variety of scenarios including failures and restarts. How is state maintained coherently. There are the kinds of systems problems that an engineer needs to reason through, and if there are bugs in such decisions, they end up becoming costly. I dont expect AI or LLMs to solve these problems at all, since each of them has nuances and tradeoffs which are specific to each system. In short, there is specification complexity in precisely describing system wide behaviors, and unfortunately, there is no lean/tla+ to meaningfully describe systems at scale. You could then ask: How can a system have guaranteed behaviors if they cannot be even stated or proved formally ? The answer to this is how protocols like raft/paxos initially convinced us of their behaviors which is in human review and understanding. That begs the question: How can human review and understanding be reliable, and the answer is that it is not reliable, but humans have ability and processes to continuously learn from experience in the real world. So, our understanding is grounded not only by whats out there in books etc, but also by our own interactions with the world.

Long story short: The responsibility for system-wide behaviors of software systems relies on human review and understanding, which while imperfect can continuously learn.

hey man, don’t knock the JSP, I just edited a few :) it is alive and kicking in 2026

If that's how you create software then you belong to the lazy and incompetent group in my book. I provide AI with valuable context such as code coverage information, architecture analysis, test requirements, important "gotcha's" that a competent engineer would know about in their architecture or system etc. I'm still very much the person who comes up with the solutions. For me AI is replacing the code editor, it's not replacing the thinking.

> How is it a "multiplier" rather than an "equalizer"?

Because without the responsible human engineer in the loop, it'll all gradually decay in a cascade of edge-cases. This happens with human written code as well (every "we'll replace this prototype before we ship" you've ever worked on), but with LLMs it happens at 10-100x the rate.

Not completely, just as a very personal example:

In optimizing my game I noticed framerate hitching even after efficient algorithms were in place for expensive stuff, which was caused by shaders not being precompiled consistently or assets not being preloaded in time. The Agent who'd been profiling and optimizing had moved many preloads to a loading screen, which caused a long loading lock, and what it didn't move ahead was loaded and compiled at use, creating slow frames since work was being done on the main game loop.

I instructed the agent to create a speculative pre-warming/compilation priority queue with a per-frame budget, with priority being determined by likelihood signals that the asset or shader will be used soon. Then I had the AI run fully headed games and hunt down causes for frames going over 16ms, and work through them until a batch of games had fewer than 1/1000 frames >16ms and no frames over 60ms after a short initial settling period.

The approach, the metrics, the validation system and the loop were "prompt engineering" above and beyond what I would expect from someone who was merely "vibe coding a game."

The skill floor has definitely been lowered, but if this were actually true then firms would be replacing senior software positions with entry level ones, not the other way around.

Do you use the word "equalizer" in this context to mean that AI has made the playing field equal for both competent developers and laypeople? Do you reckon that competence plays no role these days?

If this is how you use LLMs, you are the problem.