> Suddenly, everything has changed. Computers now work the way I thought they did when I was 8.

I've been feeling this way for months and months. If you're a person who's curious about computers and what they can do you can do for you, we just kind of talk to the computer now and ask it to do the thing. And it does it. I know most of what's happening the whole time yet it still feels like magic. We're pondering orbs all day now.

I've been a professional software person for 15+ years... my assumptions as to what the right decisions are in building software now are racked every day. And more than ever I want the device you're describing: blank slate hardware I build to do what I want how I want it to. Yes, I know that's not for everybody. But I really want to just boot up something from scratch and say, "this is how we should deal with email." Because the way I want to deal with email is the way I want to deal with email, and LLMs will help me get there. Get all this UI chrome out of my face.

Last, I've also mused (heh) about a sort of GitHub for PRDs:

> ...there’ll be thousands of times more applications that pull in 1/7th of the guts of a word processor to solve some idiosyncratic work or home life problem for somebody who doesn’t know what a for-loop is.

I think those guts-as-md-files can be maintained in on publicly available platform for all to use. Sort of a "best practices of the commons." Language-agnostic. Or rather, one language: English. Apps going forward don't necessarily need a datatable plugin — because every datatable plugin eventually has defaults or assumptions that clash with what you need — but it needs the schematics for the types of parts a datatable can have.

It's just such an interesting time to be curious about computers.

Interesting that all the patterns Rails adopted for humans to write better code can't easily be funneled into the LLM doing the job now. Seems like it should be.

Is it types? Are types the answer? Is it rust?

I think the issue with Rails, as a long time developer in that ecosystem, is that much of the default assumptions are a) not common (not so far off-piste that a human can't get used to them, but outside the center of the bell curve), and b) not explicit. So it's very common to do things like install a plugin that has across-the-repo effects but that is only documented in e.g. the config directory and the bundle. Unlike, say, NPM, when you install a new package where you explicitly have to e.g. import it everywhere you want to use it.

As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.

As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.

So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.

Sorry, but what’s “install a plugin” in rails? That’s not a thing; not even a thing someone who’s ever worked on a rails app would say by mistake.

How certain are you about that? https://guides.rubyonrails.org/v2.3/plugins.html

Back in the very early days you would have used script/plugin install (svn url)

Here's one of my mirror repositories migrated from SVN into git. https://github.com/jaggederest/acts_as_voteable

Types are great. No nulls are great. Exhaustive switches are great. Derive macros and Serde are great. Detailed errors are great.

However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.

If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.

Sounds like OCaml has the answer then. It has the equivalent of all the great things you described in Rust, plus compile speeds similar to or better than Go. Agents should be able to blaze through changes with it.

Sounds like I should check in on rust in a year or so.

Yeah. I'm going through an exercise right now with a large codebase where I'm split some of it up into crates so that iterating on specific parts incurs less build overhead. Literally changing my architecture... which annoyed me a bit, but it does make sense.

I like the codegen = power tools analogy to writing software.

I didn't go to school for CS or adjacent: I went to art school 20 years ago for 'new media' which feels like a _silly_ thing to have on a diploma in 2026.

My career started in high school and ran this way: print design w/ computer geekery on the side -> classes in all sorts of digital media production methods -> web design -> web development -> full-stack development w/ a UI/UX focus -> engineering manager ? -> engineering director ??

Then Claude comes crashing in a couple years ago and suddenly code I would grid on to get right got easier and easier to ship. I have enough _experience_ to know not to trust it, put in the appropriate guardrails, and now we can deliver work at a velocity that makes more people happy and keeps my team grounded in a reliable 40hr workweek.

Back to power tools: I'm done going to READMEs and docs and learning the order of operations to build with a hammer and nails. Turns out I didn't really _love coding_. The Job To Be Done was to build the app/feature in a way that satisfies business and user requirements, can be reliably maintained over time, and is securely integrated with existing systems. The tools are now fully-automatic instead of semi-automated with IDEs and linters. Turns out I just like delivering product that solves business objectives (working on turning that into a bigger thing).

I'm still functionally the Responsible Party that gets in trouble if things break down, and its been a couple years of codegen entering our repos and things haven't broken down.

I'm using the lightness of mind the above now provides to find space for the things that strike me creatively, like I did when I was younger and more into art and music. I'd rather spend that creative juice elsewhere, not coding.

So I'm sorry to the coders who love the craft and feel like the industry is slipping from them. Like many industries that have started as craft, code has officially entered its mechanization phase. It requires less finish carpenters who know how to work a coping saw and more general contractors with the latest 18v line of tools.

There's a bigger audience of businesses and consumers that want solutions built quickly, reliably, from a trusted party with experience than there is for tailored code.

I don't mean for this to be discouraging. I really like photos OP took in this piece, and that NoAi camera app looks really great! I'm sorry there's no profitable market for it, but I'm glad it exists! I feel like the skills that created that app belong at an Adobe or an Apple working on creative tools where they can afford to hire someone to work on just single feature or idea.

I wish there was more opportunity for everyone to do work that brings them good brain tingles makes you feel the most human you can be. "Fuck it, make it anyway" is exactly the right attitude rn if you can afford to do it.

I agree with you in theory, but wealth goes hand in hand with relationships. If you can use your skills to make something great with AI in a short amount of time, someone else probably do it too. If they have better connections than you do, they win. Relationships get you farther than raw skill.

This is a problem for sure. I don't care what writes the code, but if I commit it or approve the merge, I need to be able to explain it, full stop. I don't need go line by line, just point and explain this does this does that which leads to that.

If "can you explain this?" is a question a direct report has to put into a prompt, they are failing at their job.

I’m ready for Apple to swipe the basic idea and roll it into the next version of macOS. Gels nicely with the spatial widget work they do on visionOS. Deprecate stage manager while you’re on it.

Maybe but I like the idea of it serving as an agent sandbox or context boundary which is probably too specialized for Apple to build into the OS.

This is like the how it’s made of a website. I could read and click through an endless amount of these kinds of explainers.

This is happening in every creative industry. The creators on the edge of this space in every medium have seen it from both sides.

AI creative is easy to spot _right now_. It will not always be that way.

This but software: https://en.wikipedia.org/wiki/Supergroup_(music)