I built my site from scratch in WebAssembly. Using AI coding you can vibe wasm from fast C or Zig. I generated a Markdown renderer in Zig from the CommonMark spec. No Vite or React or frameworks, just me and my agent.

Getting excited by coding agents because they’ll let you write way more code is a bit like flooding a lake and getting excited because you’ll be bit by way more mosquitoes.

A 2009 PHP app on bare metal serves 12,000 requests/min on 384MB RAM. Meanwhile, our modern React/Node.js rewrite needs 4GB just to start. 15 years of "progress" and we're using 10x more memory for the same functionality. What happened to efficiency?

I went to my local ATM machine and entered my PIN number looking at GUI interface on the bright LCD display and wondered if the underlying API interface used the HTTP protocol.

I think the idea of junior engineers has been flawed for a while now. Twenty years ago if you said you could write code that made a computer dance then you were a programmer. And then you developed the skills of boundaries, how to break problems down, how to think about security, patterns worth repeating etc from writing and reading code and seeing what worked. We decided in the age of bootcamps (I used to teach one) to call people “juniors” and hold their hand and spoonfeed them small bite sized pieces. It created this false divide of you either are a senior or you aren’t. I think it held people back by only giving them pre-digested work without much fiber and making them believe the seniors had everything figured out that there was to know about programming. I worry if both "juniors" and "seniors" change their work to reviewing the output of coding agents then the skills of both are going to diminish. The people that review history books in magazines are often other history book writers. They know the pain and the traps and what novel ideas and framing the author brings. They aren’t professional history book reviewers who only review the work of others.

Expecting that your job can become monitoring an AI and just reviewing its output is a bit like expecting you can appreciate what your boss writes and think you could do their job?

Hyrum’s AI: With a sufficient amount of inspection of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be probed and discovered by an AI.

This is wild: edit and run Swift code in the browser. MiniSwift supports SwiftUI and even Metal shaders. Did I mention the browser-based IDE? miniswift.run

Anthony Bourdain wrote about this. This was his pitch for Parts Unknown. Trust me, read the whole thing.

Ben Affleck says his entire movie crew gets a bonus if the film succeeds "it's not like we're saints or philanthropists... it's completely self serving" "in order to do the job well, everybody who's working on it has to be really invested and give a shit about the result" "if this thing actually blows up and does really well, you should benefit from that" "everyone got their rates, everyone got their hourly, no one cut anything" "this is just an exercise in actually proving that it's not bullshit, that if there's success, you'll get some extra little success"

The difference in production costs between a dozen cage-free eggs and a dozen normal eggs is 19 cents. But the cage-free eggs can cost nearly $2 more. Big supermarkets use cage-free as a price discrimination tool - targeting them to richer customers who are willing to pay more. Poorer customers, even if they care a lot about animal welfare, end up buying the normal eggs. But when states pass laws banning caged eggs, the markup disappears.

Prefer reference implementations to Markdown specs I have an API implemented in Go, JavaScript, and Swift. I renamed a bunch of things and the JavaScript version was the easiest for a coding agent to modify since it’s the smallest. I then asked for the Swift version to be also updated, and so I pasted the JavaScript source and told it to match the naming there. Code is a much more natural way to express. A reference implementation is closer to real than a theoretical spec. A spec with close attention to edge cases and careful consideration of nuances remains powerful, but most Markdown specs made to feed to AI aren’t this. A reference implementation can be easily studied and proven to work. Code remains a valuable communication tool.

we live in age of great moral panics about things that don’t matter and zero moral outrage over some of the most egregious societal sins we’ve ever seen

With agentic coding it’s more important than ever that APIs feel obvious. Names should be recognizable — whatever an LLM would first pick. How things compose together should be self-evident without external knowledge. Names should click and those things should click together.

What I really started worrying about today is a near future in which all access to information is intermediated by AIs, able to infer intent and political coding of all user activity, like a librarian reading over your shoulder and denying your access on a page-by-page basis.

Being part of a generation that was told “Wikipedia is not a source” makes it genuinely baffling to me that jobs are now telling people to just use ChatGPT for everything.

My biggest AI wish from WWDC is to rid of token limits. In the same way a MacBook means you often don’t worry about battery-life, it should mean you don’t worry about token-life. Don’t mind if it’s via the cloud or on-device models it should be unlimited.

How could this be perceived as anything but a massive failure in today’s world? Would Stripe even be investable today? Which investors would ever think that only launching after two years of work and with 50 users would ever be the beginning of something gigantic? I can’t see how anybody would be happy with this today. And yet, almost imperceptibly, Patrick and John were painstakingly laying the foundation for something that was built to last and built to grow strong and immovable like a Sequoia. How can mushroom growth rates produce anything other than mushroom longevity? I’m not saying that real value CAN’T be built quickly. But I think it’s far more common than we like to talk about that founders work for two, three, four, seven, even fifteen years before something extremely valuable is born into the world and really takes off. James Dyson worked on the design of his vacuum cleaner for 5 years before he got to a working prototype and 8 years before it became a commercial product. Dylan Field worked on Figma for four years before launching a *closed* beta. Tim Leatherman worked on his idea and prototype for 8 years before he had his first multitool design that was ready to sell. Palmer Luckey spent about 7 years from the time he began working on VR prototypes before Oculus released the first consumer headset. Jensen Huang started Nvidia in 1993 and it wasn’t until 4 years later in 1997 that they had their first major commercial success with the RIVA 128. Steve Wozniak was the fastest and went from an idea for a personal computer in 1975 to the Apple II release 2 years later in 1977. Time and again the reality is that great things take time to build. I’m not saying it doesn’t take hard work. I’m definitely not saying it doesn’t take determination and extreme focus. But it does take time. I think we try and pretend that it doesn’t take time and lift up the seeming exceptions to the rule. Why not be honest and instead focus on the determination and extreme grit that it takes to keep building for years before any outward success arises or glory is received? I hope we can be honest with young founders and repeat these stories again and again so that they learn to work thanklessly for years before the outward vindication comes, because that’s what it really takes.

70k words, 600 illustrations, and 1000s of hours (so far). Making Software is now available in early access. makingsoftware.com/early-acc…