Engineering brief
Velocity Through Rigor: The 30% Guardrail Rule for AI Teams
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- Now
- Warnings
- None
Cate Huston argues that the management playbook for scaling human teams still works for AI agents—but the ratio of output to guardrails needs to be 70/30. Teams that skip the rigor will drown in incidents.
Managing AI agents requires the same managerial rigor that scaled human teams—just applied faster.
Watch if you want a concrete, experience-based argument for investing in process alongside AI tools.
Summary
The proposal. Cate Huston, a former engineering leader at Automattic and DuckDuckGo, argues that the management practices that scaled human teams apply directly to AI agents. She proposes allocating 30% of total output to guardrails—tests, CI, process, architecture—based on her experience building two production products with a single engineer and Claude. The ratio is not arbitrary: her team's data shows that without this investment, incident rates and firefighting time eat into the gains from AI velocity.
The evidence. Huston cites Meta's internal data showing a 220% increase in changes but only 36% more user-facing impact, with a 40% increase in incidents and 70% more firefighting time. Faros AI and DORA 2025 confirm the pattern: throughput up, stability down. Her own team ships five releases per week with about 25 PRs each, but CI costs eventually overtook AI spend.
The trade-off. The catch is that investing in guardrails requires saying no to features. Huston's CEO asked only for features; she said yes to nothing for four months to re-platform off a no-code stack. The velocity win came from the platform change, not from AI alone. Leaders face the tension between visible feature output and invisible process work that prevents incidents. The 30% rule is a heuristic that forces the conversation.
What's missing. Huston's experience is from a two-person team using Claude on a single platform. Scaling to 20 engineers with multiple models and codebases introduces heterogeneity that the 30% rule may not cover. She acknowledges that medium-sized teams suffer most from variance. The video doesn't provide a framework for breaking down guardrail allocation across teams or measuring whether 30% is the right number for different contexts.
The managerial implication. Huston recasts the manager's job from scaling humans to scaling rigor in machines. The same layers—mission, strategy, tactics, process, execution—still apply, but each moves faster. She argues that process is how judgment scales into execution, and that agents multiply the variance of human habits. Engineering leaders must now budget for guardrails as first-class deliverables, not overhead.
The bottom line. The video's core actionable insight is that teams should measure guardrail investment as a proportion of output and target ~30%. The deeper lesson is that the management playbook is not obsolete: it's reconfigured for a world where execution is cheap but reliability is expensive. Huston's talk is a credible, experience-grounded argument for treating process as a product alongside features.
My take
I buy the 30% guardrail rule as a useful heuristic, but I'm skeptical it's universal. The real insight is that the management playbook hasn't changed, we're just applying it to machines instead of humans. Most teams will underinvest in guardrails because they're seduced by raw output. The hard part isn't the rule, it's the discipline to enforce it when your CEO is asking for features. I'd also note that her experience is with a two-person team and Claude; scaling this to a 20-person team with multiple models will introduce new variance. Still, the principle holds: fix the bug class, not the bug.
What to do with this
- Set a guardrail budget: track what percentage of output goes to tests, CI, and process.
- Instrument your CI pipeline to measure workflow duration, success rate, and deploy frequency.
- Map your incident classes and automate a guard for each class within the same sprint.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
Why AI Coding Demands Slowing Down
AI coding tools tempt teams to rush features, but Kent Beck warns: without building optionality, they lose the ability to change code at all.
Why a Positive A/B Test Is Not Enough for AI Features
Bumble's PM reveals why a positive A/B test for an AI feature is only the start: low adoption, bad long-tail outputs, hidden costs, and regulatory walls.
Why Your AI Agents Need a Manager, Not Just Permissions
AI agents need HR-style governance: identity, sponsor, and machine-speed oversight. The talk from Gravitee offers a framework but no proof.
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.