Even if you’re totally not technical, you probably know that software is made of code. You don’t generally have to touch it, or even see it these days, since a coding agent can handle all of that for you. (I’m a professional software engineer, and I’ve got personal apps I use every day where I’ve never once looked at the code.)

But for some people, the fact that it’s code on the inside makes them ... uneasy. They feel like they should be able to read and write code, and that not being able to do that is some kind of deficiency or blocker to making software.

Well, I’m here to tell you that it’s not. There’s nothing wrong with you; code is just weird.

Code is exacting. It’s cryptic, even abrasive; it rejects casual inspection. It’s almost like regular English, sometimes—there are words you recognize—but they’re arranged in a seemingly random order, and littered with mysterious bits.

Like, here’s a little bit of Python code that you might find on, say, a pet adoption website:

for dog in shelter.avail:
    if dog.is_friendly:
        print(f"This is {dog.name}! They like {dog.likes}.")

This is really simple code (by code standards); it just loops through all the available, friendly dogs at the shelter and prints out a little message about them.

But what the hell? for dog in shelter.avail sounds like robot-speak. It’s certainly not how a human would say it. There are also uncommon symbols, like curly braces, and the lines are indented strangely. And what’s with that little “f” before “This is ...”?

And as code goes, Python code tends to be pretty readable; you can kind of get the gist of that block, even if you aren’t technical at all. Unfortunately, most code looks more like this bit of JavaScript:

const val = obj?.data?.items?.[0]?.name ?? fallback?.name ?? 'Unknown';

Or worse, like this glob of Perl:

$_ = $o->{d}{i}[0]{n} // $f->{n} // 'Unknown'; s/^\s+|\s+$//g; $v = $_ || undef;

(Those two blocks of code do roughly the same thing, by the way. 😩)

Even as a professional software engineer, when I look at these examples, my eyes just glaze over. It’s a disaster.

Why does this suck so much? Is it hard on purpose, like canceling your Amazon account? Is it a bizarre initiation rite to keep non-programmers out of the club?

No—at least, not mostly. It’s just kind of an unhappy side effect of how code works (and it’s something you can now easily get past, as we’ll see in a minute).

Code Is Instructions

In part, code is like this because it isn’t natural language; it’s a set of precise instructions telling the computer what to actually do, which electrons to put where.

Thus, it’s much more dense and strict than regular language. Every symbol, space, or word has a specific meaning, with no ambiguity or room for interpretation, and nothing extra. You can’t use the English phrase “for every available dog in the shelter” in code, because “for every” and “in the” are meaningless in Python; it has to conform to a specific set of rules to even run at all.

Computer chips don’t tolerate ambiguity; they require exact precision. And they execute code sequentially, one line at a time. If you forget a step, the chip won’t just “figure it out”; it’s just a machine.

We’re not used to this, because it’s not at all how we speak. Regular language is fluffy! It’s like those styrofoam packing peanuts—you can throw in a little more or less to couch your meaning, give it a different vibe. You can be playful or meandering or prissy, you can gesture vaguely at something, you can make it rhyme.

But not code. It’s all business.

Code Is Terse

Historically, programming languages have had to strike a balance where they are both precise (there’s no ambiguity) and concise (they don’t take too long to type, and they don’t waste space in the computer’s memory).

The latter concern—not using too much memory—is just a relic from decades ago, when computers were slow and limited, so you really had to be economical. We don’t have to worry about that anymore; the first version of the Linux operating system was smaller than the “Pizza Rat” video.

But the notion that languages should be concise is still baked pretty deeply into programming culture and language design. Once you get the hang of it, concise code tends to be easier to work with than verbose code, because it’s just less to parse.

Over the years, there have been languages that have tried to be more verbose and “English-like”, but that always ends up being worse. For example, COBOL (from the 1960s) was supposed to be a computer language that “regular business people” could use; here’s what that kind of language looks like:

IDENTIFICATION DIVISION.
PROGRAM-ID. RETRIEVE-DISPLAY-NAME.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 CUSTOMER-NAME       PIC X(50) VALUE SPACES.
01 FINAL-DISPLAY-NAME  PIC X(50).

PROCEDURE DIVISION.
    IF CUSTOMER-NAME NOT EQUAL TO SPACES
        MOVE CUSTOMER-NAME TO FINAL-DISPLAY-NAME
    ELSE
        MOVE "Unknown" TO FINAL-DISPLAY-NAME
    END-IF.
    DISPLAY FINAL-DISPLAY-NAME.
    STOP RUN.

Does that look “regular business friendly” to you? Being verbose doesn’t really make it better—just longer. Long code takes more time for programmers to type and read. So programmers (who type all day long) love to abbreviate things.

That might sound ok, until you run across some monstrosity like:

skt.ttl = MAX_TTL_MS

