The Weird Future of Personal Software

I built a feed reader that’s only half-finished software.

It has a normal interface: sources on one side, feed items in reverse-chronological order, you can tag things.

But behind that surface, an AI agent writes source-specific ingestion scripts, runs them, decides what deserves attention, summarizes what does not, keeps a running memory of my preferences, and suggests new things it might watch next. More than just using AI, the software intentionally leaves parts open for AI to keep building and operating.

That feels like a small but important discontinuity. Most AI products still produce familiar outputs: more writing, more code, more slide decks, more customer support, more executive-assistant-style task completion. Strange new machinery, recognizable old products.

But the feed reader made me think about a different question: what kinds of software become possible when the boundary between user, tool, code, data, and agent gets blurrier? The interesting unit of AI-native software may not be the finished app, but the scaffold: a stable workspace with open surfaces where agents can keep building, adapting, and operating.

In my last post, I argued against treating AI as an empty prompt box waiting for instructions. A more useful frame is AI embedded inside the established practices of knowledge work: reading, sorting, noticing, remembering, comparing, drafting, revising, deciding.

The prototype is an extension of that, a feed reader run partly by and with AI. The human-facing interface is intentionally boring. Items from selected sources appear in reverse-chronological order. The backend is where the interesting part happens.

Instead of relying only on RSS, the system lets an LLM write source-specific ingestion code in isolated scripts. In principle, it can monitor anything the model can figure out how to access and normalize into a shared item schema: RSS feeds, public websites, database records, documentation pages, release notes, search results, whatever. The code is arbitrary, which is powerful and obviously dangerous.

The LLM also routes items into attention buckets. Some items go into the main feed because they seem worth reading closely. Some get summarized into a secondary feed. Some are skipped. The system supports thumbs up, thumbs down, and freetext feedback on sources and items. The agent folds that feedback into a markdown preferences file, then uses it to adjust future prioritization and suggest new sources.

This is not a product I would ship. It’s a rough architecture sketch made out of dynamic parts. But that is what made it useful. Building it gave me a working example of software that is not quite an app and not quite an agent. It is a workspace with some stable surfaces and some intentionally unfinished ones.

That made a few AI-native engineering patterns feel much more concrete.

Traditional software planning often starts with feasibility: what can we build, how long will it take, what APIs exist, what data is available? With competent code generation, feasibility moves later in the process. For prototypes, you can often assume there is some way to assemble the basket of features you want.

That means the first useful constraint is the shape of the workspace. What should it feel like to move through the feed? What decisions should be easy? What should stay hidden until needed? Where should feedback live? What should the agent remember so the human does not have to keep repeating it?

For this prototype, the useful design move was not “build an AI feed reader.” It was “build a workspace for allocating attention.” Once that was clear, the prototype became a living wireframe: a working sketch with real data, backend processes, and enough agent behavior to feel out the interaction.

In AI-mediated software, the same feature can be implemented in very different ways. A source connector could be a hand-written integration. It could be code generated once by an agent and checked into the project. It could be generated repeatedly in a sandbox. It could be an agent using browser tools directly. It could be a data contract where the agent can do whatever it wants as long as it returns the right shape.

These are entirely different kinds of software, and they’re why “code is cheap” matters in practice. I would never hand-write and maintain custom ingestion scripts for every random source I might want in a personal feed reader. But if an agent can write those scripts, test them, and revise them when a site changes, the absurd architecture starts to make sense.

A lot of AI product design still treats the model as a narrow endpoint: send input, receive output, place output somewhere in the interface. That mental model is too small for this kind of system.

In this prototype, the agent writes code. It runs code. It turns messy source material into structured items. It classifies those items by likely relevance. It summarizes. It maintains a memory document. It uses feedback to change future behavior. It proposes new sources. The pattern is to distribute agent capability across construction, operation, maintenance, personalization, and evaluation.

Human-agent software needs at least two interfaces. The human needs a surface for judgment, navigation, and control. The agent needs a surface for reading state and taking action.

Those surfaces should not be separate worlds. The human sees feed items, attention buckets, source settings, and feedback controls. The agent sees the underlying item schema, source definitions, scripts, logs, and preference notes. These are the same objects from different angles.

That shared object model matters. If the agent acts on some hidden representation the human cannot inspect, the system becomes hard to trust. If the human interface is disconnected from the files, tables, commands, or APIs the agent can touch, the agent becomes brittle.

Agent-facing tooling does not need to be beautiful. It needs to be legible, hard to misuse, recoverable, and pointed at the same objects the human actually cares about.

You do not necessarily need a custom stack of API calls to build this kind of thing, especially for personal software.

Codex and Claude Code already provide a lot of what this prototype needs: scheduled tasks, headless execution, tool calling, shell access, file editing, web search, and the ability to inspect and revise their own work. For a local system, those harnesses can function less like chat products and more like weird application runtimes.

That changes the economics of experimentation. Instead of building a full agent platform, you can ask what your existing agent subscription can already do, then shape the software around those affordances. The result will not look like conventional SaaS infrastructure. Good!

Under no circumstances should a normal production product casually allow arbitrary AI-generated code to run in the background. That’s a security, reliability, and efficiency nightmare.

But personal software has a different risk profile. I can decide what I’m willing to run locally. I can inspect scripts. I can isolate processes. I can delete the whole thing if it gets too strange. It doesn’t matter if the solution would scale to a million users. It just needs to help one person shape a workspace around their needs.

Many of the most interesting AI-native patterns may be anti-scalable at first. They depend on local context, personal tolerance for mess, evolving preferences, and the ability to change the software as the user changes. Workspaces are deeply personal. The software that creates them should be too.

AI labs used to talk more about capability overhang: the idea that existing models support far more innovation in tooling and interfaces than we can absorb. They bring this up less now, but the idea feels more pressing than it did a year ago. Models are increasingly good enough to participate in the messy middle of real work. The interesting question is no longer just “what tasks can AI automate?” It is also: What forms of software have we not yet learned how to make?

The feed reader points toward one possible answer.

Developers may start shipping fewer finished applications and more scaffolds: a code skeleton, a set of schemas, a few core workflows, safety rails, and a process for eliciting the user’s preferences. The end user and their agent will then grow software inside that scaffold.

We’ve already seen early examples of people shipping not finished applications, but specs: markdown files that describe a piece of software so a user can paste them into a coding agent and generate a local version. I think that pattern will become more structured. AI may change the unit of software from a finished artifact into a cultivated workspace: a software garden. The developer supplies the trellis. The user, with an agent, grows the thing into the shape they need.