There are two pieces of advice about tests and architecture in AI-built projects, and both are wrong. One says write the tests first, design the architecture up front, do it properly from day one. The other says skip all of it, ship on vibes, you can add the boring stuff later. Following the first kills the speed that made AI worth using. Following the second guarantees the collapse everyone warns about.
The right answer is a moment, not a policy. And the useful news is that the moment announces itself, if you know the signal to watch for. It is the same signal for tests and for architecture, which is why I treat them together.
Why day one is wrong
Writing tests and designing architecture before you know if the idea works is spending your most expensive effort on your least certain bet.
Most of what you build in the first days of an AI project will not survive the week. You are exploring. The whole point of building with an agent is that exploration got cheap, so you can try five versions of an idea and throw four away. Tests written against code you are about to delete are pure waste. Architecture designed for a product you have not validated is a cathedral built for a congregation that may never show up.
There is a real cost to premature structure beyond the wasted hours: it makes you reluctant to throw the code away. Once you have invested in testing and structuring something, you defend it, even when the right move is to delete it. Premature rigor turns exploration into sunk cost. In the phase where you should be most willing to discard, it makes you least willing.
So day one is wrong not because tests are bad but because you do not yet know what deserves them.
Why never is wrong
The other failure is more common and more expensive, because it does not hurt until it is too late to be cheap.
An AI project with no tests and no architecture runs fine right up to the point where you need to change it without breaking it. Then the absence of both becomes the thing that stops you. Every change is a gamble, because nothing catches a regression and nothing constrains the blast radius. This is the fear of touching your own code, and it is not irrational. It is the correct response to a codebase with no safety net.
“Never” also compounds. Each feature an agent adds to an unstructured, untested base makes the next one riskier, because the base it builds on is less trustworthy. What starts as speed becomes paralysis, and the paralysis arrives exactly when the project is succeeding and you most need to move. That is the mechanism behind vibe-coded apps breaking around month three: not a sudden failure, but the accumulated cost of “never” coming due.
The signal: load-bearing
Here is the moment. A path deserves tests and structure when it becomes load-bearing, which is a specific and observable thing: when breaking it would hurt a real user, and when you are going to keep changing it.
Both conditions matter. A path that would hurt a user but never changes does not urgently need tests, because tests protect against change and there is none. A path that changes constantly but hurts no one if it breaks can stay scrappy. The intersection, high stakes and high change, is where you invest, and it is usually a small fraction of the codebase.
This gives you a rule you can actually apply. Do not ask “should this project have tests.” Ask, for each path, “would a user be hurt if this broke, and am I going to touch it again.” When both answers are yes, that path just became load-bearing, and that is your signal. Not the project’s age. Not a coverage target. The status of the specific path in front of you.
Tests first, then architecture
When the signal fires, do the two things in order, because one enables the other.
Add the tests first, and add them as characterization tests: tests that pin down what the code currently does, before you change it. On an AI-built project you rarely have a clean spec to test against, so you test the behavior that exists and works. What you are actually testing shifts when a machine wrote the code, which is a discipline of its own: testing AI-generated code is about catching the failure modes a human author would not have produced. Characterization tests are specifically the tool for locking down behavior you did not design so you can change it safely. And they only count if you actually run them. An agent that reports green without executing the suite has handed you nothing, which is the whole reason done has to mean done.
Then, and only then, refactor the architecture, using the tests as your net. Now you can restructure the load-bearing path, because the tests will tell you the moment you change its behavior. Refactoring without that net is how you introduce the exact regression you were trying to prevent. The tests are what make the architecture work safe instead of terrifying.
Notice the sequencing. Tests do not come first because they are more important. They come first because they make the architecture change survivable. Reverse the order and you are restructuring blind.
This is paying debt in the right order
If you have read how I think about vibe coding debt, this is the same idea from the other side. Verification debt and architecture debt both come due when a path becomes load-bearing. “When to add tests and architecture” is just “when does that debt come due,” and the answer is: when the path can hurt someone and you are going to keep touching it.
That framing also protects you from the green-build trap. A load-bearing path with tests that pass but prove nothing is not protected, it just feels protected, which is worse. The tests have to actually exercise the behavior that matters, or you have paid the cost of testing without buying the safety. That is the difference between a real safety net and a green build that is not a correct feature.
And this whole discipline is what separates shipping a demo from shipping something you can operate. Knowing when to add rigor, and where, is most of the actual work of getting from vibe coding to production without either drowning in premature process or collapsing under none.
Where PaellaDoc fits
The hard part of this rule is not agreeing with it. It is knowing, at any given moment, which paths in your project are load-bearing and whether they are actually covered. That knowledge lives in your head, and it goes stale fast when an agent is changing the codebase faster than you can track.
PaellaDoc keeps that map current: which parts of the product are load-bearing, what contract each one is supposed to meet, and what evidence exists that it does. So when a path crosses into load-bearing, you see it, instead of finding out when it breaks. The signal stops depending on your memory and starts living in the system, which is the only version of this rule that survives contact with real speed.
FAQ
Should I write tests before I start an AI project? Usually not. Early code is exploratory and mostly disposable, and testing code you are about to delete is wasted effort that also makes you reluctant to delete it. Wait until a path becomes load-bearing.
What does “load-bearing” actually mean? A path is load-bearing when breaking it would hurt a real user and you are going to keep changing it. Both conditions have to hold. High stakes with no change, or high change with no stakes, do not urgently need the investment.
Do tests or architecture come first? Tests first, as characterization tests that pin down current behavior, then architecture using those tests as a safety net. Refactoring without tests reintroduces the regressions you were trying to prevent.