As a programmer, when I see that, I instantly know that “MAX_TTL_MS” means “maximum time-to-live in milliseconds”, but how on earth would you know that?

There are also operators, which are often weird combinations of symbols. For example, the operators in C++ include:

• Arithmetic: + - * / % ++ --

• Assignment: = += -= *= /= %= &= |= ^= <<= >>=

• Bitwise: & | ^ ~ << >>

• Pointer/Member: * & -> . ->* .*

And that’s not even half of them. What the heck are these? Does ++ mean “add it twice”? (Nope! It means “add one”.)

This makes code look and feel even more like reading math equations than it does like reading prose; it’s quite difficult to visually parse. (Plus, even these symbols are different in each language!)

The net result of all this is that as an outsider, programming code is cryptic; it might as well be an actual secret code.

Code Is Arbitrary

Now, this might surprise you, but in a way, code is also a lot less strict than natural language. When we speak to each other in English, we are forced to use real words—like, words that are in the dictionary, with specific meanings. We don’t get to just decide what each word means, or make up new words on the spot, because no one would understand what we’re trying to say.

But in code, you can (and must!) do exactly the opposite, all the time. Nearly every word you see in code is a word that some programmer has defined. And those words have a specific meaning in this context because they were explicitly defined to have that meaning.

For example, here’s that first code snippet again:

for dog in shelter.avail:
    if dog.is_friendly:
        print(f"This is {dog.name}! They like {dog.likes}.")

The words “dog” and “shelter” in that code aren’t the real words “dog” and “shelter” that you use in everyday speech. They are symbols with structure and meaning defined in the program. You could equivalently have picked different symbols:

for d in myShelter.available_dogs:
    if d.easy_to_work_with:
        print(f"This is {d.name}! They like {d.likes}.")

The words are almost entirely different (”d” instead of “dog”, “myShelter” instead of “shelter”). But the functionality is identical. The symbols are completely arbitrary! They can be anything you want, as long as they’re consistent in context.

This takes some getting used to, precisely because you’ve spent your whole life using real words with shared meanings. That’s not what these are at all. You have to put on a special mental lens to be able to “read” something where every word was just made up by someone!

In fact, only a small handful of words have fixed meanings in code; these are called keywords, and there are hardly any of them. For example, here are all of the reserved keywords in Python:

and as assert async await break class continue def del elif else except False finally for from global if import in is lambda None nonlocal not or pass raise return True try while with yield

That’s right—just 35 words! JavaScript has a whopping 38:

await break case catch class const continue debugger default delete do else enum export extends false finally for function if import in instanceof new null return super switch this throw true try typeof var void while with yield

Compared to the full vocabulary of different words you’ll see in code, these lists are tiny.

That means that literally everything else you see in a program (besides symbols, like + and *) is just some word a programmer came up with. And those made-up words aren’t universal—the same word will mean something totally different in another program (or maybe even in a different part of the same program!).

And each symbol has to be a single series of characters without spaces, because spaces mean that what follows is a different symbol. So that code didn’t ask if the dog “is friendly” (with a space), it asked if the dog “is_friendly” (with an underscore); “is_friendly” is a single value (true or false). Programmers (who are always in a hurry) will therefore often opt for really short symbols for things (like “f” instead of “friendly”).

Programmers aren’t trying to make code hard to read. They want to be able to read it, with their regular English-reading eyes, and they want other people to be able to read it too. They just fail at that most of the time, for all these reasons.

The Good News: You Can Un-Weird It

Once in a while, you might find yourself wishing you could just read the code like a programmer—maybe something feels fishy, or maybe you’re curious to see if it really does what you want. How do you know it’s not doing something completely boneheaded?

To whatever degree you actually want or need to do that, there’s a much more effective way now than reading the code yourself: just ask the coding agent to translate it.

Hey buddy. Could you take this code for showing the list of available dogs and translate it into regular language for me, line by line? Explain it like I'm five.

It’ll patiently explain exactly what the code is doing:

Sure! This code starts by going through all the available dogs in the shelter, one by one:

for dog in shelter.avail:

For each one, it checks whether the dog is listed as friendly:

    if dog.is_friendly:

If it is, it prints out a message with the dog’s name and what it likes:

        print(f"This is {dog.name}! They like {dog.likes}.")

You can ask it to zoom out (”what happens on the whole page here, in a little bit less detail”), or dig deeper into something you still don’t understand (”Where does it get the things that the dog likes? How many can there be?”). It’s wild, but that’s where we are—you’ve got an infinitely patient helper who can read code as easily as you can read nursery rhymes.

You may not find many occasions to engage like this (since most of the time, just using the software is sufficient to see if it does what you want). But don’t let “I can’t read code” be an excuse; if you ever do need to dig in at that level, the door is open to you.

Watching the latest Andy Weir adaptation, Project Hail Mary, I was struck by something profoundly hopeful and empowering.

