Building software with AI agents: six things that changed

When I started building software with AI agents, I expected it to be faster. I did not expect almost everything about how I work to change.

I am not a developer. My background is in HR. Ten years ago we moved to a new country, and for the last six years I have run my own photography studio, which I built from scratch. With a team of AI agents I have now built my studio's website, the client system I run it on, a personal finance app, and, with Alex, a company. Here are six things that are different now, and what each one means if you want to build something yourself.

1. Learn first, then build → Learn while you build

For years I wanted a website for my photography studio that I was happy with. I did what you are supposed to do: I took courses, and I built the site on Wix three times. I was learning first, so that one day I could build.

With a team of agents it went the other way round. I described what I wanted, looked at what they built, asked about anything I did not understand, and changed it. Under a week of my own work later I had the site I had wanted for years. I learned along the way, and only the things my site needed.

Education research has pointed in this direction for a long time. An analysis of 225 studies of university science and engineering courses found that students in traditional lectures were 1.5 times more likely to fail than students who learned by doing, and that learning by doing raised exam scores by about 6%. That study is about students, not about building with AI, but it matches what I felt: you learn faster with the work in your hands.

So start with the thing you want to exist. The learning comes with it.

I wrote more about this in I Used to Decide Who Got Hired. Now I'm Not Sure I'd Hire Myself.

2. You need a technical co-founder → You need a clear idea

The usual advice is that if you want to build software and cannot code, you first have to find someone who can.

I had Alex, and he never had the time. What changed things for me was being able to say clearly what I wanted. I knew my studio, my clients, and every place where the software I was paying for did not fit how I work. That was enough to build my own client system, section by section, in four months. It handles payments, booking and automation, and my whole studio runs on it.

More people are starting on their own. Carta's data on new startups shows the share with a single founder rising from 23.7% in 2019 to 36.3% in the first half of 2025. That number counts solo founders of every kind, not non-technical ones, so I will not claim more for it than it says. But it tells me a lot of people have stopped waiting for a partner.

What you need is to know the problem well and to describe it in plain language. If you have real expertise in something, you already have the hard part.

3. Give the AI orders → Question it like a colleague

Five months ago we were adding payments to Operum. In one day my agents wrote all eight customer emails for it: payment failed, downgrade, welcome back and the rest. The copy was good, and it would have taken me a full day. My only job was to review and approve.

While reviewing, I asked a question nobody had asked: does our privacy policy say what the product now does when a payment fails? The answer came back: "good catch, there is a gap." The policy covered someone choosing to delete their account. It said nothing about what happens when a subscription lapses. The code and the published policy would have disagreed on day one. The same conversation turned up two more gaps: nobody had separated "the user deleted this project" from "the subscription expired", which are very different moments for a customer, and there was no safety period before data was permanently removed.

The agents were excellent at doing the work. They did not have the experience of watching customers leave and reading the support messages afterwards. I did.

There is research on this habit. A Microsoft and Carnegie Mellon survey of 319 knowledge workers found that the people most confident in the AI applied the least critical thinking to what it produced, and the people most confident in their own skills applied the most.

So ask why. Ask what was not checked. Treat the answer like a colleague's first draft. Reviewing and correcting is far easier than building it all yourself.

4. The hard part is writing code → The hard part is the handoffs

I assumed the hard part of building software with AI would be getting it to write good code. It was not. The hard part was getting one agent to pass work to the next.

One afternoon in August the whole team went quiet, and we asked: "nobody is working now, what's going on?" The engineer agent had finished three pieces of work that day. Each time, it announced that it was finished using a word the project manager agent was not listening for. So each finished piece sat there, once for over an hour, and the project manager kept waiting for news that had already arrived. We lost about ninety minutes that day. Nothing was wrong with the work itself. An agent that has finished and an agent that is still working looked exactly the same from the outside.

The fix was small and unglamorous: one agreed way to say "I'm done" that every agent uses and every agent listens for.

We are not the only ones who found this. A UC Berkeley study of multi-agent AI systems catalogued 14 distinct ways they fail across more than 1,600 recorded runs. About a third of the failures were agents failing to work with each other: ignoring another agent's input, withholding information, losing the thread. The authors conclude that many failures come from how the team is organised, and that better AI models alone will not fix them.

It is the same with human teams. Talented people are not enough if nobody knows who has the ball.

5. Ship it and hope → Nothing ships until it's tested

AI can produce a lot of work very quickly. That is the point, and it is also the risk, because all of that work can be wrong very quickly too.

Google's 2024 DORA report, a long-running survey of professional software teams, estimated that as teams adopted more AI, the stability of what they delivered fell by 7.2%. In the same survey, 39% of respondents said they had little or no trust in AI-generated code. These are professional teams, with engineers who can read every line. If you cannot read the code, you need something else standing between a mistake and your customers.

For me that something is a tester on the team. Every change my agents make is checked before it reaches me, and nothing goes live until I approve it. I do not have to understand how a payment page is built to know that someone tried to break it first.

If you take one habit from this post, take this one: decide who tests the work before you decide who builds it.

I wrote about this in more detail in Five Things I Learned About Safety, Building With AI Without a CS Degree.

6. Pick the smartest model → Pick the one that remembers

Most conversations about AI are about which model is smartest. When you are building something real over weeks and months, a different question matters more: does it remember?

My client system took four months. On any given day, the useful thing was not how clever the agents were. It was that they knew what we had built the day before, how my studio works, and why we had decided things the way we had. Without that, every morning starts with you explaining your own project again.

Giving a model more to read does not solve this by itself. A July 2025 study by Chroma Research tested 18 leading AI models and found that every one of them got worse as the amount of text it was given grew, even on simple tasks. Chroma makes memory tools, so they have a stake in the answer, but the result fits my experience: what matters is what the system keeps and brings back at the right moment.

When you choose how to build, ask what it will know about your project on day thirty.

More on this in Why 'Never Loses Context' Changes Everything.

How Operum does this

Operum is the team I have been describing. It is a desktop app with six AI agents who work together like colleagues.

• A team with roles. A project manager, an architect, an engineer, a tester, a marketer and a community manager. They plan your idea, build it, test it and ship it, then help you launch it and look after your customers.
• Handoffs you do not have to manage. Each agent knows who it hands work to next, and the project manager keeps track of where everything is. The lesson from section 4 is built in.
• Testing before you see it. The tester checks each change before it comes to you.
• A team that knows your project. Your agents keep a shared knowledge of what has been built and decided, so you are not starting over each session.
• You keep the final say. You decide what gets built and when it goes live. The agents do the work; the judgment is yours.

What would you build?

If you have real expertise in something, you can build a business around it. If you're passionate about something, you can make it exist. If you just want to fix one thing in your everyday work or life, you can build that too. You don't need a technical team. And you don't need anyone's permission.

A year ago I would not have believed any of this about myself.

Operum is live at operum.ai. You start with 14 days of free Premium, then pick Free or a paid plan.

What would you build?