spec isn't code. There's a C language specification and many implementations. There are a handful of browsers each implementing HTML, JS, and CSS specs in their own way.
And given a C description of a program, a C runtime can implement that program in various different ways — interpreted vs compiled, explicit memory management vs garbage collection, different pointer sizes and memory layouts, parallelism at various points or not. It's turtles all the way down :) It just becomes ‘code’ at the point where a computer can execute it (in one way or another) without further human intervention.
I moved over back when GitHub was planning to charge per minute to use my own runner. It was easy with Claude, the gh API, and forgejo web API. I even set up daily backups to my S3 clone of choice.
The only repos I left on GitHub are forks and one with a bit of public engagement.
> Most of us, when we want to ship a product, we start at the beginning and with the most obvious ingredient: the product. Because when you can create, the act of creating feels most natural and straightforward. But it makes it so easy to end up with a product that nobody wants to buy. And isn't that every new entrepreneur's worst nightmare? All that work, and nobody cares.
People like this will create a net increase in software jobs. Once his software makes enough money so he doesn't have to sit in front of a computer, he will employ someone. It will initially be a gig fixing slop. https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-co...
People in the trades have a ruthless pragmatism that SV has forgotten.
about a year ago I shared this on /r/AskProgramming:
"...a Pull Request is a delivery. It's like UPS standing at your door with a package. You think, "Nice, the feature, bugfix, etc has arrived! And because it's a delivery, it's also an inspection. A Code Review. Like a freight delivery with a manifest and signoff. So you have to be able to conduct the inspection: to understand what you're receiving and evaluate if it's acceptable as-is. Like signing for a package, once you approve, the code is yours and your team's to keep."
The metaphor has limits. IRL I sign immediately and resolve issues post-hoc with customer service. The UPS guy is not going to stand on my porch while I check if there's actually a bootable MacBook in the box. The vast majority of the time, there's no issue. If that were the same with code, teams could adopt a similar "trust now and defer verification" approach.
The article has a section on Modularity but never defines it. I wrote a post a few weeks ago on modularity and LLMs which does provide a definition. [1].
reply