Yusuf Young

Why I think AI agents will replace much of today’s software

So I just launched my trading bot. Some of my trading I enjoy, like following sources I actually learn from. But much of it was just something I had to do, so I decided to automate that part away. I asked myself, why can't an AI decide which stocks to buy and sell? My decision making basically consists of:

  1. having beliefs about the future
  2. reading from sources I trust and thinking about it based on what I know
  3. making decisions about what has the greatest combined risk/reward probability

An AI can be taught 1, do 2 way better than me, and do 3 without emotions clouding its judgement.

I did quite a lot of backtesting to see if my hypothesis held. And - yes - by far!

So I built a trading bot.

Anyway. The bot is really just my excuse to talk about something else.

Because somewhere between teaching it to trade and arguing with the broker's API, I became convinced that the way we think about software is now completely obsolete, and that there is a much better way to build software now. A path I should have taken, but decided not to (this time!).

Let me show you how the bot works first. This detour will make sense in a minute.

How the trading bot works

The system does four jobs. Only the decision maker uses an LLM; the others use traditional software:

  1. Collect information. Collectors gather the research from public sources I trust. <-- Traditional software
  2. Prepare prices. A service prepares market history and current quotes. <-- Traditional software
  3. Make the decision. An AI reads a saved snapshot of the research, prices and bot-owned portfolio, then proposes a portfolio decision. <-- Agent
  4. Carry it out. A broker service checks the decision, places the orders it can afford, and records what actually happened. <-- Traditional software

The bot and I use the same physical broker account, so the software must keep our separately owned shares and cash straight. The AI makes the portfolio decision. The other parts follow written rules to gather its inputs and carry out its request.

The bot-owned section of my Portfolio Control dashboard, with private figures blurred.

My Portfolio Control dashboard, September 30, 2026. Allocation shows each holding's share of my tracked portfolio with various metrics that are important for me.

What I realized

When I planned this, I considered making each part a separate agent. Seemed like a cool way to do it. But I figured that would be much harder than writing classic software. The decision making needed an agent; surely the rest could just execute its steps?

I mean, how hard could it be? The modules seemed quite independent. One collects data. Another takes the AI's decisions and places the orders with the broker. Simple enough.

Boy, was I wrong...

My rough estimate of where the development time went: 85% on the broker service, 12% on collecting research and preparing prices, and 3% on the AI agent part!

Why? Because a classic program is fixed. Any flexibility it has is flexibility you built into it. A different input, a different sequence of events, a different combination with another system: if you want it to cope, you have to write the logic for that. Miss something, and even a small variation can break it.

You can make it adaptable with clever engineering. But now you're building a much more complicated program, trying to think through all those possibilities before they happen. That's the huge upfront cost.

And then the things you never thought could vary… vary. During paper testing, repeated broker records made an account update take many minutes, leaving a fresh account view unavailable while it ran. A fee arrived after a fill. Money reserved for a currency conversion left too little for a planned share purchase.

Each case meant finding the actual sequence, changing the code, and testing that the fix hadn't broken another sequence.

Why agents avoid this problem

With the AI part, I just had to get the core loop working: make sure the LLM gets the inputs it needs, can use its tools, and returns its output. That was it. I didn't have to sit there anticipating and programming every variation in what it might read.

Because with an agent, you're starting with a neural network that already has the ability to interpret unfamiliar input and reason about what to do. You don't have to build that flexibility from scratch. It comes with the model.

The input arrives in a different format? It can work out what the data means and how to turn it into the required output. Something is missing? It can fetch it again. Something goes wrong? The error becomes new information. It can inspect what happened, change its approach and try again.

That's what I find so powerful. I can say: "Here's your input. Here's the output I need. Here are your tools." The agent can work out the steps in between as the situation unfolds. I don't have to program every possible path in advance or design clever algorithms to handle every conceivable scenario.

Now imagine building the whole system this way. Each agent gets an input, has a job, and produces an output for the next one. If needed, another agent coordinates them.

For example, I could give the collector this job: "find the new material, preserve the original, identify what changed, and hand the next agent a complete, dated record". If the source changes its API, a page moves, or the fields arrive in an unfamiliar order, the agent can inspect what's there and work out how to produce that record.

That's the shift I see: a huge upfront cost of anticipating and coding exceptions becomes a much smaller, ongoing cost of reasoning about them as they occur.

I define the job, give the agent tools and clear guidance, and improve that guidance when a real exception reveals something missing. It can also reuse what it learns, build small tools, and improve them over time. I expect the total work to fall tremendously, including the maintenance caused by changes in other systems.

Building a “bot force” is surprisingly similar to building a workforce

Another thing that surprised me: building a team of agents is eerily similar to building a team of people doing the same work.

When I built FunnelBud, I couldn't write a script for every situation an employee would face. I gave people roles and goals, then wrote down principles for how to reason through decisions and what those decisions should align with. Those went into an internal guidelines portal, with examples. We practised through role plays and discussed what a better response would look like.

When someone made a choice I didn't think aligned with what's best for the business, I asked: What led you to that decision?

Sometimes the goal wasn't clear. Sometimes a principle was missing or wrong. Sometimes an example taught the wrong lesson. I'd update the guidance, then use it in training. Whenever something was uncertain, we went back to those principles and asked how they applied.

The portal improved through real work, and training reinforced it until those principles became part of how people thought and acted.

I'd give agents the same hierarchy:

  1. A goal: What output should this agent produce, and what are we ultimately trying to achieve?
  2. Principles: What should guide its decisions when the input or circumstances vary?
  3. Examples: What situations can we think of now, and how do the principles apply to them?

The examples aren't an exhaustive script for the future. They help the agent understand the principles. When something new happens, it can reason from the examples, through the principles, back to the goal.

That is how I built a human organisation. I think it's also how we should build an organisation of agents.

What this means and what you can do next

So what does all this mean? I think that, in many, many cases, the old way of engineering software has just been surpassed.

We used to have to build the logic and algorithms into the machine ourselves. Now we can give an LLM an input, tell it what we want it to achieve, and let it work out how to get there. We don't have to specify, or even fully understand, every step of its reasoning.

The work becomes guiding its behaviour through clearer goals, principles and examples. We shape how it makes decisions, and it figures out which output fits those instructions.

Whether you're a programmer, a CEO or a product manager, next time your first instinct is to build software, pause and ask: what input do I have, and what output do I need?

You can write a deterministic program to connect the two. Or you can give an agent a goal, principles, examples and tools, and let it work out how to get from one to the other.

For a bigger system, give each agent a specialised job. Its output becomes the next agent's input, and it tells that agent when the work is ready.

If I were building my system again, I'd organise it like this:

  1. A research agent collects research and information and saves it.
  2. A price agent prepares market history and current quotes and saves them.
  3. A decision agent reads that research, the prices and the bot-owned portfolio, then decides which trades to make.
  4. A broker agent checks the decision, places the orders it can afford, and records what actually happened.

The bot's four grouped jobs today and how I would organise them as specialised agents.

Do you see why I think this will replace much of today's software? A system that can reason through unfamiliar situations is far more flexible. It can handle cases that would otherwise break it, with far less work to get it running and keep it running.

That's how I want to build from now on. For me, deterministic software is dead. If my agents need it, they can build it for themselves, on the fly.