4 ms·

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 e

by umvi 5mo ago

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.

echelon 5mo ago
Frameworks and ORMs were the pre-agentic AI "iron man suit". I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.
josephcsible 5mo ago
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.
- Kiro 5mo ago
  You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.
  - wizzwizz4 5mo ago
    Relevant reading: https://nesbitt.io/2026/02/16/changelog.html https://nesbitt.io/2026/02/16/changelog.html > Removed: mathjs dependency. 14MB, 200+ functions. Twelve functions used. Added: Custom math utilities module (src/math-utils.js). Addition, subtraction, multiplication, division, a handful of trig functions. Co-authored-by: chatgpt. Changed: Bundle size reduced by 68%. Build time down from 12s to 4s. Module: 47 lines across 1 file. 0 tests. 0 dependencies.
    - olzd 5mo ago
      Are you aware this is satire?
      - wizzwizz4 5mo ago
        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.
- umvi 5mo ago
  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.
xmodem 5mo ago
Rather than have complexity centralised and managed, let's generate the same vulnerable code across millions of apps. Great plan.
- umvi 5mo ago
  "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" [1] https://go-proverbs.github.io/ https://go-proverbs.github.io/
deleted 5mo ago
[deleted]
c-hendricks 5mo ago
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)
tredre3 5mo ago
> 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?
- umvi 5mo ago
  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

by umvi 5mo ago

echelon 5mo ago

Frameworks and ORMs were the pre-agentic AI "iron man suit". I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.

josephcsible 5mo ago

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.

Kiro 5mo ago
You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.
- wizzwizz4 5mo ago
  Relevant reading: https://nesbitt.io/2026/02/16/changelog.html https://nesbitt.io/2026/02/16/changelog.html > Removed: mathjs dependency. 14MB, 200+ functions. Twelve functions used. Added: Custom math utilities module (src/math-utils.js). Addition, subtraction, multiplication, division, a handful of trig functions. Co-authored-by: chatgpt. Changed: Bundle size reduced by 68%. Build time down from 12s to 4s. Module: 47 lines across 1 file. 0 tests. 0 dependencies.
  - olzd 5mo ago
    Are you aware this is satire?
    - wizzwizz4 5mo ago
      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.
umvi 5mo ago
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.

xmodem 5mo ago

Rather than have complexity centralised and managed, let's generate the same vulnerable code across millions of apps. Great plan.

umvi 5mo ago
"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" [1] https://go-proverbs.github.io/ https://go-proverbs.github.io/

deleted 5mo ago

[deleted]

c-hendricks 5mo ago

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)

tredre3 5mo ago

> 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?

umvi 5mo ago
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