Hacker News: swee69

New comment by swee69 in "Evaluating GPT5's reasoning ability using the Only Connect game show"

swee69 — Wed, 13 Aug 2025 14:17:02 +0000

So basically - LLM usefulness has plateau’d hard - Sam A knows this and will pivot to capturing revenue now that the high growth phase is over - more restrictive rate limits, higher bills

They U-turned on the recent rate limit changes after the release backlash but more is coming

New comment by swee69 in "There are no new ideas in AI, only new datasets"

swee69 — Tue, 01 Jul 2025 18:55:08 +0000

prizes != breakthroughs

New comment by swee69 in "Intentionally Making Close Friends (2021)"

swee69 — Sat, 12 Apr 2025 16:37:16 +0000

I think you could estimate the risk in micromorts from taking LSD from darkweb and find it’s not that different from other activities you do regularly (~multiple times a year, if not more)

New comment by swee69 in "Are people bad at their jobs or are the jobs just bad?"

swee69 — Thu, 03 Apr 2025 17:34:09 +0000

Gig economy employment model works great for Amazon’s end product - the other companies have just executed poorly

New comment by swee69 in "You should write "without bugs""

swee69 — Fri, 24 Jan 2025 13:02:00 +0000

> As an engineer, you should always be writing code with a absolutely minimal defect rate and well-understood capabilities.

I think the problem with the purists is that this is just a moral claim - it's not based on how businesses + marketplaces actually work. The lower you attempt to crank the defect rate (emphasis on the word "attempt"), the slower you will iterate. If you iterate too slow, you will be out-competed. End of discussion. This is as true in open-source as it is in enterprise SaaS. And in any case, you're just begging the question: how do we determine the "absolutely minimal" rate in advance?

> you can strive to write adaptable code that can accomodate those iterations.

This is a damaging myth that has wasted countless hours that could have otherwise been spent on fixing real, CURRENT problems - there is no such thing as writing "adaptable" code that can magically support future requirements BEFORE those requirements are known. If you were that good at predicting the future you would be a trader, not an engineer.