Hacker Newsnew | past | comments | ask | show | jobs | submit | bobnamob's commentslogin

> slop that works

Until that slop that works leads to therac-26 or PostOfficeScandal2 electric boogaloo. Neither of those applications required software superior to their competitors, just working software

The average quality of software can only trend down so far before real world problems start manifesting, even outside of businesses with a hard requirement on "software superiority"


Anyone can say that something works. Lots of things look like they work even though they harbor severe and elusive bugs.


It's so bizarre to me seeing these comments as a professional software engineer. Like, you do realize that at least 80% of the code written in large companies like Microsoft, Amazon, etc was slop long before AI was ever invented right?

The stuff you get to see in open source, papers, academia- that's a very small curated 1% of the actual glue code written by an overworked engineer at 1am that holds literally everything together.


Why is it bizarre? I’m a tester with 38 years in the business. I’ve seen pretty much every kind of project and technology.

I was testing at Microsoft on the week that Windows 2000 shipped, showing them that Photoshop can completely freeze Windows (which is bad, and something they needed to know about).

The creed of a tester begins with faith in existence of trouble. This does not mean we believe anything is perfectible— it means we think it is necessary to be vigilant.

AI commits errors in a way and to a degree that should alarm any reasonable engineer. But more to the point: it tends to alienate engineers from their work so that they are less able to behave responsibly. I think testing is more important than ever, because AI is a Gatling gun of risk.



Ah TIL. These are tiny models though but maybe it’s a good sign.


But most of its profit from AWS


The three layers of middlemanagement between engineers and whichever director owns this particular incarnation of RDS


A single cloudflare durable object (sqlite db + serverless compute + cron triggers) would be enough to run this project. DOs have been added to CFs free tier recently - you could probably run a couple hundred (maybe thousands) instances of Stevens without paying a cent, aside from Claude costs ofc


Heh


https://en.wikipedia.org/wiki/Real-time_computing

Hard real time (or just "real time" in firmware/hardware contexts) is effectively a term of art. One that's been increasingly watered down by the rest of the industry.

Strict definitions matter when system failure == pacemaker missing a beat or train signalling system drives a freight train into the back of 400 passengers.


But in gaming, real time means something different: https://en.wikipedia.org/wiki/Timekeeping_in_games#Real-time

Context matters.


In game development we still care about the distinction between soft and hard realtime. Almost all games are soft realtime, even if the gameplay itself is turned based as we're processing user input, updating UI, animating things and so on.


A lot of gameplay elements are firm realtime in practice, not unlike something like video decoding.


Just wait till 'slopper' starts getting classified as a slur


"Slopper" maybe not, but "slophead"...



And now you've pulled in a full sql parser as a dependency (admittedly a dev/build time dependency, but a dependency nonetheless) in a project that has no business parsing sql.

In this day and age of increasingly rampant supply chain attacks & dependency vulnerabilities, I'd definitely be second guessing the approach of "just write a test for it" if that test involved blowing up your attack/vuln surface


I don't really see an attack surface for a dev dependency.


Your development machine, potentially with API keys and access tokens in `$HOME`, is the attack surface


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: