Plenty of startups are selling AI agents to businesses. They deliver the solution, and they often deliver it fast.
But is it built on a sound structure? Is it sustainable?
I understand the urgency. Business owners and heads of organizations want to benefit from AI, get an edge from it, and it’s moving so fast that it feels like you have to go now.
Still, nothing beats something well structured, built on a sound architecture. It can evolve, it keeps improving, it keeps helping you. Because your organization is in it for the long run.
Vendors aren’t the only ones moving fast
So do we.
A business leader went it alone. AI-assisted development, no structure, very fast. Within a few days, he had something out.
And it worked. Partly.
That’s where the trap springs, and it looks nothing like a failure.
A system that crashes, you see it. There’s an error message, a blank page, a call from the client. You stop it, you start over, you’ve lost a few days. It’s annoying, and it’s no big deal.
A system that half works, you use it. That’s the whole difference. It actually helps, so you lean on it. You build on it. The team gets used to it, data piles up in it, processes start depending on it. Every week that goes by raises the cost of undoing it, without anyone consciously making that call.
Then comes the day it has to hold up for real. A bigger client, a larger volume, a new person on the team who has to take it over. And at that point, there’s nothing to fix.
What was built without structure can’t be maintained, doesn’t transfer, and doesn’t get fixed with patches. You don’t fix it. You rebuild it.
What I wrote in June, and the word that mattered
In June, I wrote that vibe coding, properly governed and led by experienced people, was becoming a competitive weapon. That custom software was within reach again, and that an organization could finally get tools that reflect how it actually works instead of adapting to someone else’s.
I still think so. The important word was governed.
This edition isn’t a retraction, it’s the second half of the sentence. The same tools, in the same hands, without the governance, produce exactly what we just saw: something fast, impressive, and unsustainable.
It matters to say it plainly, because the nuance gets lost fast. When a practice becomes popular, people keep the part that appeals and forget the condition that makes it viable. Vibe coding cleared that bar easily. Governance, much less so.
Speed was never the problem
Let’s be precise here, because the natural reflex would be to conclude “slow down.”
That’s not my point, and it would be the wrong answer. Speed is a real advantage. An organization that takes nine months to decide while another ships in three weeks isn’t being careful, it’s simply losing. Refusing to move fast in 2026 isn’t wisdom.
The problem is what you skip to go fast.
And the first thing that gets skipped is always the same: the definition work. Understanding the real path your operation follows before coding anything. Knowing where a request starts, where it goes, who decides, where it sits.
It’s the step that produces nothing visible. At the end of a day of definition work, there’s no demo to show, no screen lighting up, no “look what it does.” There’s a sheet of paper. That’s exactly why it’s the first thing cut when the schedule gets tight.
There are things I’m less sure about. Not this one. You can code fast. You can’t define fast. Understanding how an organization really works means watching, asking questions, and getting corrected by the people who do the work. No tool speeds that up, because it isn’t a technical problem.
What was still standing when everything was thrown out
Back to the leader.
He ended up hiring a firm. They redid everything, top to bottom.
He lost money. He lost time. That doesn’t come back, and I’m not going to pretend otherwise so the story ends better than it did.
But one thing was still standing.
His process was properly defined. He knew how his organization actually worked, step by step, who decides what and where things wait. He had done that part before starting, and it wasn’t thrown out with the rest.
So the firm didn’t start from zero. It started from his process. It didn’t have to go back into discovery before writing a single line. The slowest work was already done, and it was good.
That’s the whole difference between starting over and picking up where you left off.
The code, on the other hand, was disposable. It always had been. The code you write today will be obsolete in two years anyway, when the tools have changed again, and all the faster if it was generated in a hurry. The definition work wasn’t. It’s the only part that survived a complete rebuild.
Write the process, the rest is replaceable
If you’re going fast, go fast. I’m not going to tell you to wait. Waiting costs too, and it often costs more than the mistake.
But before launching anything, take the time to put your process down properly. Not in a tool, on paper. The real path: where the client’s request starts, where it goes, who decides, where it waits, all the way to cash in the bank.
It takes half a day. It takes no technical skill. And it doesn’t expire.
It won’t stop you from being wrong about the technology. You will be wrong, everyone is, the tools move too fast for it to be otherwise. That’s fine, that’s just the cost of doing business right now.
It will keep you from being wrong twice.
Because the day everything has to be rebuilt, and that day comes more often than people think, the only question that matters is this one: do I start from zero, or do I start from something?
Just write the process down. The rest is replaceable.
To get the weekly analysis on AI and digital transformation for SMB leaders, subscribe to L’Architecte (in French).
