The prototype works. Users can sign up, complete the core flow, and get the result the product promised. You demonstrated it to someone last week and it held together. But when they asked how the authentication connects to the user profile, you said something vague about middleware. When they asked what happens to the data after the form submits, you described what you thought was happening rather than what you knew. When they asked whether you could add a second user role, you said you would have to look into it.
You built something you do not own. It runs, but it runs without your understanding. That is not a technical problem. It is a structural one, and it was created during the build, not after it.
What a Black Box Build Actually Is
A black box build is a prototype whose internal logic is opaque to the person who built it. The inputs and outputs are visible — you can see what the user enters and what the system returns — but the mechanism connecting them is not. You know what the build does. You do not know how it does it.
This happens in AI-assisted development for a specific reason: the operator accepts outputs without interrogating them. Each prompt produces code, configuration, or architecture that the operator did not write and did not verify. The code works, so it gets absorbed into the build. Over the course of a session, the build accumulates logic the operator has never read, cannot explain, and has no map of. The prototype becomes a collection of accepted outputs rather than a structure the operator understands and controls.
The distinction matters because understanding is what makes a build modifiable. If you cannot explain how the authentication system works, you cannot safely change it. If you cannot describe the data flow from form submission to database write, you cannot debug it when it breaks. If you cannot articulate the relationship between the session state and the user profile, you cannot extend either without risking a collision.
The black box is not a knowledge gap. It is an accountability gap. At no point during the build did you require yourself to understand what was being built before you moved on.
Why the Build Process Creates This
The default pattern in AI-assisted building is: prompt, receive output, test whether it works, move on. If the output passes the surface test — the screen renders, the button functions, the data appears — it gets incorporated. The operator never asks what the output is doing underneath the surface, because the surface is working and there is more to build.
This pattern is efficient at producing builds and catastrophic at producing understanding. Every output you accept without interrogation is a piece of logic you have outsourced permanently. You can use it, but you cannot own it, because ownership requires comprehension.
The problem compounds across sessions. AI coding tools do not maintain a coherent architectural understanding between conversations. Each session begins from whatever context you provide. If you have not built and maintained your own model of the system — what each part does, how the parts connect, what each decision was made for — then after several sessions you have a build that no single entity, including the AI that helped produce it, fully understands. You are the only person positioned to hold that model. If you did not build it during construction, it does not exist.
The Interrogation Requirement
Every output produced during a build session needs to pass a minimum comprehension check before it is incorporated. This is not about reading code line by line. It is about being able to answer three questions:
What does this do? Not in technical terms if those are unfamiliar, but in functional terms. "This handles what happens after the user submits the form — it validates the data, writes it to the database, and sends a confirmation email." If you cannot answer in functional terms, you do not understand the output well enough to incorporate it.
Where does this connect? What does this output receive input from, and what receives output from it? Every component in a build exists in relation to other components. If you cannot name those relationships, you cannot predict what changes to this component will affect elsewhere.
What would break if this changed? If you modified the core logic of this output, what else in the build would need to change to accommodate it? This question reveals dependencies. If you cannot answer it, you cannot safely modify the build later.
If you cannot answer all three questions about an output, do not move on. Ask the tool to explain what it built. Ask it to describe the dependencies. Ask it what would break if you removed it. Keep asking until you can answer the questions yourself, in your own words, without referring back to the tool's explanation. That threshold — your own words, without prompting — is the minimum for comprehension.
Building the Map as You Build
The interrogation requirement alone is not enough. You also need a running record of what you have built and how it connects. Without that record, comprehension gained during one session dissolves between sessions, and each new session starts from a reduced understanding of the system's current state.
The record does not need to be technical. It needs to be accurate. Before each session ends, write a plain-language description of what exists in the build: the components, their functions, and their connections. A paragraph is sufficient. "The app has a form that collects three fields. On submission, it validates the input and writes a record to the database. A confirmation email is sent via a third-party service. There is no authentication; access is via a direct link." That is a complete structural description of a simple build. Anyone reading it knows what exists and how it connects.
Update it every session. When you add a component, add it to the description. When a component changes, update the description. When you remove something, remove it. The description is your architectural map. It is also what you hand to someone else if you ever need help — instead of "here is the code, good luck," you have a document that explains the system to anyone who reads it.
This map serves a second function: it makes the build modifiable. When you want to add a feature, you check the map first. You can see where the new feature would connect, what it would depend on, and what it might affect. That is the information you need before you prompt. Without the map, you are making architectural decisions blind.
What Owned Means
The output of this process is a build you own. Not in the legal sense — in the operational sense. You can explain what it does. You can identify where something went wrong when it breaks. You can describe to someone else what would need to change to add a new capability. You can make deliberate decisions about the build's future rather than reactive ones.
This is the standard the build should meet before you show it to users, before you hand it to a developer, and before you use it as the foundation for the next phase of building. A prototype you cannot explain is not a foundation. It is a liability.
The Vibe-Coding Autopsy walks through six structural failure categories including the black box pattern, with diagnostic questions and corrective steps for each. Run it on your current build before your next session.