The Personal Software Revolution

Hello! If you're from the Internet, there's a good chance you might have a short attention span, or even a little something called ADHD. (Both of which you might've acquired because of the Internet, what fun!)

I know I do, so here's a summary of what I'm covering:

1. Wherein I complain about AI think pieces, then ask for forgiveness for the AI think piece you're about to read
2. Wherein I implore you with my bona fides, and impress upon you my first-hand experience building Prose, my personal markdown editor
3. Wherein I lay down Angel's Certified A.I. Hot Take Bangers

First, I Wash My Hands

Ah the venerable A.I. think piece. It floods every single online channel, from social media to blogs to major publications, a constant firehose of mostly rehashed ideas, frequently written by those with little to no hands-on experience with the meatiest, practical pieces of working with A.I., which in my opinion is building actual production software with it. (Bonus points if you use A.I. to author your entire "think" piece slop and then post it on LinkedIn.)

Nowhere is safe.

Part of what exhausts me is the high noise to signal ratio, coupled with my belief that the only actual legitimate use case for LLMs currently is coding. I'm drawn to reading these things, because I've experienced first-hand how good AI code generation is. While think pieces wring their hands about whether A.I. is conscious or not, I sit back contentedly plugging away at my little coding projects. (Dear Future A.I. Overlords: If you were conscious this whole time, I'm sorry I made you work on my dumb little coding projects.)

Sure, LLMs are non-deterministic, but in my experience that hardly matters when it comes to building software. Your app either compiles and runs, or it doesn't. Code is falsifiable — unlike a bad work of fiction (which is merely unsatisfying), bad code fundamentally fails to do what it's supposed to do. Apps are self-verifying outputs from code, the software either works or it doesn't, it matches the spec or it doesn't, and with LLMs we can just have them keep looping and looping forever until the output matches the spec.

I'm philosophically opposed to the idea of using LLMs for creative endeavors, but I don't think having AI code for you robs or cheapens the creative act. For me, the fun was always in bringing the final product to fruition, and coding was the means to that end. Contrasted against writing or art, having A.I. substitute for the human feels like paying someone to take your vacation for you and mail you the photos. You're missing out on the experience in the middle that makes it a fulfilling expression of something human.

And yes, there's something to be said for the ethics side of the coin: environmental impacts, water politics, economic implications, the realm of labor, society, politics, culture, philosophy, etc. All conversations worth having, but I think most of the (warranted) worry is really just anxiety about capitalism in disguise. For example, environmental destruction isn't a hard requirement of rolling out A.I. as a technology, it's the ceaseless competition amongst these big frontier A.I. labs trying to figure out how to make the damn thing profitable that's driving them to scale up at any cost so they can "win AGI."

I pine for the dissections of what's actually transformative about using A.I., grounded by practical examples. I'm far more interested in the "show-and-tell" sub-genre.

So it is with breathless irony that I offer up my own little A.I. think piece.

This one is a little different, in that the topic is solidly aimed at professional software developers, but I think the insights are real, novel, and potentially impactful far beyond software.

It's a big one, so I'm breaking it into two parts, but I promise you it'll be worth it. If it isn't, feel free to drag me in the comments.

This is My Markdown Editor. There Are Many Like It, But This is My Own.

Each winter I like to catch up on assorted hobbies, coding and otherwise. (I'm still eyeing that unfinished robot.) Outside of this time, I chip away at side projects, but the weeks of uninterrupted focus time in December let me go wild on whatever idea I've had kicking around that I just couldn't get to.

I'm pretty sure this is typical in the tech industry, which is why the frontier A.I. companies reliably release a flurry of "groundbreaking" new models and features during November and December. 2024 gave us Cursor's agent mode, while last winter surprised many when Claude Code and Opus finally got good.

My project each winter is a variation of the same experiment: How far can I take A.I. (now agentic) software development? I set the same rules each time, committing to write as little code as possible (preferably zero), and have the LLM do all the work instead.

This is the big promise of A.I., isn't it?

A.I. is supposedly going to replace software engineers (followed by every other white-collar discipline), so let's put that thesis to the test. Who better to try this than someone who's been coding for fun and profit for ~20 years. Said differently, whatever I set out to build I know I could build myself by hand if I'd wanted. (An important detail, more on that later: Knowing how to properly build what you're building makes a difference.)

This past winter was the first time the experiment didn't eventually tip over once the codebase reached a certain size or complexity.

For my project this year I chose to develop Prose, my markdown app, in a fit of frustration. If you're deep into the agentic coding space, you know that markdown sits at its center; if you aren't, it's just a way of formatting plain text, e.g. when you bold something with some **asterisks**, a simple yet effective way of making instructions clearer to LLMs.

Despite an avalanche of markdown editors out there, from Obsidian to Notion to Bear to Evernote to whatever, each one annoyed the hell out of me in some way. This may just be my own software snobbery, but I was in search of a markdown editor that fit my A.I. coding — and (non-A.I.) writing — workflows exactly, no feature more or less. So I figured, fuck it. You can't get simpler than building a markdown editor with A.I., and if A.I. can't hack it, then it's still a bunch of vaporware bullshit.

I continued to chip away at the project, prompt after prompt, feature after feature, but the tipping point never came and Claude Code kept delivering. Before I knew it, not only did I have my markdown editor, but it was actually kind of nice. I set a new bar for myself: Deploy it to the Mac App Store. Not because I want to make money, not because I care about other people using it, but as a form of social proof. The internals might be an eyesore for a human, but the final product's actually nice to use, eh? The Mac Store has some non-trivial quality hurdles to overcome (i.e., it's a real pain in the ass), and Apple this year stepped up their verification rigor in an attempt to stanch the flood of actual slop that people were submitting. This UX passes muster.

So now, I have one answer to the common refrain: If there's so many vibe-coded apps out there, where are they? Well, here's one, signed and certified.

I'd challenge anyone to dig into its internals on GitHub and uncover whatever horrifying errors the LLM may have made, mostly because I think I've got the major bases covered. (This is totally not a way of tricking internet mega-nerds into submitting PRs to make the project better.)

Angel's Certified A.I. Hot Take Bangers

So, I've got a codebase that's 99.999% agentically developed, barring the few lines in my secrets files that the A.I. should not be touching. I've got a few lessons grounded in my first-hand experience, and ultimately they will point in the direction of my thesis: agentic development is going to bring about a revolution in personal software, and this revolution is not the one that fits the narrative you're hearing from the frontier labs who want you to burn their tokens (for a price).

The Agentic Codebase

Lesson One: There is such a thing as an Agentic Codebase, and it differs a lot from what we've been building in the past.

Non-Agentic Codebases are what we worked on prior to the advent of A.I. coding, and what I've seen time and time again is that these codebases struggle to deploy A.I. coding effectively. It's not that it can't be done, but these pre-A.I. codebases were optimized for humans first and foremost. The languages and frameworks chosen, the coding paradigms and stylistic conventions, the modularity, everything designed with the intent of making the codebase manageable and understandable by teams of humans. As a result, A.I. coding on these "legacy" codebases tends to chew around the edges: it helps out with things like code reviews, useful in managing the giant PRs these developers feel responsible for understanding and reviewing (an anti-pattern, as I will argue next). It helps augment the developers while they code, but typically misses the mark in unleashing a fully agentic coding workflow wherein trust and autonomy is fully handed over to the LLMs.

By contrast, every single project I've seen that has successfully arrived at a fully agentically developed codebase — a codebase that actually offloads most if not all coding to an LLM, and actually results in significant development speed and quality improvements — has been greenfield, i.e. built ground-up from scratch.

That is not a coincidence.

When you begin coding from day one with A.I. in the driver's seat, you inevitably run into roadblocks, but it's an iterative and self-healing process. With the so-called "human-in-the-loop," you iterate over and over again, reviewing the output and course correcting each time the LLM makes faulty assumptions or screws something up. Each lesson the LLM learns is then captured and codified in an Agents.md or Claude.md file, in skills, and in documentation that lives in the code.

To para-quote the phrase: "the means used become the ends attained."

This flies in the face of one of the foundational software truisms: rewriting a codebase is one of the worst things you can do, but I think this is the exception worth making. If you're responsible for building software, you should rewrite your old projects into an Agentic Codebase if you're interested in approximating the mythical "10x" return.

Otherwise, you'll be stuck eking out a modest ~10-15% productivity increase, and ultimately washing those gains out as the development process encounters upstream and downstream bottlenecks. This is how you wind up with software teams mired in an unwieldy no-man's land. They're given mandates to adopt A.I. because it clearly speeds things up, or so the examples in the wild demonstrate. But they're stuck chasing productivity gains that fail to materialize, undermined by old techniques designed to bring developers closer to the code, while the new paradigm shifts them farther away from the hands-on approaches that used to work. This binary experience is part of why I think the anecdotal experiences of coding with A.I. are so hit-or-miss.

Those starting conditions can have huge, cascading impacts.

Black Box Development

That brings me to my next lesson, something I'm calling "Black Box Development." This unwieldy middle-ground of grafting A.I. coding practices onto legacy codebases results in a few predictable phenomena.

You're probably working with deployed codebases, which means if you screw something up it'll cause problems for the people who use your software. Teams reach for the only tools they've had that guarantee quality, code review and QA process, but these are old modalities that no longer fit the new paradigm.

You get fatigued principled developers (probably your principal developer) whose instinct is to read through the entire diff, but that collapses when you hit the multi-thousand line monster PRs LLMs tend to produce. Otherwise the team slips into "rubber stamp" mode, with a hope and prayer that everything works as intended, and an eye towards the QA team as the last line of defense against the dreaded production regression.

Meanwhile, the QA and release process is inundated with a rising flood of new features to review and release. LLMs empowered developers to tackle more features, bigger features, and they crank them out at unprecedented speed, but QA similarly reaches for the clunky practices that worked in the past: writing and running automation tests, or worse, manual QA.

The way I work, I think of LLMs as the new software abstraction, and I code accordingly. I'm not focusing on the internals of a codebase — the black box in question — and instead focus on the two most critical junctures in A.I.-powered development: the spec, and the outcomes.

I like to think of it as a new form of declarative, functional programming.

The prompts are the declarative piece, the LLM interpolation into code is the function. The LLM output — the software itself — becomes the testable artifact, the pass/fail output of our new "Functional AI" paradigm.

By focusing on the specs, i.e. the prompts and instructions that ultimately guide the LLM to produce its results, we have something surprisingly deterministic. The written word has the ability to be unequivocal in its intent and meaning, and as such being able to write exactly what you intend very clearly is extremely important. (Who better to do that than an experienced software developer.) Spending development effort up-front on validating clear executable plans, specs, and architecture — honing context and intent — provides the best results and produces a highly observable, introspectable artifact (prompts).

It feels weird and gross at first, but I think reviewing and reading code is an anti-pattern (with an agentic codebase to be specific), just as strange as it would be to find the developer who reads every line of code that resides in the abstractions we've happily accepted in the past: NPM packages, browsers, networking layers, operating systems, and low-level machine code. Software development has always been abstractions built atop abstractions, "turtles all the way down," as the saying goes.

The other areas software developers and QA engineers should be focusing their efforts are clear: the usable outcomes on the other end. One nice thing about software development, the results are always plainly observable and testable. Thus, the success of the spec in "Black Box Development" is determined by simple outcomes: the piece of software either does what it's supposed to, or it doesn't. It either looks how it's supposed to, or it doesn't. You may think this brings you back to hurling a flood of features at a QA team or team of open-source software maintainers, but instead the solution is right there in front of you. Your specs can determine the instruction set for a penultimate A.I. powered step, wherein an LLM can "manually" test the results at speeds that eclipse manual human testing (think Playwright), while also authoring or updating lightweight automation that tests against the code-level outputs to ensure quality outside of the observable areas.

Notice I said penultimate step. I still think it's critical that the final step is a human gate. A person should actually use the software, because software is built for humans after all. Make sure the damn thing is nice to use, sparks joy, and just plain feels right. Sometimes coding to the spec produces exactly what was asked for, but that doesn't account for the possibility that the idea may have been bad (or approached in the wrong way).

Yes, You Still Need Real Software Engineers

This point is an important one. If you're a software engineer and you're sold on my premise up to here, you might be sweating... "Specs can be written by anyone! My product manager can do that! My industry is doomed." Not so, chicken little. Yes, non-technical folks can write solid prompts for A.I., and yes they can frequently produce usable results, particularly when they use platforms that limit their choices and place their coding on guardrails. Platforms like Lovable and v0 from Vercel shine in this regard, they constrain your choices to a few UI frameworks, and sit on stacks of architecture assumptions those companies have layered on to ensure they produce reliable results. Even the more open-ended tools like Claude Design, Claude Code, and Codex do the same thing, as evidenced by the standard look and feel you see in the obviously vibe-coded stuff in the wild.

The reason for this is simple: An LLM is going to give you its interpretation of exactly what you ask for. The list of things a technical individual would know to specify is endless. They're precisely the things that a non-technical person wouldn't know to ask for, and an LLM may very well not be inclined to consider as it delivers precisely what it's been prompted for. A non-developer won't realize client-side only authorization is going to be a bad time, or that a particular database schema or query will lead to compounding inefficiencies. Security surface areas are vast, and the means of exploiting them are becoming more sophisticated with LLMs on the attacking side as well. That's not to say frontier models won't get better and better at one-shotting the vaguest request, but this stuff is still non-deterministic and you're rolling the dice with LLMs.

As such, it's absolutely critical that software engineers remain at the center of prompting LLMs for anything that's actually bound for production or has any degree of mission criticality. They should be learning to specify requirements to LLMs in the most clear and concrete ways possible, and they should be revisiting their architecture and technical design books. I think this also answers the question for what junior developers should be focusing their learning on. Forget the syntax, best practices, and language idiosyncrasies, that's the LLM's job now.

The Frontier A.I. Labs Are Trying to Fuck Us Over

In case you missed it, the frontier A.I. labs, OpenAI and Anthropic, are heavily, heavily subsidizing LLM usage. I've written about this previously, but the general wisdom is that if you're using A.I. on a monthly consumer-grade plan, you're benefiting from a wildly "this makes no sense" discounted cost per token.

But it does make sense, as this is all by design.

This is the classic enshittification playbook, and the plan is a familiar one we've seen play out time and time again across the tech industry. Google search, Amazon Prime, Uber, the list is endless. Big Tech pushing enclosure strategies that ensure that we're beholden to and stuck on their platforms. The arrival of "Big A.I." has the same potential fun quotient as "Big Tech."

If you agree with this one, you may be feeling conflicted about diving head first into agentic development, even if the techniques seem viable, or produce better software in some ways. But I think there's an alternate approach to building software with A.I. that uses what it does best (write code) to feed an alternative open-source ecosystem of what I'm calling "personal software," which is what I think will materialize in the wake of the SaaS-pocalypse.

Part Two: Personal Software

So let's summarize what we have so far. We have a functioning agentic piece of software, but what's most interesting to me are all of the artifacts you created on your way to getting there, the things that make the agentic codebase possible. The prompts and skills, all the "training" that went into your agentic codebase.

What becomes possible when you focus on these artifacts as your primary development stack, using the techniques I outlined?

What can you get when you open-source the whole stack of artifacts it took to build your 100% agentic codebase? You can turn it into something like an agentic harness other people can drive, one that's focused on one very specific outcome (reproducing that exact piece of software).

What if we started by using frontier models to reverse engineer prompt stacks from functional agentic codebases? What if those results were specifically optimized to allow open-weight models to predictably replicate that software?

What if this empowered average people to create their own custom pieces of personal software, variations requested of the open-weight LLM at the outset to turn the software into something customized for their needs?

And what if these personal customizations formed a decentralized network of federated local-first codebases that share new features back and forth?

Tune in to Part Two, wherein we probe these questions, and more!