Directing AI is like directing a human
AI can build almost anything, but not on its own. This is the method I learned building URG: explain well, break down the work, verify every delivery, and write it all down.
There is a line I repeat a lot: AI can build anything, but directing it is like directing a human. I learned it building URG Technology, a complete online store I put together alone, in about four months, with Claude as my tool. I do not say it to sound trendy. I say it because it describes exactly where the hard work ended up.
Anyone can ask an AI for something. Getting it to build an entire project without falling apart is a different matter. This is what works for me, in the order I apply it.
The bottleneck moved
For years, the limit on building software was writing code. With AI, that limit moved somewhere else. It became directing: explaining well, reviewing, and deciding. If the instruction is vague, the result is vague. If nobody reviews, mistakes slip through. If nobody decides, the project spins in circles.
Anyone who has led a team already knows that. I learned it first with people: across four summers at Cedar Point, in the United States, I went from food and beverage to leading teams of up to 80 people, through long shifts with thousands of guests waiting. The rules of good leadership do not change all that much when the team is an AI.
1. A document that works as a contract
You do not tell a new team "build me a store" and walk away. You explain what is being built, for whom, and under what rules. It is the same with AI. Before touching a single line of code on URG, I spent close to two months writing a document of about 195 pages: identity and pricing, every screen, the three product-page formats, payments, the admin panel, and twenty-five rules for preventing errors.
That document was the contract. When a result did not convince me, I did not argue with my own memory: I went back to the document and checked what had actually been asked for. And when reality changed the plan, I wrote it down: that is why a second version exists, one that describes the verified state of things, not what we had once dreamed up.
The difference between "build me a store" and a request with rules is enormous. The second kind says what has to happen, what can never happen, and how it gets checked: the same unit can never be sold twice, the customer has 8 minutes to upload proof of payment, if the search finds nothing, offer three alternatives. With that, the AI builds what you actually need, not whatever sounds similar.
Not every project needs 195 pages. The La Roca catalog was built in 4 or 5 days. The size of the plan depends on the size of the risk, but the plan always exists, even if it fits on a single page.
2. Small tasks that can actually be reviewed
URG was not built in one go. It was built across 293 logged tasks, each with a concrete request: make the mobile header take up less screen, stop the payment-logo strip from jittering, center the sold-out stamp. A small task explains itself in a few lines, gets tested fast, and if it comes out wrong, gets asked for again with more precision, without knocking down everything else.
At Atlantic Center the pace was different and the idea was the same. The client asked to "bundle it all together," so each release gathered many changes, got tested as a block (with scripts for the sensitive logic and the real application for the interface), and shipped all at once through an automatic update.
3. Verify in the code, not in the promise
This is the rule that has saved me from the most trouble: nothing is taken as done until it is verified in the code. An AI can say "done" with total confidence. So can a human. In both cases, the job of whoever is directing is to check.
At La Roca I learned the finer version of that rule. An early version of the analytics panel let anyone in with any password: the code treated any server response other than "unauthorized" as a success. Out of that came a principle I now apply to everything: the absence of an error is not confirmation of success. Verifying is not reviewing what the code believes, it is measuring what the user actually sees.
When real money is on the line, I raise the bar even higher. At Atlantic Center, before touching the teacher payroll in the version the client was already using, I wrote automated tests for the renaming logic and for payroll. Not because I distrusted the AI: because a bug there gets paid for with someone else's money.
4. Tell apart what is asked for from what is needed
Directing is not obeying. At Atlantic Center, the client wanted to create the same bus route three times, once per price. The system already allowed changing the fare on each trip, so it was not necessary. With teachers, on the other hand, that did not exist yet and had to be built. More than once, the literal request was hiding a different need, and whenever money was on the line, I asked before acting.
With AI the risk is similar: if what you ask for is not what you need, it can build the wrong thing very well. The judgment has to come from whoever is directing, and that includes telling the client when they believe they are more protected than they actually are.
5. Write everything down
A project with no documentation depends on one person's memory, and memory fades. That is why URG has two documents: the first with the vision, and the V2.0, from June 19, 2026, with 98 pages that describe only what is verified in the code, written so that another team, or another AI, could rebuild the store almost identically.
This very site was built the same way: with a master document, clear decisions, and verification of every delivery. If you ever want to switch providers, what is written down is what sets you free.
What AI does not replace
After URG, Atlantic Center, and La Roca, the split is clear to me. AI builds fast and never gets tired. I bring the right question, the plan, the review, the decision on what does not get built, and the responsibility for the result. With AI you can build almost anything, but you have to know how to direct it.
- 1Write the plan before you build.
- 2Break the work into tasks that can be reviewed.
- 3Verify in the code, not in the promise.
- 4Ask what is needed, not just what is being requested.
- 5Write down what changed and why.
Know someone this helps? Share it.
