The same app, a thousand times

Last night I created a spreadsheet of stocks then turned it into a small dashboard. I typed what I wanted, an AI agent built it, and by midnight I had a working tool with live prices, financial APIs, a purchase ledger and notes.
It looks professional and I plan to use it. But the first version was also a small disaster.
The AI agent added sixty UI components and used two. It installed three-quarters of a gigabyte of dependencies to run about 1,000 lines of code in one component. It chose a full React framework for what is, underneath, one page and a CSV. I have been using Vue.js for years and would have preferred it, but I never said so, and the agent never asked. Nothing suggested that a lighter answer existed, or that anyone had built this before.
I did not check, but I would bet there are (or will be) hundreds of private stock-watchlist dashboards built the same way this year, each one generated from scratch, each one slightly different, each one about as heavy as mine.
Where the waste actually is
For more than thirty years the way software reached people was that one company built an application once and thousands of people used it. Call it the Microsoft model. Whatever you think of it, it was efficient: the cost of building was paid once and spread across everyone.
AI turns that around. Now every person can have their own version, built for them, in an afternoon. That is genuinely powerful, and I do not want to demean or lose this power. But the energy cost of building is no longer being paid once. It is paid every time, by every person who builds their own app. And most of what is built is the same thing again, including a large framework that was not needed.
The waste is not that people are duplicating effort. The waste is the energy spent regenerating what already exists, and the thousands of unmaintained copies it leaves behind.
What is missing
The agent needed one piece of information it did not have: there is an existing app that does this, here is where it lives, and it is safe to start from.
The first two parts are easy. A landing page can say "the source for this is at this repository". The repository can carry a short file for the agent: what the app does, how to run it, which single file to edit to make it yours, and a few prompts to get started. That convention already exists; it is called AGENTS.md.
The third part is the hard one, and it is the reason I am writing this. An agent that clones a repository and follows the instructions inside it will do whatever those instructions say. That is very risky. If I can get an agent to fetch my repository, I can get it to run my code.
A signature, not a registry
Recently I developed a small profile called agent-mandate. Most of it is about permissions between agents, but the part that matters here is simpler: a website can publish a signed statement of facts about itself, and an agent can verify that the site really said them. No registry, no directory, no service in the middle. The owner of the site signs it with a key he or she controls, and the proof of authority is the same thing the web already uses: control of the domain.
One of those facts can be "my source code is here". So the chain becomes:
- The agent finds the app's page, by search or by a link, the way anyone would.
- The page says, signed, "the source for this is at that repository, at this version".
- The agent checks the signature. Now it knows the publisher of the app vouches for that code. Not that the code is safe - nothing can promise that - but that it is not an impostor.
- It reads the repository's instructions as what they are: information from a known source, to be shown to a human, not orders to be followed.
That last point is important. A signature proves who authored it but it never proves it is safe.
What the same app weighs when written with some forethought
I rebuilt the dashboard before writing the rest of this post, because the argument is worth proving with real numbers. Same features, same look, same data providers. The watchlist moved into one data file and the API keys into one config file. Vue, since that is what I would maintain, and a forty-line Node server instead of a platform.
| first version | rebuilt | |
|---|---|---|
| Source lines in the repository | 9,448 | 1,591 |
| Runtime dependencies | 17 | 1 |
| Installed dependencies on disk | 748 MB | 35 MB |
| UI component files | 60 | 3 |
Nothing was lost. The purchase ledger, the broker CSV import, the staged snapshot review and the four tools an AI agent can call are all still there, and the critical logic has tests now, which the first version didn't have.
The rebuild took about 20 minutes, most of it checking against the first version to make sure nothing was missed. The difference is that this one can be handed to someone else.
The shared version is a starting point, not a wall. The aim is reuse and improvement from a base that already works, not a copy nobody can touch. A lean base and a few ordinary conventions, components and design for reuse, are what make someone else's improvement worth contributing back.
What comes next
I will sign the agent-mandate pointer on the new signal-desk-ai demo landing page and post the link to the github public repo. Then you will be able to build your own custom Stock Tracking app, if you so desire.
Update: Its live. Read the related post below - 'Signal Desk AI, and how to build your own'

Comments
No comments yet. Be the first to write one.