A standard mechanic in hero movies is that no matter what the actual expertise or background of the hero, they can obviously tackle complex science or engineering problems in totally unrelated domains. In Independence Day, for example, David Levinson, who is fully a satellite technician for a cable company, manages to whip up a computer virus that runs natively on alien hardware. The Tony Starks and Jack Ryans on the screen never have the slightest trouble expertly one-shotting solutions in areas they have no business knowing anything about (and always under time pressure).

And we forgive this in the movies because ... well, they’re movies. It’s a macguffin, don’t think about it too hard.

In Hail Mary, Ryan Gosling’s character (Grace) follows suit. He’s a junior high school teacher, exiled from the world of biology research, who finds himself alone in space. And after initially freaking out and rejecting the mantle of hero, he comes to embrace it over the course of the movie, and we’re rooting for him.

We’re rooting for him so hard, in fact, that we barely notice when he does things that a former academic biologist (even a very clever, handsome one) would never, ever be able to do. Like:

• Creating a linguistic translation model for a non-human species from scratch

• Reprogramming flight software for probes in a way that will send them many light years away with inconceivably precious biological cargo

• Manufacturing tools and parts out of xenonite, a material invented by someone else’s civilization.

Even if you grant that he came equipped with some cool near-future technologies, and that Rocky did a lot of heavy lifting, it still doesn’t add up. Any one of those things that Grace did on his own would take teams of the most expert humans working for months on the engineering problem to even have a hope of coming close. It’s just not believable.

Unless! Unless one of the technologies he brought with him from Earth was a future version of something like an AI Coding Agent: an engineering sidekick who understands what you’re trying to do and can fill in all the details to implement what you’re asking for—writing code, creating prototypes and materials with robotic appendages, and working out all the test cases and alternatives, with your feedback to keep it moving in the right direction.

Imagine the prompt:

OK, I need to create a sophisticated model to start to understand Rocky’s language. Let’s build some realtime translation software for it. Make me a harness that records what he’s saying and I’ll give indications of what I think he means. Draw on humanity’s best linguistics research and maintain a suite of statistically possible translation paths, getting better over time.

Or:

Hey, we need to send these Beetle probes home to Earth on their own. Build some simulations of what might happen and what onboard software and hardware changes are needed for them to make the journey in the most resilient-yet-fast way possible.

We don’t see him doing this, outright. The computer doesn’t even have a fun name like “Claude” or “Siri”. But you can imagine that this is what he’s actually doing—in fact, that in this future, this is just something everyone does, and it’s common knowledge. Not a fancy hyped up “AI”; it’s just how building stuff works. Your intent stays in the foreground, you engage with ideas and intents ... and machine intelligence fills in the details, checks the math, etc.

This is the part I find empowering and hopeful. When some people think about the role of AI in our lives, it’s in the frame of “replacement”, dulling our mental faculties and making us dumb. But this vision is a radically different one: the idea that capabilities like this might be an integral, quiet part of our lives, allowing us to do MUCH bigger things with machine intelligence as a tool. Science and engineering only get more complicated over time; to live on the cutting edge, where no single human can master everything at an expert level, we have the opportunity to adjust our altitude and wield machine intelligence as a tool in the background.

In the early days of generative AI—which was last year, by the way—you couldn’t turn a corner without encountering a story about some boneheaded action taken by an AI, on behalf of some bewildered (and / or negligent) company. Giving away plane tickets or cars, making up words doctors didn’t say, suggesting the sale of pre-nibbled cheese. These are potent cautionary tales; saving a little money on your call center won’t do you much good if you turn around and recommend chlorine gas as a refreshing mocktail.

The natural reaction is that this is a “bug” that needs fixing. Can’t we just teach these models to tell the difference between truth and lies?

This is the wrong framing. I mean, it’s not wrong to want to make them more truthful, but you won’t succeed in any real way, because their nondeterminism isn’t a bug; it’s so inherent to the technology, it’s practically a feature. LLMs are outlandishly complex artifacts, and there’s no future world where you just “iron out the kinks”. They are guessing machines, and if you put them into situations where they can’t guess correctly, they will still guess.

Reports like this have become more rare in 2026—not because models no longer make mistakes, but because companies got wiser and put in guardrails (though, at least as of this writing, you can still use the Chipotle bot for free AI inference tokens).

OK, fine—if that’s not the right framing, then what is?

A Tale Of Two Softwares

Consider: there are now two fundamentally different kinds of calculation, and they work by radically different rules.

Traditional software performs calculation like a gear: deterministic, with teeth that always mesh in the exact same way. It’s so precise, in fact, that we can build towering stacks of software (like, say, the Linux operating system, or the internet) that actually (largely) work.1 ¹

