Happy Star Wars day, everyone! Seems an appropriate day to dive into a Jedi/Sith-scale debate. Following last week’s post about how many developers are completely missing the power of LLMs as learning and education tools, let’s dive deeper into the profound, ongoing religioous war over coding agents.

Building your own lightsaber

On one hand, we have the face-melting awesomeness of Geir Isene. In “A desktop made for one,” he describes vibecoding his way to a hyper-optimized custom shell written entirely in assembly.

From what I can research, nobody has previously built shell, terminal emulator, and window manager in pure x86_64 Linux assembly. And it was done in about two weeks.

This is a whole new world where I command my own environment in ways that was completely out of reach back in 2025. I foresee the death of software as we know it where people use general purpose apps. I expect AI to craft tailor-made solutions for anyone with the imagination to ask for it.

He proudly notes that “[t]he resulting Assembly shell is a 150Kb executable with a 9 microsecond startup time.” Some of us build tools to explore hundreds of pages of 40-year-old transparencies; others build a blazing-fast shell from scratch. Isene goes into meticulous detail about why, exactly what a desktop for one entails, and the jaw-dropping benchmarks.

How can you be a computer science nerd and not love this?

Yet, he still has to defend his decision.

(xkcd #1745)

Wait, what? Defend?

Just take a look at the top-ranked lobste.rs response:

Really? I’m pretty sure I do. Well, at least that’s just a weird, crabby little corner of lobste.rs.

Narrator: it isn’t

For starters, Lars Faye argues that agentic coding is a trap.

No, Faye isn’t referencing the 2024 film by M. Night Shyamalan. Instead, he insists that it is “actually different this time” (i.e., this isn’t just a repeat of the doom scenarios surrounding assembly, higher-level languages, scripting languages, or IDEs):

What is happening right now is a trend where developers, who’ve never had that longevity or the 30+ years of friction that led to that deep understanding, are being moved into higher-level workflows requiring the same skills to manage the AI agents that the senior engineer took decades to obtain.

Ah, I see. It’s the classic calculator argument repackaged. Denis Stretskov points out that this isn’t a new anxiety. We’ve already seen it in manufacturing, and the underlying fear is that we’re going to forget how to code.

The pattern. Build capability over decades. Find a cheaper substitute. Let the human pipeline atrophy. Enjoy the savings. Then watch it all collapse when a crisis demands what you optimized away.

In defense, the substitute was the peace dividend. In software, it’s AI.

The tech world is awash in thought pieces about the impending dangers, the lost skills, and the flawed analogies. Doom, gloom, and more doom.

Or, we could embrace our new superpowers

Alternatively, you could read the two-year-old post by Maggie Appleton: “Home-Cooked Software and Barefoot Developers: The emerging golden age of home-cooked software, barefoot developers, and why the local-first community should help build it.”

For the last ~year I’ve been keeping a close eye on how language models capabilities meaningfully change the speed, ease, and accessibility of software development. The slightly bold theory I put forward in this talk is that we’re on a verge of a golden age of local, home-cooked software and a new kind of developer – what I’ve called the barefoot developer.

Seriously, she wrote this two years ago. In ways deeply aligned with my previous post, she explores what happens when building apps becomes a highly personal, communal activity.

Home-cooked apps, like meals, are apps you make for the people you know and love.

It’s a wonderful presentation: fun, thoughtful, and incredibly prescient. I’ve been exploring this shift through the tech island lens, but Appleton’s framing is just as vital.

It echoes Isene’s point but takes it a step further: if I can build the exact tools I want for me, then any of us can build exactly the tools we need.

How can you care about products and outcomes and not love this? And the more you care about quality, the more exhilarating this paradigm shift becomes.

Because this isn’t just about vibe coding.

I didn’t pull the Outcome Engineering Manifesto’s principles out of a hat. Building tailored, robust software isn’t about aimless vibe coding or operating without learning. It demands rigor:

02 The Truth Verified Reality is the Only Truth
06 The Map No Wandering in the Dark
08 The Artifacts Failures are Artifacts
11 The Graph All the Context, Everywhere

and, of course,

13 The Documentation Show Your Work
16 The Validation Audit the Outcomes

As I’ve said before: do not accept a black box. Right now, arguably the most complete expression of this philosophy is “Gas City,” which Steve Yegge covers in detail in his announcement.

I don’t think R2 should have to wait outside.

What an amazing time to be a builder.