From Directing Teams to Directing Models
The same governing role, applied to a model instead of a team.
The constraint
With current AI tools, capability is no longer the constraint. Any founder can access a model that writes, designs, and builds at a level that was expert-only two years ago. What that access does not decide is whether the output is correct, coherent, and usable, and that is now the harder problem. The constraint has moved from producing the work to governing what gets produced.
Governance is the work because of the specific way these models fail. A model will lock onto one line of reasoning and follow it past the point where it still serves the goal. When the source material is thin, it fills the gaps by inventing, and presents what it invented in the same confident register as everything it got right. The failure does not announce itself: the output looks finished whether or not it is. The cost of missing it is compounding: work gets built on a false direction, whole sections resting on something that was never true, and once it enters the source material the model carries it forward as fact. On real projects, under deadline, I have caught inventions that would otherwise have shipped.
Governing the work
Governing the work is a set of controls. The problem is defined precisely before anything is built, because a model given a vague target still commits to a direction. From there the model works only inside the confirmed system: the rules, the settled decisions, and the source material it is allowed to draw from. Its output is checked against a fixed standard before it is accepted. As the project changes, superseded decisions are removed from that source material, so a discarded direction cannot resurface later as though it still held. The discipline is heaviest at the start, when the least is established. Three things stay mine and never pass to the model: the definition of the problem, the standard for the work, and the relationship with the client, which is not automated at any point.
On a cybersecurity firm’s site, the model produced the wireframes section by section, and I reviewed each as it came. When I found an error, I traced why it happened and wrote a rule that let the model catch that class of error itself. The rules accumulated as the project ran, and the output grew more reliable as they did. This is why the discipline is heaviest early: each error caught at the start becomes a rule, so the same mistake does not return later.
On a wealthtech brand identity project, the model produced visual assets, and the same failure appeared. After a change of direction, colours and materials that had been dropped kept returning in new output, and they were harder to clear than the errors on the wireframes. Fabrication is the standing risk: the model presenting invented data as established. I handled both the same way: caught each, traced why it happened, and set rules that stopped it recurring. On an illustrated book, the model’s task was keeping a story consistent across each section of the book, and the same loop governed it. Three surfaces with nothing in common, wireframes, visual assets, a narrative, and on each the failure was caught, traced, and turned into a rule the model applied to its own subsequent output.
The same role, from teams to models
Two capabilities carry this work, and both predate AI. The first is building and governing structure: brand systems from 2012, then design systems and a design department built from zero in lead roles, then my own studio. The second is designing AI-powered products: by 2019 I was building them across government, security, wealthtech, recruiting, and conversational AI, years before AI was the tool I built them with. Working primarily with AI as the production method began in 2025, years after both capabilities were in place.
I have never written a line of code. Before AI, I shipped software by governing the developers who built it. That is the role I hold now, with a model in place of the team, directed the same way and to the same standard. What it produces across surfaces is what a team produced before. Although I cannot do this work by hand, it still ships, because the value was never the execution but the governance. This now includes vibe coding, producing the software itself through the model, governed the same way as everything before it.