Extremely Personal Software and the Collapse of the Talent Pipeline

TLDR; / Thesis

Open source software is changing, and there's a new strain / a new breed of tooling: Extremely Personal Software (EPS). Skilled programmers will reap most of the benefits, while the market adjusts and people figure out how to bring this new workflow to the masses.

Intro

I have had two things swimming around in my head recently, and I'm realizing they are more interconnected than I had initially understood.

On Monday, I wrote a short piece because I was moved by some very silly software. The specifics aren't that important (it makes video game sounds when agentic coding events trigger), but the bigger picture is quite fascinating.

I'm trying not to be too dramatic or clickbait-y here, but: open source software has evolved. There's a new strain of software that I have heard dubbed Extremely Personal Software. I quite like that name.

EPS is open-source software which, as the name implies, is entirely and wholly customizable. Nothing is off limits. What separates this from "traditional" open source software? The traditional workflow is something like... developer builds minimally useful tool for their use-case, thinks others might find it useful, publishes to GitHub, continues adding features, in rare cases a community of contributors will assemble around a project, more features and use-cases are uncovered, users want more and more niche features, maintainer(s) balance many aspects of project health, feature completeness, their time and sanity. (This is an oversimplification and there are many versions of this workflow).

But, I return to this HN comment.

It's becoming passé to ask for feature requests and even to submit PRs to open source repos. Instead of extensions you install, you download a skill file that tells a coding agent how to add a feature. The software stops being an artifact and starts being a living tool that isn't the same as anyone else's copy.

Of course the "traditional" open source software project is not going to go extinct. There is immense value, and will continue to be immense value, in software that is built by teams of maintainers who keep a carefully procured, walled garden of clean software, with the right, well-built, secure features.

But there's also a new breed of Extremely Personal Software that is knocking on the door—the purest forms of which will be architected as simple and customizable by design.

Extremely Personal Software projects have almost zero features. They are more like a software harness than a final project. They are built to morph, stretch, have more software plugged in, and then be bolted onto something else.

Using Extremely Personal Software feels like using a computer in the early days of home computing. It feels like having a sparkling, animated cursor and a desktop pet. It feels like a perfectly well-curated, personalized set of bash aliases and shell scripts, terminal theming, and hot keys.

Examples of Extremely Personal Software

Pi

This is the best example of an Extremely Personal Software that I can give. This is pure EPS design.

Pi is an "AI coding harness" with the tagline—"there are many coding agents, but this one is mine". This tool has received a recent bump in attention because of it's inclusion in "OpenClaw". It's very similar to Claude Code, but it's free, open source, and very, very stripped back. What strikes me most about this tool is the "Philosophy / What we didn't build" section near the end of the home page. I'll just paste the section below:

Philosophy / What we didn't build

Pi is aggressively extensible so it doesn't have to dictate your workflow. Features that other tools bake in can be built with extensions, skills, or installed from third-party pi packages. This keeps the core minimal while letting you shape pi to fit how you work.

No MCP. Build CLI tools with READMEs (see Skills), or build an extension that adds MCP support. Why?

No sub-agents. There's many ways to do this. Spawn pi instances via tmux, or build your own with extensions, or install a package that does it your way.

No permission popups. Run in a container, or build your own confirmation flow with extensions inline with your environment and security requirements.

No plan mode. Write plans to files, or build it with extensions, or install a package.

No built-in to-dos. Use a TODO.md file, or build your own with extensions.

No background bash. Use tmux. Full observability, direct interaction.

The whole philosophy here, and I think for all EPS tooling, is what isn't included. Instead there are clear, documented ways to customize the tool to your exact use cases. For every potential feature that they easily could have built and included with the tool, Pi instead links to the docs for extensions and tells the user to do it themselves.

OpenSuperWhipser

My first foray into EPS was with OpenSuperWhisper. This is a free and open source MacOS application which runs OpenAI's whipser model entirely locally, letting you do highly accurate speech-to-text without sending data to 3rd parties. It being a desktop application means it integrates really nicely, and you can just press the right-option key, say what you want to say, and it will paste the dictation wherever your cursor is placed. It's hard to explain how amazing this experience is. It has really changed my relationship with my computer. And this project only has 648 stars.