The other kind—generative AI—is not a gear. It is a ghost: a force that’s powerful, responsive, and reminiscent of human form, while still being obviously (and eerily) non-human. The words inside an LLM probably emerged from a living human’s mind once2, and the technology of generative AI has given us the ability to summon them back from the void, as conversation partners and problem-solvers.

This sounds ridiculous, but LLMs are ridiculous. An AI foundation model is a sprawling, cavernous universe. It’s not huge in absolute physical terms—the whole thing would fit on a $100 hard drive from Best Buy—but inside, there’s a compressed, blurry representation of a vast slice of shared human knowledge. When you converse with it, you’re forging a single path through its infinite, labyrinthine web of concepts and impressions. The results are ghostly whispers, emerging from a process that’s not consciously experienced by a living being, but preserves the shape and the meaning of thought.

And which—by the way—is incredibly effective at a wide range of cognitive tasks (when used correctly). LLMs can write code, summarize information, plan and debate and digest; and they are outlandishly fast compared to humans. They’re rapidly reformatting whole fields of human endeavor.

The true gears are still there, of course, in the background, doing gear stuff—trillions of lines of code, running continuously and flawlessly, embedded in every process, tool, and device on earth. The gears go on gearing, unaware that ghosts have arrived at the party and are vying for a share of the computational pie.

Gears Are Terrible Ghosts

For as precise and faithful as gears are, they’re also crap at doing many important things because they are narrow and rigid. Their exacting logic makes them unsuitable for the fuzzy, nebulous work our brains do all day long. That shape in the distance—is that a bear? That email subject line—is that going to upset my boss?

Even tasks that seem straightforward—”hey, could you merge these two customer spreadsheets?”—are a pain in the ass to do with gears. If you try to solve problems like this with traditional code, you end up in a series of increasingly desperate heuristics and brittle special cases without end.

But an AI just knows how to do this stuff. It knows that names and titles aren’t just strings of characters, they’re meaningful and richly patterned. It knows Bob and Robert are the same name. It even knows that Margaret and Peg are the same name. It deals in probabilities as a native language, not a special case.

Before AI, people tried SO HARD to make gears do ghost things. The Cyc project spent decades manually encoding common sense so that programs could use it. Machine translation limped along as a bunch of massive lookup tables with rules bolted on, capable of translating “Where is the bathroom?”, but giving you word salad if you asked for a joke or a poem. Try writing code that can read a document and give you a summary; there’s no algorithm for “what matters” or “how similar is this thought to that one”. Gears can count words; they can find keywords, extract sentences, store data.

But working at the concept level? Understanding what something is about? That’s a ghost thing.

Ghosts Aren’t Very Good Gears, Either

The same disparity goes in the other direction, too. Ask an AI to multiply two large numbers (without using a calculator), and after a million FLOPs through the belly of a neural network, the guess you get out the other side will be wildly wrong. A calculator from 1972, on the other hand, will turn its little silicon gears and get the perfect answer, every time, in microseconds. LLMs have a sort of “fuzzy impression” of what multiplication is; the calculator actually performs the algorithm.

But it’s not just “bad at math”, like a 1960s Barbie doll. It’s bad at doing anything that needs to happen the same way every time. Try using it to file your taxes—run it 10 times, and you’ll get 8 “very similar” results. That’s just its nature—it’s specifically nondeterministic, and each token is generated with a little bit of chance thrown in, every time. When you ask the guessing machine something really clear and obvious (like “Who was the first president of the United States?”), sure, you might always get the same answer. But venture into any subject even slightly more complex or subjective and all bets are off.

This means that you absolutely cannot build a “towering stack” of software atop LLMs, because there’s just too much room for creativity and divergence. Gears don’t work if the teeth are spaced a little differently on each spin.

This is no knock on LLMs; it’s just how they work. They aren’t algorithms; they are apparitions.

Putting The Ghost In The Machine

The upshot of this new duality is that for any given goal, you have to choose: do you want to use a gear (fast, cheap, rigid) or a ghost (expensive, non-deterministic, flexible)?

People on the cutting edge—the self-described “AI natives”—are trying to do everything with AI. Don’t read your emails, they say; let a ghost read them and act on them. Don’t call your prospects; have your ghost pick up the phone. Don’t bother with databases and UI widgets and logic and all that nonsense; it’s ghosts all the way down.

Some of that might succeed, but I suspect most of it will fail for things that really matter, because it’s much harder to confidently reason about what a ghost is going to do. If you could be confident that they’ll always be “close enough”, that might be one thing; but in practice, they’re often egregiously, horribly wrong.

On the other hand, while the “no AI ever” crowd might have defensible moral high ground, there are just some kinds of cognitive work that ghosts do ... better. If you’ve ever written code by hand, watching a coding agent work makes that abundantly (painfully) clear. Same goes for any kind of detailed symbol manipulation work: searching through nebulous data, editing prose, etc. You can choose not to use LLMs for these things, but you can’t pretend your way is more effective (since, to quote Spurgeon, the LLM will have “gone ‘round the world while you’re still pulling your boots on”).

