Water is handled at the city level, not the federal level. If you have incompetent local leadership, this can happen. Incompetent local leaders can (and have!) bankrupted their cities.
Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps?
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
"A little copying is better than a little dependency." - Go Proverbs [1]
Most complexity is unnecessary. Adding dependencies to your project exponentially increases your project's surface area, which in turn increases its regulatory/cybersecurity burden, especially if your software is a medical device, munition, etc. Why is Echo/Gin/Gorilla/etc better/more secure than vanilla Go's mux? Just anecdotal, but we use the Echo web framework for Go and it's caused nothing but headaches. It does magical XML parsing by default even though we don't deal with XML which gets us flagged in pen tests. Updating from v4 to v5 broke production for us because they made an undocumented server config change that makes all requests have a 30 second timeout. Meanwhile vanilla go has the ability to register routes and middlewares, so what value is Echo bringing to the table? Ditto for lots of other unnecessary dependencies. A lot of times we just need one little thing out of the whole package, and in those cases a little copying (or a little AI generation) is better than a little dependency.
A static go binary with minimal dependencies running in a busybox container has a tiny CVE footprint when run through grype/snyk, etc. Do the same for a NodeJS app with zillions of dependencies running in an ubuntu container and you'll spend all day triaging CVEs.
I'm not saying "roll your own crypto" but I am saying "axios-like packages don't make sense to use any more in a world where AI+vanilla accomplishes the same thing"
Wouldn't that be worse? With dependencies, it's at least possible that someone else has audited the code, but with a vibe-coded from scratch app, it's definitely totally unreviewed.
I never said AI code should be "unreviewed". I'm saying that instead of pulling in axios or requests (as a contrived example) to make HTTP requests, just use AI to generate some vanilla JS/Python that has the exact subset of functionality you need. Your code has fewer dependencies, CVE surface area, etc, wins all around.
Yes, it says so right under the title. But it's not wholly fictional: this happens all the time, to the point we have a name for it (Not Invented Here syndrome).
That it took so long before they started trying to phase out their home-rolled library for the "hard cases" is somewhat unrealistic, although possible in a sufficiently-dysfunctional organisation. Some of the details about the problems of their homespun library are clearly anecdotes translated from other settings, and are unrealistic in the context of a mathematics / finance library. (They only noticed that interest calculations were wrong when a customer complained? Seriously?) The development of 6.1.0 (via 6.0.0) taking only two weeks isn't congruent with the rest of the story, although it may be realistic for AI-driven development (with which I am unaccustomed).
But otherwise, this is one of the more realistic satire pieces I've read.
> There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
Go binaries are immensely satisfying, but I don't follow your logic here. The vast vast majority of dependencies in Go do not depend on the outside world, so the binary would remain self-contained whether it has 1 or 100 dependencies, no?
Assuming you disable CGO, yes, the binary is always self-contained. However, I want to clarify a few things.
The "self contained" part is only important in that it lets you use busybox or "from scratch" as your container runtime environment which has a very tiny cybersecurity surface area compared to, say, ubuntu or even alpine which has a bunch of system libraries your go binary isn't using, but which could still get flagged for having vulnerabilities.
Minimizing dependencies of the go binary is a separate, but equally important task that reduces the cybersecurity surface area of your go binary itself to just "the go standard library" instead of "go stdlib + a dozen github packages"
Whenever I am working with a NodeJS project I pity the fool who has to do SCA because the CVE surface area is enormous compared to go, which has a fairly batteries-included stdlib
That must be why so many vibe-coded UIs have awful UX (terrible contrast, too small fonts, everything gets its own colors, no attempts at standardized behaviour)
That's like 90 minutes of exercise a day if you take zero rest days... Not happening for most people. I think even marathon training requires less than 90 minutes a day on average.
I skimmed the study rather than the article about it and I don't see them define it at all. They just had a machine learning model take accelerometer data and classified it into "sleep, sedentary behaviour, light physical activity and MVPA". Whether any form of walking counts as light or moderate in this classification is really anyone's guess
The easiest thing for people to do if they aren't confident about their level of stress (moderate vs vigorous vs maximal) is to wear a smart watch with a HR monitor. They aren't perfect (chest straps better yada yada) but you can see your HR zones and if you are in Z1 you are moderate, Z2/3 vigorous.
The language isn't that precise because a trained marathoner is doing 7 minute miles for two hours at 50% of the populations resting heart rate.
I've got multiple wearables and they all seem to agree that normal walking does nothing for me. Barely increases my heart rate, not even Z1. Nor does "doing chores" which seems even more nebulous. But that's just a data point of one.
Right. It is a weakness and makes the meta analyses super important. I can't see all but trained athletes doing even low zone cardio for that much time. But I can see an active person walking, moving around, 12K steps, with a couple hours of genuine workouts / wk hitting that threshold. That matches with how I understand the rest of the studies on this better as well.
Often, especially on competitive games, the server is basically a full client, but just without graphics. The server will often run physics simulations etc, so that it can validate that nobody is cheating.
Sure, in some cases you can roll your own server, but often it's impossible.
Honestly, depending on the repo, I would pay a reasonable fee to get issues or PRs I open seen. No different than paying a fee to add a new game to Steam - raises the barrier to entry and prevents a lot of garbage from entering the fray.
> Don't they inject malware/adware into your build artifacts?
Aw, c'mon! The did this for about 4 months which ended in 2015! Prior to that they had Windows installers which did the same, but that also only lasted a few months.
It's now 2026. Exactly what software did you host on sourceforge from 2011 to 2015? Because I hosted my GPL stuff there, and I moved away because I was affected, and yet I am not concerned that they will do that again.
We recently switched from Node.js + Mathjax for rendering latex to Goja (https://github.com/dop251/goja) + Mathjax, and surprisingly it worked really well. We did this because the app is already 99% golang, and this allows us to eliminate the remaining non-go pieces, greatly simplifying the SBOM. And yes, we tried go-latex, but it's not nearly as feature complete as Mathjax. Not to mention using goja + Mathjax adds 10MB to binary size while Node.js adds 200MB+
Ultimately code is an iterative refining process, like sculpting granite or spinning pottery. You start rough and iteratively shape and polish it. LLMs just rapidly speedup the iterative process. The next generation will be using LLMs to quickly setup the rough shape of new software and then iteratively refine them.
The "smarter/better" attributes you are worried about LLMs not having happen between iterative steps, when the human is inspecting the current state of the software and compares it to the desired state of the software (in their mind's eye). The human then course corrects for the next iteration.
This would be like if Michelangelo carved the David using a robotic 6-axis chisel. It takes him 1 month instead of 3 years because he can convey his initial vision to the robot and then iteratively refine the granite until it matches his vision.
You can try to claim LLMs don't invent new things, but humans using LLMs absolutely invent new things (source: myself).
OP said "The next generation of developers will, for better or worse, grow up using AI assistance to write their code, but none of them will ever become a Zig contributor."
You rebutted with (paraphrasing) "no, you can't build compilers with LLMs because LLMs don't invent new things"
I used a lot of words to demonstrate that you can invent new things with LLMs, including compilers, as long as it's a human + LLM iterative loop and not an unsupervised LLM running in a vacuum.
To me it sounds like you did all the actual hard work of the inventing. If an LLM brainstormed some ideas and you validated which ones worked and implemented the idea and fully grokked the code then the zig developers probably wouldn't ever know that an LLM was involved and you'd be fine to contribute.
Food companies try every trick to make carb counting difficult. Companies will tout "zero sugar" in the label even though the first ingredient is maltodextrin or maltitol or some other thing that quickly turns into sugar the moment you ingest it. The only way to get good at it is to wear a CGM and then see how your body reacts to things and then keep a mental list after that. A company may claim some product only has 2 net carbs, but I've found those claims to be false a lot of the time, with bigger companies being the biggest offenders.
That’s fair, NixOS avoids the direct stuff from Docker itself but if you’re basing on an Alpine image or something that would probably be more minimal / smaller
reply