Building With AI When You Don't Know Architecture: 5 Checks

Building with AI without architecture breaks around month six. Five checks you can run without reading code, what each answer means, and the cheaper path before a rewrite.

The fifth question is the one nobody answers without opening the repository

If you are shipping a product built with AI and you cannot judge architecture, run the cheapest check first. Take a laptop with nothing installed on it, and try to bring your system up from scratch using only what is written in the repository. Time it. If it takes more than a couple of hours, or if exactly one person on earth can do it, you do not have a running system. You have a chat session that happens to still be open.

That is the first of five questions listed at the end of this piece, and none of them asks you to read a line of code. They exist because building with AI without an architecture background rarely breaks in the week the code is written. It breaks around month five or six, in a very specific scene: you have to make a call, you ask two people, and both answers sound equally reasonable to you.

A dev.to post on this exact topic collected 70 reactions and 51 comments in a few days. The comment count is the interesting number. Nobody comments on a tool guide. People comment when they recognize their own week in the text.

I sat on that side of the table and could not even phrase the question

Clean laptop, timer running: the cheapest check on the list

Before Revin I ran a startup renting construction equipment through an app, the "Uber for excavators" idea that everyone tried at some point. I came from mechanical engineering and industrial assembly. I could read a drawing, argue over a measurement, and I had signed off technically on the steel structure of a racetrack. Put a developer in front of me and I went quiet.

He would say the booking module needed reorganizing before the new screen could be built. I had two options: believe him, or fight with no argument at all. I believed him, every time. And the sprint kept ending without the delivery I expected.

It took me close to a year to find my own mistake. His answer was never the problem. My question was, because it was always "how long will it take". That is why I went back to writing code. The startup died for other reasons too, but that part I could have avoided.

AI hands the same feeling to anyone starting today, and hands it faster. You describe what you want, code appears, the screen loads, the button works. It feels like control. It feels a lot like walking out of a sprint meeting with a date written in my notebook.

Month six breaks quietly, and all at once

The first symptom is the tiny change that crosses the whole system. You ask for new wording in a confirmation email and the edit touches something like twelve files, because the same rule got written in five different places on five different days. Each piece worked when it was born. Together, they have no owner.

Then there is the machine problem. There is one way to run the thing, and that way lives in one person's head or in their downloads folder. None of that sounds technical enough to reach a meeting agenda, which is precisely why nobody fixes it.

The third one is the most expensive and the quietest: no trail. Ask what the system did yesterday and the honest answer is someone opening the database by hand. Teams that leaned on AI without that discipline paid for it in a measurable way, and I have written before about squads that doubled production bugs after adopting AI without guardrails.

The fourth takes ten minutes. Ask someone to deliberately break the rule that calculates pricing, then run the test suite. If nothing fails, what you have is quality theater: the coverage number exists, the guarantee does not.

"But it works and customers are paying"

On site, the photo shows the bolt. The drawing is what holds the structure up

Fair objection, and I hear it in almost every call. Working is the easiest requirement on the list. What separates a product from an expensive prototype is the price of the second change, then the third, then the one requested on a Friday afternoon.

The bill usually arrives with the first enterprise customer. They open the contract and ask for SSO against their directory, per user audit logs, and a report that scans two years of history without timing out. That is the day your architecture becomes your product, except now it is being graded by the person signing the check.

One short detour, because it helps. In industrial assembly, the part that shows up in photographs is the bolt. What keeps the structure standing is the drawing nobody opens after the ribbon is cut. Software behaves the same way, with the extra twist that the drawing may never have existed.

When all five answers come back bad

A full rewrite is the request that reaches me most often, and it is almost always the most expensive one. Rewrites freeze the product for months and give you back, at best, what you already had. Two cheaper roads come first.

One is buying instead of maintaining. Much of what stalls these projects is generic plumbing: authentication, recurring billing, email delivery, invoicing. Every quarter you keep that in house is a quarter the stack you never update keeps accruing a bill you did not budget for.

The other is putting a genuine senior engineer on a review before you hire anyone. Not a hire, a review. It helps to know the range that costs, and rates for software developers in Brazil in 2026 swing wider than most buyers expect. Thirty odd hours of an experienced reader costs less than one month of rewriting in the dark. If you are unsure how to tell senior from confident, there is a way to measure real seniority without trusting resumes.

Where this ruler does not apply

If you have three weeks to find out whether anyone wants the thing you imagined, ignore almost all of this. A prototype does not need a trail, tests that actually test, or a second person able to boot it. It needs proof of demand, fast.

I also cannot tell you whether the ruler holds for an internal tool used by four people who talk daily. At that size, documentation is lunch. The moment a paying customer and a server that cannot go down enter the picture, it applies in full.

The five questions, worth printing

1. Can someone who has never touched the project boot the system on a clean laptop in under two hours, using only what the repository says?
2. When you ask for a small copy or rule change, how many files get modified, and why is it more than one?
3. Can you answer what the system did yesterday without someone opening the database by hand?
4. If someone deliberately breaks the rule that computes price, discount or permission, does any test fail before it reaches production?
5. Besides the AI and you, who can say out loud why a given structural decision was made?

You already know the first answer

You read the list and felt which of the five is going to hurt. That does not take an audit. It takes one afternoon blocked this week and someone next to you with permission to say it is bad.

Here is the question I never learned to ask in my own startup, the one that would have changed how it ended: if the person who knows how to boot your system stops answering the phone for two weeks, what exactly stops working in your business?