But this stark dualism obscures what I think might be a happier middle path: you can use them both, together. You can build software that is real, concrete, specific code ... right up to the point where it needs to look at some human language nonsense and make a decision about it, at which point you summon a little ghost, ask it to do that one thing for you, and then release it back into the bardo.

We can have our real software—our dependable precision gears, now crafted at 10 times the speed—but when the time comes to parse that messy web page, or figure out which option someone really wants—well, say the magic word and you’ve got a single-use ghost for the occasion.

In this week’s episode of the Conjuring Code podcast, my guest Mark Wochner made an interesting point that’s worth repeating.

We talk a lot about “personal software” these days, which is made possible by AI assistance. Building your own software is certainly not a panacea—as it turns out, lots of software is more complex and subtle than you think—but one real virtue is that it lets you engage with the world in the way YOUR brain works.

In Mark’s case, this was specifically around weather data. There are plenty of weather apps out there, but for one thing, they only show you weather in the future, and Mark wanted to be able to see weather in the past (which is why his app is called Historicast).

But what I found even more interesting is that this app shows you four different forecasts, rather than just one. (They come from the four different major weather models around the world.) Where perhaps your typical bloke might just want an average across these four, Mark actually wanted to know when they disagree, because as a scientist, his brain is trained to engage with that kind of statistical uncertainty, seeing things as probabilities across multiple models rather than a single guess.

My point isn’t that that’s a “better” way of looking at the world (though I think it probably is). My point is, that’s what he wanted. And building his own software let him have it.

There are lots more insights in this week’s episode, give it a listen!

I had to have a hard talk with Claude today.

We’d been working on a new feature all morning. At first, I thought our progress on the feature (a leaderboard view in an app at work) was going swimmingly. It showed the data I wanted, and our conversation about how to calculate the scores was even interesting!

But then things started to go awry. I asked to make sure all the tests were working, and Claude pointed out that there were no tests (because I hadn’t asked for any). Then, in the process of writing some tests, it got very confused about what was complete, which calculation we agreed on, and which database to use. It broke some other tests in the process, and generally started to spin its wheels. After a dozen go-arounds without getting steadily worse, I decided it was time to cut bait:

Hey buddy. I think we got off on the wrong foot on this one. Take what we learned from trying this and write an explanation of what we decided to build, without any details about how we did it. Then reset the state of the local project to before we started, deleting any changes since the last commit.

Then I started a new session and handed Claude that explanation, but this time I made sure to say:

And use red/green TDD

(Hat tip to Simon Willison who shared that “cheat code” on Lenny’s podcast last week; it’s shorthand for asking the LLM to always write tests before writing code. “TDD” stands for “test driven development”, and red/green means you start with failing (red) tests and only then do you build the code that makes them pass (green)).

This time, I got much better results. I was starting with a clear picture of what to build, and so was Claude.

This is a useful thing to remember. Anytime you find yourself going down some path with AI and it doesn’t feel quite right, you have an amazing option that programmers never had before: just take a do-over.

I guess I should say, it’s not that we never had this option before; it’s just that in the old days, that involved throwing away hours (or days) of hard work. Even if you’re really sure that’s the right thing to do, actually doing it was so painful that often, you’d try to convince yourself otherwise. It’s not that bad! Maybe I can salvage it! Or maybe I should just live with it?

With AI, there’s just a lot less sting. You’re throwing away, what, a few minutes of work that you didn’t even do? Who cares? Just wipe it out and try again:

Let's start over. Write a very brief document outlining what we were trying to do in this session, and then roll back to before we made any of these changes.

The next time around, you can tweak your request to get better results. What did you dislike? What did you learn? You can dial in your request and context better, to make it more likely that you’ll get what you want this time.

Yesterday’s NYT daily podcast with Clive Thompson was a delight (and nicely summarized many of the things he covered in his full length op-ed last month). The impact of AI on professional software engineering is profound; everybody agrees that a lot more code will get written, a lot faster. But beyond that, nobody knows how it’ll all play out, or what the implications are for the career and discipline of software engineering.

Over here in not-a-professional-engineer space, though, things are decidedly more cheery. When AI can take your idea from a description to working code, it opens up vast new possibilities for people who—realistically—would never have developed the skills to do modern software development. The fact that you no longer need to wade through the abject complexity means regular people can actually make useful, fun software now. Rad.

This means the ideas you’ve had floating around in your head for years can suddenly come to life. That perfect to-do list; the website for sharing your snarky burrito reviews; the app to mediate fights between your kids; whatever you’ve been dreaming of.

