AI wrote your code. Who owns it?
Infinia ยท
A two-person team can now ship like ten.
Features that used to take a sprint take an afternoon. The demo works. Customers are happy. For a founder at $2M ARR, it feels like the engineering problem finally solved itself.
Then someone asks a simple question: "How does this actually work?"
And nobody can answer.
AI gave small teams speed. It didn't give anyone the job of knowing what's in the codebase. That job used to come free with writing the code. It doesn't anymore.
What changed
When code was slow to write, the person writing it understood it. They had to. They typed every line, debugged every edge case, and carried a map of the system in their head because they had built it piece by piece.
That map was never written down, but it existed. If you needed to know how billing talked to the database, you asked the person who wrote it.
Now code arrives faster than anyone reads it. An engineer describes a feature, reviews what comes back, runs the tests and ships. It works. But, the review is a skim, not a build.
Do that for a year and you have a codebase that works and that nobody fully understands, including the people who shipped it.
That isn't a criticism of your engineers. It's what happens when output grows faster than attention.
The three moments you find out
Most founders don't notice the gap until one of three things happens.
1. The first security questionnaire. A prospect sends 40 questions about data handling, access controls and encryption. Where does customer data live? Who can reach production? What happens to backups? Your team gives a confident answer to half of them and guesses at the rest. The prospect's security team can tell.
2. The first enterprise deal. The contract is close. Then their engineers ask for an architecture review. They want a diagram, a description of how your services fit together, and an explanation of how you handle failure. You have a repo and good intentions. The deal slips a quarter while someone reverse-engineers your own product.
3. The first engineer who leaves. They were the one who understood how the pieces fit. Not because anyone planned it that way, but because they happened to be in the room for most of it. Now they're gone, and so is the map.
Each of these is survivable on its own. But they tend to show up together, right as the company is growing into the customers who ask harder questions.
Why AI makes the part-time CTO more necessary, not less
Here's the part founders don't want to hear.
The common assumption is that AI coding tools reduce the need for senior technical leadership. If the tools write the code, why pay for a CTO?
At $2M ARR, it works the other way.
You don't need a CTO to write more code. You have plenty. You need one to own it.
The bottleneck moved. It used to be producing code. Now it's understanding, governing and explaining the code you already have. That's a senior job, and AI made it bigger, because there's more code, written faster, with less of it understood by the people who shipped it.
What "owning it" actually means
Ownership is specific. It isn't a title or a weekly check-in. At this stage it usually means three things.
A one-page architecture. Someone can explain how your system works on a single page: the main services, where data lives, what talks to what, and what breaks if one piece goes down. If that page doesn't exist, the knowledge doesn't either.
Answers to the security questionnaire. Not guesses. Someone knows who has production access, how secrets are stored, and what your backup and recovery story is, and can say so in writing before a prospect asks.
A list of the shortcuts. Every fast-moving team takes shortcuts. That's fine. What's dangerous is not knowing which ones you took. An owner keeps track of them and knows which ones will cost you a deal next year and which ones never will.
None of that requires a full-time executive. For most companies at $1M to $5M ARR, it's a few days a month, not a $250K salary.
When you don't need one
To be fair to the other side of the argument: not every team needs this yet.
If you're pre-revenue with one engineer, you need a builder, not an owner. The architecture is small enough to fit in one head, and that head is probably yours.
If you already have a strong technical co-founder who reads every pull request, you may have an owner already. The question is whether they still have time to do it, now that the team ships three times as much.
The gap opens when the company has real customers, real data and more code than any one person has read.
A test you can run this week
Ask your team three questions:
- Can someone draw our architecture on one page without opening the code?
- Could we answer a 40-question security questionnaire in a day without guessing?
- If our most senior engineer left on Friday, who would know how the pieces fit on Monday?
If the answer to any of them is "not really," the problem isn't speed. You have plenty of that.
Speed was never the problem. Ownership was.
*Infinia introduces founders to fractional CFOs and CTOs who own a number, not a calendar. One introduction, free.