Fast to Build Is Not Cheap to Own.
By Martin Bergmann | AI Project Lab | October 2026
Jeremy Utley recently described a habit of Jim VandeHei, the CEO of Axios. Whenever he hears that someone at the company built something that solves a problem, he emails that person the same day and asks for a call. They walk him through it, and according to Utley, several of those builds have since become products. Everyone else learns that building something is the fastest way to the CEO’s calendar.
I love that. In a larger portfolio, though, that same week usually goes to intake forms and prioritization committees, and most of the time for good reason. I asked a version of that question in a comment on Utley’s post: how much of that speed survives contact with change control before it becomes recklessness instead of agility?
Gates were priced for expensive builds.
My reading is that approval gates exist because building used to be expensive. When a project costs a team months, an hour of committee time is cheap insurance. AI changes the price of the thing being gated. Work that once took a team weeks can sometimes take an afternoon, and the committee can become the slowest step in the chain.
Building is not the only cost, though. Simon Green argues that AI made producing things nearly free but did not make owning them free, and the data point in the same direction. A 2025 Faros AI study of more than 10,000 developers found that teams using AI heavily merged 98 percent more pull requests, but their review time rose by 91 percent, and their bug counts rose by 9 percent. Building got faster. The queue after it did not.
Move the gate to ownership.
This is my opinion, not a research finding: do not remove the gate. Move it. The question that guarded the start, “should we build this?”, matters less when building is cheap. The question that matters now sits later. Before this runs for real, with real data, real users, or real obligations, who owns it, what will it cost to maintain, and what would make us stop?
Speed is not the only thing that matters in a real environment. Maintainability, scalability, and security matter too, and so does the question a quick build hides: what will this cost to keep running? That is total cost of ownership, the cost of running, supporting, securing, and eventually retiring something, not just of making it. Fast to build is not cheap to own. Speed gets something started, and total cost of ownership decides whether it was worth having.
That keeps the speed Utley describes and puts the control where the new cost lands. It also leaves the hard controls where they are. Security review, data protection, and regulatory requirements still apply to anything that touches real data or regulated work, however cheap it was to build. This is a case for lighter gates at the start, not weaker controls at the end.
It is the same question as the one about the stop rule in my last post. A business case should say what would make you stop, and an ownership gate asks it at the moment something becomes real.
Where AI actually helps.
Use AI to make the new gate cheap to pass, honestly. When someone builds something, have it draft a one-page ownership record from the build itself: what it does, what data it touches, what it depends on, who uses it, and what would retire it. A person confirms the draft and puts their name in the owner field. The AI cannot supply an owner. Ask for a first estimate of what it will take to maintain, secure, and scale, and treat the answer as a question for the owner, not a number to trust.
Then point the same AI at what already exists, and ask it to list the tools, reports, and automations your team has built that nobody owns. That list is your starting backlog, and it is the same kind of inventory the subtraction post recommended.
A gate should guard whatever is expensive. AI moved the expense from building to owning.
Martin Bergmann is the Director of an IT PMO and founder of the AI Project Lab. He writes about AI, project management, and the future of intelligent work.
Comments