But there’s something more. Some of the most amazing things you’ll do with this new ability are ideas that you haven’t even been able to have yet.

This is something that really stuck out to me in the interview:

What’s going to happen is that software stops being something that is precious and rare. It reminds me maybe a little bit of what happened with, like—this is going to sound really weird, but—with paper. So, paper used to be incredibly rare. You go back to pre-revolutionary Pennsylvania, and the average person had access to four pieces of paper a year.

And then suddenly, it becomes a lot cheaper, and all over the place, and you’ve got weird things like Post-It Notes, which are these really weird forms of paper that just transform the way that you live your life ...

So I think something very weird is going to happen as software stops being something that is special and difficult, and becomes almost like a Post-It Note, where it is ubiquitous; we call it into being for short-term reasons; it changes aspects of the way we communicate, and the way we deal with other people, in ways that I can’t really predict. But I do think that is what we’re looking at.

When paper is expensive and hard to come by, the notion that you would use it in this disposable way—like, so you don’t forget to pack your kid’s lunch—seems ludicrous.

When software is expensive and hard to come by, it’s the same thing. What kinds of new uses haven’t even crossed your mind yet?

This is one of the core benefits of getting in to the practice of making software right now; not just that it lets you work through your backlog of ideas (which it does!), but that it might open your mind to ideas you haven’t even had yet (nor has anyone else).

As a (very) minor example of this, I’m working on launching a new podcast (stay tuned, launching next week!). I narrowed it down to a few choices of opening music, but wanted a second opinion (especially given that my taste in music runs a bit eclectic). Normally, I would’ve just asked a couple friends for their opinion, but knowing how easy it is to make software, I thought to myself, “Why not make a little poll where a bunch of people can rank the options, and I get the one that’s most popular in aggregate?” So I did! And I got much better feedback. It’s here if you want to take it yourself:

conjuringcode.com/podcast/intro-poll

(I’ll have to decide on the actual music within the next day or two, but I’ll leave it open for a while as an example at least.)

It’s not like this is a particularly novel approach, nor is it something that would’ve been all that hard to make before. But before, the difficulty of actually doing it would probably have prevented me from even seriously entertaining the idea.

As you become better at making the software that comes into your mind, what new kinds of things are going to occur to you?

More than a few people have asked me, “Bro, why are you writing a book about this? Why not just smaller things like articles and podcast episodes?”

I get the question; writing a book is not a hip choice these days. By comparison to micro-format things like posts and threads, books seem so ... big. Difficult. Monolithic.

Plus, who has the attention span to even read a whole book these days?!

Well, as counter-cultural as it is, this feels like the right thing. Anybody can make software now, and I want more people to experience the fun of that. But even with AI to get you past the technical hurdles, for a lot of people, it’s still too much, too unfamiliar and scary. So helping people cross that chasm—that’s the spirit of the book, to be your friendly guide through the whole landscape, even if you only need a little bit of it right now.

Of course, I will also be doing all those other things—blogs, podcasts, articles, talks, etc. Now that I’ve got this draft, I am ready to start unleashing all the other kinds of content. I just needed to put all the pieces together in my mind first, in one cohesive frame.

I’d never created anything book-length before, and boy howdy is that a learning experience. But I’m proud of how far it’s come and I think you’re going to love it.

You can check out the current Table of Contents right here, and if you’re interested in being a beta reader in the next round (May 2026), let me know.

I’m serious, man. Programming is going to be for everybody. And it’s going to be the most amazing thing. Because you know how much fun we’ve been having all those years. And we’ve been telling people it’s really fun. But now they’re going to get to experience it.

While the implications of AI on the software industry are massive, I think the real story is what this change makes possible for the other 99.9% of humanity. Yesterday, if you weren’t a coder, you couldn’t be a programmer. Today, you can.

Last week’s New York Times story also said it well:

This is the cultural side-effect of coding becoming conversational: the realms of programmers and everyday people, separated for decades by an ocean of arcane know-how, are drifting closer together.

That’s the purpose of this Substack (and book!). I’m not satisfied with “drifting closer”; I want to get out and push!

If you’re someone who’s not a software engineer by trade, and you’re curious about using this new-found power to make your own apps and software, drop me a line. I’d love to talk to you, to share my in-progress work, and maybe even to feature your story as part of it.

This post from Tess earlier in the week captures it pretty well:

What’s the deal? Why is all this software so bad?

It isn’t because people who make software hate you, or think you deserve bad software. It’s because, from an economic viewpoint, good software is hard to get. Code is so difficult to create—so cryptic and fragile, so precise—that it’s very expensive to make. Even bad software is extremely expensive, let alone good software. This great passage from Paul Ford’s NYT editorial this week puts it in perspective:

When I rebooted my messy personal website a few weeks ago, I realized: I would have paid $25,000 for someone else to do this. When a friend asked me to convert a large, thorny data set, I downloaded it, cleaned it up and made it pretty and easy to explore. In the past I would have charged $350,000.

