Hacker News Reader

Comment by sublinear | Hacker News Reader

Wrong.

If the software makes money because it's expected to work reliably, every edge case matters. Web games aren't exempt from engineering challenges. In fact, the more trivial the problem seems on the surface, the more likely it is to have edge cases.

Bugs are always prioritized based on how big of a deal it is for the customer. They don't like to wait and they rarely give second chances.

AI doesn't fit into any dev workflow except greenfield or analysis. Everything else needs a lot of close human attention and human discussion. AI doesn't read minds.

View on HN

I think you are misssing the economics of the situation, which the GP is implicitly referring to. You have 24 hours in a day. A person that is making a web game that he wants to release cannot spend all of his effort chasing one in a million bugs, as that would eat into the time he has to actually make a great and engaging game. He can’t worry about how the game renders on Internet Explorers running in PowerPC. If you are making a kernel, a single RCE in an edge case (worse, even in a adversarially induced edge case) can equate to an emergency patch and general loss of trust in your system. The kernel programmer is even incentivized to do the opposite of the web game guy, which is remove functionality that they do not think they can reasonably completely test. So yes, edge case importance matters differently in different applications.

> The kernel programmer is even incentivized to do the opposite of the web game guy, which is remove functionality that they do not think they can reasonably completely test.

Why wouldn't a game dev do the same? It's pretty common for initial game releases to lack features.

Web games don't make money because they're expected to work reliably, people play them on impulse. If it breaks 1% of the time, that's hardly a problem at all. If a kernel breaks 1% of the time, nobody would use it ever.

A raytracer demo doesn't need to be engineered to the same standard as the Apollo onboard computer software. A $20 paint app doesn't need to work as reliably as banking software that handles millions of dollars of transfers every day. All software exists on a scale from trivial to critical. It's like saying a toy drone needs to be designed the same way as a F-16.

No that is not a correct read -it might be based on this past few months or so state of the art, while instead that state of the art is moving forward every month- and at the rate these ai coding systems are improving and our harnesses for managing them- bug handling and brownfield codebases are becoming increasingly accessible to AI coding

Ie you are making the mistake of assuming the tech is static when it most assuredly is not

Aside from having incremental new releases, it has stopped moving that fast, in evolutionary jumps, for over a year now.

That is not true for AI coding at all: ie the evidence is the massive difference between Claude code in opus 4.6 vs opus 5.5

That difference is enough to unlock AI coding for so many real life teams

Reply on news.ycombinator.com