Velocity Through Rigour: Then & Now • Cate Huston • Bug Bash EU 2026
Cate Huston, CTO at Twill and author of The Engineering Leader, shares how she rebuilt a no-code product into a production platform with a two-person team and agents, and argues that the management playbook for scaling people still applies to scaling AI agents. She covers the shift from f(n) to f(n × a) team scaling, the four management layers, guardrails and the roughly 30 percent of output she believes they require, shift-left practices, CI as a cost and quality lever, and why rigour is what turns speed into lasting velocity.
Rigour as the engine of velocity
Cate Huston argues that the playbook that made large engineering teams effective has not disappeared in the age of AI agents. It has been compressed and reconfigured. Her central question is what share of output should go to guardrails, and after a year of rebuilding a product with a very small team her working answer is roughly 30 percent.
From managing people to managing robots
Her experience leading organizations of up to 80 people at Automattic and DuckDuckGo shapes how she approaches agents. She defines a good manager as a force multiplier who finds bottlenecks, removes them, helps individuals grow, and keeps the team’s needs in view. Managers encode judgment through process, which is how judgment scales into execution, and through relationships, which is how it moves between people.
Agents behave like a narrow-range version of a human. They are more consistent and less creative, they rarely ask why enough, and they seldom admit they don’t know something. Huston compares them to junior developers, while acknowledging the comparison is imperfect. The real difficulty is that managers now manage humans who manage robots. Many of those humans have no management experience, and they are working under threat, trying to prove that the skills they invested in still have value.
Rebuilding a platform in a single year
Huston moved from advisor to fractional CTO at Trello, where the product ran on a no-code platform that had reached its limits as the data model began to hold the business back. Her first job was rationalization: ending two-way writes between the tables and the no-code tool so the business could keep functioning while a proper database was introduced. She notes that re-platforming was necessary from day one, but it took months to create the conditions where it was possible.
The arc ran from April and May of setup, to June finding its rhythm, to July reaching feature completeness with careful data migration, to a reactive August launch, and then a return to roadmap-driven feature work in September. The data migration she compares to moving a to-read pile into a library system: painful and a one-way door. The output came from two engineers, with an intern for six weeks in the summer.
The velocity playbook, reassembled
Velocity came from a rapidly assembled set of practices. She added a release branch and a formal release process, which she admits goes against conventional wisdom but argues is better than letting problems arrive at inconvenient times. She put an orchestrator in a merge queue to act as a strict validation and sequencing step, which also saved CI minutes that had been wasted while working chaotically across five terminals. She aligned board hygiene with P0 through P3 priorities and tagged features for the next release.
She also invested in developer experience: ephemeral database targets, authenticated end-to-end tests, explicit environment variable requirements, a full design system, and automated nightly backups. Her argument is that these are the things that should be in place before leaving an AI unattended, and that 20-plus person teams rarely reach this level of DevEx, which she considers necessary rather than over-engineered.
The missing multiplier
Huston reframes team scaling with a simple model. Traditional process overhead grows as f(n), where n is the number of people. With agents, it becomes f(n × a), where a is the number of agents per person. The missing multiplier is agent management effectiveness, and small teams already have most of what they need to exercise it, because most of that infrastructure is what larger teams used to build over years.
Four layers, changing at different speeds
Huston organizes management into four layers. Mission is the value the team delivers to the business and gives people a frame for their decisions. Strategy is how the team prioritizes toward that mission. Tactics and process turn strategy into deliverable work and make the state of work transparent and queryable. Execution is getting things done.
The industry assumed execution was the bottleneck, which is why CEOs became fixated on AI. Huston argues that problems usually originate higher up and only surface in execution. None of the layers disappeared; they changed speed. Mission remains stable, strategy needs to be thought about in weeks rather than quarters, process that once took months to learn is now written for agents that learn in a day and are enforced by machines, and execution has moved from this week to continuous overnight work. She calls this the dark factory model, and it works only when everything above execution is aligned.
Guardrails and the second roadmap
Her working definition of a guardrail is a way to prevent problems. Large companies built layers of tooling so people could operate with partial understanding. Smaller teams relied on tribal knowledge and hiring only seniors, which worked partly because distributed teams struggle to tell when someone is stuck. Incidents and bugs form a second roadmap that nobody writes down, except when explaining why the first roadmap was not delivered.
Process, in her view, should be designed for a persistent robot in the worst case rather than a good person on a bad day. Where postmortems once produced fixes every few weeks or months, the response is now to install a guard for that class of problem on the same day, because otherwise it will happen again tomorrow.
She points to industry data that sharpens the concern. Reported Meta figures show changes rising about 220 percent, user-facing impact rising only 36 percent, incidents rising 40 percent, and firefighting time rising 70 percent. A randomized trial found experienced developers were 19 percent slower in their own repositories while believing they were 20 percent faster. The DORA 2025 findings show throughput up and stability down. The question she sees engineering leaders needing to answer is how increased output becomes business value.
Her answer is to write things down, automate them better, and instrument everything, because anything missed is a signal to automate. Her guardrails evolved from written instructions, based on the theory that agents read documentation and humans do not, into automated checks, because agents do not always read the manual either. Her intuition of around 30 percent aligned with the team’s average, though they started below it. Tests were not enforced until coverage was instrumented with a check, which revealed debt that had to be cleaned up. Incidents were included in the count, and most were low severity.
Shift left and architecture
A design system built early with full visual snapshot coverage is, in her telling, now a strong lever for consistency and accessibility, which is increasingly a legal requirement in the EU. Such systems used to take more than a year, and she knew more attempts that failed than shipped. Generating queries from the schema eliminated a whole class of 500 errors, and migrating every handler onto generated queries was a large undertaking that she judged worthwhile after repeated failures.
Architecture matters earlier than before. Good architecture, she argues, makes sensible decisions easier. Adding role-based access control in month one was expensive and seemed premature, but it was vindicated by month four. Because high output means high churn, fundamentals are amortized across many changes, which makes them matter more. The right approach is to identify the load-bearing pieces and invest in them with more guardrails, tests, reliability, and resilience, instead of trying to perfect everything in a startup.
Release gates, UI review and CI as a cost center
Separating release from main gives a single gate for human review of what is going to production, rather than hoping the important PRs were looked at. UI changes are reviewed through Chromatic snapshots. Schema changes are much harder to roll back than code changes, so they demand more care. Feature flags arrived by month five, which she says she would never have adopted before.
Huston also came to see CI as something she needed to manage directly. Tokens generate CI minutes, so more rigor pushes cost up, and she tracks base costs (the cost of running the platform) separately from velocity costs (which should be justified by what was delivered). In September, CI spend overtook AI spend, though that comparison reflects a flat-rate plan rather than metered usage.
She cites a CircleCI report showing that CI quality predicts gains from AI. Top organizations run thousands of workflows a day, and their benchmarks include 10-minute workflow duration, one deploy a day, 60-minute time to recovery, and a 90 percent success rate on main. Gains concentrate in the top half of organizations while the bottom half sees no growth. The divide is driven by pipeline quality rather than company or team size, and team size no longer correlates with throughput. Her own cadence has moved from five releases a week with around 25 PRs each to three or four releases a week with 50-plus changes each.
Product, prioritization and the cost of doing everything
When execution gets cheap, doing everything becomes tempting, but doing everything is not a strategy. Huston sees two extremes in product work: engineering managers who think they no longer need product managers because AI can do the job, and product managers who believe everything can now be executed at once. Good product managers always prioritized by user value, and while AI may produce a reasonable prioritized list, that is not a high bar. Clarity about what is most valuable and in what order is what strategy is.
The ‘AI slop’ complaint, she suggests, often comes from non-technical people sending engineers specs that begin with what Claude said would be easy. Having an AI write a spec does not remove the responsibility to think it through. Many engineers used execution difficulty to defer ideas that were not well thought through, and the honest conversation about half-baked ideas needs to happen. Asking a human to read something you have not read yourself is disrespectful. Code review is one place where human reading still matters, while code is ultimately for the compiler and runtime, so machine checks belong there.
Huston also argues that AI adoption works best in homogeneous systems. Human adherence to process has always varied, and agents amplify that variance. Small teams are homogeneous because they talk constantly, large teams because a company mandates process, and medium-sized teams carry the heaviest heterogeneity. Offloading robot management to people without management experience widens the outcome range further. Her recommendation is to set defaults that apply to all agents rather than relying on lossy human structures.
Leading through the chaos
In her own setting, the CEO asks only for features, and the guardrails that make those features possible are Huston’s job. She said no to everything for four months, which drew public criticism, but the velocity win came from leaving the no-code platform, and scope creep is what kills v2s. The challenge for leaders is how to deliver velocity to people who only ask for features, and the answer is to show how each move advances a shared goal even when the manifestation differs. Her practical rule echoes advice she received early in her career: you can have everything, but not all at once, so decide what comes first.
Her deeper point is that none of us fully understands this moment yet, and progress is easier to measure than state. She likens the current picture to the parable of the blind men and the elephant. Each describes a real part, but none has the whole. She is explicit about her own vantage point, which is a small, chaotic, AI-native team. The failure mode of AI, in her framing, is cognitive surrender, and the remedy is rigour. Good managers always practiced it, and she is now applying it to a blend of humans and robots, where the blend is hard but well-understood tools exist to start from.