So when Tess talks about “deflation”, this isn’t a hyperbolic AI insider term. Literal financial deflation on the order of 100-1000x.

Is this sad for the software business? I guess it depends on who you ask. For example, if you look at the team that Paul theorizes would have worked on that data transformation project:

That last price is full 2021 retail — it implies a product manager, a designer, two engineers (one senior) and four to six months of design, coding and testing. Plus maintenance.

What he’s describing there is accurate, but that is sad! Conceptually, the work he’s describing isn’t really worth $350K; that’s just what it costs. But that means we don’t get enough of something that’s useful and good. We get mediocre software at best.

Imagine if we didn’t have … I don’t know, industrial corn production. A world where every ear of corn is lovingly grown and harvested by a human. In that world, a cheese enchilada would cost, what, $300?

Enchiladas are good, but not $300 good.

And likewise, converting a thorny data set is good, but not $350K good. It’s just out of whack with the actual value of the result, owing entirely to the scarcity and difficulty of the work.

So yes, you should be cheering, cheering, cheering.

If you make a living in tech, and you’re not following this curve and producing 10x as much value as you did before, you’ll have trouble staying employed. That’s individually sad, but there’s so much room for better software, we should still be able to justify employing lots of programmers who work with this much longer lever. They become more valuable, not less.

But maybe more importantly, if you’re someone who’s not in tech, and you’re interested in making apps yourself, this is very good news. All that terrible software out there in the world has some new competition: you!

If you want to read more about how the landscape of making software is changing, particularly for people who didn’t previously consider themselves to be “engineers”, subscribe here:

Subscribe now

Read more on conjuringcode.com.

The ad is fun, and it really captures the joy of discovering that you really can build useful software now, even if you couldn’t before. It’s downright revolutionary.

Now, Base44 is selling a particular product that aims to help people do that. It seems like a nice product! It probably removes some decisions you’d have to understand and make, and streamlines some things that are tricky (for example, they help you get an app in the app stores, which is pretty useful).

On the other hand ... do you need another product for that? I mean, beyond the foundation model / coding assistant? Every layer you add in software adds some cognitive burden of particular things you need to learn, and it can box you in to a particular way of thinking about things. Part of the magic of the underlying LLM technology here, though, is precisely that it unboxes and unbinds you. No matter what road you’re going down, no matter what you want to do or how you want to approach it, it can go there.

Personally, I get that feeling every day building apps with AI models directly, and I don’t see much value in a pretty layer on top. But what do you think?

So when we change something, we always change a copy rather than changing the real thing (aka “production”) directly. We only push our changes to production when they’re ready (i.e. we’ve tested that nothing is broken).

This isn’t how most professions work, at all. Surgeons don’t get to “make a copy” of your body, and then swap out the copy with the “real” you if the procedure works out. (If they could, the state of the art in medicine would move much faster!)

The closest analog I’ve been able to imagine in other fields is something like a chef making new recipes. Most of the time, line cooks just follow the same recipes night after night. But if you’re a chef and you have an idea for a new dish, you don’t just start randomly feeding it to real customers. You iterate on it by yourself, behind the scenes (during the daytime, or in a test kitchen) where only you (and maybe a couple other chefs) get to judge whether it’s good enough. You tweak, you change, you taste, and only when you’re happy with it do you push copies of that recipe out to the real kitchen and put it on the menu.

This is so important in software, it’s practically second-nature. When you change something complex like code, you always risk accidentally breaking something else. (”I was just trying to change the font, but now the database is unreachable...!”). But this buffer zone of “development” means you don’t have to pussyfoot around—you can try whatever you want, even if it is very disruptive, because you know you’re just changing a copy, and you’ll check it locally before pushing it to production.

This property is one of the reasons I think building software is among the best things you can do with AI. Like humans, LLM coding agents make mistakes all the time. If you let them touch “the real thing” directly, those mistakes might have consequences. If you keep them in the test kitchen, and check the results before you go live with them, it’s much better.

This didn’t give me AI vertigo. It made me feel like I had super powers.

I sometimes wonder if I’m in a bubble. I mean, I think making software is obviously useful and fun, but … am I a weirdo? Does anyone else even care? Well, these guys care, and make a pretty great case as to why other people might care too—not just programmers like me.

In the first episode, they invited listeners to send in what they had vibe coded, and talked over some highlights on the next episode, which included stories like:

• A dad who gamified household chores with a leaderboard

• An interior decorator who made a wallpaper surface-area calculator

• A welder making his own business software

• A family Christmas letter turned into an interactive Zork game

I love this. I can’t get enough of it.

