HN user
https://www.slater.dev/
Since 2002 Richard Stallman has spoken again using term "content" this way.
using the word as a noun to describe works and communications through which people have expressed themselves adopts an attitude you might rather avoid: it treats them as a commodity whose purpose is to fill a box and make money. In effect, it disparages all the works by subordinating them to the box that is full.
This is the right thing to do
That's an interesting argument. In construction, the larger a project, the more justifiable it is to invest in quality. Is it different than software? I think a better argument against licensure is that it makes small projects too expensive, but I disagree. It shifts not the overall cost, but when cost is paid: "The upfront cost will increase, but a long tail of costs stemming from quality issues will decrease."
I worked for 10 years in medical devices. QMS was business as usual. I think large software projects with millions budgeted should have them. But the difference between a QMS and licensure is a person's signature and their personal commitment to a statement of ethics as well as their accountability and ability to appeal to a professional organization.
I'm glad you mentioned downward market pressure on quality. I agree that is an issue. That's why I advocate for licensure of software engineering professionals, which exerts a counteracting force back up.
https://www.slater.dev/2025/09/its-time-to-license-software-...
It's kind of like the saying "the right note played at the wrong time is wrong." An implementation that works today but could break in the future is wrong. I'm not willing to treat an LLM as an oracle that knows the difference. It certainly hasn't earned that trust.
from the post:
It was reasonable to be skeptical the first time
It's still reasonable to be skeptical. A few weeks ago a post was discussed here on HN [1] that asked:
What would have to be true for us to ‘check English into the repository’ instead of code?
to which I replied:
Code is already the cheapest path to working, correct software. LLMs do not change the calculus because figuring out what to make is the expensive part, not coding it up. Skipping code makes the specification of what to make even more expensive and throws away the tools that keep precision affordable. Programming in English would be more expensive than just using a programming language. [2]
[1] https://annievella.com/posts/finding-comfort-in-the-uncertai...
[2] https://www.slater.dev/2026/05/why-english-will-never-be-a-p...
"when you're looking for things, you find them" - my physician explaining excessive reliance on diagnostic imaging
The job when picking up a codebase made by human or machine always involves reverse-engineering the design intent from code. That's especially hard for LLM-generated code because the path to runtime was so rushed.
It's more expensive to fix code at runtime than at compile time and at compile time than at design time. Unfortunately, AI rushes people to runtime as fast as possible.
https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-co...
Sorry about the infelicitious timbre. Nope, I'm just a happy customer.
I'm Doug, quoted above. I took Jimmy's excellent course, and when I learned about Command Center, I subbed immediately. I wasn't disappointed. It's a bit like turning your LLM into a graduate of that course.
every time I use Gleam I feel happy
The tanker deal is not just a competition won; it is a decision that shifts the balanc
I didn't just stop reading at this line, I slammed the back button like releasing an emergency exit door.
If the question is not worth asking, why did Thoughtworks ask it?
Thanks for reading. The question the article addresses is, "What would have to be true to check in English to the repo' and the answer is grounded in how business works: it seeks to minimize costs. Maintenance of code rather than very detailed English happens to be cheaper.
Contrarian view: Why English will never be a programming language. https://www.slater.dev/2026/05/why-english-will-never-be-a-p...
For a deep dive on UB with printf, see https://srs.fyi/see-conversions/
When programming in C, to avoid unexpected pitfalls, one must be acutely aware of a whole slew of implicit behaviors (some of which are implementation-defined or even undefined).
Chrome is recommended
Who recommends Chrome? I don't.
Obligatory in any discussion of money fraud: https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra...
I will move the handful of my projects that use Bun to something else. I don't trust governance that permits this kind of reckless change.
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.
One thing is clear: an LLM wrote this.
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.
the corollary of Chesterton's Fence is also valuable: don't go putting up unnecessary fences, because others won't be able to take them down
Mentioned in the footnotes, CuriousMarc has 3 videos on this device. https://youtu.be/aPIZwqq_W_k?si=wAkRagRx-B06TXwY
Email is the most accessible interface in the world
Email is one of the most gatekept interfaces in the world.
There's been a course for that since before 2015: https://30x500.com/academy/
I am currently taking it.
From the landing page:
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.
"The bearing of a child takes nine months, no matter how many women are assigned." -- Fred Brooks on project management
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].
[1] https://www.slater.dev/2026/02/relieve-your-context-anxiety-...
Next up: DOGE cancels leap seconds. /s