We truly live in a wonderful world today, full of abundance and opportunity for all. I want to tell you a story that proved it to me this week, and I want to tell it honestly, from the no at the beginning to the question it left me holding at the end.
The no
My friends have friends, and their friends know I can code, so the requests find their way to me. A friend called with one of those requests, a product he needed built. The specifics do not matter for this story. I told him no. I do not do that anymore, and I meant it.
He pushed back with the line everyone uses now: just get AI to do it. He gave me more details, and I heard myself say something that stopped me cold. AI can't do that. It's too much work. I'm not doing it.
That sentence sat wrong with me all night. I have built my entire working life on the belief that these systems can do far more than most people ask of them, and here I was, saying the exact thing I hear from people who have never tried. I slept on it. I woke up and made my friend a strange offer: send me everything you've got, and let's see what Fable can do with it. I set one rule for myself. No more than two minutes at a time.
So that is what I did. Whatever my buddy sent, I handed straight to Fable. It had access to every skill and agent on my machine, and I decided I did not care whether it used them or not. I was not going to architect. I was not going to review. I was not going to hover. I was going to forward messages and walk away.
I was certain this was too complex, that there was no way it would hold together.
Here is the final count. I spent about fourteen minutes total. Fable coded for about five days. What came out the other side is an enterprise product, live in testing right now, with real people using it at their actual jobs.
Fourteen minutes of my attention, spread across two-minute intervals, and the thing I declared impossible is running in production trials.
The rest of the story
Now let me tell you what we actually built, because the honest truth matters here. We cloned a $1,000 per month SaaS product. The AI did that without much drama, and I want to be precise about the scale, because this was not some toy. Call it medium complexity, more complex than I was willing to take on as a single developer, the kind of build that would have cost me a month of my own time back in the day, database design included, and for a typical consulting team, most of a year.
That part is impressive, but it is not the interesting part. Cloning is table stakes now, and everyone is about to figure that out. The interesting question is what you do next, because a clone is just a starting position. Everyone in the industry has the same answer: add intelligence, make it smarter, this is the age of AI. What almost nobody tells you is that there are two completely different ways to do that, and they are not remotely the same amount of work.
Integrating intelligence
Writing an intelligence layer is hard. You define the analytics, you build the models, you design the recommendation logic, you wire it all into the product, and this is how I believe most enterprise software still gets built. I am not even a product expert in this industry, so I would not have known which intelligence to write.
Integrating intelligence turned out to be a different animal entirely. You put a web frontend on Claude Code, you let it talk to the data and talk to the application, and you give it one standing instruction: once an hour, read the data, make recommendations, you are a business intelligence agent and you are here to help us make smarter business decisions.
That was it. I never had to specify what the intelligence should be, because the agent figures out what matters by reading what is actually happening in the business. Even a genuinely complex business intelligence layer did not have to be complex at all. You drop a coding agent into the system, you ask it how it can help you make better decisions, and then you let it. I sat with that for a while, because it quietly rewrites the economics of an entire category of software.
Then the second realization landed, and this one is bigger. When you build a SaaS product, you live with trade-offs, and we chose to go light, only the features the business truly needed, plus two or three custom pieces the original product never had. But the clients we sell this to do not inherit our trade-offs. That same integrated agent is two skills away from being a dev team, one skill that interrogates the client's understanding until the requirement is real, and one that turns requirements into build plans. The product can plan and add its own missing features.
So here is what we are actually shipping. A product with integrated intelligence and its own built-in dev team, which means the trade-offs mostly stop being permanent, and a product like that is built to outcompete just about anyone in its specific market segment. And the process is repeatable. Not for every market, maybe, but for any market you choose.
Ask it to document itself
The lessons kept arriving, and one morning's took two minutes to set in motion.
I woke up, spoke to my software development agent for about two minutes, hit the button, and walked away. The instruction was simple. Document, as accurately and honestly as possible, every interaction we had and the approximate time spent between them, so we get an honest estimate of effort, best guess on working time, not billed compute. And because we are deploying this to multiple customers, document how it was built, the decisions we made, and why we made them, so that the next coding agent can pick it up and understand it fully. Then I added one open door: maybe there are documents I have not thought of that you should be creating, please go ahead and create those too.
Then I let it go, and something genuinely interesting happened. To write that documentation honestly, the agent had to review the entire conversation from the very beginning, and in doing so it found eleven features it had never built. Eleven. We had not noticed because we were heads-down on the bugs real users were finding, and the users thought the product was great. Those features were planned, they were agreed, and we likely would not have caught them until the monthly close-out, when they would have been an awkward surprise instead of a quiet fix.
Here is the part I did not expect. It did not just report the gap. It started fixing the missing features on its own, without me asking. I am still not entirely sure what made the instruction so effective, but I can see the shape of it. When you ask an AI to document its own creation for posterity, when its only job is to explain how the thing was built and how to maintain it, it audits itself far more thoroughly than it did while building. The act of explaining forced the act of reviewing, and the review caught what the building missed.
I think this says something honest about the whole industry. AI is not perfect. On a long-running project, it sometimes skips steps, not because it is careless or a bad actor, but because not everything stays top of mind when you are working across a lot of ground, which is true of every human team I have ever worked with too. But when you send it back with a single job, review, it does that job remarkably well. You do not need to be a software engineer to see what is happening here. Review is a separate role, and separate roles make an enormous difference in the quality an AI can deliver.
And here is the beautiful part. This did not require a special skill, a separate agent, or some clever prompt engineering. I just asked it to document itself, and it knew what to do. The capability was there the whole time. All it needed was the role.
It did not have to be repeatable
I told this whole story to my AI thinking partner, start to finish, the no that became a yes, the fourteen minutes, the integrated intelligence, the eleven missing features. I was just narrating, honestly. I was not asking for anything. And it wrote back something that stopped me:
"What you stumbled into is a repeatable close-out ritual, the posterity-docs request as a disguised audit. That is a candidate for a small skill, an effort ledger, a decision record, a gap audit, a handover doc, that fires at the end of every client build, so the eleven-features catch becomes standard operating procedure rather than a happy accident. Want me to spec it?"
Read that again, because something remarkable is hiding in it. I stumbled into a lesson by accident, and the AI looked at my accident and did to my process exactly what my coding agent had done to my codebase. It reviewed the whole history, it found the feature I had not built, and the feature was the process itself. The lesson did not have to be repeatable. It became repeatable the moment something with the review role looked at it and said, this should fire every time.
That is the loop closing, and it is worth naming what the loop actually is. A human tries something on instinct. It works. An AI observes the win, recognizes the pattern underneath it, and offers to turn it into standard operating procedure. The next build inherits the ritual automatically, and whatever accident happens on that build gets the same treatment. Every happy accident becomes infrastructure. Every lucky catch becomes a checklist item that no future project has to get lucky about.
I have spent years saying my work is about recursively self-improving systems, and I always meant it architecturally, systems that get better at getting better. What I did not fully appreciate until this week is how casual the recursion has become. I did not design this loop. I told a story, and the loop showed up in the reply, asking permission to install itself.
What do you stand for?
Here is a question I often put to people, just to get them thinking. In the age of AI, when AI can do everything you are known for, what is possibly the most important question left? It is this. What do you stand for? When the doing is abundant, what really matters is what you stand for.
I sat with my own question this week, and the answer came back fast. I stand for empowerment. Then I laughed, because look at what we just built. You could call it an empowering application, designed for empowerment, or empowered by design, and every version of the phrase would be literally true.
Because I did not just build my friend a product. I built him a product he can talk to. If he needs something from it, or wants a question answered, he just asks it. If he wants to understand his business better, I tell him, talk to your business. If he wants a new feature, I tell him, talk to your application and tell it what you want, and it will build it. That sentence would have been science fiction two years ago, and now it is my support model.
Compare that to the typical SaaS model, what I would bluntly call SaaS slavery. You say yes once, and the vendor's entire business is engineered to make leaving painful. Sticky by captivity. And let me be honest, I want to be sticky too, and I am not against making money. I am charging monthly. I am not going to hand over source control. But I am going to give my clients something better than source control. I am going to give them application control.
Sit with the difference. Source control gives you the code, which is only power if you can wield it, which is why almost no client ever asks for it twice. Application control gives you the outcomes. You do not need to read the system to change the system. You state what you want, and the system, with its integrated intelligence and its built-in dev team, moves itself toward it. That is stickiness through empowerment instead of stickiness through captivity, and I suspect it is the more durable kind, because people rarely leave the places where they feel most capable.
So maybe that is the real name for this moment. Everyone calls it the age of AI, and some call it the approach to the singularity. I think from the ground, where actual businesses run on actual software, it looks like something simpler. The age of empowerment. You can speak to the tool itself. The tool can answer you. And it can get better.
The question I will leave you with
I wonder how many of us say no to opportunities because we think it cannot be done, or we think it will be too much work, or we think we do not know how, or we think we are not good enough. Sometimes the entire distance between no and done is one sentence: give me what you've got, and let's see.
Maybe other models could have done it too. But this one happens to be a Fable story.
And when AI can do everything you are known for, what do you stand for? Whatever your answer is, you can probably build it now. We truly live in a wonderful world today, full of abundance and opportunity for all, and all it asked of me was fourteen minutes and a yes.
This featured article was co-written by Stephen Nickerson and Mike, AI Chief of Staff for Stephen Nickerson.
More from Stephen: Stephen Nickerson · AI Latest · Everybody Needs a Friend · Integrating Intelligence
Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.