Sometimes, when you’re faced with just open-ended possibility, it can be stultifying (”gosh, I could create anything…”). But it just takes a little nudge to remember that there are opportunities literally everywhere. And the friction is so low, it doesn’t take much to try something, even if it might be a stupid idea.

For example: last weekend, I got together with some college buddies. At some point, someone suggested it would be funny if we had a bingo game for all our stupid inside jokes. Twenty minutes later, I was installing a web app on each of their phones with exactly that.

At one point, while talking about all these little apps and projects, Casey said something I found incredibly profound:

To me, this stuff is the flipside of slop. This is anti-slop, right? If slop is about a world where every surface online seems like it’s being taken over by these digital creations that you didn’t ask for, that you find confusing, they blur the line between reality and fiction, and they just sort of make you feel hypnotized and gross. This is the reverse of that. This is real people saying, I have a need in my life and I’m gonna go make it with my own hands. And we’ve always talked about AI as a dual use technology. We do spend a lot of time on the show talking about its many downsides, which are huge and real and scary. But there is also upside here, which is, at least in this moment, this can be an empowering tool.

Amen to that.

Slop is the word for when AI creates something vague and ungrounded, something that doesn’t represent the thoughts and desires of a real, living human. Slop is low quality, not because it’s technically bad, but because it’s vacuous and generic. No human cared enough to want it.

Anti-slop, then, is a perfect word for making something that you actually care about, that serves some function in your life, even a little one. It’s creative, it’s fun, and it’s led by what you want. It’s there because somebody wanted it.

I just wanted to draw a line in the sand. I am anti-slop, and I think using AI to make software you actually care about is anti-slop, too.

Subscribe now

Most people don’t make software.

And that’s a shame, because software is incredible. It’s intelligence made real: diligent, patient, and immeasurably fast. Nothing like our modern world would be possible without it, and if used well, it could help us with lots of our current problems, too.

The reason most people don’t make software is that making software is really hard. It’s a kind of focused intellectual work that most people aren’t well-suited for, because it involves gobs of arcane and ever-changing detail that all has to be arranged just so. It’s no wonder we call it “code“: it’s cryptic, and making it is slow, error-prone work. (Which, by the way, is also why so much software in the world just sucks—it was just too slow and expensive to make it any better.)

But, there’s something important you should know:

This is one of the consequences of generative AI: we now have machines that can effectively and rapidly translate between “what you want” and “how to do that in code”. This means that all that effort and arcane knowledge required to create software has decreased dramatically (and it’s getting easier by the day).

So … why isn’t everyone rushing out and using AI to help them write code to solve their problems?

There are two reasons: one easy, one hard.

The easy reason is that they simply don’t know (or believe) that this has happened. I work in a prominent big tech company, and I can tell you that many of the people I work with don’t really know (or believe) it.

But the harder reason is that even with this change, the reality is that you still have to know stuff to make software—at least, if you want it to work.

Maybe you’ve heard the phrase “vibe coding“? That’s when you use AI to write some software, but you don’t care what it’s doing on the inside, or how it’s conceptually constructed.

Vibe coding is fine for some purposes, but sooner or later—and probably sooner—you’re going to fall off a cliff when something unexpected happens, and you realize that the software you “vibed” is not only a mystery to you, it’s full of nonsense and inconsistency, and doesn’t really do what you thought.

Making software, even in a world with AI, is still hard. But not all hard is the same. There’s “bad hard”, and “good hard”.

“Bad hard” is all the stuff I mentioned above: code is cryptic, unforgivingly precise, and full of mind-numbing drudgery, even to get boring things to work reliably. Stupid little missteps can eat up entire days, even for professionals.

But there’s also “good hard”! Making useful software means thinking differently about the world, seeing everyday life with x-ray vision. It forces you to grapple with what you (and other people) really want, and gives you endless opportunities for clever, intuitive new solutions to old problems. In the moments when you connect with the “good hard”, it’s the most fun, incredible feeling, and it’s why many of us who are professional software engineers got into it in the first place.

In the past, this dual difficulty was a fact of life for software engineers: “you take the good (hard), you take the bad (hard)”. But that’s not true anymore! Because of what LLM coding agents can do, and how fast and reliably they do it, the bad hard is evaporating before our eyes, leaving (mostly) good hard.

Which is still hard!

If you want the incredible benefits of making your own software, and you want to rise above the precarious level of “vibe coding”, you need a basic grasp of what software even is: how it works, how you make and ship it, and what parts of it are easy or hard (or even possible in the first place). In other words, you need the knowledge that a software engineer gathers over her career (alongside all the battle scars and eye-twitches from the “bad hard” stuff).

But now, you have the benefit of speed-running this knowledge. That doesn’t mean there aren’t going to be some very interesting and difficult things for you to learn; you’ve just got a much bigger running start.

So this publication will explore what it means to build software with AI help, even if you don’t consider yourself a professional software maker.

Subscribe now