Two kinds of holes

The list everyone recognizes

When an AI-assisted MVP starts to strain, the symptoms are familiar:

• Dozens of unrelated features wired through one giant file, so every change risks breaking something far away.
• State scattered across components with no single source of truth, so bugs become impossible to reason about.
• One or two enormous service files talking to the database, external APIs, business logic, and email all at once.
• A schema grown by ad-hoc columns ("we need a status2 now") with no migration story.
• Tests that do not exist, or that check shape without describing behavior, so nobody dares refactor.
• Integrations that each work in isolation but not as a system: no handling for retries, idempotency, or ordering when things fail.

None of this means the AI did something wrong. It is the predictable shape of a codebase whose structure emerged from a sequence of uncoordinated good answers, rather than from a person holding the whole product in their head. The framework became the architecture by default.

Two kinds of holes, and they mean opposite things

Split that list in two, because the items mean opposite things about the work.

The first group is structural: everything through one file, state everywhere, god services, ad-hoc schema, the general big ball of mud. These are the signature of an absent steward. Structural holes compound. Each new feature makes the next one harder, until a rewrite looks cheaper than another change.

The second group is resilience: thin tests, happy-path integrations, missing retries and idempotency. These are the signature of a product that has not met production scale yet. Every early product has them, including ones built by an expensive senior team. They are bounded, known, and schedulable.

A stewardship problem, not an "AI can't" problem

The missing ingredient in the broken codebases is not model capability. It is a human mental model of the product and the domain that every AI answer has to respect. Architecture should be driven by the domain (billing, auth, content, the actual nouns of your business), not by whatever the last answer suggested. The framework is the delivery mechanism, not the design.

Concretely, the structure that prevents the structural holes looks like this:

• Module boundaries set deliberately, so a change in one area cannot reach into another by accident.
• A single source of truth for state, so the same fact is not stored and updated in four places.
• Services scoped to one domain each, so no file becomes the place every concern goes to die.
• Ordered, version-controlled migrations from day one, so the schema has a history you can read.
• Tests that encode the behavior that matters, so the code is safe to change rather than frozen by fear.
• Integrations treated as a system, with retries, idempotency, and ordering designed in, not discovered in an incident.

How we build

This is the part SDS exists to do. When we build with AI, and we build with it every day, the model writes code inside a structure we own. We set the boundaries first and keep them. We keep state to one source of truth. We scope services to domains. We version migrations from the first one. We write tests on the paths where money moves or a person gets the wrong result. We treat each integration as part of a system that has to survive a retry and a failure, not just a happy-path demo. Every project passes our own internal multi-dimensional review before handoff, with the findings written down so you can see exactly what was checked.

Here is the part most firms would never put in writing. We recently ran this exact six-failure-mode lens across our own portfolio. The structural holes came back clean: real module boundaries, coherent state, focused services, ordered migrations. The gaps we found were the resilience kind, the ordinary debt every pre-revenue product carries, and the work to close them is already scheduled. We say that because a firm that hides its own gaps cannot be trusted to find yours.

The compounding payoff is real. Because the structure is deliberate, the second feature is cheaper than the first, and the second product launches faster than the first. That is not a heroic story. It is the predictable outcome of architecture someone is actually stewarding.

What this is not

This is not an argument that AI coding is bad. The opposite. AI is the fastest set of hands we have ever worked with, and the gains are enormous when there is a steward directing it. It is not a claim that we ship zero gaps; we ship known, named, scheduled gaps, which is different from hidden ones. And it is not a one-size refactor prescription. The right path out of the holes depends on your domain. The wrong path is another round of snippets.