Staying in control of software you can't read
Control does not come from reading code. It comes from being able to check specific things, and every one of them is available to you.
If you cannot read the code, the usual advice is to trust your developer or your tool. That is not control, it is hope with extra steps. And the alternative is not learning to program.
Control comes from being able to verify properties of the system rather than its contents. You can check every one of the things below without reading a line.
The five things you must own
Not documents to file away. Things whose absence is a genuine emergency.
The repository, in your account
The code lives in an organisation you own, on a service you pay for, with you as owner. Not on a contractor's personal account, not only on a laptop. This is the single most common and most damaging gap.
The ability to deploy without one specific person
Written instructions for putting a new version live. If only one human can ship, you do not have a product. You have a dependency with a notice period.
The accounts, in your name
Domain, hosting, database, email provider, payment processor. Every one registered to a company address you control, with billing you can see.
A description of the architecture
What the parts are, and what talks to what. One page or one diagram. Not API documentation: the shape of the system.
A record of what stores personal data
Which parts hold customer information and where it goes. You are legally accountable for this regardless of who built it.
Questions that work without technical knowledge
Each of these has a good answer and a bad one, and you can tell the difference without understanding the details.
| Ask | Good answer sounds like | Worry if |
|---|---|---|
| "Can you show me the system on one page?" | They draw it in two minutes, confidently | It takes days, or it comes back as a wall of text |
| "If you disappeared, what would break first?" | A specific, honest answer | "Nothing, it's all documented", which no system ever is |
| "What happens if this change is wrong?" | "We revert it, here is how" | Uncertainty, or a long pause |
| "Where does customer data live?" | A short, exact list | A general answer about the database |
| "What are you worried about?" | Something real and specific | "Nothing", which is the biggest red flag on the list |
The last one carries the most information. Every competent engineer has a list of things that worry them. Someone who claims none is either not looking or not telling you.
Checks you can run yourself
Genuinely doable without technical skill, and they find real problems.
- Make two accounts and try to see the other's data. Sign up twice, log in as the first, and attempt to reach the second's information by changing what you see in the address bar. This finds real permission bugs and needs no expertise.
- Ask for a change to be reverted. Pick something small and recent and ask for it to be undone. If that is hard, the ability to recover from a bad change does not exist.
- Check the last time the map was updated. If the architecture description has not changed while the product has, it is now fiction.
- Ask what a new developer would need on day one. A team that can answer crisply has a system someone else can take over. One that cannot has a system that depends on the people currently in it.
The warning signs that matter
Not "the code is messy": you cannot judge that, and it matters less than people think. These are the ones that predict trouble:
- 01Estimates growing for similar work. A change like one that took two days last quarter now takes two weeks. This is the clearest measurable signal that the system has become hard to reason about.
- 02"We should rewrite it." Sometimes true, usually a symptom that nobody understands the current system well enough to change it safely.
- 03Nobody wants to touch a particular part. There is a file or an area people route around. That is where the next incident will come from.
- 04Changes break unrelated things. The strongest signal of all. It means the parts are connected in ways nobody has mapped.
Why this is harder now, and also easier
Harder, because AI-generated code arrives faster than anyone can review it, and it looks tidy while being structurally confused. The old proxy (does the code look well kept?) has stopped working. See technical debt from AI coding.
Easier, because the same shift makes structure checkable by machine. Questions that used to require a senior engineer's afternoon (what are the parts, what calls what, is anything duplicated, does the code still match the design) can now be answered automatically.
That is what Graphlit is for, from your side of the table: the drawing is something you can read, and it is mechanically checked against code you cannot. When they stop agreeing, you get told, which means "is the system still what we agreed?" becomes a question with an answer rather than a matter of trust.
Five nodes claim a file in this repo.
Press Check sync to hash every one of them against the code that is actually on disk right now.
None of this replaces trusting the people you work with. It means you are not relying on trust alone for things that can be verified.
Common questions
How can a non-technical founder manage developers effectively?
Verify properties rather than judging code. Own the repository and accounts, insist on a one-page architecture description, ask what would break if a specific person left, and watch whether estimates for similar work are growing. All of that is available without technical skill.
What should I ask for at the end of a development contract?
Owner access to the repository and all infrastructure accounts, written deployment instructions someone else can follow, an architecture description, and a list of what stores personal data. Agree these at the start. They are much harder to obtain at the end.
How do I know if my developer is doing a good job?
The most reliable proxy is whether similar work is getting slower over time, and whether a change can be reverted quickly when it turns out to be wrong. Both are measurable without reading code, and both track the health of the system more accurately than code appearance.
Is it risky to build a company on AI-generated code?
It is risky to build on code nobody understands, whoever or whatever wrote it. Generated code makes that easier to end up with by accident, because it arrives faster than review does. The mitigations are ordinary: own the repository, keep an architecture description, and get security-sensitive parts read by a human.
Draw it. Then keep it true.
Graphlit turns an architecture drawing into a typed graph, builds against it, and proves the code still matches. Free to start.