# Deterministic guardrails must evolve to control probabilistic AI systems | LinearB Blog

> LaunchDarkly CTO Cameron Etezadi explains why traditional engineering pipelines are breaking down in a probabilistic, AI-driven world. Discover how to safely manage non-deterministic systems using feature flags, the automated dark factory delivery model, and runtime agent control frameworks.

[Blog](https://linearb.io/blog)

/

Deterministic guardrails must evolve to control probabilistic AI systems

# Deterministic guardrails must evolve to control probabilistic AI systems

![Photo of Andrew Zigler](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Headshot3_d7231cbda7?_a=BAVMn6ID0)

By [Andrew Zigler](https://linearb.io/blog/launchdarkly-cameron-etezadi-deterministic-guardrails-probabilistic-ai-darkfactory#andrew-zigler)

|

July 17, 2026

![Blog_Post_Name_2400x1256_5_f5375661ec](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Post_Name_2400x1256_5_f5375661ec?_a=BAVMn6ID0)

For 30 years, [Cameron Etezadi](https://linearb.io/dev-interrupted/podcast/launchdarkly-cameron-etezadi-dark-factory-agent-runtime-frameworks) has built and shipped software as a professional engineer, a run that stretches back to Amazon in an era when the entire company counted just 1,200 engineers. Today he serves as CTO at LaunchDarkly, the company that defined the feature flag category more than a decade ago and now serves 60 trillion flag evaluations a day at worldwide latencies under 200 milliseconds.

That vantage point makes Etezadi a rare kind of authority on the current moment. He is neither a hype merchant nor a skeptic. He is an operator watching the infrastructure of software delivery strain under a load it was never designed to carry, and he has a clear diagnosis of why. The industry, he argues, is misreading its own crisis.

## **Deterministic pipelines are breaking down in a probabilistic world**

The common complaint in engineering leadership circles is that developers have gotten lazy, or that they are bad at prompting AI. But that framing misses the mark. The real failure sits in the [delivery infrastructure itself](https://linearb.io/blog/how-agentic-ai-will-disrupt-your-software-delivery-lifecycle): the processes, guardrails, and pipelines built for a deterministic world that are now buckling under probabilistic outputs.

The psychological contract engineers signed up for has quietly ruptured. "We love determinism. It's why I got into this business," Etezadi says. "There's something about my psyche, and I think a lot of people in this business, we're like, tell the computer, 'You do this,' and it does exactly that, barring a hardware failure. That doesn't exist anymore." Ask the same model the same question twice, and you get two different answers, which for a career engineer is enough to induce a little heartburn.

The consequences reach deep into production. As teams build systems that call agents or inference in the runtime path, the outputs can drift even when the code has not changed, because a model upgrade carries its own faint randomness. Things that tested perfectly in the lab used to work perfectly in production (scale and unknown unknowns notwithstanding), but they do not anymore. This upends everything the industry has been taught, learned, and believed about building software and being good engineers.

This is why the collapse between vibe coding and agentic engineering, a convergence [Simon Willison](https://simonwillison.net/) has written about, compounds the pressure rather than relieving it. More code, generated faster, with less human review, lands on shakier infrastructure. Rebuilding for that reality means treating uncertainty as a first-class engineering constraint. People are looking for solutions that bring them back to a deterministic outcome in a probabilistic world, and that ultimately comes from guardrails and from controlling agents.

## **The dark factory makes end-to-end automated delivery a reality today**

The clearest picture of this rebuilt pipeline is the dark factory, a [fully instrumented delivery line](https://linearb.io/resources/engineering-leader-guide-to-predictable-project-delivery) that runs without manual ceremony at any station. Imagine an agentic coding tool that writes the code and checks it in as part of a PR. The change is automatically wrapped in a feature flag, automatically instrumented for an experiment to confirm it does what it was meant to do, and observed in production. When it proves out over time, a second PR arrives to remove the flag so the environment stays clean. We are incredibly close to making this complete loop a widespread reality.

The manufacturing analogy is deliberate. Look back to Henry Ford abandoning the practice of building a car one piece at a time in favor of the steering-wheel expert, the tire expert, and the welder, each occupying a discrete station on the line. While that assembly line looks different for every manufacturer, the fundamentals of mass production are universal. The dark factory separates authorship, validation, release control, and observability into stations that compose the same way regardless of whether a team runs GitHub or GitLab, CircleCI or Argo CD.

The economic case is where the vision turns concrete. LaunchDarkly's oldest, gnarliest part of its codebase was a project that traditionally would have been estimated as a year of work for eight engineers, though that was likely a polite fiction closer to two years. Instead, two engineers rewrote it in a single quarter using Claude. Not only did that run at a fraction of the cost, but it also captured nearly two additional years of ROI in the marketplace that would otherwise never have existed. Factoring in that earlier revenue, the real productivity multiplier sits closer to 20x.

Token cost economics anchor the whole calculation. Spending roughly the equivalent of the two engineers' salaries in tokens is a rational trade against millions in Silicon Valley payroll over two years. The deeper shift is philosophical. Where engineering once behaved like a discipline of theoreticians who had to get it right before shipping, it now behaves like one of experimentalists who push to production, observe, and iterate, provided the pipeline is instrumented to measure spend against outcomes.

## **Decoupling deploy from release is even more critical at AI velocity**

[Feature flags](https://linearb.io/dev-interrupted/podcast/reimagining-dora-metrics-leveraging-feature-flags) always existed to split the technical act of deploying code from the business decision to release it. At the volume agentic tools now produce, that separation stops being a preference and becomes a requirement. At LaunchDarkly, 61 percent of all check-ins are now written by AI, and every person in the organization uses the tools weekly. There is no safe way to ship at that rate without a controlled release layer sitting between code and customer.

Part of the reason a battle-tested platform matters is physics. An agent can happily wire up a config-file-based flag, and for a hobby project that is fine. But a config redeploy cannot propagate globally in the window a worldwide consumer brand needs when something goes wrong. It is physically impossible to safely roll something out globally in 200 milliseconds using hand-rolled configurations. The gap between a basic home-grown setup and a CDN-backed system widens sharply when the cost of delay is damage compounding across a global user base.

Guarded releases close that gap. By embedding rollback criteria directly into the release mechanism, a flag reverts automatically when observed behavior diverges from expected behavior, providing the practical bridge between probabilistic AI output and the deterministic SLAs production must honor. As vibe coding and agentic engineering keep converging and the distance between idea and shipped artifact collapses, this decoupling layer becomes the primary safety membrane in the stack. Organizations that treat it as optional are quietly accepting that every agent action is a direct production event.

## **Runtime agent control is the missing layer in agentic development loops**

The unsolved problem in agentic development is not the [agent framework](https://linearb.io/resources/apex-framework). There are a lot of really good ones out there with excellent open-source options available. What no framework supplies is the runtime control plane that lets operators inspect, steer, and constrain agent behavior while the system is live.

The answer is an agent control framework that extends the same flag-and-experiment infrastructure to govern agents at runtime. Operators can change which model backs an agent path, swap the prompts behind it, and goal-seek toward better outcomes, all from the dashboards and the MCP server interface already used to manage feature flags. This MCP layer acts as the core UX, creating runtime control for an entire agent fleet built on the same principles that govern feature releases.

Token budget protection is the immediate, visceral use case. No company wants a chatbot agent on its website that a user can prompt to reverse a linked list in Python, burning through the token budget the way several well-known brands did recently. The behavior is not always malicious, but the bill lands the same either way, and a runtime control layer can detect and terminate it faster than any human could react. As the loop between human intent and running code compresses, that window shrinks toward milliseconds, which is precisely why the control layer has to be always-on and automated.

## **The bottleneck has shifted from writing code to releasing it safely**

To explain what the industry is living through, look to Eli Goldratt's _The Goal_ and its theory of constraints, along with Gene Kim's reworking of those ideas for IT in _The Phoenix Project_. Remove one constraint and you do not eliminate it; you relocate it. The bottleneck used to be writing code, as that was traditionally the slowest part of the cycle. It simply is not anymore.

The evidence sits in the queues. The PR volume is more than humans can get through, and the ratio of tokens spent on testing versus actually generating features is borderline obscene, looking like a cartoon vault of wealth for frontier model companies. That imbalance only widens as coding agents get cheaper and faster. The constraint has moved downstream into review, testing, release, and observability: the surfaces originally designed for a world where a human wrote every line.

The shift rewrites the career ladder too. The role that simply turned spec into execution, the classic "code monkey" archetype, no longer holds the leverage. Teams are now hiring frontline managers at every level, except they are managing agents instead of people. Early-career engineers now have to think like product managers, designers, and engineers all at once, which demands strategic muscle traditional curricula rarely built.

For leaders, the theory-of-constraints lens doubles as a diagnostic. If an organization has adopted AI coding tools but seen no throughput gain, the [bottleneck has already slid downstream](https://linearb.io/platform/programmable-workflows/features) into testing pipelines, release processes, or observability gaps. Piling more AI onto authorship will not help; it will only starve the real constraint further.

Taken together, this reality reframes the AI transition not as a productivity story but as an infrastructure one. The tools that generate code have raced ahead, and the systems meant to validate, release, and observe that code have to be rebuilt to treat non-determinism as the expected state rather than a rare edge case. The organizations that thrive will be the ones that stop asking their engineers to be better and start asking their pipelines to be probabilistic by design, with guardrails, runtime control, and a release layer strong enough to turn uncertain outputs back into dependable outcomes.

To hear more of Cameron Etezadi's insights on the dark factory, decoupling deploy from release, and runtime agent control, listen to the full episode on the Dev Interrupted podcast.

## Improve developer productivity with LinearB

Find us on

[](https://www.linkedin.com/company/linearb)
[](https://devinterrupted.substack.com/)

![Headshot3_d7231cbda7](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Headshot3_d7231cbda7?_a=BAVMn6ID0)

## Andrew Zigler

Andrew Zigler is a GTM Engineer at LinearB and the host of Dev Interrupted, a twice-weekly podcast and newsletter where 40k+ builders decode the transition to AI-native development and agentic orchestration. A classicist by training with a degree from The University of Texas at Austin, Andrew spent his early career teaching in Japan before channeling his interdisciplinary instincts into the tech world. His polymath background informs everything he builds, from automated workflows to the stories he tells about the seismic shifts reshaping software creation.

### Connect with

[](https://www.linkedin.com/in/andrewzigler)
[](https://substack.com/@zigler)
[](https://x.com/andrewzigler)

## Your next read

[![Cover image for Slack turns channels into the context engine for agentic AI](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Post_Name_2400x1256_077524ba8b?_a=BAVMn6ID0)](https://linearb.io/blog/slack-jaime-delanghe-mcp-agent-context-channels)

AI

[Slack turns channels into the context engine for agentic AI](https://linearb.io/blog/slack-jaime-delanghe-mcp-agent-context-channels)

Slack Chief Product Officer Jaime DeLanghe breaks down how channels serve as the foundational context layer for human-agent collaboration. Learn why Slack is...

[![Cover image for How leading teams turn AI into an engineering productivity edge](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Post_Name_2400x1256_be95b2d258?_a=BAVMn6ID0)](https://linearb.io/blog/ai-productivity-edge)

AI

[How leading teams turn AI into an engineering productivity edge](https://linearb.io/blog/ai-productivity-edge)

Developers using AI heavily are merging PRs up to 2.2x faster than a year ago. See the mid-year benchmark data on the widening productivity gap, and how to...

[![Cover image for AI ROI comes from measuring engineering outcomes on day one](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_ROI_comes_from_measuring_engineering_software_security_2400x1256_2c5eae0862?_a=BAVMn6ID0)](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

AI

[AI ROI comes from measuring engineering outcomes on day one](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

Kraken Engineering Operations Lead Nik Sudan details how to establish day-one data infrastructure to accurately measure AI ROI. Discover why raw token adoption...