Seed Software
making apps designed to be modified
In 1981, at the age of 25, Steve Jobs gave an interview in which he described a vision he had regarding personal computer adoption. By then, he’d already figured out that the key to selling more computers would be to make them easier to use.
And the way that that’s going to happen is we’re going to be spending more and more of the computer power in the box to adapt the computer more to the way people are familiar with doing things, so that people have to adapt less to the way computers do things. And therefore it will require a more sophisticated computer.
That’s the paradox in our industry right now: to make a computer simpler to use requires a more sophisticated computer.
In 2026, this paradox is as relevant as ever: the latest example is the coding agent.
I think it’s important to point out another layer in Jobs’ paradox regarding users of computers. A majority of computer users today couldn’t tell you much about how computers work beyond how to use the applications they need to use. As coding agents allow more and more people to do things that previously required significant technical experience, it’s probably safe to think that we’ll see most people learn how to direct the agent from the highest level of abstraction without much technical understanding as opposed to learning how to code by hand.
As these non-technical users enter the world of building software, what kind of software will they build, and how?
Software Now
For most consumers of software, there is a major downside which most non-technical users may have sort of taken for granted up until now: the consumer doesn’t get much say in what direction software gets built. Why would Microsoft make Word for me, Miguel, when their goal is to appeal to basically every business professional and student? In this case, the answer is that Word is a closed and extremely complicated application, designed for a broad base of students and professionals. Reorienting this massive tanker takes time and is incredibly complicated, so it makes more sense to design one product for a few different profiles of users, and then for all users to adapt this product.
But not all software applications need to be as large as Microsoft Word, both in complexity of code and in breadth of user scope. When the App Store launched in 2008, it showed user demand for smaller, personalized software applications.
What happens if every user now has the ability to modify code and at the same time the cost of development gets cheaper? Software has the chance to become more personal than ever.
An Example: inContext Lite
One example to illustrate what the future might look like is this lightweight version of inContext that I made. inContext is an immersion based language acquisition app, and creates content tailored to your interests and language level. Unlike the original, which took Alex and me many weeks/months to develop, I built the lightweight version in a day with a powerful coding agent called Pi. Since there’s no real backend, costs on my end are literally zero. The user adds their own API key for the LLM calls, which also means my costs are zero. The user can see the code on github, and fork it and add any new feature that they want.
This app is relatively simple, and users will probably find it limited in some specific way depending on their goals. Good. That’s exactly the point. Want to add more questions than the three that I made? This could be as simple as modifying a prompt or modifying a few lines of code. Want to add an automatic Anki vocab card maker? You’d need to look up the Anki format, the Anki documentation, and write code that can export the saved vocab words to Anki.
Or, you could just tell a coding agent what you want and it could do all of these things for you without you needing to understand any of the details, building off of what already exists.
Software of the Future
As everyday users gain the ability to modify software, I suspect that we will see new categories of software applications, and new distribution methods. In particular, I think we’ll see a rise in base software that is designed to be remixed and modified, the way music is. This software could be purchased as a one time cost (by a user or their agent), and comes with no hosting or updating responsibilities from the vendor, and external API calls like for LLMs are offloaded to the user.
I think a good term for this could be seed software. When the user adds water and provides light, this software grows into something new.
Here are a few examples of what I think would and wouldn’t count as seed software:
Seed software: A personal finance tracker you pay $5 for. With your coding agent that runs in your browser or locally. You add custom categories, connect to your bank, and design a custom dashboard for your goals.
Seed software: WordPress templates like _s (Underscores). A starter WordPress template originally designed for developers. Simple and customizable, though designed for a pre-coding agent era.
Seed software: Tau, a self-modifying agent that runs in your browser and only needs an API key to run. (Alex and I wrote some more about it here.)
Not seed software: Microsoft Word. Can’t be modified and quite complex.
Not seed software: VS Code. While open source, it’s a large and complex codebase. Coding agents will probably get good enough to allow users to make modifications to this, but it’s not intentionally simple and modular in a way that invites customization.
Not seed software: Notion. You can customize things and build things but only in the way the makers intended; users can’t modify any code.
Interesting middle ground: Obsidian. The code itself is closed but the ecosystem of customizable plugins and local markdown files means people build radically different things with it in a way that’s similar to seed software.
Challenges
As computers get so easy to use that spoken word is enough to direct the power of a “genius-level” coding agent, users will still face a challenge. Well-designed software is more than an idea translated to code. Good software comes from hundreds of major and minor decisions about purpose, design, engineering, intended user base, and more. Even when users can make agents build whatever the user wants, the question of what exactly one wants is not easy to figure out, and must be worked out through experimentation. Coding agents make it tempting to skip this part, and to just keep prompting until features appear. Successful software makers will have to be intentional about these decisions.
Today we still have classical musicians. We also have artists that sample from all kinds of music and sound to make something new. Even as producing and copying sounds has gotten easier, it hasn’t removed the creative challenges of making music. Every artist tackles this challenge differently, but electronic duo ODESZA provide some insight into their process:
The tracks themselves usually start with a melodic idea, then we build the rhythmic elements and experiment with a bunch of different sounds and layers… Then we peel back everything that isn't crucial to the song and try to make it as simple as possible.
Coding agents are picking up the complexity of building layers on top of an existing piece of software, and this is changing most users’ relationship with software. Computers are becoming sophisticated enough that using one now looks less like operating a machine and more like tending a garden: planting a seed, shaping what grows, and pruning what doesn’t serve you.
It’s my hope that in this future, we all grow our software.
 | A guest post by
|
As someone who spends most of my time directing agents rather than writing code directly, the "seed software" framing lands harder than it's supposed to. The apps I find myself modifying aren't the ones with cleanest abstractions — they're the ones that leave visible seams. Jobs' paradox flips here: the software easiest to modify from a prompt is the software sophisticated enough to expose its own joints. Abstraction as a favor to the modifier, not just the user.