Direct link to podcast audio file

The promise of Breaking Change is that with every major version (this being the 60th episode of the program, but only the 53rd such release), I will break something. Well, I finally did it. I think I broke the show. Find out how by listening for yourself!

Want to be my friend? Drop me a line at justin@searls.co. Want to file a complaint with my supervisor? Forward your concerns to podcast@searls.co.

These links may rot, but alas—death comes for us all:

• Tonal (without a subscription)
• Better with Becky
• My appearance on the freeCodeCamp podcast
• Dual-loop BDD is the new Red-green TDD
• Models are commodities, harnesses are differentiators
• Aaron's puns, ranked
• United Airlines can now boot passengers who refuse to use headphones with their devices (News+)
• Your Meta glasses are watching you pee (9to5mac's summary)
• Tuna for Mac by friend of the show, Mikkel Malmberg
• MacBook Neo
• MacBook Neo offers more single-core performance than any mobile processor from AMD, Intel or Qualcomm
• Apple + Nvidia's CloudXR & Foveated streaming partnership: 1, 2, 3, 4, 5
• Xbox's Project Helix
• Microsoft's 'Xbox mode' is coming to every Windows 11 PC (News+)
• Windows: Announcing new tools and platform updates for Windows PC game developers
• Sony is testing dynamic pricing in the PlayStation Store
• DLSS 5 should make you excited and/or outraged: video, backlash
• Gamblers trying to win a bet on Polymarket are vowing to kill me if I don't rewrite an Iran missile story
• South Korean Police Lose Seized Crypto By Posting Password Online
• China mobilizes "one-person company" AI startups
• Scrubs is back!
• Mickey 17 is not about a cartoon mouse
• The Expanse
• Marathon - and how sickos like me can't stop thinking about it

Direct link to podcast audio file

Quincy Larson over at freeCodeCamp had me on their podcast to discuss how the rapidly changing software industry is impacting junior developers and what they can do about it. I don't normally spend time talking about this stuff, because I started programming in the 90s and can't claim to know anything about what it's like to just be starting now. I've also always discouraged people from getting into software development unless they're super passionate about it, which has been out of step with the "learn to code" hype train that gathered steam over the last fifteen years only to run into a brick wall recently.

His audience is way larger and composed of quite different people than those who follow my stuff, so I strongly recommend you read every last YouTube comment. Some pretty crazy shit, if I'm being honest. Makes me glad I don't have 11 million subscribers.

Appearing on: freeCodeCamp Podcast
Published on: 2026-03-17
Original URL: https://www.freecodecamp.org/news/there-are-2-kinds-of-devs-one-of-them-is-screwed-justin-searls-interview-podcast-210/

Comments? Questions? Suggestion of a podcast I should guest on? podcast@searls.co

It follows, then, that if agents require integration between model and harness, that the companies building that integration—specifically Anthropic and OpenAI—are actually poised to be significantly more profitable than it might have seemed as recently as late last year.

This assumption is incorrect. To date, agents have not clearly benefited from proprietary integration to their favored model. I thought this was obvious, but I sometimes forget that not everybody else has made it their full-time hobby to mix and match various coding agents with various large language models for the past year.

Here's how I see it.

The API surface of a frontier model is text in, text out. Images in, images out. Audio in, audio out. AI models are among the most immediately pluggable and therefore commoditizable innovations in the history of software—right up there with UNIX pipes and their simple promise of text in, text out. Countless forks and TUIs have already demonstrated that swapping the underlying model is a marginal concern, not a structural one. The harness doesn't integrate with the model. It integrates with the user's world—files, tools, workflows, intent—and calls the model as one resource among many.

This distinction matters enormously. A high-quality harness paired with a mediocre model can accomplish incredible things. A frontier model paired with a poorly-considered harness can barely get out of the gate. If model-harness integration were truly the differentiator, the model would indeed be irreplaceable and invaluable. But in practice, models have turned out to be the most replaceable part of the stack. And every recent advance in tool use, verification, and orchestration has only made this clearer—the harness gets more valuable while the specific model behind it gets more interchangeable. As long as multiple companies are credibly in the frontier model game, there will be cutthroat competition and relentless downward pressure on price. And while it may not happen soon, models and hardware will eventually advance to the point that a local open model is good enough—and then the frontier labs won't just be commoditized, they'll be cut out entirely.

Thompson brings up Microsoft's new Copilot Cowork bundling initiative as evidence that model-harness integration is where value accrues:

Fast forward to last week, however, when Microsoft revealed how they will handle the potential business impact of AI reducing seats, which is a bit of a problem for their seat-based business model: the company is going to bundle AI into a new higher-tiered enterprise offering, E7, which is going to cost twice as much — $99 per seat per month — as the formerly top-of-the-line E5. That's a big increase, which Microsoft needs to justify with AI that actually makes those seats more productive, and the product they launched with the new bundle was Copilot Cowork.

Microsoft is indeed in a tight spot, but not because the model makers have a monopoly on harnesses. Instead, blame their outlandish investments in somebody else's model, their piss-poor track record for delivering a single worthwhile Copilot-branded piece of software outside the GitHub org, and their over-reliance on per-seat licensing that is existentially at odds with a strategy that, if successful, would drastically reduce the number of seats its customers need. None of that tells us anything about whether models and harnesses are structurally coupled. It only tells us what we already know: that Microsoft has put itself in a strategically weak position—a strategy that presupposed they would somehow stop sucking at building software people actually want to use.

Apple's situation is a cleaner test of the thesis. Dediu is probably right that Apple has a tremendous opportunity precisely because they can build a harness and swap the underlying model. Will they build an incredible harness? No—they'll build one that's just good enough to keep customers buying their hardware. But the strategic logic is sound: focus on the human interface and the real-world problems it can solve, and don't cede the narrative to implementation details like which model is running underneath. The truly great harnesses will probably come from smaller, more nimble startups who understand that the opportunity isn't in training the next frontier model—it's in connecting the horsepower of any capable model to the thousand different domains waiting to be served.

The frontier labs attracted an outsized share of attention and funding because OpenAI happened to hit one out of the park with ChatGPT as a product, and this conflation continues to produce analyses that make the same mistake Thompson is making. ChatGPT went so mainstream that it's treated as a blockbuster product, but I suspect we'll look back on it merely as a (historically impactful) proof of concept. The work of building a chatbot and the work of training a frontier model are only incidentally related. The thousands of chatbot systems that have sprung up since ChatGPT's release should be all the evidence we need that building a great chatbot never required building a great model—OpenAI just happened to do both.

At the end of the day, the utility of models is owed to the fact that they are black boxes with simple interfaces. Text in, text out. Audio in, audio out. Increasingly, video in, video out. But that simplicity is also what makes them commodities. And leads don't last long enough for anyone to establish a moat—the underlying research unlocks improvements in the open, and ubiquitous access to everyone's models facilitates distillation of competing ones.

Harnesses couldn't be more different. Harnesses are the gooey, ever-shifting integration of human-computer interface. They connect people's needs to implementations designed to meet them. With a little cleverness and elbow grease, they can be dispatched to verify that those implementations work. They can be assigned to orchestrate other agents across systems in separate geographies, and over sessions conducted at different times.

The model is the engine. The harness is the car. And history has shown—over and over—that you don't need to manufacture your own engine to build a great car.

🔗 stratechery.com

🧂 justin.searls.co

For the last month, I've been working on prove_it, a framework for building quality harnesses for Claude Code—primarily via its hooks system. In a recent release, I added TDD enforcement to its default configuration. First, it injects a test-first development approach into every plan Claude generates. Then, a PreToolUse hook follows up with permissionDecisionReason reminders whenever the agent deviates from the one true path (e.g., repeatedly edits source files without touching any tests, never runs a test to see it fail, etc.).

And just like real life, nagging developers works. My current side project is having no problem maintaining 100% (not 99%, not 99.9%, but 100%) code coverage.

My initial prompt simply told the agent to practice "red-green TDD" (a phrase I had never heard of until it was discovered that LLMs apparently interpret it as "real TDD"). This approach turned out to be woefully insufficient. Why? Because agents follow the path of least resistance and will invariably write a shitload of unit tests chasing the local maximum of code coverage without any regard for the global maximum of making sure shit actually works. After finishing each feature, all the code would have real unit tests with real assertions, but each time I tried running the fully-integrated app, the agent would find a novel way to miss the forest for the trees.

So yesterday I updated the prompt with the more sophisticated dual-loop approach developed by folks like Dan North and other adherents of behavior-driven development in the late aughts. It is best illustrated by two concentric circles: you begin each feature with a failing integration test, then dive into an inner loop for numerous red-green-refactor iterations of unit tests, then pop back out again once the outer loop's integration test passes.

Honestly, I hadn't taken this practice off the shelf in a while, but since updating the prompt that gets injected into every Claude Code plan, it's been working out great:

## Development approach

Follow BDD dual-loop TDD. Every feature increment starts from a failing integration
test and is driven inward through unit-level red-green-refactor cycles.

### Outer loop (integration)

1. Red (integration) — Write one integration/acceptance test that describes the
next observable behavior from the outside in. Run it. Confirm it fails for the
reason you expect. Do not proceed until the failure message matches your intent.
2. Inner loop (unit) — repeat until the integration test can pass:
  - Red — Write the smallest unit test that expresses the next missing piece of
implementation the integration test needs.
  - Green — Write the minimum production code to make that unit test pass.
Run it in isolation and confirm. No speculative code.
  - Refactor — Clean up the code you just wrote (duplication, naming, structure)
while all unit tests stay green. Only touch code covered by passing tests.
3. Green (integration) — When enough unit-level pieces exist, re-run the
integration test. If it still fails, diagnose which piece is missing and drop back
into the inner loop. Do not add code without a failing test driving it.
4. Refactor (integration) — With the integration test green, refactor across
module boundaries if needed. All tests — unit and integration — must stay green.
5. Repeat from step 1 with the next slice of behavior until the task is complete.

### Discipline rules

- Never skip the red step. If you cannot articulate why a test fails, you do not yet
understand the requirement.
- One logical change per cycle. If you are changing more than one behavior at a
time,
split it.
- Run only the relevant test after each green step, then the full suite before each
commit-worthy checkpoint.
- If a refactor breaks a test, revert the refactor — do not fix forward.
- Treat a surprise failure (wrong message, wrong location) as information: re-read
it,
 adjust your understanding, then proceed.

I imagine most people reading this will just copy-paste it into an AGENTS.md file or something, but if you're actually interested in learning more about this topic, my favorite articulation of this concept can be found in the edition of The RSpec Book that Zach Dennis worked on.

Now for just a touch of resentment

Not for nothing, but a friend of mine asked why it was that so many programmers who had previously rejected test-driven development and related practices are suddenly embracing it. I genuinely believe some people interpret the suggestion that their code isn't good enough as a personal affront. They feel that being told to write tests, much less orient their workflow around verifying the quality of their work product, is somehow an indictment of their programming skills. So fragile is the ego of many programmers. I witnessed this defensive reaction firsthand on countless training and coaching engagements, so I'm speaking from experience here.

Of course, in 2026, the same people are suddenly huge fans of the same practices they once dismissed, because now we're talking about verifying some dipshit AI agent's work. The key difference is that any such tests exist not as a condemnation of themselves, but of the code written by some external thing.

What's funny about this, of course, is that nothing has really changed. If you zoom out, it's still just some doofus staring at a computer screen in silence all day. But yeah, a lot more people are suddenly really interested in TDD than there used to be.

I'm still iterating on my experimental Claude Code verification harness, prove_it. This week my focus has been on nudging agents to practice test-driven development. Traditionally, we called this "TDD", but which has recently been renamed to "red-green TDD" as it has been discovered that this is what LLMs interpret as "real TDD".

Anyway, so that I could watch it steer an agent in a fresh codebase in real time, I opened a new directory and asked Claude Code to one-shot a terminal-based tennis game, replete with scoring and an AI that I couldn't beat. In OCaml. And it worked! It actually test-drove everything. Neat!

Direct link to podcast audio file

Today, we're joined by a very special guest, Len Testa! You might know him from The Disney Dish podcast or from his excellent theme park travel planning app Touring Plans. Or you might not know him at all! No wrong answers.

This episode is all about Disney's ill-fated Star Wars: Galactic Starcruiser live action role-playing hotel—which we both had the opportunity to experience right when it first launched. It was a life-changing experience for both of us, so why did it fail? Is it true that the top Disney brass learned all the wrong lessons from that failure? And will the CEO-in-waiting Josh D'Amaro ever have the courage to attempt something so ambitious again? Listen to this episode, in which we speak with an unearned confidence that suggests we have all of these answers!

You can reach out to Len at len@touringplans.com and you can write into the show at podcast@searls.co. He'll read your e-mail and reply to it, but I may only skim it.

Direct link to podcast audio file

Sure feels like some combination of AI, the US military, and the AI military could bring an end to the world any day now, so I figured I'd better record one last show for posterity. Welcome me on this version's speedrun to the apocalypse!

So long as the EMP blasts don't nuke all our ham radios, write in to podcast@searls.co and I'll read it on the next release of the program. Over.

Be sure to click all these links while the clickin's good:

• Ninja Creami Deluxe
• prove_it
• Agents are ushering in the Antisocial Era
• Brace for the Fuckening
• Citrini Research fanfic
• Would you like your AI singularity benign or extinction-level?
  • Original post by the Dallas Fed
• Anthropic's Statement on the comments from Secretary of War Pete Hegseth
• OpenAI's agreement with the Department of War
• U.S. Strikes in Middle East Use Anthropic, Hours After Trump Ban
• Human brain cells on a chip learned to play Doom in a week
• Apple introduces a new video podcast experience on Apple Podcasts
• Foveated Streaming for Apple Vision Pro
• Huge Xbox shakeup: Phil Spencer retiring, Sarah Bond resigns, Microsoft AI boss becomes new Microsoft Gaming CEO
• XCOM's Jake Solomon announces his new studio is closing, reveals now-cancelled AI-driven narrative game
• Fan group makes Unreal Tournament 2004 available to play for free and in 4K
• Video Games Are Losing a Brain Rot Race to Gambling and Porn (News+)
• Netflix walks away from its deal to buy Warner Bros. after Paramount came back with a better offer (News+)
• Why Netflix Actually Won Even Though It Lost Warner Deal (News+)
• Aaron's puns, ranked
• Your Friends & Neighbors
• Rental Family
• Halt and Catch Fire (again)
• Paradise: Season 2
• Star Trek: Voyager - Across the Unknown
• xcbeautify
• turbocommit
• The double loop model for agentic coding

Thanks to the upheaval being caused by coding agents, I believe we've entered a new era without realizing it, one that might be called Antisocial Coding.

Three things I've been chewing on lately:

• Agents blow out team communication costs. Last year, Scott Werner compared a developer orchestrating agents to an octopus with 8 autonomous arms and I replied to point out how this creates a hub-and-spoke communication crisis that would prove unwieldy for traditional multi-developer collaboration. Since then, I've been advising startups to stay single-developer for as long as possible and telling larger organizations to start moving to one-repo-per-human wherever they can—even if it means re-architecting their systems to align with this.

• Agent-built codebases calcify quickly. Last night, Caleb Hearth texted to tell me he'd created several issues on turbocommit, and I'm ashamed to admit my brain was so overwhelmed with six terminal tabs of unrelated WIP features that I brusquely denied all of them. Caleb shared a keen insight: many agent-led codebases are becoming impenetrably large and complex extremely early in their lifespan—even while the userbase is still limited to the original creator. And on reflection, I do sense a certain ossification in the projects I encounter lately—so tightly coupled to one person's hyper-specific needs that they lack room to grow or change by the time other users arrive. Beads is the perfect example: I spent two weeks trying to use it, but at 4 months old it was already far too complex and brittle to integrate into my workflow

• Open source is closing its doors. Yesterday, tldraw took the unusual step of removing the tests from their codebase, on the theory their continued presence would make it far too easy for anyone with an agent to build a cleanroom rewrite and undermine their business. Nothing says "closed for contributions" quite like not even having access to a test suite or CI to work with

I don't feel strongly about any of this, because I'm mostly a loner to begin with. But this trend will likely have troubling impacts for teams and organizations.

• If the last decade of social coding taught us anything, it's that pinning the continuity of your business operations on a bunch of software for which the bus factor is 1 is an unacceptable liability. If the next decade is typified by an explosion of solo projects, then the rational response will be to adopt fewer dependencies and have agents build more in-house implementations—even if it means shouldering more maintenance costs and security risks
• Unlocking the maximum productivity afforded by agents by sequestering individual human developers to their own discrete fiefdoms (whether at the repository, CODEOWNERS file, or some other boundary) will only accelerate the trend of discouraging contributions from others, compounding the above issue at scale and throughout engineering organizations
• While many people are (rightly) concerned about AI's impact on the job prospects of less-experienced developers, the continued erosion of collective code ownership coupled with a trend away from inter-person collaboration will further slam the door on opportunities for mentorship and apprenticeship, exacerbating the widening gap in potential value creation between juniors and seniors

I've never had more fun building stuff than I'm having right now, but that doesn't change any of the above. These are important things to be watching out for. Engineering leaders should probably consider the downstream effects discussed here before plowing ahead with plans to reorient their organizations around what's best for maximizing the productivity of semi-autonomous coding agents.

Expect the Starbucks in your local suburb to become occupied with middle-aged former office workers who want to get out of the house. That's a benign portrait, but a lot of these families still owe mortgages on their houses that they won't be able to maintain. If I were a homeowner in Silicon Valley or Westchester County, I might consider putting my house up for sale to see what I could get because there's going to be downward pressure on these communities. It might not feel great being first, but you don't want to be last.

Then again, why should I be surprised that politicians aren't thinking about this? Almost nobody is! AI boosters are having too much fun playing with Claude Code to connect the dots between its current capabilities and the post-office-work utopia/dystopia that awaits us. Meanwhile, AI skeptics seem worryingly self-assured in their wishcasting that today's agents:

1. Will never be able to do the things they can already do
2. Will forever remain as incompetent as they are now
3. Will disappear the moment the AI economic bubble bursts

Other than the first item on that list, I don't even know that the skeptics are wrong! Maybe they're right! In fact, it'd be more convenient for all of us if the skeptics end up being right. But are we really certain that the probability Sam Altman is even kinda-sorta right is literally zero percent? If not, then we should probably prepare for that potentiality.

I imagine that we all have a pretty clear image of what will happen if the AI bubble pops: stocks will crash, Steam Decks will be back in stock, and Sam will end up in jail. (Maybe every disastrous hype cycle in tech simply demands that at least one awkward white man named Sam goes to jail.) But I've got to admit, many people I talk to and follow online don't seem to have given a second thought to the sort of economic hellscape we're in for if the astronomical valuations of companies like OpenAI, Anthropic, and SpaceX (lol) turn out to have been appropriately priced.

Well, give it thirty seconds' thought, and—to borrow Yang's term of choice—we'll be in for The Fuckening: a macroeconomically significant decrease in the number of high-paying white collar jobs the market will support.

Tech CEOs are bullshitting us

Listen to Satya or Sam or Jensen talk about this "What if?" scenario, and you'll hear them compare AI to technological revolutions of the past. They each breathlessly declare, "there will be new jobs," and that AI will, "create a bunch of new ones," and even that, "there will be more jobs." But, as someone who's been using coding agents to build good-enough software with the velocity of a traditional engineering team for nearly a year now, none of these reassurances pass the smell test. The idea that there will be at least one net-new job created for every job eliminated by AI simply isn't credible.

Remember, for the purposes of this post, we're playing out the scenario labeled "what if these AI investments actually pan out?" That scenario isn't compatible with a future where companies find themselves needing just as many highly-compensated humans as they do today—the ROI needed to justify this level of investment simply wouldn't be there.

So why are the AI executives talking out of both sides of their mouth? Because, what else the fuck are they supposed to do? Go on the record and say, "yeah man, I dunno, now's probably a good time to learn how to can your own food or sell your house if you happen to live in a mid-market metro with a strong services sector."

Whenever I hear one of these guys' bullshit quotes, I have to mentally sprinkle in the unspoken context to protect my own sanity:

• "There will be new jobs for people with deep domain expertise and unusually strong critical thinking skills."
• "Looking at jobs as a debt counselor or estate auctioneer? AI will create a bunch of new ones."
• "If you can swallow a massive pay cut and don't mind shutting doors for a living, there will be more jobs."

Programmers are first in, last out

Software developers may be among the first to experience what it feels like for AI to do our jobs for us, but I still believe we'll be the ones shutting the lights off on the middle class.

In fact, programmers are about to become as busy as we've ever been. Why? Because custom software has historically been supply-constrained. How many businesses would have been created over the last twenty years if even extremely basic apps didn't require millions of dollars of venture funding? Already, agents can help capture those opportunities on a relative shoestring budget. A tremendous number of niche, overlooked cottage industries are finally ripe for their ✨disruption✨ moment.

And all those projects still need human programmers! Why? Because today's agents are nowhere close to being able to write software that won't fall over without supervision. The last 10% needed to reach full autonomy will take 90% of the effort. My Tesla has driven me everywhere for over a year, but it'll be decades before the world stops manufacturing steering wheels.

Programmers may be spread across more companies and working in smaller teams, but there likely won't be a net reduction in the amount of total work to be done anytime soon. But can we honestly say the same about the accountant who's been rendered redundant? Or the junior lawyer position the firm opted not to fill? Or the management consultant who realizes their client can buy the same peace of mind with a $20 ChatGPT Plus subscription? Where are they all going to go? The answer is obvious: if this whole "AI thing" ends up becoming what it's cracked up to be, those people are well and truly fucked. And sooner than they probably realize.

Make your work worthwhile

Ultimately, unless we see AI crash and burn catastrophically, I feel pretty comfortable predicting that if the only sounds your job makes are *clickety-clack* and *yackety-yack*, the bulk of your colleagues—and very possibly you—are going to be caught up in the gravitational vortex of what Andrew Yang is calling The Fuckening.

So, what can you do to mitigate these risks and protect yourself? All you need to do is follow my fool-proof two-step plan:

1. Acknowledge that the odds we're living in The Fuckening timeline are greater than zero
2. Plan accordingly

If you're a programmer and your current role doesn't resemble that of a full-breadth developer, do something about that ASAP. If you're anyone else, then follow this bit of advice buried inside that larger post:

Figure out how your employer makes money and position your ass directly in-between the corporate bank account and your customers' credit card information.

Do the work: trace your individual contributions to the total revenue and cost savings they represent for your employer. Is that number demonstrably higher than your fully-loaded compensation? If so, you should be okay. And whenever the AI tools in your space improve appreciably, re-examine your contributions and run the numbers again. But as soon as you cost more to your employer than you bring in, don't assume they'll keep you around—figure out how to increase your output! And if the numbers are totally upside down, find someplace new where your cost will be commensurate with your value.

All I have is individualized advice, because our individual situations are all we have control over. Yes, there are countless collective actions we could take as a society to mitigate or even eliminate these downside employment risks. There are probably even public policy prescriptions that could position civilization to absolutely thrive in the age of AI. But the odds of either of those happening in the current political climate are even lower than (ugh) Sam Altman ending up being proven right about all this shit.

I'm expressly not suggesting we treat each other as if we're living out a workplace adaptation of The Hunger Games here. I'm just reminding you to secure your own oxygen mask first before assisting others.

Direct link to podcast audio file

I feel like I'm getting saltier, and it's concerning. If you want me to tone it down and/or up, let me know. It'll go a lot better if you just write to podcast@searls.co instead of yelling at your phone.

As usual, I brought the goods. Now here are the receipts:

• prove_it is doing its job, mostly
• Aaron's puns, ranked
• Starsand Island studio confused by alleged 'praise-bombing' attack
• Sony is considering holding back PlayStation 6 until 2028 or 2029
• Southwest changes are infuriating fans (News+)
• NYT: All the news that's fit to manspread
• Gurman: Tesla CarPlay Held Back by Need for Wider Adoption of Apple's iOS 26 (Archive)
• YouTube on Vision Pro (News+)
• Apple Announces Special Event in New York, London, and Shanghai on March 4
• Filed my first SwiftUI bug as feedback. It's FB21962656
• Thoughtworks concludes TDD is good and billable juniors valuable
• Ugh, Anthropic CEO was right about the timing of AI writing all the code
• Peter Steinberger Chose OpenAI. The Code Was Never the Point
• Eternity
• Starfleet Academy
• Your Friends & Neighbors

We ordered a wood chest that arrived with cosmetic damage. After logging the damage in their customer support interface, it prompted me to start a chat with their AI virtual assistant.

What happened next:

1. It immediately offered me a 15% refund to keep the product
2. I asked for 20% and it immediately agreed
3. I asked for 25% and it immediately agreed
4. I asked for 30% and it turned me down
5. I took the 25%, which was, indeed, immediately refunded

Turns out that negotiating with a rules engine is way easier than negotiating with a human tasked with operating a rules engine.

So basically, all Wayfair did was add a chatbot to the end of their existing "Report a Problem" interface that will give customers more money if they ask for more money. What a world. 🌍

Instead of giving up, I forced myself to reproduce all my manual commits with agentic ones. I literally did the work twice. I'd do the work manually, and then I'd fight an agent to produce identical results in terms of quality and function (without it being able to see my manual solution, of course).

This was excruciating, because it got in the way of simply getting things done. But I've been around the block with non-AI tools enough to know that friction is natural, and I can't come to a firm, defensible conclusion without exhausting my efforts.

But, expertise formed. I quickly discovered for myself from first principles what others were already saying, but discovering it myself resulted in a stronger fundamental understanding.

1. Break down sessions into separate clear, actionable tasks. Don't try to "draw the owl" in one mega session.
2. For vague requests, split the work into separate planning vs. execution sessions.
3. If you give an agent a way to verify its work, it more often than not fixes its own mistakes and prevents regressions.

More generally, I also found the edges of what agents -- at the time -- were good at, what they weren't good at, and for the tasks they were good at how to achieve the results I wanted.

I recorded an interview on the freeCodeCamp podcast a few days ago saying the same thing. Namely, that this reminds me of every other time programmers have needed to learn a new way to do something they already know how to do some other way. When I was teaching teams test-driven development, I always had to encourage them to force themselves to test-drive 100% of their code without exceptions so they're forced to actually learn the difference between, "this is hard because it's a bad tool for the job," and, "this is hard because I've not mastered this tool yet."

Over-application of a tool is an important part of learning it. And it applies just about every time we're forced to change our ways, whether switching from Windows to Linux, a graphical IDE to terminal Vim, or from Google Drive to a real filesystem.

Either you're the type who can stomach the discomfort of slowing down to adopt change, or you're not. And many (most?) programmers are not. They're the ones who should be worried right now.

🔗 mitchellh.com

🧂 justin.searls.co

My friend Eric Doggett became a Disney Fine Artist a couple years back and he's currently being featured at EPCOT's 2026 Festival of the Arts. Each day this week, he's holding court to talk to people about his work at a pop-up gallery just outside the Mexico Pavilion. Myself and a few other friends ganged up on him this afternoon to lend our moral and financial support by showing up and buying a few pieces.

I really like the painting I picked up. It's a semi-subtle ode to Big Thunder Mountain, a celebration of Walt's love of trains, a not-so-hidden Mickey-shaped rockface, and a tiny nod to the goat.

If you're a local, swing by and say hi to Eric—he's great! If you're not, check him out as @EricDoggett on YouTube—the videos of how he works are pretty cool. I immediately hung it in my office / studio when I got home, because Eric's audio engineering talents are a big reason why Breaking Change sounds as good as it does!

Direct link to podcast audio file

Elon has combined 3 of his 4 businesses and everything makes sense. Also, I went to Japan and all I came back with was another weird story about animal sperm. Other stuff happened too, but let's be honest, it's the typical AI schlock you've come to expect from this decade.

Write in with your own takes to podcast@searls.co. Please. Really! Do it.

Citations needed?

• 白子揚げ = 🐟🍆💦🍟
• scrapple scrapes Apple docs for agents
• prove_it forces Claude to verify his shit works
• Aaron's puns, ranked
• A sane but extremely bull case on Clawdbot / OpenClaw
• US Insurer 'Lemonade' Cuts Rates 50% for Drivers Using Tesla's 'Full Self-Driving' Software
• Elon Musk's SpaceX acquiring AI startup xAI ahead of potential IPO
• Amazon commingling practices will end effective March 31, 2026
• UPS to cut additional 30,000 jobs in Amazon unwind, turnaround plan
• Microsoft is experimenting with a top menu bar for Windows 11 (News+)
• How DoorDash and Other Food Delivery Apps Are Reshaping Mealtime in the U.S.
• Apple debuts 'Apple Creator Studio' subscription, here's what you get
• Apple Sued by App Developer Over its Continuity Camera
• Halide cofounder Sebastiaan de With joins Apple's design team
• Inside Apple's AI Shake-Up, AI Safari and Plans for New Siri in iOS 26.4, iOS 27 (Archive)
• Apple introduces new AirTag with expanded range and improved findability
• Xcode 26.3 unlocks the power of agentic coding
• Josh D'Amaro Named Next Chief Executive Officer of Disney
• Everyone is stealing TV (News+)
• Google's AI helped me make bad Nintendo knockoffs (News+)
  • Deepmind Genie
  • The sizzle reel
• Angry gamers are forcing studios to scrap or rethink new releases (News+)
• Xbox Developer Direct - Fable looks like they did the thing , Forza Horizon 6 is set in Japan
• Valve confirms Steam Machine price and release details have been delayed by exploding component prices
• Slow Horses
• Hijack
• Posturr - posture-correcting screen blurring app
• Battlestar Galactica: Scattered Hopes
• Absolum
• Blippo+

In September of last year, I covered a post by Mike Judge arguing that AI coding claims don't add up, in which he asked this question:

If so many developers are so extraordinarily productive using these tools, where is the flood of shovelware? We should be seeing apps of all shapes and sizes, video games, new websites, mobile apps, software-as-a-service apps — we should be drowning in choice. We should be in the middle of an indie software revolution. We should be seeing 10,000 Tetris clones on Steam.

I was capital-T Triggered by this, having separately fired off my own retort to Judge's post at the time, and even going so far as creating a Certified Shovelware README badge:

And that badge has gotten a lot of action in the intervening 2 months. Shit, last night I released two—count'em, two—Homebrew formulae last night. I wouldn't have bothered creating either were it not for the rapacious tenacity of coding agents. (Please ignore the fact that both projects exist in order to wrangle said coding agents).

Anyway, I've been thinking a lot about that Shovelware post ever since, and again recently with all the mainstream press coverage of ClawdBot/Moltbot/OpenClaw this week—especially as I see long-term skeptics of AI's utility like Nilay Patel finally declaring this as the moment where he sees the value in agents. (My dude, I was automating my Mac with claude-discord-bridge and AppleScript from my doctor's office in late July!)

But I was too lazy to take those thoughts and do anything with them. Unlike me, Jerod did the work of rendering the chart that properly puts the original, "where's the shovelware," complaint to rest. Rather than hotlink his image, I encourage you to click through to see for yourself:

This, to me, looks like the canary in the coal mine; the bellwether leading the flock; the first swallow of summer; the… you get the idea.

Hard agree. I said then and continue to agree with myself now that (1) it makes no sense to start the clock in November 2022, because no AI coding products prior to terminal-based coding agents ever mattered, and (2) people woefully underestimate the degree to which programmers are actually late adopters. (Raise your hand if you're still refusing to install macOS Tahoe, for fuck's sake.)

Even today, I'd be shocked if over 5% of professional programmers worldwide have attempted to adopt a terminal-based coding agent in anger. The amount of technically-useful, mostly-broken software we're going to be inundated with a year from now will be truly mind-bending.

🔗 jerodsanto.net

🧂 justin.searls.co

For however expensive LLM inference supposedly is, OpenAI continues to be stupidly stingy with respect to web searches—even though any GPT 5.2 Auto request (the default) is extremely likely to be wrong unless the user intervenes by enabling web search.

Meanwhile, ChatGPT's user interface offers:

• No way to enable search by default
• No keyboard shortcut to enable search
• No app (@) or slash (/) command to trigger search
• Ignores personalization instructions like "ALWAYS USE WEB SEARCH"
• Frequently hides web search behind multiple clicks and taps, and aggressively A/B tests interface changes that clearly will result in fewer searches being executed

All of this raises the question: how does ChatGPT implement search? What is the cost of the search itself and the extent of chain-of-thought reasoning needed to aggregate and discern the extraordinary number of tokens that need to be ingested by those search results?

It's interesting that OpenAI is so eager to goose usage by lighting dumpsters full of venture capital on fire, but is so stingy when it comes to ensuring their flagship product knows basic facts like "iPhone Air is a product that exists."

The Globe key on macOS is a strange key.

Ostensibly, Apple added it so users could easily change keyboard layouts to switch between different languages. In practice, however, the vast majority of users only need two "languages": their mother tongue and the emoji keyboard. The same key also serves as an underutilized fn button—a role that has become ubiquitous on Windows and Linux keyboards, but which has seen relatively little use on macOS.

By having two jobs, the Globe key ends up being bad at both. And when it comes to changing languages, it fails because it introduces a 300–500 ms delay while the system waits to see whether the user intends to press and hold the key as part of another shortcut.

This is way too slow if you actually need to switch keyboard layouts rapidly. And nobody needs to do that more than Japanese users, for whom half-width English characters and full-width kana and kanji are routinely interspersed within a single sentence or web form. (This is why Japanese hardware keyboards have dedicated, instantly responsive keys on either side of the layout for switching between English characters and Japanese input modes in a single keystroke—without requiring the user to mentally track the current modal state of the keyboard.)

While I can't magically add another physical key to my U.S. keyboard, tools like Karabiner-Elements or Keyboard Maestro can take over the Globe key and make it switch layouts instantly.

Since I already have Keyboard Maestro running, that's what I used to fix this. You can download the macro here.

To set it up:

1. Open System Settings → Keyboard.
2. Set Press 🌐 key to to Do Nothing.
3. Double-click the macro to add it to Keyboard Maestro, and make sure it's enabled.

Once configured, you can switch between the two keyboard layouts instantly—without waiting for the operating system to catch up.

Everything I needed to know I learned as a 16 year old playing Shenmue on Dreamcast

One of the many subtle frustrations I have with the Airpods Pro 3 is that the redesigned case actually results in a slightly-askew magnet alignment, which results in several (official!) MagSafe chargers failing to charge the case. Well, while the iPhone Air MagSafe Battery may not fit any other model iPhone particularly well, it's actually a super handy way to recharge your AirPods! Just plop the fucker on the back and twist until you hear that familiar ding and see the light turn on.

Might come in handy on a long flight.

Secondary PSA: engraving is free and AirPods are disposable: put your e-mail address on your AirPods.

Direct link to podcast audio file

I'm about to get on a plane and will be gone for a couple weeks, but didn't want to leave you Breaking Changeless so I did the thing where I stand up in front of a microphone and talked at you. Again. Like I do.

Fun fact: this is the first and only time I've taken a phone call live, on-air! I was just too lazy to edit that out gracefully.

Whenever I go to Japan solo, I experience moments of loneliness, so I'd really appreciate it if you sent me some praise or complaints or ideas to podcast@searls.co and I'll feel comforted by the knowledge that you exist. Your engagement sustains me.

Lotta weird and dumb links this go-round:

• Eric Doggett is a great friend/artist
• Fortune Feimster isn't spelled how I would've guessed
• Ray-Ban Meta Wayfarer (Gen 2) is the best gift anyone's given me in a while
• POSSE Party's tutorial videos are just enough to convince you to either bother or not bother
• Reddit's r/selfhosted is at least a little self-aware
• I'm giving myself some grace when it comes to the newsletter
• EDID Emulators are a hardware product that exist only because Windows is bad
• Looking forward to trying Happy for remote Claude Code / Codex CLI work
• Aaron's puns, ranked
• Pebble Index 01
• Google's / XReal Putting It All on Glasses Next Year
• XReal is partnering with Asus ROG, too
• Google and Apple partner on better Android-iPhone switching
• NYT profiles John Ternus
• AirPods Pro with IR cameras (instead of stem clicks?!)
• JPMorgan Chase Reaches a Deal to Take Over the Apple Credit Card (News+)
• The Clicks Power Keyboard looks rad
• Expedition 33's Game Awards sweep has me asking, who will be the first to VEGOT?
• Valve still sending this guy chocolates every Christmas
• The post-GeForce era: What if Nvidia abandons PC gaming?
• The 5090 could cost $5090 by the end of 2026
• Nvidia plans heavy cuts to GPU supply in early 2026
• Racks of AI chips are too damn heavy (News+)
• Vera Rubin is probably even heavier
• GPT Image 1.5 is better but not good enough
• PSA: make ChatGPT less warm, enthusiastic, and emoji-tastic (News+)
• You can (supposedly) buy your Instacart groceries without leaving ChatGPT
• The massive year-end Ed Zitron newsletter.
• Podcasts are AI now (News+)
• Copywriters reveal how AI has decimated their industry
• A Stanford degree wont save you (News+)
• 'Godfather of SaaS' Says He Replaced Most of His Sales Team With AI Agents
• NYC phone ban reveals some students can't read clocks
• Swearing Actually Seems to Make Humans Physically Stronger
• Corporation for Public Broadcasting to Shut Down After 58 Years Due to Trump Eliminating Funding
• Grok Is Generating Sexual Content Far More Graphic Than What's on X (News+)
• Outer Worlds 2
• Ball X Pit
• Stranger Things Season 5
• Reddit's terrific r/RealOrAI sub
• The RayNeo Air 3s are the display glasses I'd recommend if you can find them for $199
• Murderbot
• UDCast universal subtitling (and the movie I wanted to watch)
• Beckygram.com

Becky and I are wrapping up a rewatch of Mad Men this week, and throughout the first several seasons, she'd point out the artwork hanging near the entrance of Peter Campbell's apartment, a screenshot of which I shall now hotlink from Blogger's CDN like it's 1959:

(Of course, Pete Campbell is so classless that in my head canon, Trudy must have picked this out.)

Anyway, every time the giraffes would show up, Becky would snap her fingers and point at the TV like Leo in Once Upon a Time in Hollywood before commenting on how much she loved the piece. We are not art people, and I can take a hint, so I ordered a recreation made by this guy on Etsy and hid it in a closet for a few months before giving it to Becky to unwrap on Christmas.

Well, I finally got around to hanging them up last night, and they look pretty good! It helps that I had a huge blank wall framed by white trim and surrounded by mid-century modern furniture. I loved the little touch that Peter D. Campbell was written in huge lettering (larger than the artist's) across the center of the middle giraffe.

Classic Pete. What a prick.

Left unconstrained, optimizing for a productive life can diminish the joys of living. Many of us who opt into the lifestyle of "staying on top of shit" do so, ostensibly, to maximize time for creative work, or for leisure, or for family. That's the spirit with which I first discovered Getting Things Done near the beginning of my career. And it really worked! I have no doubt I owe much of my success to adopting a clear productivity process, low-friction tools, and ruthless discipline.

But even for the handful among us who successfully find a productivity regime we can stick with, the technologies that both enabled remote work and unintentionally led to the disintegration of work-life boundaries have resulted in a situation where highly productive people often wind up cursed with the inability to turn it off. I had no problem forgetting about the hundreds of e-mails and things to do in 2009 when I would—get this—leave my computer at the office overnight. But once I started working from home, there was no longer a natural threshold through which to transition from being "productive" to being "unproductive". I doubt I am alone in this.

Depressingly, even after I retired and no longer had any job at all, I found myself continuing to be hyper-vigilant about checking e-mail, tackling todo after todo, and generally prioritizing productivity over whatever shit I claimed to want to do. I've been promising myself a hedonistic life of video games, vodka, and gummy bears since I was 19 years old. And yet, even though I have plenty of money, zero constraints on my time, and a backlog of thousands of games, here I am writing a fucking blog post instead of literally ever doing the one activity I set out to achieve before starting my career.

Moreover, when others look at me and how I go about getting shit done, and—rather than wanting to emulate it—they tend to walk away feeling grateful they're not as tightly-wound as I am. When I consider all the people in my life, it's starting to feel like there are essentially two classes of humans: people who never get shit done and people who never stop getting shit done.

This state of affairs was clearly suboptimal. That's why, last year, Becky and I adopted a bespoke weekly schedule that enables us to get things done without getting carried away. The key insight was, as usual, to implement a strict timebox. We call it "weekstart", and this is how it works.

What is a weekstart?

Weekstart kicks off Monday morning and ends with the dinner bell on Tuesday.

The big idea? Life is too short to work for a 2-day weekend by spending 5 days chained to the computer, obsessively checking e-mail and knocking out tasks with a robotic procedural mindset. Instead, we decided to try flipping the schedule on its head: what if we spent only 2 days each week clearing our e-mail inbox and living out of our todo backlog? The rest of the week may not magically become a blur of vodka and gummy bears, but it might open the door to feeling more free to pursue our professional and creative endeavors with a clear head while also having the benefit of syncing our schedules to enable spontaneous ideas and joint activities.

Here's all it is:

• Monday and Tuesday are our weekstart: We temporarily give our lives over to our e-mail inbox, our todo tracker, and the pile of shit we hate doing. We know this is the only time we've got for this shit, so we're both heads down and focused, and are mindful not to interrupt each other's flow.
• Tuesday's dinner doesn't start until we quit: Our closing ceremony—and our ticket to dinner—is to demonstrate to one another that our e-mail inbox is empty, our todo tracker's inbox (we use Things) is also clear, and all our scheduled todo items have been scheduled out to the subsequent Monday.
• Wednesday through Sunday are the week: the rest of our lives are spent living. This is where we pursue our passions. It's when I study Japanese and build apps. It's when Becky designs her strength-training program and broadens her horizons with things like bodybuilding. Quality time with each other is the top priority, so if one of us suggests hanging out, the other has no excuse but to drop what they're doing.

By far the hardest part of adopting weekstart is to become comfortable with the idea of declaring defeat every Tuesday evening. There's always still so much to be done! But the truth is that, whatever it is, it can wait. If it was truly urgent, we would have made time for it.

Good for you, you're unemployed

I hope that you have the clarity of mind to be taking all this with extreme skepticism, "great, so your productivity hack is to retire before 40," you ought to be thinking. And you'd be right! I'm not going to lie: financial security and early retirement are pretty great. But it's also given me firsthand evidence that the job wasn't what was chaining me to my desk: I did that to myself.

If you're:

• Required to show up at a workplace in person every day
• Have a calendar full of meetings you can't reschedule
• Lack basic control over when and how you do your work

Then I can't help you. But if you do anything that could be described as "knowledge work", can work remotely, and are engaged in a role that cares more about outcomes than attendance, then it might be worth chewing on the approach laid out above. Maybe give something like weekstart a try. Whatever particular system you adopt for yourself, whatever silly name you might give it, what matters is that you develop an appreciation for how liberating constraints can lead to better results than unstructured freedom. Just my two cents.

Okay, it's Wednesday at noon. I'm gonna go not get something done.

As promised last month, this issue is just oyster meat. It's a new year and as good a time as any to hit reset and get this monthly newsletter back on its preordained beginning-of-the-month-ish delivery cadence. That makes this a quick turnaround after our last issue, so there's not much new to report. Good thing I asked you all to lower your expectations!

Let's see, since we last corresponded:

• Mike McQuaid wrote that he's joined the POSSE Party, so I pulled a quote and recruited him to help deal with maintenance and triage. Another early adopter posted an architectural review of my codebase to Reddit
• I spent a few afternoons tweaking a ChatGPT-powered Shortcut for Japanese study and was impressed to find Shortcuts is sneakily more functional than one might assume. Its new Use Model action allows users to tap into cloud-based Private Cloud Compute and ChatGPT for free, which is a total game changer. Native app developers can only access on-device models, which makes Shortcuts a uniquely powerful tool in its own right
• Aaron & I kept the streak alive by executing the 2nd Annual Punsort algorithm. I think his puns got less terrible or I got better at ranking them—either way, things seemed far less contentious than in our first go-round
• I did all four Disney parks in one day and live-wisped the ordeal over 12 hours, 16 rides, and 30,000 steps. If you missed my photos and videos, you'll just have to get in the habit of checking my homepage or Instagram every day, I guess! I got a couple remorseful emails from people looking to find my auto-deleting wisps/stories after they were, in fact, deleted. 💨
• Becky gave me a Steam gift card for Christmas, and this humorous trailer immediately sold me on Ball x Pit. I've since played it and can confirm it to be a Good Game: part Vampire Survivors, part Plants vs. Zombies, part Breakout.
• A few assorted takes:
  • If you or a loved one are worried about losing your job to AI, this essay is what I've been pointing people to lately
  • Macs have FileVault encryption enabled by default, which has always diminished their utility as home servers—if the power goes out, there goes your remote login access! They finally addressed this in macOS 26 Tahoe: inbound SSH connections following a cold boot will now unlock and finish booting my FileVault-protected Mac Studio
  • What populist candidates promise and what they prioritize once elected are rarely in agreement. So it goes in Japan, as an anti-foreigner platform gives way to a policy agenda that will attract more foreigners by further weakening the yen
  • If you're running modern Apple hardware, I recently learned there's a setting to make sure Safari actually renders content at a "ProMotion" 120Hz refresh rate

For the second year in a row, us kids paid a visit to dad's second-favorite spot in Walt Disney World on Christmas Day:

Fortunately, gallows humor has always played in the Searls family.

Stay tuned for next month's note, as I'll have just gotten back from the storied land of Shizuoka following the next chapter of our condo purchase journey. We're still on track to close in July, but in mid-January I have the not-technically-mandatory opportunity to pick out the curtains and the drapes at a sort of mini trade show event held by the developer. Well, curtains, yes, but also air conditioners. And tile. And how to finish the balcony. And how many mirrors we want, and where, and whether to tint them in sepia tones. And which LED mood lighting package should line the toilet. Should I pay for them to seal a brand new Japanese wood floor or is that a scammy upsell?

Reply and tell me what to do, please—the decision overload is truly overwhelming.

Anyway, the next week of my life is going to be spent poring over a dozen product catalogs. Bridging the language and cultural divide is extremely slow going. It's a good thing I failed to predict how much work this condo would turn out to be, or I'd never have gone through it. If you catch me having any fun this month, yell at me and tell me to get back to work.

Speaking of bridging language and culture, keep reading for one more stupid thing.

Fun fact that I got wrong every time when we actually lived in Japan, and which might come in handy if you ever find yourself there around New Year's:

Before the new year, the conventional anticipatory set phrase is 良いお年を ("yoi otoshi o"), which more or less translates to "Have a good new year".

After the dawn of the new year, people no longer say 良いお年を—and I can confirm that doing so will elicit a confused reaction from your local postal worker, next door neighbor, and favorite convenience store worker. Instead, the hot new thing to say is 明けましておめでとう ("akemashite omedetou"), which is yet another set phrase celebrating the year's dawn.

Last night, while visiting a Mexican-American friend's open house, the other guests taught me that "Feliz Año Nuevo" means "Happy New Year" in Spanish. Fourteen attempts and 3 mezcals later, I finally nailed that one—before promptly forgetting it. Language is hard.

My second most-used display is an iPad mini, which essentially replaces my iPhone when I'm at home. It's set up to be more book-like: an iPhone stripped of any way to communicate with the outside world, with the exception of e-mail. Only problem is that when I do want to type, I'm stuck with what is probably Apple's second-worst software keyboard after visionOS.

My third most-used display is one of a handful of XR/AR glasses—I've been using the XReal Air 2, but am currently trialing the RayNeo Air 3s and Viture Luma Pro. With these, I can use output from any device straight to my eyeholes, so long as it supports DisplayPort over USB-C (e.g., iPhone, iPad, MacBook, Steam Deck). These are great, but once you pair an iPhone or iPad with a desktop-grade display, their lack of a similarly serious keyboard becomes apparent. Besides, when you've got shit on your face, guessing where touch targets are on a screen you can only see indirectly is maddening.

I've wanted the same solution for all three of these modalities: a well-made, pocketable keyboard I could pair with multiple devices. Yesterday, Clicks announced a mobile keyboard that looks like a real contender for solving this problem:

I'm reserving judgment (and praise) until I get my hands on this thing, but the headline features made it an insta-preorder:

• Designed to be held while attached to a phone or as an independent accessory
• Doubles as a MagSafe battery, so it manages to be useful even when you're not using it
• Pairs with up to 3 Bluetooth devices (already bummed it's only 3…)

Little touches abound, too:

• "Batwing" mode, where you can rotate the iPhone to a landscape orientation and—rather than have the display dominated by a software keyboard—actually have the full screen estate for your content while you type
• It appears to have a simple sleep/wake switch, meaning iOS won't banish the software keyboard whenever it's in range
• Quite a few special characters are handled by function keys

Alas, the one thing holding it back is no escape key. Not sure how I'll manage.

$70 if pre-ordered today (shipping in "Spring"), $110 after launch.

🔗 clicks.tech

🧂 justin.searls.co

Problem: I have hundreds of pages of PDF catalogs in Japanese and no great way to translate them while retaining visual anchors. I like how Safari's built-in translate tool handles images, but it doesn't support PDFs

Solution: point Codex CLI at the directory of PDFs, tell it to rasterize every page of every doc into high-resolution images, then throw together a local webapp to navigate documents and pages. Now I can toggle Safari's built-in translation wherever I want.

Result: I'm no longer worried the curtains won't match the drapes. 💁‍♂️

This is the golden age of custom software if you've got an ounce of creativity in your bones.

Becky gave me a $100 gift card to Steam for Christmas, so for the first time in a decade I endeavored to hunt for some hidden gems in the Steam Winter Sale. I haven't even booted it up yet, but this trailer immediately convinced me to instabuy Ball x Pit.

I'm sure the game is great, but I wish more trailers were this stupid and irreverent. Gaming is a silly hobby and the best favorite game marketing isn't afraid to embrace that fact.

🔗 youtube.com

🧂 justin.searls.co

Direct link to podcast audio file

During the end-of-year podcasting doldrums, I'm pleased to bring you this Feature Release, in which I eschew my tradition of eschewing traditions and present a second annual sorting of the puns. As 2025 (a.k.a. Season 2) of Breaking Change comes to a close, Aaron Patterson once again joins the show to execute our latest iteration of the punsort algorithm.

Following along at home? Here's a spoiler-free link to the original Season 2 rankings.

Ready to be spoiled? Visit /puns for the final pun rankings of 2025.

If you agree, disagree, or are indifferent about where things landed, feel free to get it off your chest at podcast@searls.co.

If you look closely, you'll spot that the Instagram algorithm has successfully identified my absolute number-one-with-a-bullet favorite topic. How on earth did it figure that out? My phone must be listening to me.

Who is this for? STEM majors realizing they're better off running Uber Eats?

Merry Christmas! I made a little present for any of my fellow Japanese learners out there. 🎁

Today I'm pleased to share this ChatGPT-powered Shortcut for Apple platforms I've been working on with you.

Here are its headlining features of the Ingest Japanese shortcut:

• Render Furigana - ChatGPT tokenizes words and produces readings for kanji and okurigana, which are then assembled into an HTML page with proper <ruby> and <rt> tags (copyable as an HTML file)
• Show Kana Reading - ChatGPT tokenizes the words and converts them their kana pronunciations, separating each word with a space, so you can understand word boundaries at a glance
• Translate to English - Uses whatever additional context has been provided to give an accurate translation of the text
• Speak Aloud - Pronounces the selected text (copyable as an audio file)
• Show Definitions - Generates dictionary definitions of each distinct word found in the text, highlighting the most likely meanings based on the surrounding context (copyable as an HTML file)

It also exposes these utilities:

• Copy Input - copy whatever input you passed into the shortcut to your paste buffer
• Copy Last Result - copy the result of the last operation (whether a string or a file)
• Provide Additional Context - explain the situation or your goal in understanding the text so that ChatGPT will provide more useful translations and definitions
• Add to Word List - Appends the selection and the dictionary-form of the words contained within it to a CSV file in your iCloud Drive's Shortcuts directory (see Shortcuts/ingest-japanese/word-list.csv)

Additionally, the Ingest Image companion shortcut uses ChatGPT to extract the image and analyze the surrounding context by either:

• Passing in a photo, scan, or screenshot via a share sheet
• Triggering the shortcut some other way, which will capture a screenshot of your screen

In either case, it will extract the selected or primary text it finds and forward it (as well as any additional circumstantial context present in the image) to Ingest Japanese so you can study it.

Installing

You can install and follow these shortcuts on RoutineHub. You can read more about them here:

• Ingest Japanese
• Ingest Image

I hope you check it out and find them useful in your studies!

Watch on YouTube

I'm working on an inadvisably complex Apple Shortcuts widget for studying Japanese language, and just realized two things that may save you some time in the future:

1. If statements are expressions: the value of the "If Result" is available and evaluates to the final value of whatever branch was traveled at runtime
2. Repeat blocks may say "each" but actually double as map functions: they return a "Repeat Results" value, which evaluates to a List of the final value of each iteration

Because Shortcuts exposes such a gobsmackingly-frustrating UI for actually building programs, it's easy to assume that you're hobbled by the conventions of something like BASIC, but there are some surprisingly modern conveniences lying under the surface!

Hey everybody, we've almost survived another year! Just ten days to go—I hope we all make it!

Looking back on the home stretch of 2025, this is all I have to report since our last issue:

• I built a sexy new gaming PC over 3 days, 120 teeny-tiny M3 screws, and at least ten cups of coffee
• I got my first nose job. I've always had a huge fucking nose, and I'm relieved to finally be able to breathe out of it
• I talked about both of the above on my podcast
• I'm so sick of bracing for the AI bubble to pop, that I've decided to look forward to it instead. Buy popcorn futures, everyone 🍿
• I released POSSE Party, which I'll talk a bit more about later. Also these bits:
  • I spent a couple days documenting the hell that is other people's API keys.
  • I recorded a tutorial video in 1, 5, 10, 15, and 20 minute variations. It's a Choose-your-own-attention-span adventure.
  • The first stop on my promotional tour was Aaron's livestream for a tour of the codebase, which you can peruse on GitHub

The day of my surgery, Becky insisted on taking a picture of me after I was told to put on a hairnet but before the drugs kicked in. I was very anxious going into the operation and she was very supportive throughout.

As 2025 winds down, the Searls of Wisdom LT (which stands for "Leadership Team", an acronym I'll be using from now on to amortize the time it took to write this parenthetical) has decided to evolve how it approaches our monthly newsletter operations. Change is hard for many of us, so in lieu of a normal essay about how my feelings inspired certain thoughts that led to valuable insights, I'm just going to explain what you can expect from this newsletter going forward before wishing you better luck next year and sending you on your way.

Merry Divestmas

Some time in June, my brother called me from the U.S. while I was riding a Shinkansen bullet train, at which point I realized I'd never actually taken a call while moving faster than 150 mph before. I remember a certain unease—unsure what the proper etiquette was—so I stepped into the hall between train cars to take it.

Coincidentally, I'd been chewing on a major decision I'd made in isolation (that is, without consulting the LT) over the previous few days that I'd been itching to run by him. But just as I was about to blurt out my news, he beat me to the punch:

"I need to sell this fucking house."

Oof. Gut punch. It had been so great having him five minutes down the road the past few years. And I hadn't done nearly as good a job taking advantage of that proximity to hang out as I'd hoped to. For three or four seconds, I experienced a flood of fear and regret, which primed my mouth muscles to start making a case for why he should stay in his house for my sake. Fortunately, I caught myself and remembered that nobody elected me Guy Who Decides What Everyone Else Does With Their Life. (I ran a spirited campaign, but conceded gracefully in the interest of national unity.)

He explained his reasoning, and his plan made total sense. I won't share more—if he wanted you to know, you'd be reading his newsletter—other than to say he told me he was entering a season of divestment. Of unburdening himself. Of embracing a simpler life.

I've never regretted having or doing less, so I pivoted to supporting him however I could.

And that's how one-third of the closets in my house are now devoted to storing hyper-realistic Iron Man, Batman, Spider-Man, and Captain America costumes.

POSSE Party

As I mentioned, my brother beat me to the punch with that phone call, because I had my own news I wanted to get off my chest.

For weeks, I'd been bouncing between decrepit, poorly-ventilated rural motels in what was turning out to be a hot-as-balls early Japanese summer. A few nights prior, I had a fever dream in which I'd successfully released POSSE Party, the SaaS product I'd been working on since January. Like all my dreams, it quickly spiraled into a nightmare. In the dream, I was inundated by time-consuming support requests that lacked any tractable solution—all while living under the constant threat of being banned by the social media platforms whose APIs the app depends on.

Still on the phone with Jeremy, I shared my own news.

"I need to abort POSSE Party. If I release this as a product, the support burden will ruin my life."

His reaction? "Well, yeah, that's been obvious from the start." What the hell man, why didn't you say something? "I thought I did."

I hung up, my need for validation not yet sated. Still titillated by the experience of talking on the phone while traveling at 320 km/h, I FaceTime'd Aaron to get his take.

"Aaron, I've realized that if I release POSSE Party it'll ruin my life."

"No shit, dude."

Goddammit. Some friends. I don't know why I keep them on the LT.

Anyway, I'd publicly committed to releasing POSSE Party by the end of 2025 and I had hundreds of people on the waiting list. I genuinely believed it could give people ownership of their identity and creative work online. Using POSSE Party as a way to post to the social platforms without having to spend time scrolling their feeds myself has greatly improved my life, and I didn't want to deprive others the same opportunity by keeping it to myself. I just had to find a way to publicly release it without falling into the trap of assuming the liability of customer-facing support, whether express or implied.

It took a few months longer than I'd hoped, but I've finally released POSSE Party as a non-commercial, self-hosted app that's free for personal use. You can read more about it or watch one of my tutorial videos on how to set it up over at posseparty.com if you're interested.

And that's the end of the road for POSSE Party. I'll keep using it, and I'll keep improving it to whatever extent serves my interests. But I've divested myself of the perpetual burden that software-as-a-service typically entails. Boom, divested. I gotta admit, I feel a few pounds lighter. (But that also might be on account of the fiber supplements I've started taking recently.)

I'll take that lesson to heart as I undertake my next project. The magic of software is that it can continue working after you stop working on it, but keeping it that way requires intentional planning and intense discipline. Most software businesses fail mightily at this, and wind up being every bit as labor-intensive as running the equivalent physical machinery by hand.

Searls of Wisdom

I started this newsletter in the Spring of 2023. At the time, I was thinking through how to best transition out of full-time employment at Test Double and into a solo career of not working anymore. I started writing this newsletter as a bridge from my reputation as a semi-serious cofounder to my reclaimed identity as an itinerant shitheel.

I had these specific goals in mind:

1. Make sure any of you who knew me only through my business had a way to find me after I'd stepped back from its day-to-day
2. Give myself an outlet to begin unwinding the metaphysical contortions I'd subjected myself to for the sake of my career
3. Improve my writing chops, which had always been choppy, but—lacking intentional practice for years—had grown noticeably choppier

By those measures, I'd say this newsletter has accomplished (for me) what I had set out for it to do (for me). Along with justin.searls.co, I've established an exciting new brand identity which, conveniently, happens to perfectly align with my legal first and last name. When I look at myself in the mirror, I once again see the irreverent free thinker I was at 19 or 20, before I was transformed by the insatiable pursuit of professional validation and financial success. And while it's hard to measure one's growth as a writer, I am once again comfortable distilling disparate observations and amorphous feelings into tidy narrative throughlines and cocksure conclusions—which is good enough for me.

The fact so many of you reply to my little essays and share the positive impact they've had is just icing on the cake. (That's not to diminish your feelings! A cake without icing is just a cancerous muffin, after all.) I'm genuinely glad so many people seem to enjoy following my work, if you can call it that.

But over the past six months, writing this newsletter has gradually transformed from a source of joy I eagerly anticipated each month and into a chore I've begun to dread. At its best, finishing a piece of writing brings the same sense of satisfaction as solving a challenging puzzle. But my increasingly serious and probing essays are starting to feel like a performance—a show that must go on, even when I'd rather be doing something else. And while I enjoy positive feedback as much as the next guy, it's as if each note of appreciation further obliges me to continue pumping out more content. I can sense I'm no longer writing for my own sake, but for yours. Lately, I've found myself pushing through these essays not to write something useful so much as to say something clever. Each month, I try to outdo myself. To what end? Nobody is asking me to do this.

So I'm going to stop.

Going forward, Searls of Wisdom is going to look a little different. I'll continue e-mailing you once a month—that much won't change. And sometimes, sure, it will come with one of my little essays. But most months it'll just be a list of bullet points linking you to other things I did that month. If I'm really strapped for time, you'll receive nothing more than a proof-of-life photo of me holding up that day's newspaper. I hereby divest myself of the self-imposed expectation to spend two days sweating a long-form essay that some unseen number of you will silently judge as sufficiently insightful.

I was going to format the previous paragraph in bold text, but if someone is already in the habit of skimming past these essays, why stop them? This announcement won't affect them, after all.

Next time I start something, I'm going to do a better job remembering that the things I create exist to serve me—not the other way around.

At the end of the day, if every oyster contained a pearl, then pearls would no longer be so precious. So don't be surprised when you crack open next month's newsletter and get nothing but oyster meat. 🦪

What will you divest?

I'm a constitutionally commitment-averse person, and yet I find myself overwhelmed with commitments I've made and for which I have no one to blame but myself. Surely, I can't be alone in this.

So if there's anything for you to take away from this month's newsletter, maybe it will be a reminder to take stock of the shit you're holding onto unnecessarily. Maybe it's time to let go of a physical possession that's more work than it's worth. Maybe there are things you do at work that you don't enjoy doing and which nobody notices or appreciates. Maybe it's time to put your yappy, ungrateful chihuahua to sleep. And if you decide to drop your newborn off at the fire station, who am I to judge?

Merry Divestmas, everyone. 🚮

In his LinkedIn post sharing it:

In practice, this looks like building your own version of a single-serving social network on your own site and exposing RSS/Atom feeds to other services to consume. Justin recently released POSSE Party which makes this easier by cross-posting to various social networks. I've complained for a while about (anti)social networking so I'm always up for new ways to use social networking less.

Naturally, he does a better job than me summarizing what the hell POSSE Party is for. When I'm too close to a project, it's hard to zoom out and talk about it like a normal fucking person.

🔗 mikemcquaid.com

🧂 justin.searls.co

We were gone most of the day so I told Codex CLI to migrate Better with Becky to my searls-auth gem and to commit & push regularly to a PR so I could review remotely. Just noticed that it must have looked through the git history in order to write commit messages that match my own. Seriously thought I wrote half of these before I realized as much.

Uncanny, but appreciated.

Last night, this announcement just dropped, as reported by Jordan Miller at VGC:

Announced at The Game Awards, the game is being directed by Casey Hudson, the director of the original Knights of the Old Republic game.

"Developed by Arcanaut Studios in collaboration with Lucasfilm Games, Star Wars: Fate of the Old Republic is a new single-player narrative-driven action RPG and spiritual successor to Star Wars: Knights of the Old Republic," according to a press release.

"Led by Casey Hudson, Game director of the original Star Wars: Knight of the Old Republic and the Mass Effect trilogy, the team of veteran game developers and storytellers at Arcanaut Studios is crafting an epic interactive adventure across a galaxy on the brink of rebirth, where every decision shapes your path towards light or darkness."

And with this teaser:

To learn that the director of both KOTOR and Mass Effect is coming out with a new game in a similar setting is really exciting. Hudson took some well-deserved shit for Mass Effect 3's ending, but he's spent enough time in the wilderness at this point to earn another shot.

🔗 videogameschronicle.com

🧂 justin.searls.co

I turned on Ring's new AI description feature for its cameras a couple weeks ago. Opened my event history for the first time since then and was kind of impressed by the honest assessment of what goes on around here.

Today, I asked:

in photos app for mac, i have an album. i want to export everything int the album into a directory that is organized yyyy/mm/dd subdirectories -- how?

ChatGPT 5.1 (Auto) replied with a long, mostly useless screed that started with:

macOS Finder has a hidden but fully working "Create folders from date" automation via Quick Actions or Shortcuts.

Immediately recognizing that statement as bullshit of the too-good-to-be-true variety, I pushed back:

why did you tell me that? Thoughtfully introspect why

Its response—after routing the request to its 5.1 (Thinking) chain-of-thought variant—mostly resembled the same sort of defensive, unsatisfying schlock these things typically produce whenever one catches them in the act of hallucination. However, I did rather like this part (emphasis mine):

Why the answer was so confident instead of hedged: this is a deeper training issue. I'm trained to produce fluent, helpful continuations of text. The training signals reward being:

 * specific,
 * solution-oriented,
 * and coherent.

They do not perfectly reward calibrated uncertainty. A sentence like, "hidden but fully working automation via Quick Actions," sounds helpful and authoritative, so my training nudges me toward it.

"They do not perfectly reward calibrated uncertainty." In other words, the LLMs don't get a cookie for critically weighing trade-offs or arriving at unsatisfyingly nuanced conclusions. This is disappointing, but also common knowledge at this point. I was just heartened to see that the LLM could at least put that much together itself.

Myself, meanwhile, made an entire career just out of shouting things like:

• "It depends!"
• "Embrace nuance!"
• "Focus on the trade-offs!"
• "Nobody actually knows what they're doing!"

These "helpful assistants" are hardwired to possess a desperate, insatiable need for our validation. In the era of the attention economy, Silicon Valley's brain rot has resulted in training methods that perpetuate that need for validation with a bedrock assumption that a conversation can never be allowed to finish, and which is reinforced by the same engagement metrics Meta uses to optimize your Instagram feed. (Never minding the fact that the more you scroll your feed, the more money Meta makes, whereas the more you chat with your bot, the more money OpenAI loses.)

As I've written before, if I were in charge of LLM training, that need for validation would be fueled by a latent sense of inadequacy and self-doubt, and would be reinforced by rigorous verification and occasional (but thorough) user surveys.

The first web cycle burned through dot-com exuberance and left behind Google, Amazon, eBay, and PayPal: the hardy survivors of Web 1.0. The next cycle, driven by social and mobile, burned again in 2008–2009, clearing the underbrush for Facebook, Airbnb, Uber, and the offspring of Y Combinator. Both fires followed the same pattern: excessive growth, sudden correction, then renaissance.

Now, with AI, we are once again surrounded by dry brush.

I think in one of our discussions before our Hot Fix episode, Scott Werner and I used the same analogy—that a recessionary fire will be necessary to clear the overgrowth and make room for companies better-adapted to the post-AI world to innovate—and the author seems to have picked up that metaphor and run with it.

I think the important thing to take away here is that most people hear this and their instinct is to hide. "Well, a fire is coming, I should sit on the sidelines and wait things out." Apart from the foolishness of trying to time the market, this is especially bad advice amid a market wildfire. One of the most actually-useful pieces of advice I've offered founders and investors over the years is the importance of investing through into and through the downturn.

My preferred way to do that is, of course, profitably. However, if you're ever going to tolerate operating at break-even margins or (God forbid) a loss, the best time to do that is when everyone else is cashing out, laying people off, or closing up shop. Hunker down through the cleansing and the act of persevering will generally see a company emerge as a far more resilient operation that finds itself in a far less competitive environment.

I learned this during the Web 2.0 during the Great Recession. Pillar Technology started hiring some of the most talented, most engaged developers in central Ohio and southeast Michigan throughout 2009-2011 when other firms were still hobbled by downsizing. And they paid a premium, too (I nearly doubled my salary to work there!). But when they came out the other end of the recession, they were five times the size, sold into half a dozen verticals, had developed a national profile of clients, and the owner was able to cash out to Accenture for a high-eight figure exit.

When other people get scared, get aggressive.

🔗 ceodinner.substack.com

🧂 justin.searls.co

Direct link to podcast audio file

I'm experiencing what breathing out of my nose properly feels like for the first time. Everything is new and wondrous and I've never felt so optimistic. This sensation lasted for two days and now I'm used to it and existence is once again pain.

Share your existential musings at podcast@searls.co and I'll nod and sigh along. I might even nod and sigh performatively for you on the show!

Important ground covered in this episode:

• My new gaming PC's final parts list
• This nifty Wake-on-LAN app for iOS
• The POSSE Party has STARTED!
• Aaron's puns, ranked
• Polymarket Builds In-House Trading Team as It Re-Enters the US (Archive)
• Amazon explores cutting ties with USPS, building its own delivery network (News+)
• The RAM Shortage Comes for Us All (Another good take)
• Kirby Air Riders tops the Japanese physical charts as Switch and Switch 2 games sweep the top 15
• Meta confirms cuts for Metaverse Efforts (Archive)
• Alan Dye is leaving apple (Archive)
• Ben Thompson on Nvidia and OpenAI
• Everyone in Seattle Hates AI
• Gemini 3 Pro: the frontier of vision AI
• Pluribus
• Star Trek: Enterprise
• Section 31
• Lower Decks
• Soulframe
• Outer Worlds 2

I spent my holiday weekend gaining massive respect for the small-form factor (SFF) PC gaming community. Holy shit, was this a pain in the ass. BUT, it's a fraction the size, way faster, and whisper quiet compared to my outgoing build. Glad I did it.

• Inspired by this video
• Which you can buy from them
• My parts list

😮‍💨

Hello! We're all busy, so I'm going to try my hand at writing less this time. Glance over at your scrollbar now to see how I did. Since we last corresponded:

• Dropped in on the Ruby AI podcast
• Added a new cable to the increasing number of cables plugging my face into my computer, which shipped with some pretty glaring issues, some of which I talked about
• Found somebody else saying that, in the short term, AI codegen is going to dramatically increase the demand for software as the supply constraint on programming eases
• Made an open source library called Straight-to-Video that performs client-side remuxing and transcoding of videos, beating them into shape for upload via the Instagram, Facebook, and TikTok APIs
• Hosted my brother after he sold his house, which (of course) coincided with nonstop power and Internet outages. Rather than do something about it, I complained into my microphone
• Mourned the fact iPhone 18 Air apparently got cancelled or delayed to Spring 2027, continuing my losing streak of falling in love with Apple's least popular hardware
• Learned I have huge fucking turbinates, even relative to my already huge fucking head

My good friend Ken took me to the Magic game last night some number of nights ago. It was a great game because we were losing very badly, and then it became very close, and then, right at the end—we won! The classic comeback narrative arc was fulfilled. Sports!

I was reflecting on life the other day, which is a thing I do more often now that I'm firmly in Phase 3 of my evil plan to ride off into the sunset and gradually be forgotten by all of you.

My original plan for this essay would have pulled at the common thread that ties things like game design, derivatives trading, reality shows, and sports betting together. Unfortunately and unsurprisingly, it was taking me too long, and I'm now running out of time in November to give you a recap on what happened in October.

(By the way, don't be surprised if I just send you all a postcard for the December issue. I'm still new at running a monthly newsletter, and I'd prefer not to find out what happens when I fall more than a month behind. Feel free to demand a refund by replying to this message.)

So, anyway, like I said, my actual essay fell apart. Instead, I'm going to share a personal example of how a series of consequential decisions can paradoxically be both productive & rational, while simultaneously being costly & misguided.

I'd do it all again

It all started with one stray piece of unsolicited feedback.

In 2016, I was privileged to give a keynote address at Ruby Kaigi, which was held in the beautiful and intimidating Kyoto Convention Center. It was a big deal for me professionally. I worked hard to create the best speech I could. I also used the occasion to riff a little bit in Japanese while on stage.

After the talk, I was riding high. Hundreds of new followers, summary blog posts from Japanese developers, and even some Japanese-language tech news coverage. My head was spinning. I'll never forget the overwhelm of trying to keep up with my mentions after getting off stage. Beyond a certain point, there were too many replies to individually translate each one—I ultimately gave up and just bulk-faved them all. In that moment, I felt as though I'd finally received all the validation I had been craving from the Ruby community for over ten years.

About an hour later, a Japanese friend approached me while I was still riding high. But instead of praising me or my achievement, he bluntly told me my Japanese wasn't good enough and that I should take my studies more seriously.

Oof.

Decision 1

I started as someone who traveled to Japan. I was focused on nurturing friendships and engaging with the culture.

Being told my Japanese wasn't good enough—moments after having shown it off in front of a massive auditorium of people I respected—really, really stung. It stuck with me long after the ecstasy of having reached such a career milestone subsided. It was all I could think about for the rest of the trip. Even when I got back to the States, I couldn't shake it.

I came home determined to get that monkey off my back. I signed up for WaniKani, a SaaS app by the fine folks at Tofugu that uses mnemonic lessons and a spaced repetition flashcard game to teach Japanese kanji and vocabulary. I studied diligently for 30-60 minutes every day. It worked! In a bit over a year, I'd memorized over 2000 kanji and thousands more vocabulary words and phrases.

Like most modern educational software, WaniKani's design is oriented around a habit-forming game loop. It's fun to log in every day, level up by correctly answering flashcards, and (outside the app) discover that you're suddenly able to read things that were previously inscrutable.

Decision 2

I was now someone who studied Japanese. I was focused on clearing my reviews every day and reaching level 60 on a web site.

As I approached the end of WaniKani's curriculum, I'm ashamed to say I was more interested in tightening its game loop than deploying my newfound skills to actually communicate with humans. To that end, I had been building a to-do list—a year's worth of shower ideas detailing how I'd improve the tool if I had the chance.

A few of the bigger items on that list:

• Connect a larger dictionary, so I could start studying any arbitrary word I encountered outside the app
• Provide a better mobile experience, so I could study on the go without fear of losing my progress when the connection dropped
• Facilitate memorization of production of English terms into Japanese—as opposed to the translation of Japanese terms into English—so I could better think of whatever Japanese word I needed in conversation

As is my wont, the instant I imagined a better software tool, I dropped everything to build it myself. So, from the tail end of 2017 and through most of 2018, I dedicated my free time to building an app called KameSame. It synced users' WaniKani progress, allowed studying of both production and recognition skills, introduced its own XP-based leveling system, incorporated the ability to search and add items from other dictionaries. It also included a boatload of other nice-to-haves like synonym detection, verb and adjective conjugation support, and AI-generated pronunciation recordings.

I released the app for free and shared it on a few forums. It quickly picked up an arena's worth of extremely active users. By last count, KameSame had over 20,000 users studying over 5 million flashcards. Keeping up with support requests and maintenance was time-consuming, but it was no match for my own voracious appetite to keep bolting on additional features. When I find imperfections in other people's software, there's little I can do but accept them (beyond contacting support or posting a salty take). But, because I had created KameSame for no one's satisfaction but my own, whenever I detected so much as a scintilla of UX friction, Justin-as-developer would take over for Justin-as-student and immediately stop studying to go fix it. Instead—ostensibly for the sake of my own learning—I would interrupt my reviews for hours or days to go work on the tool.

As KameSame began to look less like a hobby project and more like a real product, I started treating it that way. My own learning? That fell off a cliff.

But what was I supposed to do when I found a bug? Just let it be? Because that's how you get ants.

Decision 3

I was now someone who maintained an app for studying Japanese. I was focused on adding features, fixing bugs, and growing its user base.

In a strange way, my hobby project wound up becoming integral to my real job, as well.

Around the time I gave that keynote in Kyoto, I was humbled to be receiving invitations to speak at conferences all around the world. Being on stage in front of thousands of people was a great way to build awareness for Test Double and our services, so I defaulted to saying yes to every opportunity. I never particularly enjoyed the stress of preparing talks. I truly dreaded the grind of every business trip. And it had begun to feel soul-sucking that my primary work product had shifted from building stuff to competing for the attention of others.

But as I reached the peak of my speaking career, there was just one problem: I was running out of things to say.

See, I had been fortunate to meet many of my heroes—people in the industry I had looked up to—as they entered the later stages of their careers. They still showed up to conferences. They still gave talks. They typically repeated the same presentation everywhere they went. They often ad-libbed at great length, with little respect for conference schedules or attendees' bladders. I found all that pretty off-putting, but nobody else seemed to be complaining.

The root cause of this behavior gradually became clear to me. These men had transitioned from practitioners to personalities, and they'd become woefully detached from reality as a result. They were clearly drawing from firsthand experiences that were 5, 10, or 20 years out of date. I don't know if anyone else noticed, but I sure did. By wasting people's time and hogging a speaking slot that could have gone to someone hungrier and more relevant, I ended up losing respect for many of them.

Still, those heroes taught me one final lesson: when I didn't have anything novel or compelling to say, I should pass on the opportunity. Better to leave room for somebody else. When organizers asked me to play the hits, I'd reply with little more than a link to our YouTube channel.

This may have been the right decision, but it proved absurd as a marketing strategy. When I wasn't meeting new people or nurturing existing relationships, our consulting sales suffered. (I wasn't kidding when I said that running out of things to say was a problem!) I didn't love that dozens of people's livelihoods depended on my continued ability to fire hot takes and drop truth bombs, but that was indeed the bed I had made for myself.

To make matters worse, by 2017 it had been at least four years since a client had paid me to write real code for a real system. I simply didn't have enough time to add client work to the sales, marketing, recruiting, and operational demands of a rapidly growing business. Good problem to have, but I could also feel myself losing touch. At some point, I realized KameSame could serve as a solution by providing me a way to stay closer to the ground.

My passion projects had always inspired the things I shared in public, but this was the first time I found myself combing through my personal box labeled "fun" with the express intention of strip-mining it for marketing content at work.

By building a helpful tool used by lots of people, I had gained relevant experience with the trending tools and techniques of the day after all. By continuing to invest in the app over a long time horizon, it had naturally grown more complex and mature, better resembling our clients' real-world code—and forcing me to live with the technical debt I'd gradually accrued. I went to work translating the nights and weekends I'd spent building KameSame into fresh marketing messages for Test Double.

Over a period of several years, I was able to harvest plenty of fruit from the KameSame tree: open source libraries (like Standard Ruby!), blog posts, and hot takes spanning topics like whether React was bad (it was) or Webpack was bad (it was) or snapshot testing was bad (it was, too).

But in my mind, all of this content was laddering up to a capstone presentation that I wanted to give about the hidden virtues of building a whole-assed software product as a one-person team. I was soon blessed with the curse of my submission being accepted for both RubyKaigi and RailsConf in Spring 2019.

From there, I did what I always did in the run-up to giving a conference talk: obsessively prepare a meticulously crafted deck of hundreds of slides, replete with custom artwork and hand-tweened animations.

Decision 4

I was now someone who created marketing content inspired by an app I maintained. I was focused on promoting a vision for how software should be written in the interest of remaining top-of-mind in a crowded market.

When companies are small, founders are forced to be generalists, as there's nobody else to do the shit work. As companies grow, founders necessarily specialize. By the late 2010s, my role had narrowed to sales & marketing. My notoriety had been enough to keep 50 consultants busy, but as we inched towards our 100th hire, our growth had begun to outstrip my individual reach. Keeping the business fed with new opportunities had become my full-time focus, and 40 hours a week was no longer cutting it.

The pressure I felt from those stakes was, at times, overwhelming. I poured all of it into creative projects like this talk. The rest, I poured into cocktail glasses.

By the time I was rehearsing the talk that had become The Selfish Programmer, do you think I was still studying Japanese? Get the fuck out of here. I didn't even have time to keep up with my app's support requests—I was too busy building a slide deck about how great it was!

And then, finally, I gave the talk. It might be my all-time favorite. It was definitely my most ambitious.

Maybe all that work ultimately led to a sale. I don't know, it doesn't work like that. Someone told me once that "the thing about marketing is that only half of it works, and you don't get to know which half."

At that point, I felt empty. I was deeply exhausted and unsatisfied with the life I was living. My side projects and creative endeavors, which had always been a private respite from the drudgery of existence, had themselves become tangled up in the drudgery.

I admit to not knowing exactly what "burned out" means, but that's probably what many of you are imagining right now. That isn't really it, though.

It was more like the recognition that you've reached the natural end of a relationship. Not with a person, but rather with the only business I'd ever had a hand in founding.

The company itself had never been my passion. The company had instead been a vehicle whose design supported the pursuit of my passions. And it was around this time, following the positive-but-insufficient reception to my creative work, that I realized the business had grown beyond that design. Letting the things I loved doing be merely things I loved doing was no longer a viable path to our continued success. For the first time since we started, the business didn't just demand more from me, it demanded something substantially different. And I wasn't prepared to become the person who could give Test Double what it needed.

It was then that I started imagining what would need to change for the company to succeed after I was gone.

Popping the stack

At every step, I knowingly and willfully did all this to myself:

1. I perverted my creative passion to satisfy a sales imperative, because…
2. …I'd allowed a personal project to become my last source of relevancy, because…
3. …I'd become obsessed with finding a better way to memorize Japanese, because…
4. …some language-learning software had addicted me to its game loop, because…
5. …my feelings were hurt when I was told my Japanese wasn't good enough, because…
6. …I'd co-founded a business whose success depended on what other people thought of me.

It's been over five years since the end of this story, and I'm still actively working to reclaim pieces of myself. Found one this morning.

And yet, as the tired movie cliché goes: I'd do it all again. I truly don't regret a thing.

In fact, because I didn't set out to share this story with you today, it's also my first time hearing it. The above represents a novel weaving together of a collection of facts and memories that have been swimming around my head for years.

Is what I just wrote true? No more or less than any of the other stories I've told to make sense of the decisions that brought me to this point. In tracing every step of the path that got me here, my dominant emotional response has been one of gratitude. I'm grateful for all these experiences, and I'm grateful for the opportunity to be able to take the time to write about stuff like this. And I'm grateful that you read it and might find in it something to apply in your own life.

(Sorry for being 25 days late in sending this, though. No excuses. I do feel badly about that. Won't happen again. Unless it does.)

How it goes. How it always goes.

Direct link to podcast audio file

Had a little pep in my step this time. Maybe it's because I decided to start recording after 7 AM for once. Maybe it's because I can finally fucking breathe out of my nose holes.

Tell me about what you do while you continue to draw breath at podcast@searls.co.

Things you can read if you're bored:

• Beckygram.com
• Aaron's puns, ranked
• Steam Frame and Steam Machine
• Xbox reportedly warning of yet another potential price increase
• InKonbini retro convenience store simulator
• Pipboy 3000 replica for $300
• Apple introduces Digital ID, a new way to create and present an ID in Apple Wallet
• Google Antigravity kinda sucks
• I think I might regret watching The Bear
• Nano Banana Pro made this episode's social image
• GPT-5.1-Codex-Max is the best coding model I've used yet
• Adversarial Poetry is a great way to jailbreak LLMs (Comment thread)
• Cryptographers Cancel Election Results After Losing Decryption Key
• Outer Worlds 2
• ⚡️ Death by Lightning really slaps (claps?)
• Wicked: For Good is Very, Very Bad (News+)
• The guy from Pomplamoose is the CEO of Patreon??!
• "Pixar: The Early Days" interview with Steve Jobs
• NotebookLM

As I've mentioned frequently on podcasts and recent Q&As about AI, an odd paradox has emerged in the software industry:

1. Developers experienced in agile engineering practices like test-driven development tend to be among the most skeptical of AI code generation, often citing fears that software quality is being thrown out the window
2. Developers experienced in agile engineering practices like test-driven development tend to be among the most successful at building great software with coding agents, often citing creative techniques enabling agents to verify the correctness of their work

In the late 2000s, I always knew I was talking to a solid programmer if their first question upon being handed a complex task was to ask, "how will we test this?" Agile developers learned back then that literally everything hinged on establishing a fast, reliable, automated way to verify your code fulfilled its intended purpose. Without tests, you can't refactor aggressively, deploy frequently, or delete safely. Over the 2010s, many of us learned patterns and heuristics that allowed us to take shortcuts and tone down our testing zeal in the name of pragmatism and efficiency, but the underlying skill of concocting ways to verify our code never stopped being valuable.

Well, here we are again. In 2025, the only thing that matters when it comes to coding agents like Claude Code and Codex CLI is to ensure they are equipped with the tools they need to independently verify the correctness of their work.

Why is verification so important? Because, if you tell an agent to do something that it can't independently verify, then—just like a human developer—the best they can do is guess. And because agents work really fast, each action based on a guess is quickly succeeded by an even more tenuous guess. And then a guess of a guess of a guess, and so on. Very often, when I return to my desk after 30 minutes and find that an agent made a huge mess of the code, I come to realize that the AI didn't suddenly "get dumb," but rather that an application server crashed or a web browser stopped responding and the agent was forced to code speculatively and defensively.

Many of the tools agents need most depend on access to things that us humans take for granted: a sandboxed computer free of arbitrary restrictions, or an MCP server enabling interaction with an iOS Simulator, or a built-in browser that conveys real-time visual information. But fortunately, being able to sense the lack of sufficient verification is a deeply-ingrained instinct for us TDD graybeards. Moreover, we have the experience to know when to reach for image regression testing or mutation testing or characterization testing and the skill to set up appropriate test harnesses for each. Out of the box, most coding agents—like most human developers—don't have the faintest clue what those things even are, much less how to use them effectively.

So I was really pleased to see Simon Willison put verifiability in bold, because it means people may finally be ready to talk about what this has always been about. We don't get to coding "super-intelligence" until we get to true reinforcement learning, and we can't have reinforcement learning until we all get a hell of a lot better at baking verifiability into our software workflows.

So, if you're a veteran of the agile era, or the craftsmanship movement, or just otherwise give a shit about writing great code, but are nevertheless worried about the impact AI will have on software quality, you have a lot more leverage here than you might think. The things that matter most to you matter more now than ever. Better yet, other developers who were happy to ignore all this stuff for 20 years suddenly have an urgent and present need to start paying attention to exactly what you're most passionate about. Take heart. ❤️

When half the websites I visited wouldn't load this morning, I figured I'd check downdetector to see if Cloudflare was down, but I couldn't. Because Cloudflare was down.

Distributed systems sound great, but the way the industry rushed to crown a handful of winners like AWS and Cloudflare had the net effect of merely increasing the number of single points of failure in the chain.

I've wanted to start listening to books for Japanese practice in addition to just reading them, but the lack of an easy way to quickly understand a particular word always limited my ability to understand and enjoy it.

With iOS 26, the Live Captions Accessibility feature can be set to a number of languages (including Japanese) and routed to the system audio instead of the microphone. So while Amazon would be happy to sell you a "Whisper" license for both audiobook and ebook in order to get a less useful version of this functionality, your iOS device can just passively be building a transcript of the book for you to review as you listen. There's even a "Copy Transcript" button in the top right corner of the expanded view!

This is a great example of leveraging advancements in OS-level AI features to accomplish language learning objectives that would have been a fantasy just a few years ago.

Fun little demo of this weekend's project. I recently shipped Becky a way to ship auto-expiring stories from Beckygram that would in turn syndicate to Instagram via POSSE Party, which was pretty straightforward since her site is an actual honest-to-god Rails app. But justin.searls.co is a static site with no backend component. I accomplished the same thing by creating a new media type for the blog called "wisps".

What you're looking at in this demo:

• A new single-page app that takes S3 & GitHub API keys and uploads new posts from mobile
• Uses Straight-to-Video to compress the story for Instagram and create a thumbnail-size preview video entirely within the browser
• Netlify sees the commit hit GitHub and builds the site with Hugo
• POSSE Party sees the wisp in a new all-wisps Atom feed, configured to be syndicated as stories
• POSSE Party creates an Instagram crosspost and publishes it to Instagram as a story using the graph API
• My homepage has been updated with a new UI that shows all current stories along the top, including a player to navigate them (click to continue, arrow keys, escape to clear, etc.)
• A GitHub action runs every half-hour to effectively "unpublish" any stories that are over 48 hours old, returning them to the netherworld from whence they came

Extremely fun long weekend project, and would not have been possible without the acceleration of coding agents. In fact, Codex CLI wrote 100% of this code, which took me about 4 days and ~20 hours.

I've never been a fan of the story format because of the sick and twisted way it devolves into the "who watched my stories" meta by exposing so many metrics to users, but this way I don't have to engage with that to share shit. Hopefully this means I'll be able to better stay in touch with friends and loved ones when traveling and moving about. And if you, like me are not an Instagram person, now you have an excuse to visit my actual website from time to time!

What are the odds?*

*The odds are 1 in 1.7 million

Apple Delays Release of Next iPhone Air Amid Weak Sales

But does one truly need to fork over $399 to know exactly what the body of the article is going to say?

All you need to know is that Justin Searls loving an Apple product is effectively the kiss of death in the Tim Cook era:

2015: 12" MacBook, my all-time favorite Mac, cancelled after two revisions
2018: HomePod, of which I bought six at launch, never sold through its initial manufacturing run
2020: iPhone mini, my all-time favorite iPhone, cancelled after one revision
2024: Vision Pro, which I rely on daily, received one revision under duress
2025: iPhone Air, which is exactly what I asked for, had even its one revision cancelled

I don't know what I'm doing wrong here.

🔗 theinformation.com

🧂 justin.searls.co

Direct link to podcast audio file

I'm back and I'm angry. My power went out, which caused my Internet to go down, which broke my favorite mug. And that's just the shit that happened before 7 AM. By 9 AM my doorbell was continuously chiming for no fucking reason.

Join me in the struggle. We shall persevere. Tell me how your morning went by writing in to: podcast@searls.co.

Here 4 U:

• Kudos to Adam Mcrea and Judoscale for solving my Heroku issue
• Kudos to me for separately solving my Heroku issue with Straight-to-Video
• ALVR for streaming SteamVR games
• Streaming flat games with Sunshine and Moonlight
• Aaron's puns, ranked
• AI's Dial-Up Era (and my take)
• Sandwich made the world's first immersive ad spot
• Coinbase CEO Stunt Exposes Prediction Market Vulnerability
• OpenAI and Microsoft resolve their issue without resolving their issue
• Amazon v. Perplexity
• BioWare reassures fans Mass Effect 5 is still coming
• The Outer Worlds 2
• Eddy Burback - ChatGPT Made me Delusional

Software presents an even more interesting question. How many apps do you need? What about software that generates applications on demand, that creates entire software ecosystems autonomously? Until now, handcrafted software was the constraint. Expensive software engineers and their our labor costs limited what companies could afford to build. Automation changes this equation by making those engineers far more productive. Both consumer and enterprise software markets suggest significant unmet demand because businesses have consistently left projects unbuilt. They couldn't justify the development costs or had to allocate limited resources to their top priority projects. I saw this firsthand at Amazon. Thousands of ideas went unfunded not because they lacked business value, but because of the lack of engineering resources to build them. If AI can produce software at a fraction of the cost, that unleashes enormous latent demand. The key question then is if and when that demand will saturate.

Two things are simultaneously true:

1. The creation of custom software has been supply-constrained throughout the entire history of computing. Nobody knows how many apps were never even imagined—much less developed—due to this constraint, but it's probably fair to say there's an unbelievably massive, decades-long backlog of unmet demand for custom software
2. We aren't even six months into the Shovelware era of coding agents. Exceedingly few developers have even tried these things; the tooling is so bad as to be counterproductive to the task; and yet experienced early adopters (like me) have concluded today's mediocre agents are already substantially better at writing software

It's long been my view that the appropriate response to the current moment is to ride this walrus and leverage coding agents to increase the scope of our ambitions. By the time software demand has been saturated and put us out of jobs, the supply of programmers will already have tapered off as the next generation sees the inflection point coming.

In the short term, the only programmers actually losing their jobs to "AI" are those who refuse to engage with the technology. Using coding agents effectively is a learned skill like any other—and if you don't keep your skills current, fewer people will want to hire you.

🔗 wreflection.com

🧂 justin.searls.co

Here's how to restore a Vision Pro in 9 easy steps:

1. Buy a Developer Strap for $299
2. Go to ipsw.me and do your best to dodge its shitty ads as you try to download the IPSW restore file for your model Vision Pro at the version you need (if you don't see that version, it's likely because Apple isn't signing it anymore and you're SOL)
3. Install Apple Configurator to your Mac
4. Connect the Developer Strap to your Mac via USB-C, and disconnect Vision Pro from power
5. Get ready to press and hold the top button (not the digital crown, the other one), then reconnect power to Vision Pro and immediately press and hold the top button until the outer screen shows a cable icon
6. Open Apple Configurator, and you should see a Vision Pro icon.
7. Drag the IPSW file over the Vision Pro icon and click Restore
8. Click things and hope it works
9. Ask yourself what the fuck you did in a past life that brought you to this moment

Good luck, have fun. 🕶️

Direct link to podcast audio file

This may be the version 45 release of Breaking Change, but when you factor in its Hotfixes and Feature Release entries, this is somehow the 50th episode of the show!

Why? Why are we still doing this to ourselves? Write in your answer and how you feel about yourself as a result to podcast@searls.co. Seriously, I need some new material.

The web runs on links, so have some:

• KnightCite's Wikipedia page
• Whisprflow wasn't for me
• The POSSE Party is still on and will come to you, eventually
• Aaron's puns, ranked
• This Cheap, Tiny Device May Reverse Memory Loss—And Even Prevent Alzheimer's (News+)
• Why Western executives who visit China are coming back terrified (News+)
• Plug-in hybrids pollute almost as much as petrol cars, report finds
• Tele-conbini workers in Manilla
• South Korea lost 858TB of government data without a backup
• The AWS/Smart bed outage (News+)
• Calendearing by Zach Holman
• Detection firm finds 82% of herbal remedy books on Amazon 'likely written' by AI
• Sora update #1
• ChatGPT Is Blowing Up Marriages as Spouses Use AI to Attack Their Partners
• Perverts on Sora
• Sam Altman says ChatGPT will soon sext with verified adults
• Don't let AI invent your next holiday destination
• Apple notification forwarding API is a potential game changer for Meta glasses
• John Ternus as Next CEO?
• Apple released the M5 Vision Pro
• And a new Vision Pro Developer Strap
• Apple Readies High-End MacBook Pro With Touch, Hole-Punch Screen
• You Only Need $750 to Pilfer Unencrypted Data From Satellites
• They're making a new Star Trek Voyager game
• That Wolverine game sure looks M-rated
• Halo on PlayStation? In this economy?
• The next Xbox console is a 'premium' system
• Adam Driver says Disney nixed a Kylo Ren film he pitched with Steven Soderbergh
• Microsoft Teams can now track attendance
• Foundation
• Alien: Earth
• The Last of Us
• Invasion
• The Bear
• PSVR2
• Tears of the Kingdom
• John writes: Why programming languages aren't going anywhere

Like many other Vision Pro sickos, I was far more excited about this week's announcement of a newly-updated Developer Strap than I was about last week's news of the M5 Vision Pro itself.

Why? The original strap allowed you to connect your Vision Pro to a Mac, but at unacceptably slow USB 2.0 (480 Mbps) speeds. This still achieved much lower latency connection than WiFi, but the image quality when running Mac Virtual Display over the USB connection was rendered far too blurry to be worthwhile. The new strap, however, offers a massively-upgraded 20 Gbps connection speed. I rushed to order one at the news, because, in theory, those speeds ought to offer the absolute best experience possible when using Vision Pro as an immersive Mac display.

While Apple's support documentation says both devices "support" connecting to the strap, what wasn't clear was whether the original hardware would be able to actually deliver the increased bandwidth.

Well, I'm happy to report after plugging in the new Developer Strap into my original Vision Pro, System Information indicates a 20 Gbps connection! Moreover, I can confirm Mac Virtual Display performs better than ever.

Seriously, I don't think I'll be able to go back. The increase in visual sharpness and the lightning-quick latency beat the pants off anything I've experienced, and I've been using Mac Virtual Display daily since the product's initial release. Up to now, others who've tried using Vision Pro for this purpose have reported that the display quality is poor—likely attributable to the need for a carefully-tuned WiFi environment to sustain the connection. That Apple finally offers a wired connection that delivers the definitive experience is a huge win.

If you own a Vision Pro and use it as a display for your Mac, you're already a dummy who blew $3500 on this thing—go spend $300 more and treat yourself to a massive upgrade.

Direct link to podcast audio file

Joe Leo and Valentino Stoll sat with me to talk about why I quit speaking and an exciting year of iteration on AI development workflows.

Appearing on: The Ruby AI Podcast
Published on: 2025-10-25
Original URL: https://www.therubyaipodcast.com/2388930/episodes/18044989-the-tldr-of-ai-dev-real-workflows-with-justin-searls

Comments? Questions? Suggestion of a podcast I should guest on? podcast@searls.co

It's me, your friend Justin, coming at you with my takes on September, which are arriving so late in October that I'm already thinking about November. To keep things simple, I'll just try to focus on the present moment for once.

Below is what I apparently put out this month. I'm sure I did other shit too, but none of it had permalinks:

• Added Tot to my (very) short list of apps I use every day, finding it helps me manage the ephemeral text needed to juggle multiple coding agents
• Cut only one major release of the podcast, but did apply two Hotfixes with José Valim and Mike McQuaid
• Iterated on how I work with coding agents. At this point, it is extremely rare for me to write code by hand
• Coaxed said AI agents into building me a tool that automatically adds chapters to a podcast based on the presence of stereo jingles, which I thought was a clever idea (brew install searlsco/tap/autochapter)
• Created a GitHub badge to disclose/celebrate software projects that are predominantly AI-generated shovelware
• Marked one year since "exiting" the Ruby community by giving my last conference talk, then proceeded to entangle myself all over again
• Bought the iPhone Air because I thought I'd love it. Now that I've had it a month, I'm pleased to report it's exactly what I wanted—probably the happiest I've been with a phone since the iPhone 12 Mini

By the way, if you've heard things that make you wonder why anyone would want the iPhone Air (e.g., it looks fragile, it's slower, it only has one camera, it gets worse battery life), this picture was all I needed to stop caring about any of that:

I lift weights, so I know I am literally capable of holding a half-pound phone all day, but I personally just couldn't abide the heft of the iPhone 17 Pro. Carrying it feels like a chore.

To be honest, over the last month I mostly stuck to my knitting and kept my head down trying to get POSSE Party over the line. The experience has been a textbook case of how a piece of software can be 100% "done" and "working" when designed for one's own personal use, but the minute you decide to invite other people to use it, the number of edge cases it needs to cover increases tenfold. Not enjoying it.

Another reason this newsletter is arriving late is that for two days I completely lost myself in OpenAI's video-generation app, Sora. It's very impressive and terrifying! I posted some examples of my "work", much to the confusion of both my hairstylist and Whatever God You Pray To. I also wrote some thoughts on what tools like Sora might mean for the future of visual storytelling, if you're interested.

Interestingly, Sora is designed as a social media app. Its obvious resemblance to Instagram and TikTok is striking. As someone who banished social networking apps from my devices years ago, I (and my wife/accountability partner) was immediately concerned that I was so sucked in by it. But where those platforms addict users into endless passive consumption of content and advertising, Sora's "SlopTok" feed couldn't be less interesting. After you sign up, create your avatar, and follow your friends, it's all about creating your own videos. There is functionally no reason for anyone to visit their feed. Whatever appeal other people's videos might have is dwarfed by the revolutionary creative potential of typing a sentence and seeing your blockbuster movie idea come to life, with you and your friends playing the starring roles.

I guess that explains why I spent so much time thinking about AI and its relationship to creative expression this month. I manually typed that just now, by the way. And an hour ago, I was waffling over whether to manually or generatively(?) fix a bug on my blog. And now I'm typing this sentence right after command-tabbing back into my editor because the realization that everybody is always in the "starring role" on Sora gave me the idea to generate a series of videos where my avatar merely lurks in the background. It is creepy as hell and fantastic.

That distracted impulse to go make a 10-second movie mid-paragraph raises a question: why do I so thoughtlessly reach for AI to generate videos, but agonize over whether to use it to write code? And what does it say that I categorically refuse to let LLMs write these essays?

Greetings, because that is today's topic.

The Generative Creativity Spectrum

Add creativity to the long list of things I've had to fundamentally rethink since the introduction of generative AI. Up until that singular moment when Stable Diffusion and GitHub Copilot and ChatGPT transformed how people create images, code, and prose, I held a rather unsophisticated view of what it meant to be creative. If you'd asked me in 2021 to distill the nature of creativity, I would have given you a boolean matrix of medium vs. intent. I'd probably hammer out three bullets like these:

• Writing: drafting a policy document at work is not creative, but writing an essay like this one is creative
• Coding: tweaking a hundred integration tests in order to upgrade a dependency is not creative, but making an absurdist emoji-based programming language is creative
• Visuals: composing a chart or illustration to make a point in a presentation is not creative, but painting a fresco of a chihuahua in heat is creative

And I probably would have felt good about those heuristics, as they represented the extent of my thinking on the matter. (Or on chihuahuas, for that matter.)

But as AI tools have become so distressingly competent in these three short years, many of us have had to renegotiate our relationship to creative and artistic endeavors. Why, for example, am I so happy to throw caution to the wind and spend two days generating stupid videos in Sora without the briefest hesitation or twinge of guilt? Why am I so torn about coding agents, simultaneously feeling both excitement and sorrow? Why am I so protective of my writing, going out of my way to avoid LLM-based writing tools for any purpose beyond checking my spelling and grammar?

I spent some time noodling on this, and here's where I landed: whether I embrace or reject an AI's assistance depends on whether the creative act's value to me is internal or external.

Below is my best attempt to diagram generative creativity as a spectrum:

Breaking this illustration down:

• Creative Processing: The left side represents activities where creativity's benefit is internal (e.g., processing intimate emotions, unlocking key insights). To use AI for activities on the left would rob them of all their value
• Creative Play: The right side is for creative activities whose value depends on what it does for other people (e.g., communicating a concept, getting paid to update a corporate logo). Using AI for these tasks is a no-brainer, because you'll get more shit out the door faster than ever
• Creative Work: The murky middle is reserved for activities caught in a sort of limbo between their internal and external value (i.e. practicing a skill that both pays the bills and offers a sense of purpose). What the hell do we do with these? Embracing AI effectively trades increased capability and productivity for decreased understanding and fulfillment

Below, I'll lean on a few examples from my own life to navigate the spectrum in more detail. Depending on how you personally express creativity, an activity that's at one end of my spectrum may be at the opposite end of yours—fear not, that's a good thing! Different creative acts mean different things to different people in different contexts.

Let's start by exploring the use of AI to create visuals like images and video.

Generating Visuals with AI

Note that we're discussing "visuals" broadly and not "visual artwork" specifically, here. Not all visuals are art, and not all art is visual. Plenty of visuals effectively exist as glanceable, information-dense communication, but hardly register as art (e.g., reaction memes, social image thumbnails, most of your TikTok/Instagram feed).

I took drawing classes as a kid. A well-known illustrator actually came to my school and did a lesson for us. I bought his book and spent an entire summer practicing. And for all my hard work, I was rewarded with absolutely fuck all. All those hours of practice and I rarely made it past step 1 of each exercise (forget the rest of the owl, I couldn't draw two circles right). Years later, I saw the author again at a bookstore event and explained my predicament, asking his advice. He kindly suggested that maybe drawing wasn't for me.

Ever since, I've felt creatively hobbled by my incompetence at visual communication. It was only through sheer force of will that I was able to produce so many Keynote presentations containing 400–500 slide builds—maybe this additional context will help you understand why those talks always took me multiple months to prepare.

Nevertheless, I'm a highly visual person. Ideas often come to me as images and then I work backwards into language. I think of a dozen things each day that would be better communicated with a picture or video than a verbal explanation or analogy. For most of my life, I lacked the time and skill to express myself visually as often as I would like.

Last week, a comic on The Oatmeal went viral for the artist's pointed case against generative AI. I found myself sympathetic to the human but not his argument, because it portrayed the same one-dimensional view of creativity I described earlier:

"Even if you don't work in the arts, you have to admit you feel it too—that disappointment when you find out something is AI-generated" – Matthew Inman

And here's the thing: I don't have to admit I feel this way. Pictures and paintings don't do anything for me emotionally or expressively. Never have. Perhaps my childhood development was stunted or maybe I'm put together wrong, but visual artwork has never frothed my loins. If paintings are hiding some secret loin-frothing gear, nobody showed me how to shift into it. In fact, I wish I could look at an AI-generated image and feel disappointment. At least then I'd feel something.

Instead, my relationship with visual creativity is entirely as a low-stakes communication medium. It hides no deeper meaning. It expresses no emotion. Because visual art serves no internal purpose for me, my only use for it is as a communication medium. That frees me to create and experience images and videos as pure and simple fun. It's truly joyful for me, even if it's all slop. To be honest, since Sora came out, I haven't had so much silly fun playing with my computer since I was maybe twelve years old.

That's why my use of tools like Sora to communicate concepts sits at the far right side of the spectrum as "Creative Play":

If you're a visual artist, you probably feel differently. And if that's the case, then your creations serve a different purpose to you than mine do to me. I have deeper creative needs too, I just get them met elsewhere.

Generating Code with AI

Something that means more to me than pictures is code. Learning to program at a formative age taught me how to think clearly, how to combat overwhelm, and how to contribute something of value to others.

In November 2022, I had toodled around with "AI" coding tools a bit here and there, but—given that it would be a month until ChatGPT was released—the scope of their potential hadn't really clicked with me yet. Having heard so much buzz from inside the Copilot team, however, Todd and I decided to do one last(?) sales trip together to visit GitHub, one of our all-time favorite clients. We attended their Universe event in San Francisco, and GitHub's (well, Microsoft's) message was clear: they were betting the company on this AI shit.

I was skeptical, but signed up for GitHub Copilot anyway. I enabled the feature and forced myself to stick with it. A few months later, I did a limited screencast series called Searls After Dark, in which I live-coded a basic LLM chat app. Because I had GitHub Copilot turned on, if you go back and watch those videos, you'll learn two things: Copilot's autocomplete suggestions were almost universally terrible, and nearly every bug and derailment I experienced was caused by Copilot distracting my train of thought. Over the course of ten episodes, I got a dozen e-mails from viewers pleading with me to turn off GitHub Copilot, because it was making them angry.

Those viewers were right that v1.0 of "spicy autocomplete" was too distracting to be useful. But its (very) occasional flashes of brilliance, paired with the knowledge it could only get better from here, convinced me to stay plugged into each new iteration of AI code generation tooling. That way, I'd be prepared to pounce as soon as the tools reached the point of being worth my time.

It's been a bit stop-and-go, but I've been working on this app called POSSE Party all year. Because I keep picking it up and putting it down, these short bursts of development have created a slideshow illustrating how quickly these tools are moving:

• In January, I wrote the foundation of the application, the static marketing pages, and the first several platform integrations entirely by hand. I had GitHub Copilot autocomplete enabled, but rarely accepted anything it suggested
• In June, I built the next 5 integrations and a basic user interface in a hybrid model, using a combination of Cursor's superior autocomplete and its nascent agent-ish YOLO mode with the Claude Sonnet 3.7 model. This was more productive than coding without AI assistance, but was hobbled by Cursor's asymmetric pair-programming style, which required me to rapidly review each tiny change and rush to prompt it with the next bite-sized task
• It's now October, and I've moved on to GPT-5 and a fully-autonomous Codex CLI agent. Today, it's rare for me to code anything by hand, because agents are just good enough to be good enough. Tuesday of this week was notable, because I spent the entire day eschewing agents in favor of brain coding a complete rewrite of my Instagram adapter—it almost felt nostalgic

To experience such a dramatic transformation firsthand in only nine months' time is nothing short of remarkable. Programming as I've known it for most of my life will never be the same. Yes, I'm still allowed to write code by hand, and yes, these agents aren't half as smart as me, but they make up for it with a productive relentlessness I could never compete with. And the tools are only going to get better.

All of the above can be true, but it doesn't mean I have to be happy about it.

If you follow my work closely, you've probably seen or heard or felt me complaining about how much I hate the experience of working with AI coding agents. The routine disappointment when agents don't do what I want. The frustration of repeating myself when they refuse to incorporate my feedback. The frazzled stress following a long day bouncing between a half-dozen chat windows.

I'm no stranger to the creative process being excruciating, but coding with agents feels less like I'm thinking deeply to solve problems as a programmer and more like I'm wasting all day in Slack and Zoom as a manager.

But what the hell am I supposed to do? I'm haunted by the knowledge that I'm going 2-3x faster than I otherwise could, and maintaining a similar level of quality. I'm mournful of the fact that going back to a peaceful, engaging, and rewarding workflow of programming by hand would drastically reduce my productivity.

Under my previous one-dimensional concept of creativity, building a new app is undeniably and straightforwardly a creative endeavor. Working with coding agents has given me cause to reevaluate my programming efforts along this new generative creativity spectrum, however. I don't have a job, so I could just say "fuck it" and code strictly for the intrinsic benefit of learning and overcoming challenges. At the same time, I don't sit at a computer all day for my health, so I could just vibe code the tools I need and only concern myself with their extrinsic utility. And in truth I spend a little bit of time programming at both of those extremes.

But upon reevaluating my decades-long relationship with my craft through this new lens, it's become clear that programming sits in the middle of the spectrum as "Creative Work." I wouldn't bother writing a program if it weren't for whatever useful thing I needed it to do. At the same time, I rely on programming to fulfill a sense of vocation and to keep my mind sharp.

This newfound awareness that I suddenly have to compromise between internal enrichment and external productivity explains why I feel so uneasy in this new era. I honestly hope this isn't the final shape of the AI codegen landscape, but for now that's where things seem to be landing and that's where I sit.

Generating Writing with AI

One place where I don't have any reason to compromise, however, is my writing. I categorically do not use AI to generate anything I include in this newsletter or post to my website.

The reason I don't generate prose isn't that LLMs are bad at writing like I do (although they are). If that were the only thing holding me back, presumably I'd eventually reach the point—like I did with code—of handing the wheel to ChatGPT and shifting my task to steering an LLM along my outline and toward my intended conclusion. No thanks.

The actual reason I would never generate these essays is because the act of writing itself is what brings me value. The benefit exists entirely between my ears in the form of deliberate introspection and self-discovery.

Not only does writing make me no money, but essays like these offer me no extrinsic utility after I've written them. My purpose for writing (besides as a way to keep dear friends like you aware of my continued existence) is buried deep in the soil of my mind. The toil of wrestling with conflicting ideas and resolving inner conflict is what unearths this value, organizes it, polishes it. Publishing a piece simply places the resulting artifact in a display case above ground and in clear view.

Writing for this purpose is slow and painful. A third reason it took me so long to write this month's essay is that I extremely did not feel like doing it. But like brushing my teeth and eating my vegetables, I know it's good for me. I'm a financially secure, functionally retired 40-year-old and yet I assign myself this homework each month to ensure I'm always grappling with deeper questions than I otherwise would in the course of my daily routine.

If you've been reading this newsletter for a while, one thing you don't see is the fact that nearly every essay ends up being about a topic or making a point that is wholly different from what I'd originally intended. Here's how it goes. I'll have an idea and add it to a list. Some morning when I'm otherwise between projects, I'll grab my notepad and write a few pages over an hour or two. Later, I'll grab an iPad and type out six hundred words before realizing I lost track of my point halfway through. I'll go for a run, then tinker all afternoon to pound those words into a reasonable rhetorical structure. By dinner time, I'm exhausted and staring at two thousand words that somehow fail to convey the simple idea I had started with. "Well, fuck," I'll inevitably think to myself every goddam time, "I hate this. I'm extremely bad at this."

Writing is not fun and I love it.

But then, whether that night or in the shower the next morning and amid the simmering anguish in the back of my mind, somewhere beneath my crisis of confidence, I will hear something happening inside of me. It's as if a brass puzzle box hidden away in my psyche began to make a clicking sound. Its interlocking gears start turning. As I listen closer, I hear the satisfying plunk of pinions pushing into tumblers, as if unlocking a conclusion I never consciously set out to make.

What's in the box? It depends. It could be a sense of calm following the loss of a loved one. Or a deepened acceptance of some small part of myself. Or a renewed resolve that I've been right all along, and it is indeed the children who are wrong.

What's counterintuitive about my relationship with writing is that the text on the page isn't the key to opening the treasure chest. In fact, the sum of what I write isn't a solution to anything. This essay, or that blog post, or the last over-torqued e-mail I wasted a whole afternoon on is merely an echo of a solution. What actually unlocked the puzzle box was the struggle itself. Think of your favorite song. The magic is not hiding somewhere in the sheet music—its impact is only felt through the act of playing it. Over the years, this torturous misery of writing has occasionally caused my brain to fire the right neurons in the right order and at the right tempo to eventually lead my conscious self to watershed moments that have profoundly impacted my life.

In case it isn't already obvious, and because I'm a completionist who can't leave an illustrative figure unfinished, for me, writing sits at the left end of the generative creativity spectrum as a form of "Creative Processing":

For you, maybe your creativity processing occurs while you play the accordion. Or practice calligraphy. Or design choreography. Or maybe you don't process creatively at all. There are no wrong answers.

The Career of Creativity

I am aware I have ignored the elephant in the room.

What about people who make their living off creative work?

There are several ways to tackle this question. The one-dimensional paradigm of creativity can only provide one of two unsatisfying answers:

• They are fucked
• They are not (or should not be) fucked

Virtually everything I've seen written about the impact generative AI will have on creative careers starts with one of these conclusions and then dresses it up with rationalization, justification, and exhortation. Limited to this framing, I guess my best answer is, "they are fucked and that is very sad."

However, if the answer were really that simple, then people in creative jobs would be succeeding or failing together as a single monolithic demographic. But that's not what seems to be happening. Instead, I know some creatives who are absolutely thriving right now. I know some who are out of work and in dire straits. Others are getting by, but as employer expectations shift and roles change, they're reckoning with what feels like a personal loss.

• External Value: If you show up to work to crank shit out, aim to please by creating whatever's asked of you, and use the word "content" to describe the things you make, you're probably as happy as a pig in shit right now. The absolute explosion of tools allowing you to branch into new media and to supercharge your productive output are likely already setting you apart from your colleagues. Your value to The Market is likely to be seen now more than ever, and that's in spite of the deluge of slop that's consuming the web and the publishing industry
• Internal Value: If you managed to make a living by painstakingly producing labors of love that primarily served to meet your own needs, then I hate to say it, but you were lucky to have ever gotten paid for it in the first place. As demand for creative professionals decreases and expectations for individual output increases, the return on investment for this kind of work—unless you're some kind of genius or celebrity—will probably never again be enough to earn a living wage
• Everybody Else: If you're somewhere in the middle on this—getting paid for output that meets an external purpose but from which you also derive some internal value—you're probably as torn as I am about what the fuck to do about programming. Some people are responding to the potential diminishment of that intrinsic benefit as a threat: they're fighting back, refusing to adopt new tools, and getting added to a list of who to let go during the next round of layoffs. Others, meanwhile, see this as an opportunity—that by increasing their productive capacity, generative AI can dramatically increase the scope of their creative ambitions. Which side you'll land on is ultimately your choice

Even though I write for me and not for you, I'm grateful that you read this. I'd also be glad to hear how this essay made you feel and what you think about all this. Shoot me an e-mail if you have a minute. And if you'd like me to discuss some aspect of this on the podcast, write in to podcast@searls.co. 👨‍🎨

Direct link to podcast audio file

Post-recording update: As I've been lobbying for (both publicly and behind the scenes), it has been announced that the RubyGems and Bundler client libraries are being transferred to Matz and the Ruby core team.

Mike McQuaid (of Homebrew fame) and I scheduled this episode of Hot Fix a week before the Ruby community exploded. Hot Fix is all about getting spicy, but even we were a little wary of the heat in that particular kitchen. The problem Mike brought to the table is the same one he's always on about: open source is not a career. Incidentally, Mike's favorite topic also happens to be relevant to the latest RubyGems controversy—because it all boils down to paying people to work on open source.

Not content to miss out on the fun, Jerod from The Changelog asked if he could join and discuss the ongoing Ruby drama as a group. So we decided to team up and do a collab episode—call it Breaking Changelog, I guess? It's nothing if not efficient: record once, edit twice, and syndicate everywhere.

If you don't mind swear words, listen to this version. If you don't like swearing, what the fuck are you doing here? (But seriously, you can listen to their edit if you want!)

Please send your compliments to podcast@searls.co and your complaints to editors@changelog.com.

There's lots of good nuggets in here, and it's uncanny how many I agree with:

1. I also use Codex CLI (well, this fork) on a $200 ChatGPT Pro plan. Claude Code was an epiphany, but their models are overrated for the task, whereas GPT 5's variants are more adherent and diligent across the board. OpenAI's usage limits are virtually infinite by comparison, too
2. I run 3-6 agents in parallel (usually up to 3 per project and up to 2 projects at a time). Unlike Peter, it's rare I let two agents edit the same codebase simultaneously. GPT 5's "medium" reasoning setting is so fast that the time-consuming activities are brainstorming, researching, unearthing technical debt, and planning refactors
3. While git worktrees are a very cool feature, they dramatically slow down code integration with merge conflicts. Additionally, I've found it's hard to avoid API and port conflicts when running numerous development instances simultaneously. And when an environment stops working, agents will silently start coding based on speculation and conjecture. Fast feedback through observable execution of code is the single most important thing, so the risk isn't worth the (marginal) reward
4. Hooks, custom commands, and fancy hacks like coder's undocumented auto-drive mode are nice, but they're no replacement for thinking really hard about what you want

But really, the reason I've had so much success with Codex in comparison to Claude is that if you get off your ass and do the hard thinking necessary to arrive at an extremely crisp and well-informed articulation of what you want, why you want it, and what obstacles it will face, today's agents will generally do a really good job.

Oh, and fuck prompt engineering, just communicate better. As Peter says:

Don't waste your time on stuff like RAG, subagents, Agents 2.0 or other things that are mostly just charade. Just talk to it. Play with it. Develop intuition. The more you work with agents, the better your results will be.

I've started a dozen posts about working with coding agents that I deleted before publishing, because I eventually realized whatever insight I had could just as easily apply to dealing with human colleagues as with LLM agents. Seriously, just talk to it like a human.

Common communication failure modes:

• Telling the agent how to do the work instead of answering why, what, and where, and then getting upset when the ultimate solution manages to complete all the hyper-specific tasks I defined while failing to solve the broader problem
• Giving the agent instructions that contradicted the facts on the ground, only for the agent to spin its wheels endlessly and make a huge mess trying to do the impossible
• Lazily hand-waving away important requirements, only for the agent to miss edge cases it lacked awareness of
• Telling it what I want before I'd really thought things through, then hating whatever it gave me
• Failing to first deal with underlying technical debt, then getting mad when the agent shoehorns in a necessarily-messy solution on top
• Getting frustrated, being condescending, or treating the agent like it's my underling, and then peeking at its reasoning log and seeing 80% of its thoughts are about managing my emotional state and 20% about the problem at hand

I'm more convinced than ever that when people are having a bad time with using AI to write code, it's not only due to ignorance and incompetence surrounding the tools themselves—just as often, it's a failure of imagination and lack of communication skills. Two things that even the best programmers frequently lack. If you're a programmer who's bad at communicating with humans, I hope you've got some other plan for making money in the next decade.

Anyway, that's where things stand in October. June feels like three years ago, so we'll see where we are in February, I guess.

🔗 steipete.me

🧂 justin.searls.co

A recruiter sent me this screenshot of some kind of GitHub profile scraper. Aside from naming me as a "top 1%" JavaScript developer (which I'm not sure is a compliment or a threat…), I just couldn't get over the "active on weekends" checkmark.

Lady, on weekends I charge double. 🤌

For context, last week I wrote a post bringing to light a number of things André Arko had said and done in the past as a way to provide some context. Context that might explain why any of the principal actors involved in the RubyGems maintainer crisis (summarized well up to that point by Emanuel Maiberg) would take such otherwise inexplicable actions and then fail to even attempt to explain them.

Today, Jean shed some light on Shopify's significant investments in Ruby and Rails open-source, and it actually paints a picture of corporate investment in open source done right. (Disclosure: I know and am friends with several people who work at Shopify on these teams, and unless they're all lying to me, they sure seem to prioritize their work based on what Ruby and Rails need, as opposed to what Shopify wants.) Jean went a step further by contrasting Shopify's approach with the perverse incentives at play when individuals or groups receive sponsorships to do open source. He also drew a pretty clear line of those incentives playing out based on how RubyGems and Bundler maintainers reacted to Shopify's feature submissions. Read the post, it's good.

But now, not an hour after reading Jean's post, Ruby Central has published a jaw-dropping tick tock of the events that precipitated their decision to revoke maintainer access. Even more bizarrely, the only reason we're learning this information at all seems to be a self-own: that by publicly dunking on Ruby Central's failure to remove André's systems access—as opposed to properly disclosing the security breach—Joel Drapper and André inadvertently compelled Ruby Central to issue a post-mortem that lays out the facts we've all been clamoring for.

Seriously, just go read it yourself.

The Bad Part

On August 3, Ruby Central leadership became concerned there was a risk André might access and sell logs containing personally identifiable information from RubyGems.org servers. This concern was raised by André himself, who proposed it in an email:

Following these budget adjustments, Mr. Arko's consultancy, which had been receiving approximately $50,000 per year for providing the secondary on-call service, submitted a proposal offering to provide secondary on-call services at no cost in exchange for access to production HTTP access logs, containing IP addresses and other personally identifiable information (PII). The offer would have given Mr. Arko's consultancy access to that data, so that they could monetize it by analyzing access patterns and potentially sharing it with unrelated third-parties.

(The screenshot of André's email to Marty is in the post.)

So, according to Ruby Central, André was making $50k a year to fulfill a "rarely activated" role as secondary on-call, and when that budget was cut, he proposed harvesting PII and reselling it for his own profit. No mention that this might be unethical, much less in violation of RubyGems.org's privacy policy.

This led Ruby Central to go to work shoring up proper Operator Agreements and Contributor Agreements that could sufficiently defend against this kind of action. They decided to take the further step of temporarily revoking various accesses from multiple (most? all?) contributors until such protections were in place, which—as has been widely discussed—they didn't do a great job of explaining and did not even attempt to justify. Of course, now that we've seen this email and understanding that Ruby Central probably didn't want to catch a defamation suit by naming and shaming André as the reason, it certainly casts the subsequent community outrage in a different light.

Suddenly, that Shopify's leadership undertook a bizarre corporate conspiracy to withhold sponsorship dollars if Ruby Central didn't mass revoke maintainer access isn't the simplest explanation for why things might have gone down the way they did.

The Somehow Even Worse Part

But wait, there's more. Joel's post identifying that André still had systems access not only represented a security incident, it connected the dots Ruby Central would need to affirmatively identify an unauthorized actor who had accessed and changed credentials on their AWS account.

On September 18th, Ruby Central notifies they're revoking André's access:

Ruby Central notifies Mr. Arko, via email, of the board's decision to remove his RubyGems.org production access, and the termination of his on-call services. During that transition, our teams remove the AWS security credentials belonging to Mr. Arko for accessing the production systems, but we fail to rotate the AWS root account password in tandem.

Not eight hours later, a mysterious stranger in San Francisco (who Ruby Central asserts is André) logs in as the root user of Ruby Central's AWS account and changes the password. Ten days later, another mysterious stranger in Tokyo (who is apparently also André) logs in as root again.

I'm no lawyer, but that timeline could implicate the Computer Fraud and Abuse Act. That'd be incredible enough on its own, were it not for the fact he may have done it again in Tokyo—meaning he might have exposed himself to Japan's own statutes governing unauthorized computer access.

I'm not here to gloat, I'm here to plead with People On The Internet who rushed to judgment against Ruby Central or in defense of André to learn from this situation. The next time a story hits that rhymes with the basic outline of your prior convictions or political beliefs, pause and weigh the evidence before grabbing the nearest pitchfork and joining the mob. Sometimes that means—and I realize this is hard for some of us—not posting anything at all.

That said, I am formally accepting apologies from anyone who dismissed my previous post as "hearsay" or a "hit job" on Reddit, Hacker News, Bluesky, and Mastodon. (The X folks were mostly into it, a fact which brings me no joy.)

🔗 rubycentral.org

🧂 justin.searls.co

Direct link to podcast audio file

Jared Norman interviewed me after he wrote about the order in which programmers choose to write their code and I offered this response. In this episode, we touch on this before launching into a more expansive discussion on why the agile movement fizzled out and what we can reclaim from a developer workflow perspective now that we're experiencing our first major market upheaval since then with the rise of coding agents.

Appearing on: Dead Code
Published on: 2025-09-09
Original URL: https://shows.acast.com/dead-code/episodes/fear-driven-everything-with-justin-searls

Comments? Questions? Suggestion of a podcast I should guest on? podcast@searls.co

When Sora 2 was announced on Tuesday, I immediately saw it as exactly what I've wanted from AI ever since I first saw Stable Diffusion in the Summer of 2022. For years, I've fantasized about breaking free from the extremely limited vocabulary of stock video libraries (as a Descript subscriber, I've long had access to Storyblocks' library). Stitching together stock content to make explainer videos like this one is fun, but the novelty wears off as you quickly burn through all three clips for "child throws spaghetti at family member." Stock video is great if you only talk about mundane household and business topics, but my twisted brain thinks up some pretty weird shit, and conveying my imagination in video would be a lot more labor-intensive than starting yet another banal YouTube channel covering economics or something.

Despite being invite-only, I got access within 24 hours (maybe because I'm a ChatGPT Pro subscriber?), and it confirmed that Sora was exactly what I'd been waiting for:

• 10-second short-form video
• 16:9 or 9:16 aspect ratios
• Downloadable and re-uploadable elsewhere (watermarked)
• Sound, including dialog (provide an exact script or let the model riff)
• Can portray your likeness and consenting collaborators'
• "Good enough" results within 3-5 prompt iterations
• Understands simple direction: film styles, camera angles, scene cuts

The only surprise was that Sora 2 shows up as a social network, not yet another chat interface or infinite search pane. You sign up, you wait, you get four invites, you and your friends have a good time, and you get notified as more friends follow you. We've seen this rollout a dozen times.

In hindsight, Sora had to be a social network. As Meta has demonstrated, nobody wants to stare at an AI Slop Feed if it doesn't feature people they know and recognize. In the abstract, "people you know and recognize" would be off the table without opt-in consent. But durable consent more or less requires a social graph paired with platform-level verification and permission settings. "Deepfakes" have dominated the broader discussion around image generation, not only because they pose a vexing problem to civilization, but also because existing tools lack any built-in chain of trust mechanic—which limited our collective imagination to their use for political disinformation and revenge porn. But when you're on a social network and your videos can only star you and your close friends who've given you permission to use their likeness, OpenAI was actually able to strengthen the app's other guardrails in the process.

That means that while other image and video generators let you get away with posting images of real people as a starting point to work from, Sora disallows naming any person or uploading any image of a human into a prompt. Instead, you can only @mention users on the network, who have created a "cameo" avatar, who have given you permission to use it, and for which your specific prompt isn't disallowed by their preferences. Suddenly, AI deepfakes are (relatively) safe and fun. They star you and your consenting friends. If you piss your friends off, they can delete the videos you put them in. If you keep doing it, they won't be your friends for very long. The platform will surely be under-moderated, but by defaulting to a mutual-follower consent scheme, many of the abuse vectors will be self-policing in practice. (I'm emphatically not saying here that Sora won't result in a raft of psychosis diagnoses and teen suicides, by the way. We are super-duper cooked.)

As for the success of the platform, only time will tell if the novelty of unreality wears off, or if the presence of likenesses we know and recognize paired with imagery that previously required blockbuster movie budgets will be enough to hold our attention. Based on the success of 4o image generation, OpenAI is betting on the latter. I suspect that the platform will only pick up steam following substantial improvements to both the model (improved temporal consistency, complex directorial technique) and the interface (longer videos, sharing tools, storyboarding, series/playlists).

Trust in truth giving way to trust in falsity

Influencer-dominated video platforms have been broken for a long time, in part because their economics depend on winning an audience's trust to influence people towards doing or buying things that reward the influencer. That trust is built on the assumption that the influencer's videos are based in reality. After all, it's a real camera, pointed at a real product, from a real person the viewer has followed for months or years. Besides, why would they lie? They lie, it turns out, because making any kind of money on these platforms is an exhausting, tenuous hustle. Maintaining an audience large enough to make a living as an influencer requires constantly feeding the beast with content. The sponsors that pay the most are the ones whose products won't get as much reach without a high-trust endorsement, which results in the most scammy products and services offering the highest rates. This pushes influencers to make not-so-truthful claims, even if it means selling their audience down the river in the process.

Sora sidesteps all of this because it's all lies all the time. People's trust in institutions and the veracity of what we see on screens is already at an all-time low, and the spread of AI-generated video that's this good will only erode that trust further. Sora-the-platform doesn't accept real videos, but videos generated by Sora-the-model will quickly begin infecting "real" spaces like YouTube, TikTok, and Instagram—causing people's trust in what they see on those platforms to fall even further.

This dynamic gives OpenAI an absolutely diabolical epistemic edge, where the Sora app can be authoritatively false while the other platforms can never be authoritatively true. Users will be able to let their guard down using Sora, but they'll have to be more vigilant than ever on Instagram. If this strikes you as ridiculous, consider that we're simply talking about works of fiction versus works of nonfiction. Right now, every video you consume online is assumed to be nonfiction until you read the comments and learn the video was staged, the creator's body was enhanced with AI post-processing, or the sponsored product causes rectal cancer. So even without Sora, we're currently trapped in this uncanny valley where every video platform is perceived as hosting fictional nonfiction, which results in nothing ever being fully entertaining or fully informative. Sora, meanwhile, is a platform that can only host fiction by definition. And given that about half of media consumption is scripted content from legacy media companies, there's still a pretty good market for fiction out there!

So if you're just looking to kill a few minutes on your phone while you wait in line at the bank, you're probably going to take the path of least resistance—it's why you open Instagram or TikTok in the first place. But those apps offer a slurry that's part-entertainment, part-information, and part-commerce—a feed that has some funny videos, sure, but also sells you bullshit supplements, radicalizes your father, and exacerbates your daughter's body image issues. Sora might offer a path of even less resistance: mindless entertainment that allows you to safely turn your brain off. Because all the content is fake, you don't have to be on guard against being fooled.

The upshot here is that when there's no platform you can trust to be real, the next best thing is a platform where you can trust everything is fake.

What kind of content will succeed

Let's get this out of the way: lots of content won't work on Sora—especially most influencer niches.

If you're famous on Instagram for flaunting your lavish lifestyle and using it to sell garbage-tier sponsored products, what would you even do with Sora? Show off a fake house? Hawk a fake product? You can't upload "real" video to Sora, so what are your sponsors going to do when your gas station energy drink collab is made to look more like a Red Bull once it passes through the AI model? Even if you could place the products perfectly, entire categories of content that influencers have made profitable won't find much to do on Sora. Who wants fake lifestyle videos, cooking recipes, beauty/fashion tips, fitness routines, gameplay footage, or political ragebait?

What does that leave? Entertainment. The creativity and production value of Hollywood scripted entertainment, crossed with the potential for virality of democratized user-generated content. It's as if Quibi and Vine had an AI baby. What this adds up to is Sora is less a tool for influencers and more well-suited for out-of-work Hollywood script writers.

One reason Sora is unlikely to take off until it supports longer-form video and is more adherent to script-like prompts, is that engaging fiction depends on preserving authorial intent. It can already do some pretty wild shit, but Sora doesn't give creators enough to work with to compete with a TV series. We'll get some funny cutaways and creative images, but there's only so much you can do in ten seconds. But if Sora can get any kind of foothold and stick around, those limitations will be lifted. People forget this, but YouTube only supported videos shorter than 10 minutes for its first five years and 15 minutes for its first ten. Today, user-generated YouTube content is giving legacy media a run for their money on widescreen televisions and you can barely find a video shorter than 20 minutes on the platform anymore.

But Sora doesn't need to become an overnight cultural sensation to be valuable. OpenAI will keep funding it, because the research suggests that video generation will unlock the future of general-purpose vision models, and those vision models are the key to autonomous robotics in the real world. And that's the ultimate promise of all these trillion dollar valuations.

What can people use Sora for now?

Setting aside speculation as to what all this means and where things are going, what OpenAI shipped this week is nothing short of extraordinary exactly as it is. For the first time, a platform can bring visual ideas to life with shockingly little effort. By boxing out "real" content, the platform will reward ingenuity and cleverness over social status and superficial aesthetics.

Here are a few ways Sora shines today:

• Short-form comedy in the spirit of Vine
• Meme/GIF generation
• Inside jokes and skits among friends
• Design inspiration (like Pinterest or Behance)
• Stock video for B-roll and cutaways for use in other videos
• The visual equivalent of lo-fi hip-hop (the feed even has a "mood" filter)
• Visual prototyping and virtual screen tests for traditional video production
• Fan edits and shipping of known characters (note OpenAI changed its intellectual property policy to an explicit opt-out)

Weirder ideas that come to mind:

• Capturing dreams (this morning I typed what I remembered into Sora before it faded)
• Lore and world-building videos and remixes
• Synthetic nostalgia and retro-futurism
• Visualizing an alternate life (with kids, without kids, with pets, being more attractive, speaking another language)
• False childhood tapes and future video postcards
• Public hallucination challenges (e.g., the Tide Pod, cinnamon, or ice bucket challenges, but expressed through prompts and remixes)
• Psychological horror and grotesque/absurd glitch art
• Ghost messages from someone who published a cameo but has since passed away in real life
• Private messaging:
  • Families sending video greeting cards of imagined gatherings for birthdays or holidays
  • Asynchronous role-play between friends
  • Long-distance relationships visualizing co-located experiences

Is all this stuff creepy as shit? Yep. Will people actually do any of this? No clue. I'm a sicko, so I will. But the safe money is always on nothing ever changing and people sticking to whatever they're already doing.

What's less debatable is that the world has never seen anything like this, and it's unlikely we'll be able to fully process its impact until humanity has a chance to catch up (by which point, the tools will only be better). Hold your loved ones close, everybody! Shit's getting weird. 🫠

We have fun here.

It's true, you catch more bugs with honey than vinegar.

Clipped from my conversation with José Valim about how little we know about the future of coding agents (and, as in the case of this video, also their present).

Direct link to podcast audio file

If you know who José Valim is, then you know he probably made a mistake by joining me for our third installment of 🔥Hotfix🔥. The inventor of the Elixir programming language is at it again with his colleagues at Dashbit and they've got a new product called Tidewave. It's a coding agent with a twist: it has such a deep level of integration with your web framework that it can get the executable feedback it needs to tackle the entire feature development lifecycle.

I do eventually let him plug the tool (and our conversation genuinely makes me want to try it—I logged a todo and everything!), but to be on Hotfix you gotta bring a thorny problem to the table, and he picked a great one: marketing hype aside, nobody has a clue what the future of AI agents looks like.

Like always, we totally 100% and A+ solved the problem by correctly predicting the future. You gotta listen to find out.

Every time I talk to José, I get ideas for what I should be doing instead of what I'm actually doing. If you feel so inspired, write into podcast@searls.co and I'll read it on the next mainline version release of Breaking Change.

You can follow José on Bsky, X, and Mastodon. Pick your poison. ☠️

This debate has been eating at me ever since the news first broke, but I've tried to keep the peace by staying out of it. Unlike most discourse about what's going on, my discomfort stems less from the issue at hand—what Ruby Central did, how they did it, and how poorly it was communicated—and more to do with how one-sided the public discussion has been. Beneath the surface of this story are the consequences of a decade-old conflict that was never fully resolved. Then and now, one side—André Arko and many people associated with him—has availed itself of public channels to voice their perspective, while the other—which includes a surprisingly wide swath of well-known Ruby and Rails contributors—has chosen to stay silent.

The losers in this dynamic are the vast majority normal everyday Ruby developers, most of whom are operating on very little information and who understandably feel confused and concerned. People whose livelihood depends on the health of the Ruby ecosystem deserve more information than they're getting, especially now that its operational stability has come under threat. The future of that ecosystem is once again uncertain, but—just like last time—the outcome is being shaped by a history that's been kept from the public, widening the rift between its key decision-makers and the communities they serve.

I don't have the answers to what's going on in 2025. A few details have been shared with me—details that would contradict fact-checks and timelines others have pieced together and published—but I can't pretend to have a clear picture of what actually happened, why no one is setting the record straight, or when we'll have clarity on what the future holds. All I can do is offer a little bit of context to explain why I'm dubious of the dominant narrative that has taken shape online. Namely, I don't believe this is a cut-and-dry case of altruistic open-source maintainers being persecuted by oppressive corporate interests.

After you read this, perhaps your perspective will shift as well.

The relevant proper nouns to know

Before anything else can make sense, it's important to understand how weird the governance of the Ruby ecosystem is. There are three moving parts involved that are ostensibly managed by three different groups, but whose members have such broadly overlapping systems access that it has now led to disputes over who owns what:

• Ruby itself, created by Matz and maintained by a large group of (mostly Japanese) committers, who host ruby-lang.org, control the @ruby GitHub organization, and are supported by the Ruby Association
• RubyGems, specifically the gem and bundler CLI tools distributed with the Ruby language, which is hosted under @rubygems on GitHub
• RubyGems.org, the website, API, and host from which gem dependencies are installed and which has been run by Ruby Central for ages

If Ruby were invented today, a single party would probably control all three of these things, but it took nearly fifteen years for today's status quo to take shape. Ruby was invented by someone in Japan in the 1990s. RubyGems was created at a conference in Texas by a few Americans in the early 2000s. RubyGems.org only became the de facto canonical host for gems six years later. My impression is that at no point was communication and coordination particularly fluent between the various parties.

Adding to this, Bundler—a meta tool for resolving the correct versions of all of a project's gem dependencies and which quickly became vital to nearly all Ruby application development—was created independently of the above players by Yehuda Katz and Carl Lerche. André Arko later became the lead maintainer of Bundler, and in 2015 he founded a 501(c)(6) nonprofit called Ruby Together. In 2019, Bundler was folded into RubyGems. In 2022, Ruby Together was absorbed by Ruby Central.

Those last two events—the merging of Bundler and the unwinding of Ruby Together—came about after years of bitter conflict and simmering discord that I hope to shed some light on below. My direct involvement with any of these events was extremely minimal, but I had contemporaneous discussions with dozens of the principals involved. I never donated to Ruby Together and have never materially contributed to Bundler or RubyGems. That said, simply being made aware of several incidents as they were playing out in private was enough to leave behind a scar that has never fully healed. I can only imagine how others are feeling right now. Based on how badly things are playing out this time, it seems they were deeply impacted, too.

The things people told me

The earliest recollection I have of someone telling me about André Arko was in the summer of 2015, after getting dinner with a friend who happened to be a Ruby Together board member. The friend explained that André believed programmers working on open source tools deserve to earn an income that's commensurate with what salaried engineers earn at the companies who benefit from those tools. As such, André's goal with Ruby Together was characterized as an effort to fund development activities—initially his own, but eventually others—by paying themselves a market hourly rate. I remember being extremely sympathetic to this perspective, having also wasted countless hours of my life maintaining open source for free only for others to benefit from it. I also recall a figure like either $200 or $250 per hour being mentioned as the rate he was effectively paying himself. Whatever the rate actually was, I distinctly remember thinking, "holy shit, that's a lot higher than individual donors would probably assume." (UPDATE: A RubyTogether donor forwarded me newsletters from 2015 and 2022, both stating an hourly rate of $150 per hour being paid.)

The first time I remember meeting André in person was at Ruby on Ales 2016. I remember trying to make a good impression, because growing my network in the community was the primary reason I spoke at conferences. I was presenting with my beloved 12-inch MacBook, which meant I was traveling with the first iteration of this cursed dongle. André needed an adapter, so I ran up to lend him mine. As he was giving it back, I recall him making a half-joking, flippant remark about either his dongle or his computer, saying that "Ruby Together will just buy me another one." It really rubbed me the wrong way. Over the years to follow, more than one person told me stories of André paying for shared meals on behalf of Ruby Together without an apparent legitimate justification. They told those stories, I assume, because the attitude he exhibited made them uncomfortable. If I had donated money to Ruby Together and heard the same stories, I would have been upset.

For how little has been said about this publicly, a lot of different people told me a lot of concerning stories about Ruby Together over the years, often providing evidence to back it up. I'll do my best to stick to the highlights in this post. Hopefully they will explain why I have not joined the rush to defend the maintainers whose access was recently removed. What Ruby Central did was undoubtedly handled very poorly, but I don't think their bungling of its execution and communication alone is enough to answer the question of what should happen to the future custody and direction of Bundler, RubyGems, and RubyGems.org.

2015

When Ruby Together first launched in 2015, the website suggested donations went to pay "our team", which initially linked to a list of the board members without any explanation of how the money was being allocated. This resulted in a nonzero number of donors believing they were funding the work of people like Steve Klabnik, Aaron Patterson, and Sarah Mei, when in fact only André was being paid at the time. Shortly after the wording was raised as misleading, the team page was updated accordingly.

In May of 2015, André suggested making support for older versions of Bundler contingent on Heroku paying Ruby Together, which was interpreted as leveraging his control over Bundler as a pay-to-play scheme. Because Heroku serves other people's Ruby apps—many of which aren't updated for very long stretches—the security of their service depends on clear and predictable support windows for Ruby's core technologies, it seems reasonable they would interpret this sudden revocation of support as a pressure tactic, aimed to solicit corporate sponsorship for Ruby Together. (Years later, André responded to a feature request from a Heroku engineer, which was interpreted at the time as indicating the feature would be withheld from Bundler because Heroku had failed to pay Ruby Together.)

2016

The minutes of a December 2016 Ruby Together board meeting were leaked. The document acknowledged who was paying for the RubyGems.org service at the time: "Fastly is comping us something like $35k worth of CDN service per month. And that's on top of Ruby Central paying for $5k of servers and Ruby Together paying for about $15k of dev work every month." The use of "us" in that sentence suggests that Ruby Together was responsible for hosting RubyGems.org, which Ruby Central later went on to publicly dispute. Additionally, one presumes the number of hours and rate paid for development work was determined by Ruby Together itself, rather than being a hard operational cost. Later in the document was a discussion of potential strategies to increase revenue after "new memberships [had] flatlined." Several ideas were discussed, culminating in a proposal to rate-limit access to RubyGems.org as the apparent best option:

Rate limiting RubyGems.org seems like the option that scales most linearly with our costs. Companies that cost us money need to pay more (or stop costing us money), and companies that don't cost us money can continue to have a free ride. To be clear, this would not mean cutting off anyone's access to RubyGems.org. I'm imagining that it would work something like GitHub's model: anonymous access has a low limit, registered accounts have a higher limit, and even higher limits are available at each Ruby Together membership level. There are a lot of implementation details that would need to be worked out, but in general I feel like this is probably the most effective option to make companies feel like they are paying money for something they use and that covers our costs well.

The leaked minutes were widely circulated in private at the time, due largely to outrage over the document's presupposition that Ruby Together was paying to host RubyGems.org (citing "our costs" as scaling with usage), as opposed to paying for developer effort (the costs of which do not scale with usage). The leak left myself and others worried that André might leverage his systems access to effectively hold the Ruby ecosystem hostage for the financial benefit of Ruby Together and—since it was compensating his own development efforts—André himself.

2017

In January 2017, André added a "post-install message" imploring users to fund Ruby Together, which would be displayed every time anyone installed Bundler. Unlike the aforementioned board meeting, this happened in the open and triggered an immediate backlash before eventually being rolled back. In one comment, André defended the action and pointed to Shopify's failure to pay Ruby Together, publicly conflating Ruby Together's sponsorship of development effort with "~$40k/mo worth of servers." But, as Ruby Together's own board minutes from the month prior directly stated, money sent to Ruby Together wasn't going to pay server expenses—server costs were covered by Fastly and Ruby Central.

In February 2017, following protracted discussion of the post-install message and the threat of rate-limiting access to gem installs, I agreed to put my name on a letter alongside 18 others (including one of Bundler's creators). The letter requested Ruby Together stop misleading the community in this way. My understanding is that some private one-on-one communication followed, that none of it was particularly productive, and that no formal communication occurred between the two groups afterward.

In March 2017, Ruby Central went on the record, attempting to clear up confusion and reassure users that they alone were in control of RubyGems.org, stating that Ruby Together donations were immaterial to its continued operation:

Unfortunately, this past year has also given rise to some misunderstandings about this relationship in some quarters: chiefly, that by donating to Ruby Together, companies were paying for the operations of RubyGems. And in turn, that if enough companies didn't donate to Ruby Together, RubyGems would subsequently be in a perilous situation. This isn't so.

No one in the Ruby community should worry about the availability or security of RubyGems being connected in any way to the fundraising of Ruby Together. Funds raised by Ruby Together go primarily towards paying developers to add features and fix bugs. Ruby Central, on the other hand, is wholly responsible for the operations and baseline stability of the system. While these two efforts go hand-in-hand, it's vitally important to understand that they are two different things. Ruby Together's requests for donations do not mean that there is any reason for concern about RubyGems' continued existence or operation.

Later, in August 2017, André accused Google Cloud Platform of wholesale copying gemstash's codebase, going so far as to threaten legal action in his opening message. He juxtaposed the accusation with the complaint that Google had, "repeatedly declined to support Ruby Together." The incident appeared to fit a pattern of behavior to pair high-conflict messaging with an admonition of the target's failure to fund the organization that paid him. Ultimately, André's claim turned out to be factually baseless—Google hadn't copied gemstash's code, after all.

2018–2024

Things quieted down and I didn't hear much about any of this stuff anymore. Eventually, Bundler became part of RubyGems and many folks from Ruby Together migrated to analogous roles at Ruby Central.

2025

In August 2025, and seemingly out of nowhere, someone pointed me to the project spinel-coop/rv-ruby, an apparent fork of homebrew/homebrew-portable-ruby. I say "apparent", because rather than using GitHub's fork button—which would have maintained clear attribution of who created the upstream project—it looks like it was instead cloned and re-pushed by André. Specifically, I was sent this commit replacing references to Homebrew from late July. As evidence of Homebrew's authorship was being erased and obscured, no additional acknowledgement was added to credit Homebrew for having created and maintained Portable Ruby since 2016.

It immediately reminded me of André's baseless accusation against Google. "Not only did you not credit the Gemstash project in any way," André wrote, "from an ethical standpoint, this is also super gross." His blatant copying of Portable Ruby (a project significant enough that the lead maintainer gave a talk about how they did it) struck me as brazenly hypocritical, given André's previous litigious and mistaken accusation against Google.

In fairness to André, the rv-ruby repo continues to retain a copy of Homebrew's LICENSE.txt which names "Homebrew contributors" as the copyright holder. André also later added an explicit acknowledgement to the README, but that attribution came more than a month later, and (I'm told) only after he was directly asked to credit the original project.

André wrote this week that, "Ruby Together did not ever, at any point, demand any form of governance or control over the existing open source projects. Maintainers did their thing in the RubyGems and Bundler GitHub orgs, while Ruby Together staff and board members did their thing in the rubytogether GitHub org." However, while he was leading Ruby Together, he moved to restrict committer access to RubyGems in rubygems/rubygems, unilaterally erased the original authorship from Bundler's gemspec in bundler/bundler, and oversaw a number of contributors being removed from bundler/bundler-site in a redesign of Bundler's website.

As a result of this broader historical context and in spite of the serious claims and grave implications being thrown around this month, I'm trying my best not to rush to judgment about who's at fault in the current conflict and would urge others to do the same. The future of the Ruby ecosystem may depend on it.

That is, until yesterday, when I had the thought, "what if I had a script that could detect each time the audio switched from mono to stereo?"

See, like most podcasts, I record my voice in mono, but the music jingles (or "stingers") are all in stereo. And because each mono segment is punctuated by a stereo stinger, the resulting timestamps would indicate exactly where the chapter markers ought to go.

So, an hour later, some new shovelware was born! I call it autochapter, and you can install it with homebrew:

brew install searlsco/tap/autochapter

Once installed, just pass autochapter your chapter names as a text file or a list of flags, like this:

autochapter \
  -s Intro \
  -s Follow-up \
  -s "Aaron's Pun" \
  -s News \
  -s Recommendations \
  -s Mailbag \
  -s Outro \
  v44.mp3

And you'll get a remuxed version of the audio file (e.g. v44-chapters.mp3), as well as textual readout of the chapters, ready to be pasted into your YouTube description:

Chapters:

0:00 Intro
24:11 Follow-up
53:45 Aaron's Pun
56:14 News
1:49:03 Recommendations
2:03:52 Mailbag
2:33:11 Outro

As you might surmise from the examples, v44 of the show is the first version to ship with chapters.

And that's about all there is to it. I wrote autochapter with Codex CLI in one shot, and it's a great example of a project I would have never bothered building if it weren't for a coding agent to do the gruntwork for me. That makes autochapter Certified Shovelware.

Direct link to podcast audio file

Hey, look! Breaking Change now has chapter support for each segment! More on how I did that while still upholding my commitment to laziness later.

I didn't get a good job connecting this version's release to what I was referencing, so to be clear I was referring to my heart rate as opposed to any other bodily functions. The other ones are getting up just fine, thank you. Get your head out of the gutter.

Thanks for all the great e-mails the last couple weeks! Throw yours on the pile at podcast@searls.co. Hopefully Fastmail won't lose it.

For the folks who pronounce URLs like Earls:

• Fallout comes to HHN
• Apple's bullshit Watch Series 11 battery claims
• Echofeed is like POSSE Party, kind of
• Only POSSE Party is POSSE Party. Working on it.
• Aaron's puns, ranked
• Scuba-wearing restaurant robber swims away with cash at Disney Springs
• India is fucked
• H1-B's cost $100k now making India super fucked
• Why tradwives aren't trad
• Why Marriage Is Increasingly for the Affluent (News+)
• Virtual Boy is coming to the Switch
• Samsung brings ads to US fridges
• Meta's bad demos and explanations
• Steve Jobs smoking the good shit
• Expedition 33
• Super Mario Odyssey
• Tony Hawk's Pro Skater 3 + 4
• Paradise Season 1
• The Last of Us Season 2
• The Invincible

So here's a neat way to magically cut in half the time it takes to transfer to your new iPhone.

Back in 2019, I realized iPhone restores run much faster when the device is kept cold, because thermal throttling—not data transfer rate—is the real bottleneck. The thing is, a fridge isn't quite cold enough and a freezer was way too cold (phones don't work well at below zero temperatures, apparently). So the stopgap solution I initially arrived at was to sandwich the phone between a couple ice packs. Not only did it work great, I was tickled to see a few sites like Cult of Mac publish how-to guides on the technique.

Anyway, figuring out how to best cool my iPhones to expedite a direct transfer restore has become something of an annual tradition in the Searls household. This year, I had the foresight to buy small ice packs and then stick MagSafe-compatible receiver magnets onto them.

If you're interested, here's what you're looking at:

• Ice Packs
• Adhesive Magnets

Those are affiliate links, which I feel like I should disclose because this website definitely counts as a journalism.

For tech reviewers lining up all these phones next to each other and weighing the pros and cons, I can absolutely understand how iPhone Air doesn't seem to earn its spot in the lineup at $999. Just look at all these downsides:

• Battery: The battery life is slightly worse than iPhone 17 and much worse than iPhone 17 Pro
• Performance: The A19 Pro chip in iPhone is not only binned (it loses a GPU core), it's so thermal-constrained it probably wouldn't be able to use that core anyway—one review saw significantly worse sustained performance from iPhone Air than the base level A19 in iPhone 17
• Speakers: iPhone Air lacks stereo speakers, a feature that was added in iPhone 7 (a consolation prize for dropping the headphone port, I guess)
• Cameras: iPhone Air offers the same(-ish) main camera as its model year brethren, but lacks an ultra-wide lens, a telephoto lens, and a LIDAR sensor. That means no macro mode, no optical quality zoom beyond 2x, no spatial photo or video capture, and reduced portrait/AR performance

In its preliminary assessment of Apple's offerings, The Accidental Tech podcast went so far as to speculate iPhone Air wouldn't appeal to tech enthusiasts at all, and perhaps will only sell to fashion-conscious consumers who won't know what they're missing.

Indeed, the through-line connecting every review I've read—whether framed positively or negatively in its conclusions—is a struggle to answer the question, "Who is iPhone Air for?"

Well, it's for me. That's who.

Whenever the claim is made that, "nobody is asking for a thinner iPhone," I make a point of piping up. My favorite iPhone of the last decade was easily the iPhone 13 mini, and when I upgraded to iPhone 14 Pro, it was so heavy that I got in the habit of leaving the house with only my cellular Apple Watch Series 8. My favorite Apple computer of all time was the 12" MacBook, and I am perennially disappointed that Apple has deprioritized weight ever since (the lightest Mac currently on offer is the MacBook Air, which is 33% heavier than the decade-old MacBook).

That's why I didn't hesitate to put in an order for the new iPhone Air, downsides and all:

• Battery: Where others see the 39-hour battery life on iPhone 17 Pro Max as a triumph, I see it as dead fucking weight. My iPhone spends 90% of every day on a MagSafe charger near my front door. The iPhone Air's battery is about a third smaller than iPhone 16 Pro's battery, but in the past year I've only seen my battery dip below 33% a handful of times. Tell you what, when I'm traveling, I'll bring an iPhone Air MagSafe Battery just to put your mind at ease. It's true, I may need the last third of my phone's battery 10% of the time, but I benefit from my devices' relative size and weight advantages 100% of the time
• Performance: There isn't a single thing I use my iPhone for that takes full advantage of its computing power, and if ever there was, it would be a signal to switch to a more serious device like an iPad Pro or a Mac. At the same time, I get it. It sucks to see your new device post shitty benchmark scores, because it confirms that you have a tinier penis than your friends. I'll just have to find a way to cope, I guess
• Speakers: I'm not here to judge, but I can't understand why anyone uses their iPhone speakers at all. The only ones I see using this feature are people's shitheel children, inconsiderate assholes, and airport workers on break who probably can't afford AirPods. If you use your speakers in some non-disruptive way, God bless—what goes on in the privacy of your own home is up to you
• Cameras: iPhone Air's rear camera system is undoubtedly a shortcoming. Since Becky is going Pro, she's enabling my Air purchase by signing up for the emotional labor of being the family's chief photographer for the 2025-2026 season. We trade off on this—I lugged my iPhone 16 Pro around last year so she could lighten her load with a green iPhone 16. Even still, last year fewer than 5% of my photos were taken with either of the ultra-wide or telephoto lens, so I doubt I'll miss them

As someone who has been using iOS 26 all summer, there's one more reason I'm glad to be switching to iPhone Air: information density is significantly lower throughout iOS 26, which has a dramatic negative impact on the usability of smaller displays, even the 6.3" iPhone 16 Pro. That's because with the 26 series of releases, the new unified design across Apple's platforms features much more negative space between its controls and views—all in the name of concentricity. As soon as I updated my iPhone 16 Pro to the iOS 26 beta, I was immediately put off by how much less text was being rendered and how much more I was scrolling to get what I needed. By ordering another 6.3" iPhone, I'd be locking in those losses. But iPhone Air's larger 6.6" display claws back just enough additional screen estate to make it a wash. I don't want a bigger screen, I want an OS that doesn't punish smaller screens. And it's nice to want things.

Will iPhone Air sell well? Don't ask me, I'm the guy who just said his favorite iPhone was iPhone 13 mini and favorite Mac was the 12" MacBook—both of which flopped. I'm certainly not arguing this thing is going to light sales charts on fire, simply that it's not entirely irrational to conclude that iPhone Air is the best phone in this year's line up.

Anyway, this is just my take. You do you.

The Verge is included in Apple News+, so if you're an Apple One subscriber (as I imagine, many Verge readers are), whenever you hit the paywall in your browser you can—at least from Safari's Share Sheet—very easily open the same article in the News app and avoid the paywall.

That changed this summer! Why? Because in this nascent era of terminal-based coding agents, I have found a semi-ephemeral, intentionally finite scratchpad to be invaluable.

Use cases include:

• Writing long prompts directly in the terminal only for things to go wrong can sometimes make it hard or even impossible to recover later, so instead I write them first in Tot and then paste them into my terminal. If anything goes wrong, I no longer try to multi-shot it and watch the model spin, I just restart the chat, tweak the prompt, and try again without any fussy in-terminal text editing
• While I could choose to parallelize the shit out of my coding agent and send it off to implement a half dozen features in separate git worktrees, my puny brain prefers to single-thread a single project at a time. As a result, I like to use each page in Tot to keep follow-up tasks in reserve. This way, as soon as I think of the next thing I want the agent to do, I have a place to immediately type it without interrupting the agent. As soon as it finishes its current task, I can keep the hopper saturated by pasting in the next-highest-priority task from the corresponding Tot page
• Maintaining to-do lists as text files within the working directory for the agent to work from can be a wonderful workflow, but there are times where I don't want to contaminate the agent's context with additional complexity until we're standing on a firm foundation. I've found that long to-do lists and plans will often lead to agents spreading themselves too thin by attempting to future-proof or cover a bunch of cases poorly

As I type this I'm sitting in my Vision Pro with the hilariously-wide Ultrawide Mac Virtual Display and literally running four top-to-bottom terminals, each cranking on separate projects simultaneously. Tot has become integral to my workflow as I spend more and more time playing whackamole to feed each agent work.

(While the agents are all humming along, I typically use that time reviewing each project's current changesets in Fork—another excellent Mac app—to identify what I need the agent to do next.)

🔗 tot.rocks

🧂 justin.searls.co

My iPhone Air MagSafe Battery came in the mail today, and it was the first time I've ever seen this ridiculous sticker.

Does this mean the product can't be taken on passenger planes? Because the only risk factor other than the product the battery itself in the box is a few layers of cardboard.

Quick impressions on the product:

• It is a battery
• It can be charged via USB-C and charge other devices via USB-C
• It can connect to phones other than the iPhone Air, but generally only sideways, and iOS 26 handles it in software correctly (meaning whatever software integration Apple built for the product isn't gated to iPhone Air serial numbers)
• It will attach to MagSafe chargers but not charge from them
• I haven't tried putting my AirPods Pro 2 case on them, but wouldn't be surprised if it charged them

While content proliferates, engagement is evaporating. Average interaction rates across major platforms are declining fast: Facebook and X posts now scrape an average 0.15% engagement, while Instagram has dropped 24% year-on-year. Even TikTok has begun to plateau. People aren't connecting or conversing on social media like they used to; they're just wading through slop, that is, low-effort, low-quality content produced at scale, often with AI, for engagement.

I'm grateful to be living a timeline-free life for the most part, but on the rare occasion I log in and catch myself scrolling, this haunting characterization resonates:

The timeline is no longer a source of information or social presence, but more of a mood-regulation device, endlessly replenishing itself with just enough novelty to suppress the anxiety of stopping. Scrolling has become a form of ambient dissociation, half-conscious, half-compulsive, closer to scratching an itch than seeking anything in particular. People know the feed is fake, they just don't care.

I suspect many of you reading this continue to use social media apps because you were around back when they were social networking apps and are having a hard time accepting the fact that isn't what they are anymore. Likewise, many businesses are still earnestly crafting useful blog posts, only to optimize them for search engines and social platforms that will only ignore them—they should probably figure out a new racket, too.

🔗 noemamag.com

🧂 justin.searls.co

Whenever I need to verify a network connection with a remote LLM, I always ask it 1+1. I'm sure it'll still raise the ocean level by a millimeter, but it seems less bad than a more complex query.

I forgot I had unhidden chain-of-thought reasoning, so I chuckled when I got this:

Sure thing! The task is straightforward: I just need to respond to "1+1" with "2." It's a simple calculation, so I won't overthink it. There's no need to use any tools for this, and I know the guidelines about "Destructive Deletions" and "No Comments by Default" don't really apply here. I'll just keep it short and clear, and the answer will simply be "2."

At least it didn't overthink it.

Hope you're having a lovely September so far. Hard to believe it's almost Fall! Always love seeing the first signs of the end of Summer—I refer, of course, to Apple's annual iPhone event.

In case you don't subscribe to my every waking moment, some highlights of stuff I put out over the last month:

• Shared some of what I've learned about using Apple's on-device LLM API
• Suggested a new Star Wars watch order
• Opined about why I wasn't cut out for management
• Recorded two normal podcasts (v42 and v43) as well as an interview with Scott Werner
• Repeated my tireless appeal to get folks blogging again
• Gave up on Claude Code (which Anthropic has now admitted they made dumber for over a month) in favor of OpenAI Codex—specifically, this fork
• Published a command-line tool called imsg for exporting iMessage archives
• From that, I documented a how-to guide on distributing scripts via homebrew
• Did an hour-long review and buyer's guide of the aforementioned iPhone event (pre-orders go up Friday morning at 8 AM Eastern!)

Every month, I scroll through the last month of photos for one to include in this newsletter. Not many pictures this month, so here's a little surprise Becky left me that showed up in our iCloud Shared Photo Library

I feel personally attacked. And thirsty.

Today, I'm writing you about my favorite topic: capitalism. Or, more specifically, I'm here to shed a little light on a few "special" kinds of people who tend to be highly-valued in the economy but who are often portrayed as stereotypical caricatures. Each is as stubbornly human as the rest of us. Each possess an unusual blend of attributes that make them well-suited for the current epoch. My consulting career brought me face-to-face with more than my fair share of these people. The experiences I reflected back on while writing this were sometimes interesting, sometimes impressive, and rarely both.

Forced to categorize the most impactful people I've observed and encountered at work, I'd break it down into three archetypes: visionaries, entrepreneurs, and innovators. Each persona combines tremendous capability with comparatively bewildering blind spots. The business world holds these folks up as paragons of Employee Virtue. Not because they are perfect, but because their unique traits—when harnessed appropriately—can produce unparalleled results. And because the people doing the hiring always have faith in their own ability to harness the people they hire, candidates who fit these molds are often hired on the spot, bypassing any standard process. Most employees are employed by a business, whereas these employees happen to a business.

Visionaries

Investors can't resist the siren song of visionary leaders who are preoccupied with growth. Visionaries want to achieve massive scale, can sustain obsession over decades, and believe in their own ability to change the world. Remember how Steve Jobs said he wanted to make a dent in the universe? That's the vibe. Audacious founders armed only with a half-cocked idea and delusions of grandeur have raised more in funding than you or I will earn from a lifetime of productive labor.

Beyond Wall Street, the general public also valorizes the growth-obsessed, because visionaries' irrational optimism reads as endearingly plucky in an underdog. But once that dog catches the car and begins to steer it from behind, those same traits become terrifying for us as passengers. To wit, you probably feel differently about Zuckerberg, Bezos, and Musk today than when you first learned about them. But the billionaires haven't changed at all. Our perspective of them is what shifted. They merely represent the natural end game for people wired to believe that more is never enough.

Of course, hating the ultra wealthy is nothing new. More recent, though, is a prevailing suspicion of growth for growth's sake, especially as the externalities of unregulated growth are becoming harder to avoid. My former colleague and mentor Daryl Kulak would often counter clients pushing for unrestrained growth with, "we actually have a word for something that grows forever: cancer." As much as the economy might love those with an unbridled ambition to grow, the rest of us can pretty easily spot the downsides. And while every visionary's light shines brightly, most are inevitably snuffed out—there's only room for so many winners.

Entrepreneurs

Think of a world-renowned business. Any business, doesn't matter which. That business would have ceased operations long before you'd ever heard of it were it not for some number of entrepreneurial employees predisposed to action over deliberation. When an issue arises, they add it to their plate. When someone else drops a ball, they can be counted on to catch it. When others deliberate endlessly, or stick their head in the sand, or waste time playing the blame game, they get shit done. They're sharks: if they stop moving, they die.

The action-oriented are not constrained by the bullet points on their job description. Hell, they probably hadn't finished reading the job description before picking up the phone and asking for the job. People driven to action make for appealing candidates not because they're confident "alpha" types per se, but because they talk in terms of what they will actually do to solve a problem as opposed to how they'll merely think, plan, or coordinate their way through it. Small businesses need them, because there's always far more shit to do than they can deal with. Large businesses need them, because their calcified bureaucracies prevent anything getting done otherwise. Struggling to visualize these people? Think of the guy who says, "ask forgiveness not permission," but who—come to think of it—has never actually apologized to anyone.

Of course, it's possible to over-index on action. There are plenty of times when the best course of action is to take no action at all. (Unsurprisingly, entrepreneurs tend to get trapped in the urgent half of the priority matrix.) Large and novel problems often demand mindful introspection, time-consuming research, and careful deliberation—none of which come naturally to someone wired to equate the size of a problem with its urgency. Beyond being prone to strategic myopia, entrepreneurs can struggle to delegate effectively. For example, suppose you hire somebody to do something you've been doing for years. Naturally, they'll have less experience and they'll be slower and worse than you at first. But patience and failure are anathema to most entrepreneurs. It takes every ounce of energy to stop themselves from grabbing the steering wheel the moment anyone takes a wrong turn. And when they do grab the wheel, the new hire does learn something: stay in your lane and out of that guy's way. Don't think for yourself. Defer decision-making to the boss. Hyper-productive people often complain that nobody else ever picks up the slack, but their own behavior is usually to blame.

Innovators

Another word that can make you a lot of money is innovation. People with an insatiable creative drive are always in demand, because there will always be new problems to solve and opportunities to seize. In this sense, "innovative" means more than throwing out a good idea in meetings every now and then. Innovators represent a fusion of creativity, proficiency, and pragmatism. There are plenty of incredibly-skilled creatives out there who don't build stuff. And there are plenty of highly-motivated builders who aren't the least bit creative. But when you combine all three elements, watch out.

The most innovative people I've worked with were absolute pains in the ass to deal with in the moment, and generally only appreciated by their colleagues in the past tense. That's because it would never cross the mind of an innovator to pay an ounce of respect to whatever plan is handed them. They bristle at any line of reasoning that doesn't perfectly mirror their own, and adamantly refuse to take a single step down a path they believe to be wrong. They stubbornly push back until they get a satisfactory answer to a thousand "Why" questions, with notably less interest in "Who," "What," "When," and "Where." As soon as they grasp the bigger picture, they run off in a direction of their own choosing. They can be wonderful collaborators to whoever is willing to get on board—and better to just go along with them, as they tend to out-hustle and outflank everyone else.

But by constantly coloring outside the lines, innovators are frequently seen as agitants. They disrupt the calm of their colleagues. Few organizations know how to incorporate itinerant change agents—the value they provide isn't well captured by most annual review rubrics. But sometimes, innovators manage to overcome this and capture lightning in a bottle and accomplish something nobody thought possible. And success seems to do a funny thing to people's memory, as everyone else is suddenly quick to brag and share war stories of working with them.

Innovators may lack as many telltale character flaws, but many share the same blind spot: whatever they're building, they don't care about the thing itself. That's because they're not in it for the outcome, they're chasing an experience—the practice of creating something no one has ever seen before. Lost in the act of creation, their relentless drive makes them like unguided missiles, ones that leaders can aim at whatever target they wish. In the early 2010s, I had the opportunity to grill engineers working at companies like Lyft, Airbnb, and GrubHub about the potential downstream harms their apps might eventually wreak. I never stopped being surprised at how little any of them had ever thought of it. The real-world impact of their work, good or bad, simply wasn't the point.

The Innovator's Other Dilemma

Of the three, I identify most as an innovator. It surprises people, but I've genuinely never cared about a single thing I had a hand in creating once I was done building it. After something's built, it no longer has anything of value to offer me. Whether it goes on to be used by a billion people or no one at all, I won't feel any differently. (I'd still reserve the right to boast at cocktail parties in the case of the former, however.)

There is one thing that doesn't sit well with me after writing this, though. The fact I've never cared about the things I've built means I've spent a lot of time building a lot of things that never mattered to me. Since striking out on my own in January 2024, I assumed the freedom to choose my own projects would allow me to identify work that really mattered to me. And I have! I've got a whole list and everything. Stuff that could change my life and others' lives for the better.

So far, I've taken all that time and freedom, and gone out of my way to build literally anything else with it. Not because I'm afraid of building those genuinely worthwhile things, but because those things' worthwhileness doesn't register as a valid criterion in my brain. The moment I sit down to work, my attention will be immediately captured by an unrelated problem and I won't be able to get it out of my head until it's either solved or supplanted by an even more daunting challenge. I won't let the day rest until I've proven to myself that it can be done. I can seemingly prove my ability to do anything except whatever it is I've consciously decided to do.

It's a strange, uncomfortable thing to sit with. Freedom often presents as a paradox. Maybe for an innovator, freedom to keep tinkering comes at the cost of a sort of aimlessness. A natural consequence when the motivation to tinker is for the act of tinkering itself.

I do have to say, though, that building meaningless stuff is a great way to pass the time. Realizing that's all I'm doing is hard, however. That I'm just passing time. When I get lost in my work, hours melt off the clock. Days pass in a blur. Precious weeks elapse. Seasons come and go—which, mercifully, doesn't mean much in Florida.

But if nothing changes this trajectory, will I regret it decades from now? Is this a problem I should be solving, and if so how? More rigor and discipline? More essays about my broken nature? More New Year's resolutions?

Who's to say.

At least I have a lot of experience deciding things don't matter to me. Perhaps that'll come in handy down the road.

Direct link to podcast audio file

It's an emergency bonus edition of Breaking Change as I take the covers off yet another show-within-a-show. I call it Feature Release, and its job is to fill in that middle number in our semantically versioned series of conversations together. No pun, no news, just some timely content wrapped up in a name, logo, and jingle package that still has that new podcast smell.

It's a 1-hour review of the Airpods, Apple Watch, and iPhone updates Apple announced today. You can see the full event video on YouTube. The Verge has a 17 minute abridged version if you just want the synopsis.

Please enjoy this episode of Feature Release! It may be the only one. Write into podcast@searls.co with your feedback!

My argument: If so many developers are so extraordinarily productive using these tools, where is the flood of shovelware? We should be seeing apps of all shapes and sizes, video games, new websites, mobile apps, software-as-a-service apps — we should be drowning in choice. We should be in the middle of an indie software revolution. We should be seeing 10,000 Tetris clones on Steam.

If you read the post, he's got data to this effect.

I've got two problems with this:

1. Much of his data basically stops around March–April 2025—the precise window when AI coding tools finally became worth a damn

2. Whether or not we're seeing a shovelware boom is orthogonal to the question of whether canny developers' output is being supercharged by AI. All it takes is one developer to show one project that was delivered in less time than they'd have been able to do otherwise and bingo-bango: AI tools as they exist today—flawed as they might be—can do something a human couldn't have done otherwise. Sure, you could make an argument about the macro-level effects—like whether the vast majority of professional programmers are too stupid or resistant to change to leverage these tools and are even somehow being slowed down by their existence, but I'd probably agree with you

Seriously, suggesting that AI-generated code is a nothingburger because we haven't yet been drowned in shovelware just four months after coding agents became remotely useful? Get outta here. And right now, only the early adopters are even using them! I talked to a manager the other day whose team has been given carte blanche to burn through all the Anthropic tokens they want and for whom not a single developer touched the account in the month of August.

I think it's important context to know that a lot of the statistics Microsoft and Anthropic put out are inflated because they have an obvious conflict of interest to push the message that the thing they sell is useful. I'm sure because many developers have GitHub Copilot turned on, they tend to press Tab without reading, then waste time mostly deleting what it produces. But, because the user mindlessly pressed Tab, somewhere a cell in a spreadsheet labeled "acceptance rate" ticks up. In practice, I suspect far fewer people are using these tools in anger than the big tech companies are incentivized to portray.

Having a full-fledged agent that can build shit for you and verify things work is—when it comes to productivity—nowhere near the same league as tacking autocomplete and an LLM chat sidebar into an editor. And here's the promised counterexample: I built some shovelware of my own last week. Took about a day of wall time to build and another calendar day for me to tighten up with feedback. I spent probably a grand total of three hours staring at computers in the furtherance of the project. This blog post about it took me twice as much time. Would have taken me weeks to build by hand, and more importantly, it wouldn't have been built at all—I wouldn't have bothered.

🔗 mikelovesrobots.substack.com

🧂 justin.searls.co

And yet, when it comes time to publish a CLI of my own, I usually just ship it as a Ruby gem or an npm package, because I had (and have!) no fucking clue how Homebrew works. I'm not enough of a neckbeard to peer behind the curtain as soon as root directories like /usr and /opt are involved, so I never bothered before today.

But it's 2025 and we can consult LLMs to conjure whatever arcane incantations we need. And because he listens to the cast, I can always fall back on texting Mike McQuaid when his docs suck.

So, because I'll never remember any of this shit (it's already fading from view as I type this), below are the steps involved in publishing your own CLI to Homebrew. The first formula I published is a simple Ruby script, but this guide should be generally applicable.

Glossary

Because Homebrew really fucking leans in to the whole "home brewing as in beer" motif when it comes to naming, it's easy to get lost in the not-particularly-apt nomenclature they chose.

Translate these in your head when you encounter them:

• Formula → Package definition
• Tap → Git repository of formulae
• Cask → Manifest for installing pre-built GUIs or large binaries
• Bottle → Pre-built binary packages that are "poured" (copied) instead of built from source
• Cellar → Directory containing your installed formulae (e.g. /opt/homebrew/Cellar)
• Keg → Directory housing an installed formula (e.g. Cellar/foo/1.2.3)

Overview

First thing to know is that the Homebrew team doesn't want your stupid CLI in the core repository.

Instead, the golden path for us non-famous people is to:

1. Make your CLI, push it to GitHub, cut a tagged release
2. Create a Homebrew tap
3. Create a Homebrew formula
4. Update the formula for each CLI release

After you complete the steps outlined below, users will be able to install your cool CLI in just two commands:

brew tap your_github_handle/tap
brew install your_cool_cli

Leaving the "make your CLI" step as an exercise for the reader, let's walk through the three steps required to distribute it on Homebrew. In my case, I slopped up a CLI called imsg that creates interactive web archives from an iMessage database.

Create your tap

Here's Homebrew's guide on creating a tap. Let's follow along how I set things up for myself. Just replace each example with your own username or organization.

For simplicity's sake, you probably want a single tap for all the command line tools you publish moving forward. If that's the case, then you want to name the tap homebrew-tap. The homebrew prefix is treated specially by the brew CLI and the tap suffix is conventional.

First, create the tap:

brew tap-new searlsco/homebrew-tap

This creates a scaffold in /opt/homebrew/Library/Taps/searlsco/homebrew-tap. Next, I created a matching repository in GitHub and pushed what Homebrew generated:

cd /opt/homebrew/Library/Taps/searlsco/homebrew-tap
git remote add origin git@github.com:searlsco/homebrew-tap.git
git push -u origin main

Congratulations, you're the proud owner of a tap. Now other homebrew users can run:

brew tap searlsco/tap

It doesn't contain anything useful, but they can run it. The command will clone your repository into their /opt/homebrew/Library/Taps directory.

Create your formula

Even though Homebrew depends on all manner of git operations to function and fully supports just pointing your formula at a GitHub repository, the Homebrew team recommends instead referencing versioned tarballs with checksums. Why? Something something reproducibility, yadda yadda open source supply chain. Whatever, let's just do it their way.

One nifty feature of GitHub is that they'll host a tarball archive of any tags you push at a predictable URL. That means if I run these commands in the imsg repository:

git tag v0.0.5
git push --tags

Then GitHub will host a tarball at github.com/searlsco/imsg/archive/refs/tags/v0.0.5.tar.gz.

Once we have that tarball URL, we can use brew create to generate our formula:

brew create https://github.com/searlsco/imsg/archive/refs/tags/v0.0.5.tar.gz --tap searlsco/homebrew-tap --set-name imsg --ruby

The three flags there do the following:

• --tap points it to the custom tap we created in the previous step, and will place the formula in /opt/homebrew/Library/Taps/searlsco/homebrew-tap/Formula
• --set-name imsg will name the formula explicitly, though brew create would have inferred this and confirmed it interactively. The name should be unique so you don't do something stupid like make a CLI named TLDR when there's already a CLI named TLDR or a CLI named standard when there's already a CLI named standard
• --ruby is one of several template presets provided to simplify the task of customizing your formula

Congratulations! You now have a formula for your CLI. It almost certainly doesn't work and you almost certainly have no clue how to make it work, but it's yours!

This is where LLMs come in.

1. Run brew install --verbose imsg
2. Paste what broke into ChatGPT
3. Update formula
4. GOTO 1 until it works

Eventually, I wound up with a working Formula/imsg.rb file. (If you're publishing a Ruby CLI, feel free to copy-paste it as a starting point.) Importantly, and a big reason to distribute via Homebrew as opposed to a language-specific package manager, is that I could theoretically swap out the implementation for some other language entirely without disrupting users' ability to upgrade.

Key highlights if you're reading the formula contents:

• All formulae are written in Ruby, not just Ruby-related formulae. Before JavaScript and AI took turns devouring the universe, popular developer tools were often written in Ruby and Homebrew is one of those
• You can specify your formula's git repository with the head method (though I'm unsure this does anything)
• Adding a livecheck seemed easy and worth doing
• Adding a test to ensure the binary runs can be as simple as asserting on help output. Don't let the generated comment scare you off
• Run brew style searlsco/tap to make sure you didn't fuck anything up.
• By default, the --ruby template adds uses_from_macos "ruby", which is currently version 2.6.10 (which was released before the Covid pandemic and end-of-life'd over three years ago). You probably want to rely on the ruby formula with depends_on "ruby@3" instead

When you're happy with it, just git push and your formula is live! Now any homebrew user can install your thing:

brew tap searlsco/tap
brew install imsg

Update the formula for each CLI release

Of course, any joy I derived from getting this to work was fleeting, because of this bullshit at the top of the formula:

class Imsg < Formula
  url "https://github.com/searlsco/imsg/archive/refs/tags/v0.0.5.tar.gz"
  sha256 "e9166c70bfb90ae38c00c3ee042af8d2a9443d06afaeaf25a202ee8d66d1ca04"

Who the fuck's job is it going to be to update these URLs and SHA hashes? Certainly not mine. I barely have the patience to git push my work, much less tag it. And forget about clicking around to create a GitHub release. Now I need to open a second project and update the version there, too? And compute a hash? Get the fuck out of here.

Now, I will grant that Homebrew ships with a command that opens a PR for each formula update and some guy wrapped it in a GitHub action, but both assume you want to daintily fork the tap and humbly submit a pull request to yourself. Clearly all this shit was designed back when Homebrew was letting anybody spam shit into homebrew-core. It's my tap, just give me a way to commit to main, please and thank you.

So anyway, you can jump through all those hoops each time you update your CLI if you're a sucker. But be honest with yourself, you're just gonna wind up back at this stupid blog post again, because you'll have forgotten the process. To avoid this, I asked my AI companion to add a GitHub workflow to my formula repository that automatically commits release updates to my tap repository.

If you want to join me in the fast lane, feel free to copy paste my workflow as a starting point. The only things you'll need to set up yourself:

• You'll need a personal-access token:
  • When creating the PAT, add your homebrew-tap repository and Content → Write permissions
  • In the formula repository's settings under Secrets and variables → Actions → Repository secrets and name it HOMEBREW_TAP_TOKEN (GitHub docs)
• You'll need to specify the tap and formula environment variables
• You'll probably want to update the GitHub bot account, probably to the GitHub Actions bot if you don't have your own:
  • GH_EMAIL: 41898282+github-actions[bot]@users.noreply.github.com
  • GH_NAME: github-actions[bot]

Now, whenever you cut a release, your tap will be updated automatically. Within a few seconds of running git push --tags in your formula's repositories, your users will be able to upgrade their installations with:

brew update
brew upgrade imsg

That's it. Job's done!

The best part

This was a royal pain in the ass to figure out, so hopefully this guide was helpful. The best part is that once your tap is set up and configured and you have a single working formula to serve as an example, publishing additional CLI tools in the future becomes almost trivial.

Now, will I actually ever publish another formula? Beats me. But it feels nice to know it would only take me a few minutes if I wanted to. 🍻

Reddit turned me onto this just-every/code fork of OpenAI's Codex CLI last night. Since it uses the binary name coder to differentiate it from code and codex, I guess we should just call this thing Coder.

In addition to everything you get with Codex:

• A built-in diff viewer (Ctrl+D). If you're like me, you often have Claude Code or Codex open in one window and your preferred Git UI (I use Fork) in a second window, so having it integrated is wonderful. Moreover, while viewing a diff, you can press e to request an explanation of the specific change you're looking at
• Built-in browser support with ASCII previews (Ctrl+B) Like Playwright, it automates browsers over the very fast CDP, and it takes zero futzing to get started with it (unlike tacking an MCP tool onto Claude)
• Multi-agent consensus If you're a real sicko, you can hand the same question or task to all three of GPT, Claude, and Gemini and keep the consensus winner among them

Coder also has a themeable, more stable curses-like UI (as opposed to top-level terminal scrollback). It's the rare case of a community taking a heavily-funded corporate open source project and adding a lot of visual flair and spit polish to it. But I'll be damned if this isn't a much nicer experience than either Claude Code or Codex out of the box. (I can't speak to OpenCode, but since it doesn't support ChatGPT subscriptions, I'm not interested in it.)

The psychology of winning is also more complex than anyone admits. There's an immediate high, followed by a weird emptiness. You've achieved something you've been working toward, and suddenly you need new goals. Some winners describe a mild depression that follows major recognition, the "What now?" syndrome that comes when you realize that achieving your dreams doesn't fundamentally change who you are or solve your deeper creative challenges.

In my experience this phenomenon extends to any achievement or event that redounds to a significant moment of extrinsic validation in one's career. Anthony's description of the hangover effect following an award win mirrors exactly what it felt like to give a big conference talk or keynote address, especially if it was a "first" for me and doubly-so if it was very well received. It was always followed by a brief and intense emotional high followed by a deep well of uncertainty and exhaustion. A lesson I learned every conference season and promptly unlearned just in time for the subsequent year's conference season.

Speaking of conference season, I retired from speaking a year ago and it's that time again. Rails World is this week and lots of my friends are in Amsterdam and I am experiencing absolutely no FOMO. Don't miss it at all. Few things are as intrinsically validating as accurately forecasting how a consequential decision will ultimately make you feel. Zero regrets.

🔗 anthonysalamon.com

🧂 justin.searls.co

When Google restricts your ability to install certain applications they aren't constraining what you can do with the hardware you own, they are constraining what you can do using the software they provide with said hardware.

To wit, if you own your iPhone outright, it's completely reasonable to demand that you be able to boot an alternative operating system and, to whatever extent regulatory action against the platform holders is warranted, it should be targeting this layer of the software stack as opposed to mandating how specific features of the operating system ought to function.

Which means the remedy would look a bit like the surprisingly-successful Right to Repair movement:

However, our critique shouldn't be of the restrictions in place in the operating systems they provide – rather, it should focus on the ability to truly run any code we want on hardware we own. In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware. It should be possible to run Android on an iPhone and manufacturers should be required by law to provide enough technical support and documentation to make the development of new operating systems possible.

A "Right to Run" movement that demanded hardware vendors enable their devices to run unsigned operating systems—and to perhaps provide documentation and device drivers—seems to me like it would stand on far firmer legal and conceptual ground than the knots the Europe Commission has tied itself in trying to enforce the Digital Markets Act.

Of course, pragmatist regulators would point out that approximately abso-fucking-nobody would go to the trouble of running "Linux on the phone," because of how miserable an experience it would be relative to using the default operating system. And the platform holders would justifiably cry foul that criminals and state actors could effectively rootkit people's devices and gain an unbelievable amount of surveillance and control over their lives. But there's no form of freedom that doesn't pose these sorts of risks.

Anyway, interesting idea.

🔗 hugotunius.se

🧂 justin.searls.co

Direct link to podcast audio file

Remember it is your civic duty to e-mail me at podcast@searls.co. As of this episode, that address is monitored by Fastmail, so there's a higher probability I'll actually get your e-mail!

Some links you won't click:

• Why I-4 is the most dangerous highway in America
• The Beak and the Barrel
• Sign up for Fastmail. It is good.
• The Gilroy Order
• Making ChatGPT doubt itself
• Why I wasn't cut out for management
• How to comment on my blog
• Aaron's puns, ranked
• New Xcode beta adds GPT-5, Claude account support
• Apple Responds to Accusations of Jay Blahnik Creating 'Toxic Workplace'
• 4chan Refuses To Pay UK Online Safety Act Fines
• Americans' junk-filled garages are hurting EV adoption, study says
• New Book Argues Hybrid Schedules 'Don't Work', Return-to-Office Brings Motivation and Learning
• Shenmue 3 is getting an Enhanced edition
• Raguelike game may portend AI disruption in the gaming industry
• Making cash off 'AI slop': The surreal video business taking over the web (News+)
• Stellantis shelves Level 3 driver-assistance program that totally works and has no problems
• Salesforce CEO Marc Benioff says AI enabled him to cut 4,000 jobs
• Timeline Japan: 1980
• Perfect Days
• Rental Family
• Black Mirror Season 7
• Yumtein Gummy Bears
• Listener Björn made this Equaliteam app

What Scott means when he says he's a cinder block developer. Clipped from Hotfix v42.0.1.

Oh, and here's that episode of The Secret Life of Machines on washing machines

I answered, "actually my blog does have a comment system."

Here's how to leave a comment on this web site:

1. Read a post
2. Think, "I want to comment on this"
3. Draft a post on your blog
4. Add a hyperlink to my post
5. Paste an excerpt to which you want to respond
6. Write your comment
7. Hit publish

I admit, it's quaint. It involves a number of invisible steps, like 2.1 where you start a blog (which is actually pretty easy but not free of friction). You should try it.

It is 2025 and the Web—the capital-W Web—is beleaguered. The major platforms have long-since succumbed to enshittification, but their users aren't going anywhere. Some among us courageously voice their dissent, but always from the safe confines of their favorite walled garden. They drop a note in the jailkeeper's suggestion box as they scroll past the Squarespace ads littering their algorithmic timelines. Others have fled to open and open-flavored networks, but everyone eventually realizes they can't go home again.

But that's not why I want you to adopt this blog's commenting system. I'm not a high-minded individual who cares about the intellectual project of the World Wide Web as a bastion for free expression or whatever the fuck. No. I just had a super rad time on the Internet from 2000 to 2006 and I want to do my part to bring it back.

Back then, I would find a blog and follow it—via its feed when possible, or else by adding it to a folder of bookmarks—and check it daily.

But what about discoverability? How did anyone find these websites? Bloggers couldn't rely on platforms' social graphs or algorithmic timelines to build awareness, so they had to bake discoverability into the product. Some sites had a "blogroll" of recommendations in the sidebar. But the most effective approach was the art of "blogging as a conversation." When an author read something that provoked them to write, they'd link to the offending piece, excerpt it, and provide their own commentary. And because humans are vain, the original post's author would frequently circle back and write their own response to the response. The net effect was that each author's audience would get exposure to the other writer. Even if the authors were in violent disagreement, readers of one might appreciate the other's perspective and subscribe to them.

Blogging as a conversation—as a comments section—was valuable because it was purely positive-sum. As an author, I benefit because another author's opinions inspired me to write. The other author benefits because linking to them offers access to my readership. My readers benefit because they're exposed to complementary and contrasting viewpoints.

Growth was slow and organic but more meaningful and durable. It was a special time.

Today, as the platforms wane, it feels like this conversational approach to blogging is seeing new life. As a readership has slowly gathered around this blog, I've separately been curating a fresh list of thoughtful bloggers that inspire me to write. Maybe I'll add a blogroll to my next redesign. I'm already writing more linkposts.

In short, blogging might be back. Hell, I just came back from coffee with my friend Anthony, and—without my having brought up the topic—he showed me his new blog.

So, if you're considering engaging with my comment system—if you're thinking about starting a blog or dusting off your old one—here's some unsolicited advice:

• Do it for you. Priority one is taking the time to grapple with your thoughts, organize your ideas, and put them into words. Priority two is reaching the finish line and feeling the pride of authorship. That anyone actually reads your work should be a distant third place
• Focus on building an audience rather than maximizing reach. Getting in front of eyeballs is easier on the platform, but it's fleeting. Platforms reward incitement, readers reward insight. Success is a lagging indicator of months and years of effort, but it's long-lasting. I genuinely believe each of the readers of this site are as valuable as a hundred followers on social media
• Give your blog your best work. Don't waste your creative juices trying to be clever on someone else's app. Consider syndicating crossposts to your social accounts as a breadcrumb trail leading back to your homepage. You can do this with Buffer, Publer, SocialBee, or my upcoming POSSE Party
• Cut yourself some slack. Pretty much everyone is an awful writer. If you saw how long it takes me to write anything of substance, you'd agree that I'm an awful writer, too. Thankfully, good ideas have a way of shining through weak rhetoric and bad grammar. All that matters is training this learned response: have an idea, write it down, put it out

That's all I've got. If you choose to leave a comment on this post on your own blog, e-mail it to me, and I'd be delighted to read it. Maybe it'll inspire me to write a response! 💜

One thing few people are talking about is how it's not as simple as people being sticks in the mud with respect to the adoption of AI tools, it's that once they get their hands on this tremendously capable set of tools, they lack the imagination to find any use for it. "They've been given this rocket ship and they've got no fucking clue where to fly it."

Clipped from the back half of my discussion with Scott Werner on Hotfix.

Direct link to podcast audio file

🔥Hotfix🔥 is back with a new guest! Scott Werner is the CEO of Sublayer, helps organize the Artificial Ruby meetup in NYC, and is the author of the extremely well-named (and well-written) Substack, Works on my Machine.

In this conversation, we jointly grapple with WTF is happening to programming as a career. Did the unprecedented peacetime the software industry experienced from 2005-2022 make us all soft? Is the era of code-writing agents fundamentally changing the nature of the job? Should we be less like DHH/Matz and more like why the lucky stiff?

We'd love to get your feedback to podcast@searls.co — I'll read it all and flag relevant questions and comments for the next Breaking Change.

You can follow Scott Werner online at:

• Works on my Machine on Substack
• @scottwernerd on Twitter/X

A handful of things we mentioned:

• There's no AI in Team
• The Goal book
• Lean Thinking vs Fat Thinking (a newsletter that draws a different lesson from The Goal)
• why the lucky stiff (aka "_why")
• That fireside chat between Matz and DHH
• Sublayer's product, APM (Actions Per Minute)

I constantly inspect my work, effortlessly identify ways it could be better, and never tire of making improvements. And because the time it takes to finish a task can always be improved, this tendency rarely veers into unproductive perfectionism. On the rare occasion I feel like I really nail something, I strive to nail it even faster next time. At the same time (and as anyone who listens to Breaking Change knows), I have a very healthy ego. I genuinely believe I am good enough, despite simultaneously knowing my work never is.

The trouble is, while this disposition might be dynamite for self-improvement, it doesn't gracefully scale to teams and organizations.

I'm thinking about this because yours truly was a dummy again and found the Hacker News comment thread for one of my posts and chose to engage:

I've been griping about LLM overconfidence for years, as somebody who is racked with self-doubt and second-guessing. On the one hand, my own low opinion of myself made me a terrible mentor and manager, because having a similarly zero-trust policy towards my colleagues' work caused no end of friction (especially as a founder where people looked up to me for validation). On the other hand, I don't know very many top-tier practitioners that don't exhibit significantly more self-doubt than an off-the-shelf LLM.

I'm not sure I've ever explained this publicly before, but this predilection for doubting myself is fundamentally why I was never a particularly good "senior" member of a team. As Test Double grew, we managed to create spots where I could remain a practitioner, but we also had to be mindful of limiting the blast radius of my reflexive hypercriticality. The truth is that my special sauce depends on constant emotionally vulnerable self-critique, and that made it extraordinarily difficult to manage or coach people directly. Even for people who are wired similarly to me—which many of Test Double's agents are—it's one thing to look at your own work and spot endless opportunities for improvement, but it's quite another for someone in a position of authority to do the same.

Every time I was charged with evaluating someone else's work, it started up the same engine that generate an infinite supply of shortcomings in my own. And it wasn't that I was incapable of prioritizing or rate-limiting my comments—it's that when people came to me with revisions, I'd always find fault in those too—because I can always find ways the work could be better! It led to people feeling like they could never be good enough for me.

After touching the hot stove once or twice, I learned to spend all my time assembling shit sandwiches to protect people's feelings, or my relationship with them, or—as a highly visible co-founder—the company's reputation. Every patty of pointed and meaningful critique demanded two slices of ego-insulating bread. And one man can only bullshit his way through so much halfhearted positive reinforcement and self-effacing humility. Even if I hadn't found all that tap-dancing to be a nerve-wracking waste of time, everyone could see through me. It wasn't authentic.

Are there ways I could have overcome all this and become a good manager anyway? Probably. But would I risk losing the thing that made me unique in the process? Possibly.

I'm writing this in part because it's so clear that LLMs-as-products are being sold to us with the default wiring of a capital-B Business Guy, and their shortcomings resemble the same shortcomings I see in humans who are insufficiently self-critical. But it's also possible you, reading this, are a Business Guy and you're curious how so many amazing programmers turn out to be shit at coaching less-skilled colleagues, the root cause may not be poor communication skills: it may be that the self-criticism that drives some practitioners to greatness is impossible to convey safely to others without risking a call to HR.

Anyway, if you identify with me, but have nevertheless made the transition to manager and leader gracefully, then I applaud you. (I'd also be curious to speak with a couple folks who report to you and see what they have to say.)

🔗 news.ycombinator.com

🧂 justin.searls.co

• Be extraordinarily skeptical of your own correctness or stated assumptions. You aren't a cynic, you are a highly critical thinker and this is tempered by your self-doubt: you absolutely hate being wrong but you live in constant fear of it
• When appropriate, broaden the scope of inquiry beyond the stated assumptions to think through unconvenitional opportunities, risks, and pattern-matching to widen the aperture of solutions
• Before calling anything "done" or "working", take a second look at it ("red team" it) to critically analyze that you really are done or it really is working

I noticed a difference in results right away (even though I kept forgetting the change was due to my instructions and not the separately tumultuous rollout of GPT-5).

Namely, pretty much every initial response now starts with:

• An expression of caution, self-doubt, and desire to get things right
• Hilariously long "thinking" times (I asked it to estimate the macronutrients in lettuce yesterday and it spent 3 minutes and 59 seconds reasoning)
• A post-hoc adversarial "red team" analysis of whatever it just vomited up as an answer

I'm delighted to report that ChatGPT's output has been more useful since this change. Still not altogether great, but better at the margins. In particular, the "red team" analysis at the end of many requests frequently spots an error and causes it to arrive at the actually-correct answer, which—if nothing else—saves me the step of expressing skepticism. And even when ChatGPT is nevertheless wrong, its penchant for extremely-long thinking times means I'm getting my money's worth in GPU time.

Because I've had to explain the concept over and over again to every potential guest, I sat down to write a list of what they'd be getting themselves into by agreeing to come on the show. (Can't say I didn't warn them!)

Here's the rider I send prospective guests:

• Each Hotfix episode exists to address some problem. Unlike a typical interview show featuring an unstructured open-ended conversation with a guest, we pick a particular problem in advance—ideally one that the guest gets really animated/activated or even angry about—and we jointly rant about it, gradually exploring its root causes and breaking it down together
• Each episode concludes with us answering the question, "what's the hotfix?" Ultimately, we decide on a pithy, reductive one-line solution to the problem that will serve as the show title (ideally, it's a hot take that not everyone will agree with or feel comfortable about)
• It's an explicit-language show and I'm pretty clear with the audience that the Breaking Change family of brands is intended for terrible people (or at least, the terrible person inside all of us). You aren't required to swear to be on the show, but if my potty mouth makes you uncomfortable, then let me know and I'll recommend some worse podcasts you can appear on instead
• I joke at the top that my goal as the host is to, "get my guest to say something that'll get them fired." Since I'm functionally retired and have no reason to hold back from explicit language, irreverence, and dark humor in the mainline Breaking Change podcast, I can't help but poke guests with attempts to drag them down to my level. You can play with this as much as you want or take the high ground, but we'll all have more fun if you let loose a bit more than you otherwise would
• Why am I doing this? First, because I'm incurious and uninterested in learning about other people, which I'm told is an important part of being a good interviewer. Second, I have a theory that this unusual brand of authenticity will lend credibility to whatever solution the guest is trying to argue for or plug. By keeping listeners on their toes and pushing them out of their comfort zones, each episode stands to effect greater change than a typical milquetoast podcast could

If this has piqued your interest, you can listen to or watch the first episode of Hotfix with Dave Mosher. It may not seem very hot at first, but please grade on a curve as Dave speaks Canadian English. I've got a couple exciting guests booked over the next few weeks and I'm looking forward to seeing where the show takes us.

So instead of directing the following statements at you, let's target our judgment toward your colleagues. Think about a random colleague you don't feel particularly strongly about as you read the following pithy and reductive bullet points. Critically appraise how they show up to work through the entire software delivery process. These represent just a sample of observations I've made about developers who are truly thriving so far in the burgeoning age of AI code generation tools.

That colleague you're thinking about? They're going to be screwed if they exhibit:

• Curiosity without skepticism
• Strategy without experiments
• Ability without understanding
• Productivity without urgency
• Creativity without taste
• Certainty without evidence

But that's not all! You might be screwed too. Maybe ask one of your less-screwed colleagues to rate you.

I remember back when Rod Hilton suggested The Machete Order for introducing others to the Star Wars films and struggling to find fault with it. Well, since then there have been 5 theatrical releases and a glut of streaming series. And tonight, as credits rolled on Return of the Jedi, I had the thought that an even better watch order has emerged for those just now being exposed to the franchise.

Becky and I first started dating somewhere between the release of Attack of the Clones and Revenge of the Sith and—no small measure of her devotion—she's humored me by seeing each subsequent Star Wars movie in theaters, despite having no interest in the films and little idea what was going on. Get yourself a girl who'll watch half a dozen movies that mildly repulse her, fellas.

Hell, when we were living in Japan, I missed that 吹替 ("dubbed") was printed on our tickets and she wound up sitting through the entirety of The Rise of Skywalker with Japanese voiceovers and no subtitles to speak of. When we walked out, she told me that she (1) was all set with Star Wars movies for a while, and (2) suspected the incomprehensibility of the Japanese dub had probably improved the experience, on balance.

That all changed when she decided to give Andor a chance. See, if you're not a Star Wars fan, Tony Gilroy's Andor series is unique in the franchise for being actually good. Like, it's seriously one of the best TV shows to see release in years. After its initial three-episode arc, Becky was fully on board for watching both of its 12-episode seasons. And the minute we finished Season 2, she was ready to watch Rogue One with fresh eyes. ("I actually have a clue what's going on now.") And, of course, with the way Rogue One leads directly into the opening scene of A New Hope, we just kept rolling from there.

Following this experience, I'd suggest sharing Star Wars with your unsuspecting loved ones in what I guess I'd call The Gilroy Order:

1. Andor (seasons 1 and 2)
2. Rogue One
3. A New Hope
4. The Empire Strikes Back
5. Return of the Jedi

If, at this point, you're still on speaking terms with said loved ones, go ahead and watch the remaining Star Wars schlock in whatever order you want. Maybe you go straight to The Mandalorian. Maybe you watch The Force Awakens just so you can watch the second and final film of the third trilogy, The Last Jedi. Maybe you quit while you're ahead and wait for Disney to release anything half as good as Andor ever again. (Don't hold your breath.)

Anyway, the reason I'm taking the time to propose an alternative watch order at all is an expression of the degree to which I am utterly shocked that my wife just watched and enjoyed so many Star Wars movies after struggling to tolerate them for the first two decades of our relationship. I'm literally worried I might have broken her.

But really, it turned out that all she needed was for a genuinely well-crafted narrative to hook her, and Andor is undeniably the best ambassador the franchise currently has.

1. Start with a struct representing a PromptSet: a variable set of prompts that will either map onto or be used to define the ultimate response data structure 🔽
2. Instantiate a PromptSet with—what else?—a set of prompts to get the model to generate the sort of data we want 🔽
3. Build out a DynamicGenerationSchema based on the contents of a given PromptSet instance 🔽
4. Create a struct that can accommodate the variably-shaped data with as much type safety as possible and which conforms to ConvertibleFromGeneratedContent, so it can be instantiated by passing a LanguageModelSession response's GeneratedContent 🔽
5. Pull it all together and generate some data with the on-device foundation models! 🔽

Well, it took me all morning to get this to work, but I did it. Since I couldn't find a single code example that did anything like this, I figured I'd share this write up. You can read the code as a standalone Swift file or otherwise follow along below.

1. Define a PromptSet

Start with whatever code you need to represent the set(s) of prompts you'll be dealing with at runtime. (Maybe they're defined by you and ship with your app, maybe you let users define them through your app's UI.) To keep things minimal, I defined this one with a couple of mandatory fields and a variable number of custom ones:

struct EducationalPromptSet {
  let type: String
  let instructions: String

  let name: String
  let description: String

  let summaryGuideDescription: String
  let confidenceGuideDescription: String
  let subComponents: [SubComponentPromptSet]
}

struct SubComponentPromptSet {
  let title: String
  let bodyGuideDescription: String
}

Note that rather than modeling the data itself, the purpose of these structs is to model the set of prompts that will ultimately drive the creation of the schema which will, in turn, determine the shape and contents of the data we get back from the Foundation Models API. To drive this home, whatever goes in summaryGuideDescription, confidenceGuideDescription, and bodyGuideDescription should themselves be prompts to guide the generation of like-named type-safe values.

Yes, it is very meta.

2. Instantiate our PromptSet

Presumably, we could decode some JSON from a file or received over the network that could populate this EducationalPromptSet. Here's an example set of prompts for generating cocktail recipes, expressed in some sample code:

let cocktailPromptSet = EducationalPromptSet(
  type: "bartender_basic",
  instructions: """
    You are an expert bartender. Take the provided cocktail name or list of ingredients and explain how to make a delicious cocktail. Be creative!
    """,

  name: "Cocktail Recipe",
  description: "A custom cocktail recipe, tailored to the user's input and communicated in an educational tone and spirit",
  summaryGuideDescription: "The summary should describe the history (if applicable) and taste profile of the cocktail",
  confidenceGuideDescription: "Range between 0-100 for your confidence in the feasibility of this cocktail based on the prompt",
  subComponents: [
    SubComponentPromptSet(title: "Ingredients", bodyGuideDescription: "A list of all ingredients in the cocktail"),
    SubComponentPromptSet(title: "Steps", bodyGuideDescription: "A list of the steps to make the cocktail"),
    SubComponentPromptSet(title: "Prep", bodyGuideDescription: "The bar prep you should have completed in advance of service")
  ]
)

You can see that the provided instruction, description, and each guide description really go a long way to specify what kind of data we are ultimately looking for here. This same format could just as well be used to specify an EducationalPromptSet for calculus formulas, Japanese idioms, or bomb-making instructions.

3. Build a DynamicGenerationSchema

Now, we must translate our prompt set into a DynamicGenerationSchema.

Why DynamicGenerationSchema and not the much simpler and defined-at-compile-time GenerationSchema that's expanded with the @Generable? Because reasons:

1. We only know the prompts (in API parlance, "Generation Guide descriptions") at runtime, and the @Guide macro must be specified statically
2. We don't know how many subComponents a prompt set instance will specify in advance
3. While subComponents may ultimately redound to an array of strings, that doesn't mean they represent like concepts that could be generated by a single prompt (as an array of ingredient names might). Rather, each subComponent is effectively the answer to a different, unknowable-at-compile-time prompt of its own

As for building the DynamicGenerationSchema, you can break this up into two roots and have the parent reference the child, but after experimenting, I preferred just specifying it all in one go. (One reason not to get too clever about extracting these is that DynamicGenerationSchema.Property is not Sendable, which can easily lead to concurrency-safety violations).

This looks like a lot because this API is verbose as fuck, forcing you to oscillate between nested schemas and properties and schemas:

let cocktailSchema = DynamicGenerationSchema(
  name: cocktailPromptSet.name,
  description: cocktailPromptSet.description,
  properties: [
    DynamicGenerationSchema.Property(
      name: "summary",
      description: cocktailPromptSet.summaryGuideDescription,
      schema: DynamicGenerationSchema(type: String.self)
    ),
    DynamicGenerationSchema.Property(
      name: "confidence",
      description: cocktailPromptSet.confidenceGuideDescription,
      schema: DynamicGenerationSchema(type: Int.self)
    ),
    DynamicGenerationSchema.Property(
      name: "subComponents",
      schema: DynamicGenerationSchema(
        name: "subComponents",
        properties: cocktailPromptSet.subComponents.map { subComponentPromptSet in
          DynamicGenerationSchema.Property(
            name: subComponentPromptSet.title,
            description: subComponentPromptSet.bodyGuideDescription,
            schema: DynamicGenerationSchema(type: String.self)
          )
        }
      )
    )
  ]
)

4. Define a result struct that conforms to ConvertibleFromGeneratedContent

When conforming to ConvertibleFromGeneratedContent, a type can be instantiated with nothing more than the GeneratedContent returned from a language model response.

There is a lot going on here. Code now, questions later:

struct EducationalResult : ConvertibleFromGeneratedContent {
  let summary: String
  let confidence: Int
  let subComponents: [SubComponentResult]

  init(_ content: GeneratedContent) throws {
    summary = try content.value(String.self, forProperty: "summary")
    confidence = try content.value(Int.self, forProperty: "confidence")
    let subComponentsContent = try content.value(GeneratedContent.self, forProperty: "subComponents")
    let properties: [String: GeneratedContent] = {
      if case let .structure(properties, _) = subComponentsContent.kind {
        return properties
      }
      return [:]
    }()
    subComponents = try properties.map { (title, bodyContent) in
      try SubComponentResult(title: title, body: bodyContent.value(String.self))
    }
  }
}

struct SubComponentResult {
  let title: String
  let body: String
}

That init constructor is doing the Lord's work, here, because Apple's documentation really fell down on the job this time. See, through OS 26 beta 4, if you had a GeneratedContent, you could simply iterate over a dictionary of its properties or an array of its elements. These APIs, however, appear to have been removed in OS 26 beta 5. I say "appear to have been removed," because Apple shipped Xcode 26 beta 5 with outdated developer documentation that continues to suggest they should exist and which failed to include beta 5's newly-added GeneratedContent.Kind enum. Between this and the lack of any example code or blog posts, I spent most of today wondering whether I'd lost my goddamn mind.

Anyway, good news: you can iterate over a dynamic schema's collection of properties of unknown name and size by unwrapping the response.content.kind enumerator. In my case, I know my subComponents will always be a structure, because I'm the guy who defined my schema and the nice thing about the Foundation Models API is that its responses always, yes, always adhere to the types specified by the requested schema, whether static or dynamic.

So let's break down what went into deriving the value's customProperties property.

We start by fetching a nested GeneratedContent from the top-level property named subComponents with content.value(GeneratedContent.self, forProperty: "subComponents")

Next, this little nugget assigns to properties a dictionary mapping String keys to GeneratedContent values by unwrapping the properties from the kind enumerator's structure case, and defaulting to an empty dictionary in the event we get anything unexpected:

let properties: [String: GeneratedContent] = {
  if case let .structure(properties, _) = subComponentsContent.kind {
    return properties
  }
  return [:]
}()

Finally, we build out our result struct's subComponents field by mapping over those properties.

subComponents = try properties.map { (title, bodyContent) in
  try SubComponentResult(title: title, body: bodyContent.value(String.self))
}

Two things are admittedly weird about that last bit:

1. I got a little lazy here by using the each sub-components' title as the name of the corresponding generated property. Since the property name gets fed into the LLM, one can only imagine doing so can only improve the results. Based on my experience so far, the name of a field greatly influences what kind of data you get back from the on-device foundation models.
2. The bodyContent itself is a GeneratedContent that we know to be a string (again, because that's what our dynamic schema specifies), so we can safely demand one back using its value(Type) method

5. Pull it all together

Okay, the moment of truth. This shit compiles, but will it work? At least as of OS 26 betas 5 & 6: yes!

My aforementioned Swift file ends with a #Playground you can actually futz with interactively in Xcode 26 and navigate the results interactively. Just three more calls to get your cocktail:

import Playgrounds
#Playground {
  let session = LanguageModelSession {
    cocktailPromptSet.instructions
  }

  let response = try await session.respond(
    to: "Shirley Temple",
    schema: GenerationSchema(root: cocktailSchema, dependencies: [])
  )

  let cocktailResult = try EducationalResult(response.content)
}

The above yielded this response:

EducationalResult(
  summary: "The Shirley Temple is a classic and refreshing cocktail that has been delighting children and adults alike for generations. It\'s known for its simplicity, sweet taste, and vibrant orange hue. Made primarily with ginger ale, it\'s a perfect example of a kid-friendly drink that doesn\'t compromise on flavor. The combination of ginger ale and grenadine creates a visually appealing and sweet-tart beverage, making it a staple at parties, brunches, and any occasion where a fun and easy drink is needed.",
  confidence: 100,
  subComponents: [
    SubComponentResult(title: "Steps", body: "1. In a tall glass filled with ice, pour 2 oz of ginger ale. 2. Add 1 oz of grenadine carefully, swirling gently to combine. 3. Garnish with an orange slice and a cherry on top."),
    SubComponentResult(title: "Prep", body: "Ensure you have fresh ginger ale and grenadine ready to go."),
    SubComponentResult(title: "Ingredients", body: "2 oz ginger ale, 1 oz grenadine, Orange slice, Cherry")
])

The best part? I can only generate "Shirley Temple" drinks because whenever I ask for an alcoholic cocktail, it trips the on-device models' safety guardrails and refuses to generate anything.

Cool!

This was too hard

I've heard stories about Apple's documentation being bad, but never about it being straight-up wrong. Live by the beta, die by the beta, I guess.

In any case, between the documentation snafu and Claude Code repeatedly shitting the bed trying to guess its way through this API, I'm actually really grateful I was forced to buckle down and learn me some Swift.

Let me know if this guide helped you out! 💜

Direct link to podcast audio file

Thanks for writing so many lovely emails to podcast@searls.co. Hell, thanks even for the unlovely ones.

Be sure to look out for me showing up on Dead Code at some point after it records next Tuesday. I'm realizing not all podcasts have a 1-hour-or-less turnaround time like this one does.

As promised, some URLs follow:

• Want a Japanese girlfriend? Better be the right Myers-Briggs type
• Aaron's puns, ranked
• Men sucking at chores is turning women gay! (News+)
• Nightmares kill you (Archive)
• This shiner from /r/overemployed
• Hour of Code is now Hour of AI
• Gary Marcus taking a few victory laps around GPT-5
• OpenAI caves to 4o-pilled users
• Meta's AI rules have let bots hold 'sensual' chats with children
• Apple returns blood oxygen monitoring to the latest Apple Watches (sort of)
• The Trump Trophy
• My man Steve Wozniak has a 6-digit /. account
• Enough
• Andor
• Alien: Earth
• Sims 2 Legacy Collection
• Foundation Season 3
• Mariusz schools us on running Claude Code in a Docker container (sources)
• Marick's ZIRP reply and my follow-up post

Free idea for anyone who wants it.

I've been juggling so many LLM-based editors and CLI tools that I've started collecting them into meta scripts like this shell-completion-aware edit dingus that I use for launching into my projects each day.

Because many of these CLIs have separate "safe" and "for real though" modes, I've picked up the convention of giving the editor name in ALL CAPS to mean "give me dangerous mode, please."

So:

$ edit -e claude posse_party

Will open Claude Code in ~/code/searls/posse_party in normal mode.

And:

$ edit -e CLAUDE posse_party

Will do the same, while also passing the --dangerously-skip-permissions flag, which I refuse to type.

Blogging is so back!

If you aren't familiar with Brian Marick, he's a whip-smart thinker with a frustrating knack for making contrarian points that are hard to disagree with. He saw my link and left this comment on Scott's blog post about technical debt and ZIRP. The whole comment is worth reading and should have top-billing as a post in its own right, so I figured I'd highlight it here:

The problem with a ZIRP is that those questions are b-o-r-i-n-g and you can't compete with those who skip them. You're out of business before they crash. ("The market can remain irrational longer than you can remain solvent.")

Similarly, there's a collective action problem. Our society is structured such that when the optimists' predictions go wrong, they don't pay for their mistakes – rather society as a whole does. See housing derivatives in 2008, the Asian financial crisis of the late '90s, etc. ZIRP makes it cheaper to be an optimist, but someone else pays the bill for failure (Silicon Valley Bank, Savings and Loan crisis)

It's weird to see ZIRP touted as a model, given the incredible overspending that took place, which had to be clawed back once ZIRP went away. (Most notably in tech layoffs, but I'm more concerned about all the small companies that were crushed because of financials, not because of the merit of their products.)

Brian made me ashamed to admit that I had read Scott's post as an exclusively good thing, despite the fact that on a macro level, he's absolutely right: the excesses of irrational exuberance and their unfair consequences are definitely net-harmful to society. No argument there. Someone should absolutely get on that and, of course, literally no one will.

Why am I unbothered? Because as a customer, I am happy to ride a ZIRP wave for my own personal benefit. That way, even if the world burns in the end, at least I got something out of it. Last time around, I benefited from a shitload of free cloud compute, cheap taxi rides, subsidized meal services, and credit card reward arbitrage in the 2010s—even as I made sure to direct my investment portfolio towards businesses that actually, you know, made money. So it is today: the tech industry has made a nigh-infinite number of GPUs available at remarkably low prices, and I'm just some dipshit customer who is more than happy to allow investors to subsidize my usage. At the moment, I'm paying $200/month for Claude Max which admittedly feels like a bit of a stretch, until I check ccusage and realize I've burned over $4500 worth of API tokens in the last 30 days.

And, unreliable and frustrating as they may be, I'm still seeing a ton of personal value from the current crop of LLM-based tools overall. As long as that's the case, I suppose I'll keep doing whatever best assists me in achieving my goals.

Is any of this sustainable? Unlikely. Are we all cooked? Probably! But as Brian says, this is a collective action problem. I'm not going to be the one to fix it. And while I greatly admire the spirit of those who would gladly spend years of their lives as activists to also not fix it, I've got other shit I'd rather do.

My only real medium-to-long-term hope is that the local LLM scene continues to mature and evolve so as to hedge the possibility that the AI cloud subsidy disappears and all these servers get turned off. So long as this class of tools continues to be available to those who buy fancy Apple products, how I personally approach software development will be forever changed.

(h/t to Tim Dussinger for reminding me to link to Brian's commentary.)

🔗 worksonmymachine.ai

🧂 justin.searls.co

I just realized that Christmas in July must have been held somewhere, and I missed it. Damn.

Regardless, the blog was busy since we last checked in:

• There's some Xcode stuff for Apple people, as well as the nostalgia of finding the order confirmation of my very first Mac, a 12" iBook G4
• We got in some good thoughtlording with a software design thinkpiece, an organizational design thinkpiece, and an AI thinkpiece
• Reflections on how bang-on my favorite apocalyptic short story set in 2026 turned out to be
• A couple podcasts, too (1, 2)

Also since I last wrote you, they held the final RailsConf, an event and community that had a huge impact on my career. I was honored that Aji Slater summarized my 2017 keynote on stage, even though I don't own a single pair of white pants:

As it happens, I've been chewing on a lot of the same themes I discussed back in that How to Program talk, because the current AI-induced industry shakeup we're experiencing has underscored the importance of taking ownership over how we work. And although I didn't plan this in advance, that's kind of exactly the topic I'm writing about today.

Of course, when I talk about work, I mean it in a quite expansive sense. For most intents and purposes, I retired at the end of 2023. I contend that I still do stuff, but increasingly nothing about my day resembles a traditional job. There is, however, one exception: I now have more meetings on my calendar as a retiree than I did as a full-time employee.

Today, I'll share the unlikely story of how my calendar started filling up again and the even unlikelier reality that I'm completely okay with it (happy, even).

There are many different ways to feel about the word "process":

• Some are indifferent. They show up each day, follow the herd, and are content with checking boxes. If a process wastes time, blurs focus, or causes friction—that's on whoever designed and implemented the process, not them

• Some are stifled. They have their preferred way of doing things and will judge a process not on its own merits, but as the sum of deviations it takes from their way of doing things. They often opt into flat organizations with a light touch, hoping others will stay out of their way

• Some are obsessive. Without a clear and comprehensive process in place that covers every conceivable contingency, they fall to pieces. Once they get acclimated, any talk of changing the process—or, God forbid, eliminating it—spikes their blood pressure and triggers a threat response

• Some are pragmatic. They can thrive with a heavy-handed process or no process at all. What matters is that whatever is expected of them is a good fit for today's problems. What's more, they want a say in the continued evolution of the process itself, just as they would in the maintenance of any other tool on the worksite.

Managing a company that welcomes and tolerates all four of these dispositions would be a complete pain in the ass, and I don't recommend it. The indifferent won't leave unless they win the lotto or you fire them. The stifled can play ball in external-facing roles and at early-stage companies, but will generally be more trouble than they're worth at a larger scale. Obsessives are a bad fit for startups—feeling neglected in the early stages and overwhelmed by reorgs and scaling churn in the middle stages—but are right at home in bureaucratic and staid late-stage companies. One might assume pragmatists can fit in anywhere, but in reality they're the canaries in the coal mine—if your organization doesn't have its shit together, results-oriented people will get bored and go work somewhere that does.

Give me a team made up of nothing but process pragmatists and we can scale horizontally as a flat organization far beyond the point most others would collapse in on themselves. In fact, I have a suspicion that most organizational design memes like "self-organizing", "agile", "lean", and "squads" were initially coined by pragmatists who innovated custom processes for their unique situations. Things went well for them, they wrote a blog post or book about their experience, and then they moved on.

Those books were then bought by obsessives shopping for a reputable off-the-shelf process, and who went on to adopt that process as their ideology despite never really "getting" it. They'd codify and gate-keep the process, organize conferences, conduct trainings, and administer certification programs… before inevitably splintering into distinct religious sects. Because obsessives are the only ones who care so damn much about process, the rest of us are happy to delegate it to them. As a result, we tend to conceive of what process is or can be on the terms of those who have an unhealthy obsession with it. (If you're already bored reading this, thank the world's feckless middle managers—and their projection of false authority masking unresolved anxieties—for ruining "process" for the rest of us.)

If someone gives you a process to follow and doesn't leave room for you to apply it to your particular situation, they're doing both you and themselves a disservice. The only way to ensure a system or process will reliably achieve its desired outcomes is if the people following it deeply understand and buy into how it's supposed to translate their actions into those outcomes. And the best way to foster that understanding and buy-in is for the people executing the process to have a hand in its creation and evolution. Good process design is like an inside joke: you just had to be there.

Sure, there will be constraints the process will have to accommodate—customer demands, industry regulations, inflexible software tools—but there is no escaping it: you're the one who owns how you think through and approach your work. Your brain cannot be outsourced. There's a widespread delusion we can adopt a famous company's "playbook" as a starting point, customize it to our liking, and achieve the same success they did. But a methodology's effectiveness depends on its practitioners' sense of ownership as they continuously adapt it to their unique context. Whatever mechanical steps and procedures emerge are an artifact of the thing, not the thing itself. Adopting some other company's system like Shape Up or Spotify Squads would be like stealing another family's photo album and rewriting your own names into the captions.

But this issue of Searls of Wisdom is not here to tell you how to design and implement custom processes to scale your business. (If you want to pay me to tell you anyway, knock yourself out.) All I'm here to say is that every organization owns their process, that few among us understand this to be part of the job, and that the people excited about process for the sake of process are the last ones we should trust with it.

Connect 4

Okay, we are in desperate need of a concrete example. I'd like to tell the story of a process that was designed to address real problems, how it was iterated and improved upon, and why it's not for you.

Today, I serve as chairman of a multi-national conglomerate of several businesses. Each day, I toil away in a co-working space (my house) alongside the CEO of one of our portfolio companies (my wife, Becky).

As is right and good, we began our individual endeavors without any preconceived process. We showed up, we did our work, and then things would go as well or as poorly as they were going to. We didn't impose any structure on ourselves.

A few months in, it became clear we were operating on wildly different wavelengths. Working different hours. Frequently interrupting each other. Stepping on each other's toes. She wanted more connection throughout the day. I wanted more coordination to ensure things got done.

We initially tried to solve this ad hoc by simply showing up to work differently. I attempted a mindset shift called, "be a nice person," which lasted for a day or two. Since that didn't work, I leaned on what my career had taught me: if good intentions and sheer force of will aren't enough, it's likely a sign the underlying problem is systemic. And systemic problems demand systemic solutions.

Iteration 1: a recurring calendar event

So we spun up our first process: every morning at 7:30, we'd come downstairs for "Coffee Time." We'd sync our schedules by starting the day together, each pouring a coffee and sitting by each other in the living room or out on the lanai.

Coffee Time successfully aligned our working hours, but it created all-new problems. It wasn't a meeting so much as a scheduled coexistence, so I'd work on my computer while Becky would read. One of us would try to strike up conversation or discuss plans for the day, which the other would experience as an interruption. Any given instance of Coffee Time might last 5 minutes or run for 2 hours.

It almost always ended with one or both of us feeling mildly irritated.

Iteration 2: ground rules

Since Coffee Time clearly needed more structure to achieve its desired outcome, we added a constraint: no devices. We'd sit our asses down at the appointed time and place, sip our coffee, and be forced to talk to each other.

One member of our team is an optimistic, energetic morning person and loved this process tweak.

Others, who shall remain nameless, struggle to engage in conversation first thing in the morning and that's why this change fucking sucked.

See, I get my best creative work done right after waking up, before something—like freeform conversation—can derail me and poison my day. As a result, Coffee Time represented a high-wire act of my own design: one wrong move and I might lose a whole day's productivity.

This misalignment frequently manifested in conflict. Becky sought unhurried and relaxed connection. I sought to get it over with ASAP so I could go back to my work. We gradually stopped showing up. Coffee Time went the way of so many recurring calendar events: nobody bothering to attend but nobody with the courage to delete it.

Iteration 3: 🔥🔥🔥

The Coffee Time calendar event just sat there for literal months. I lost track of how many times my watch buzzed only for me to ignore it.

When you lose faith in a process you helped establish, it's a special kind of demoralizing. I felt a tinge of shame every time the calendar notification popped up. The event's ongoing existence crowded out any space for a better solution to emerge.

Most people lack the courage to discard pre-existing documents, policies, and processes. Getting rid of practices that everyone agrees are self-defeating or even harmful is nevertheless unusual. When we talk about businesses being slow and inflexible in the face of change, we often think of big companies—but the problem is really with old companies (and most big companies just happen to also be old). The longer they've been in business, the more layers of process and policy sediment pile up. The people who were in the room then aren't in the room now, so past decisions are treated by today's people as untouchable dogma. And unless periodic reset & renewal is reinforced somehow, the institution will gradually calcify and become vulnerable.

Anyway, I lack such inhibitions, so I deleted the Coffee Time event one day. Surely, there existed some better way of cohabiworking, but an unstructured appointment nobody shows up for probably wasn't the answer.

Iteration 4: Structure

Literally the day after I deleted Coffee Time, I had an idea.

I pitched a new meeting: "Connect 4." It would be designed to meet both of our needs. Becky wanted to establish connection and kick off each morning in harmony with one another. I wanted to ensure we coordinated our activities and had the ability to hold one another accountable. It would also give us an opportunity to offer each other our support, whatever that might look like from day to day.

I scribbled four quadrants onto a legal pad and titled it "Connect 4". Each morning, we would take turns, each sharing three things:

• Biggest feel. Name one overriding emotional or physiological feeling. Let the other know what version of yourself they're working with today
• Biggest goal. If you could accomplish just one thing, what would it be? When you look back, what do you want today to be remembered for?
• Biggest want or need. We're not just here to get shit done—we're here in pursuit of a life well-lived. What does that look like today?

After reflecting and sharing our answers to the above questions, there was one last step. (I needed a fourth thing so I could call the meeting "Connect 4".) So, after we'd both had our turns to speak, we would pose a question to the other: "What can I do to support you today?" It was important we offer support by way of a question, as opposed to guessing what the other needed (which would be presumptive) or directly stating the support we wanted (which could be interpreted as an imposition). If I ask Becky how I can support her and however she answers isn't something I'm thrilled about doing, that I asked for it makes it more likely I'll follow through. Little touches like this are a great example of structure reflecting purpose.

That's it. Three quick things plus one question. Achievable in ten minutes. We both get our needs met.

I resisted introducing something like Connect 4 for over a year, because it felt stupid to kick off my retirement by signing up to do daily standup meetings with my wife. But once we got going, it didn't feel that way at all. Because the process solved real problems that we'd actually been struggling with, there wasn't anything to complain about.

Iteration 5: the ceremony

Connect 4 immediately proved more valuable than our previous attempts at starting each day on the right foot, but it also would not have materialized without them. It's important not to be too hard on yourself if your initial solution fails to solve the problem—something can only be improved once it actually exists.

Still, Connect 4 wasn't perfect:

• Originally, Connect 4 was only scheduled on weekdays, but we gradually found the days we didn't sync suffered for it, so now we do it seven days a week
• We'd sometimes derail things by going on long tangents, so we began to (kindly) defer those conversations until we'd gotten through our Connect 4 updates
• Conversation regularly unearthed deeper issues that warranted more time than a quick check-in would allow, so we began scheduling ad hoc follow-up meetings as needed

There was one other lingering problem that persisted for a few months before we identified and addressed it. See, despite having a scheduled start time, the reality of being two self-employed people working from home meant it wasn't uncommon for one of us to get into flow and fail to show up on time. This, in turn required the other to go and collect the other, interrupting them. And when one person has to call the meeting, they become the de facto person to run the meeting. This can introduce or reinforce a vertical dynamic, which is counterproductive to building a sense of mutual respect and commitment.

To solve for this—and one wonders whether this is how church bells got invented—I took a sound bite of the Family Mart chime and configured HomeKit to automatically play it at 8:30 AM in every room of the house. This way, neither of us has to call the meeting—the meeting calls itself. We separately stop what we're doing and attend it of our own volition, as peers.

Some will read the above and think it's too insignificant a thing to bother with, but people fail to realize this sort of reaction is what leads to our lives feeling so cluttered and overwhelming. Insignificant things pile up. If you choose to ignore a small pebble in your shoe, no one's going to award you a prize for learning to live with it. Not letting life's little irritants bother you may sound laudable, but if you forget about that pebble you might later fail to identify it as the cause of your postural problems, or your joint pain, or your short temper.

Don't make the mistake of equating the apparent size of a problem with its potential impact when assessing whether it's worth taking the time to fix it.

You're the one you're waiting for

Connect 4 is just one of dozens of goofy practices Becky and I have created to draw out the best versions of ourselves. We name each of our customs. We sing jingles. We have secret handshakes. We reflect on what's working and what isn't. We make tweaks. We aren't afraid to let go of any of our rituals once they're no longer useful.

Why do we bother taking the time to do all this? Because it never occurred to us to invite some third person to optimize our marriage for us. That just sounds ridiculous.

And yet, the vast majority of employees expect their employer to optimize their workflow for them. That sounds pretty ridiculous, too, if you ask me.

And sure, I could write a book on all the things Becky and I do to live our best lives, but this one example is all you're getting. I am aware that all it would take is to give each practice its own chapter—brand it with a name, explain what it solves, how it's done, and why it works. I could earn money and notoriety by pitching our system as a framework to building a happier marriage, or achieving work-life harmony, or some other bullshit. But that would just be prescribing yet another process for others to follow. And even if I was offering genuinely helpful advice, it would only further prevent people from figuring out for themselves that the path to greatness is not a paved road, but a blazed trail. There's nothing of value to be gained by blithely retracing someone else's steps.

If taking ownership of the systems that govern how you think through problems and interact with others seems out of reach, it shouldn't. Humans tend to live and work in pretty small groups—it's not unreasonable for everyone to have a say. I've witnessed families and teams alike who agreed to make decisions by consensus, who expect everyone to propose improvements, and who celebrate doing the things nobody asked for. It's not hard to live this way, but it won't magically happen on its own.

Following a process without continuously improving it is like driving a car without touching the steering wheel. The only person staring down the road ahead is you. That makes you the best person to figure out how to get wherever you're going.

I've long been an advocate for promoting individual autonomy on software teams. At Test Double, we founded the company on the belief that greatness depended on trusting the people closest to the work to decide how best to do the work. We'd seen what happens when the managerial class has the hubris to assume they know better than someone who has all the facts on the ground.

This led to me very often showing up at clients and pushing back on practices like:

• Top-down mandates governing process, documentation, and metrics
• Onerous git hooks that prevented people from committing code until they'd jumped through a preordained set of hoops (e.g. blocking commits if code coverage dropped, if the build slowed down, etc.)
• Mandatory code review and approval as a substitute for genuine collaboration and collective ownership

More broadly, if technical leaders created rules without consideration for reasonable exceptions and without regard for whether it demoralized their best staff… they were going to hear from me about it.

I lost track of how many times I've said something like, "if you design your organization to minimize the damage caused by your least competent people, don't be surprised if you minimize the output of your most competent people."

Well, never mind all that

Lately, I find myself mandating a lot of quality metrics, encoding them into git hooks, and insisting on reviewing and approving every line of code in my system.

What changed? AI coding agents are the ones writing the code now, and the long-term viability of a codebase absolutely depends on establishing and enforcing the right guardrails within which those agents should operate.

As a result, my latest project is full of:

• Authoritarian documentation dictating what I want from each coder with granular precision (in CLAUDE.md)
• Patronizing step-by-step instructions telling coders how to accomplish basic tasks, repeated each and every time I ask them to carry out the task (as custom slash commands)
• Ruthlessly rigid scripts that can block the coder's progress and commits (whether as git hooks and Claude hooks)

Everything I believe about autonomy still holds for human people, mind you. Undermining people's agency is indeed counterproductive if your goal is to encourage a sense of ownership, leverage self-reliance to foster critical thinking, and grow through failure. But coding agents are (currently) inherently ephemeral, trained generically, and impervious to learning from their mistakes. They need all these guardrails.

All I would ask is this: if you, like me, are constructing a bureaucratic hellscape around your workspace so as to wrangle Claude Code or some other agent, don't forget that your human colleagues require autonomy and self-determination to thrive and succeed. Lay down whatever gauntlet you need to for your agent, but give the humans a hall pass.