(I will say that OpenSuperWhipser is not, out-of-the-box, an Extremely Personal Software. It's built to be fully featured, and has a roadmap to add more.)

After using it for a couple days, I thought it might be fun to have more features. I use Slack and GitHub a lot, and both of these use markdown for styling text. I found myself editing dictations to retroactively add markdown styling, and I thought it would be nice to be able to dictate directly in code styling or with emphasis. Also, there are some words that are specific to my job that consistently get transcribed incorrectly. One word is TARA (an acronym that stands for transmission adequacy and reliability), that always gets transcribed as Terra.

So I cloned the repo, poked around, and started prompting Claude to help me add a "personal dictionary" feature. The personal dictionary stores some really basic regex replacement logic. You can add entries like "backtick [content] backtick" which map to [content], or it can map a single word like "Terra" to "TARA". This all took about thirty minutes to add.

But instead of forking the OpenSuperWhipser repo, opening a PR, and pushing back up my new feature, I decided to duplicate the code and make my own, personal repo. This might be against the unwritten rules of open source software, but I did not feel comfortable contributing my sloppy new feature back to the repo. I had also vetted the repo at the moment of installation to make sure that there weren't any major red flags when it came to security (data exfiltration, etc.) Duplicating the code from this specific point it time ensured that there would not be any nefarious activity coming into my new, highly personal tool from an upstream source.

I took the OpenSuperWhisper library and renamed everything. I made it entirely mine, stripped out features I didn't want (like Chinese language dictation), and went crazy with customization. I made the tool make absolutely no sense unless you're me and only me.

I have had so much fun hacking away at this little software utility. And it's genuinely a useful tool in my everyday life. But this whole process was so strange—I felt a bit crazy deciding to clone the repo and customize it in this way. But I'm starting to hear and read and talk to other developers. And many, many other people seem to be having the same experience that I had, but with their own workflows.

Peon Ping

The other close encounter I had with EPS recently was with Peon Ping, the tool that I wrote about two days ago. This software just adds video game sounds to your terminal when Claude Code event hooks go off.

I did a very similar thing to Peon Ping that I had done with OpenSuperWhisper. Peon Ping had a lot of features, and a much larger security footprint than I would have liked.

Neither OpenSuperWhisper, nor Peon Ping are EPSs, but since they're both such small codebases, they can be easily stripped back and reformed into EPSs.

This time, instead of forking, I just vibe coded a completely new codebase in Rust. It took about 10-15 minutes to get a working version of the tool, playing custom sounds during different coding events (new claude session, pending user permission, tool usage blocked, etc.).

This tool is surprisingly useful for little nudges of productivity and adds joy to my programming life.

EPS is eating paid software

One way to understand Extremely Personal Software (EPS) is in its relationship to paid, enterprise software.

EPSs are completely malleable. Nothing is off limits. Once you have a taste for it, you want all software to be just as malleable.

But paid, enterprise software solutions cannot be as malleable as open source software (unless they give you the uncompiled source code). SaaS tools cannot be EPS unless they can be self-hosted, local, and, again, they give you the source code.

Take this company Wispr Flow for example. It's a dictation app. They're offering a paid, productized version of the whipser model that you can download, run on your iPhone or Android phone, and they will manage the rest. Basically, it's what I got from OpenSuperWhipser, but it probably sends your data to their API, and they lock features behind a paywall.

The value proposition is that that you don't have to do it all yourself. You are probably not going to get the right amount of value for your time if you have to build and maintain a cross platform application for yourself, with a shared dictionary across devices, shared notes, and more. Personally, I'm not going to pay $12/month, but I'm sure is a lot of value to be had from a productized version of this tool.

But now, companies like this have to compete with EPS versions of their tool. As a paid, versioned, bundled application, they simply cannot compete with the amount of rapid customization that can be performed on an open. local tool. If nothing else, this will shake up the market, and paid software is going to have to find an answer to this new competition presented by EPSs.

Maybe this is how they (Wispr Flow) have to compete?

AI Boost, AI Drag, and the Unfairness of EPS

Now, at the start of this post I mentioned that I had two things swimming around in my head.

One of those things was Extremely Personal Software, but the other is this topic presented in this paper published by Scott Hanselman and Mark Russinovich, both @ Microsoft.

Redefining the Software Engineering Profession for AI - Without the hiring of early-in-career developers, the profession’s talent pipeline will collapse, and organizations will face a future without the next generation of experienced engineers.

Generative AI has fractured the economics of software engineering. Agentic coding assistants now give senior engineers an AI boost, multiplying their throughput, while imposing an AI drag on early-in-career (EiC) developers who lack the judgment and context to steer, verify, and integrate AI output. The result is a new incentive structure: Hire seniors, automate juniors. But without EiC hiring, the profession’s talent pipeline collapses, and organizations face a future without the next generation of experienced engineers.

Our thesis is simple: We must keep hiring EiC developers, accept that they initially reduce capacity, and deliberately design systems that make their growth an explicit organizational goal. The path forward is a culture of preceptorship at scale. We must enable senior mentorship with AI systems that capture reasoning, surface misconceptions, and turn daily work into teachable moments for EiC developers. This article explores how such systems can close the training gap and preserve the craft of software engineering in the age of AI.

This is a pretty bold claim, talent pipelines collapsing and all, but I do really find myself resonating with the argument.

If nothing else, this language of senior engineers getting an "AI boost" and early-in-career developers receiving an "AI drag" is very helpful.

The relationship between this "AI drag" idea and the aforementioned Extremely Personalized Software, is pretty obvious. The benefits of EPS are constrained mostly to software engineers. And it's probably the case that the more senior you are, the more benefits you'll see.

I'm really interested to see how all of this shakes out. What software will emerge that will augment EPS? How will normal, everyday, non-coders be able to see the benefits of EPS?

There was a time where only a select few could use computers. But better operating systems and Human-Computer Interfaces were developed. And now we have iPad kids.

Again, it calls back to the early days of home computing, when the few, the nerdy, the enthusiastic, saw the looming changes that were coming down the pipeline from computers. Justin Searles, of ruby fame, recently bumped/resurfaced his prediction from 2023 that the nerdy, enthusiastic, "10x programmer" of ye olden days is gone. It's a great read, and I almost entirely agree with him. But also, I think that the archetype of that individual he's describing is moving into a new territory of Extremely Personal Software.

Reiterated TLDR;

Open source software is changing, and there's a new strain / a new breed of tooling: Extremely Personal Software (EPS). Skilled programmers will reap most of the benefits, while the market adjusts and people figure out how to bring this new workflow to the masses.