Governance is not something I learned from a book. It is something I could not afford to get wrong.

Twenty years of working in startups does something to the way you think about shipping software. Not because startups are glamorous or fast or any of the things people say. But because in a small team, there is nobody to hand the responsibility to.

The job — the real job — starts when a founder brings you an idea. Your first task is not to build it. It is to remove the ambiguity. What does this actually mean? What problem does it solve? What does done look like?

In agentic terms, that is the prompt. And everything people are now learning about prompt quality — be specific, define the boundary, make the outcome measurable — is not new thinking. It is what experienced engineers have always had to do before writing a line of code. The difference is that a human engineer will ask clarifying questions when the brief is loose. An agent will not. It will just start, confidently, in the wrong direction.

The stakes around that first step have not changed. Everything downstream still inherits whatever confusion you leave in the brief. The executor just moves faster now.

Once the brief was clear, the work began. And it was all yours.

You designed it. Not because you were a designer, but because nobody else was going to figure out how the pieces fit together. You built it iteratively, checking back against the brief as you went, because discovering at the end that you built the wrong thing is a much more expensive problem than discovering it halfway through. You tested it — unit tests, integration tests, whatever the scope demanded — because gut feel is not a test suite and it does not run on a CI pipeline. You ran it through UAT, which in a small startup often meant sitting with the founder or a handful of real users and watching what happened when real hands touched it for the first time.

Then you deployed it. Carefully, because a bad deployment at 6pm on a Friday is a different kind of problem than a bad deployment at 10am on a Tuesday. Then you watched it in production. Then you kept watching, because production has a way of surfacing things that staging never did.

And then — this is the part that does not show up in job descriptions — you maintained it. You kept it running. You answered the questions it raised six months later when the data grew and the edge cases appeared and the thing that seemed fine at launch started to show its limits. You thought about scalability not as an abstract architectural concern but as a very concrete question: when this gets ten times bigger, does it still work, and will I still be the one responsible for it when it does not?

There was no SRE on call. No incident response team. No escalation path. If it broke on a Saturday night, you fixed it on a Saturday night. That was the deal.

That reality changes how you work. You stop thinking of governance as overhead. You start thinking of it as the thing that lets you sleep. Small slices because a large change is harder to diagnose when it breaks. Explicit verification because gut feel does not hold up at midnight. Clear stop conditions because open-ended changes drift, and drift at 11pm on a Sunday is a bad time to discover it. Good deployment discipline because you are the one who has to roll it back.

None of that came from a process document. It came from being the last line of defence, repeatedly, for two decades.

So when agentic development arrived and people started asking about governance — whether it was necessary, whether it slowed things down, whether it was just more process for its own sake — I already knew the answer. Governance is not bureaucracy. It is the discipline that experienced engineers develop because the alternative is carrying a system that can surprise you badly, at any hour, with no backup.

Agents did not make me think governance matters. They just made it more urgent to make it explicit.