DEV Community: Bala Paranj

Meta Almost Solved Config Safety at Machine Speed

Bala Paranj — Sat, 27 Jun 2026 09:54:12 +0000

Episode 84 of the Meta Tech Podcast, describes how Meta keeps configuration changes from taking down services that serve more than three billion people. The architecture is the most battle-tested config-safety system in the industry. Fleet-wide config propagation in under five seconds, canary and progressive rollouts with health checks at service and ecosystem level, a meta-analysis layer that detects correlated failures across noisy signals. An incident culture built on "blame the systems, not the people."

Meta hasn't had a site-wide outage in a while. That's investment. The investment is visible in every layer of what they describe.

This article is about where their safety model stops and what would complete it. The gap is the same gap that appears across the industry. Meta is closer to closing it than almost anyone else, which makes the remaining distance more precise and more actionable.

Config propagates at machine speed. Safety checks run at behavioral speed.

Meta's config system is config-as-code in a monorepo: mostly Python that generates JSON files, distributed fleet-wide with a 1–2 minute SLA. Often the entire fleet in under five seconds, no restarts required. Anyone can write. Any service can read. Configs control features, experiments, prediction models, system behavior — shared across Facebook, Instagram, WhatsApp.

The power is also the danger. The team says: a misconfiguration can propagate across the entire fleet in seconds. There's no predictable deploy moment. A bad config reaches billions of users before a human could read the change description.

The safety mechanism: slow it down artificially. Canary deployments test on a test tier for 10–15 minutes, then a region for 10 minutes, then production. Progressive rollouts take longer — a couple of hours. Because some services need time to bake or only read configs at startup. Health checks operate at service level and top-line level (the whole ads ecosystem), with progressively larger blast radius.

This is entirely behavioral. The system deploys the config, watches what happens, and rolls back if something breaks. The safety question is always: "did this config cause observable damage?" Never: "does this config satisfy the rules we declared?"

Behavioral checks catch what manifests. Silent violations pass through.

The concrete incidents from the podcast illustrate both the strength and the boundary of behavioral monitoring:

A config that failed to load a model was caught by model-load health checks and reverted. That's behavioral monitoring working as designed. The config caused an observable failure (model didn't load), the health check fired, the rollout stopped.

A bad config caused crashes across everything that read it via shared libraries. Engineers initially assumed the failures were "just flakiness". Because health signals are noisy and retries often mask the problem. Meta built a meta-analysis layer that detects correlated failures across multiple independent time-series: "we think you're about to break the site, please stop." That prevented a major outage. Again, behavioral monitoring working. Notice how close it came. The signal was almost lost in the noise.

Now consider the class of config change the system structurally can't catch: a config that is wrong but quiet. A security config that widens permissions without causing any service to crash. A routing config that creates an unintended path between internal and external networks without any health check firing. A shared-library config that changes a default timeout in a way that degrades throughput under load conditions that haven't occurred yet. No canary catches it. No health check fires. No progressive rollout detects it. The config is wrong — provably, from the config itself. But it produces no behavioral signal until the conditions align, which may be days, weeks, or never (until an attacker finds it).

These are deducible problems. The answer is in the config, not in the production behavior. A declared invariant — "this security config must not widen permissions beyond scope X" or "this routing config must not create paths between internal and external networks" — would catch the violation at authoring time, before the config enters the propagation pipeline. Behavioral monitoring can't see it because there's nothing to observe until it's too late.

The startup-config problem proves the gap

The podcast identifies startup-read configs as "the riskiest and hardest to test." Progressive rollouts don't always restart the task that consumes the config, so the service continues running with the old config while the new one sits unread. The failure signal is missed, because the service hasn't consumed it yet. When it does restart — during the next deploy, or a crash, or a scaling event — the bad config takes effect and the regression appears suddenly, disconnected from the change that caused it.

This is the behavioral model's sharpest limitation stated by the team themselves. The safety mechanism depends on the config doing something observable during the rollout window. If it doesn't — because the service hasn't restarted, because the load conditions haven't occurred, because the failure mode is silent — the config passes every behavioral check and propagates to the fleet.

A declared invariant checked at authoring time doesn't depend on the service consuming the config. It doesn't depend on the canary exercising the right code path. It doesn't depend on the load conditions being present during the rollout window. It checks the config against the declared rule, deterministically, before the config enters the pipeline. The startup-config problem — the team's own hardest problem is a problem that behavioral monitoring cannot fully solve and that declarative verification handles by construction.

DERP's Prevention should include declaration

Meta's incident framework — Detection, Escalation, Remediation, Prevention is structurally sound and culturally healthy. "Blame the systems, not the people" is the right stance, especially as AI introduces more automation.

But look at how Prevention works in practice: after each incident, the team improves detection (better health checks, auto-tuned thresholds), improves escalation (faster routing to the right people), and improves remediation (fingerprinting to isolate the causal change faster). Each incident makes the reactive pipeline better.

What Prevention doesn't include is declaration: converting the incident's root cause into a rule the system checks before deployment. "This config must not exceed value X." "This shared-library config must not change defaults that affect startup behavior without a progressive rollout that includes forced restarts." "This security config must not widen permissions beyond the scope declared in the service's security contract."

Each of those is a specification. A human-authored invariant checked mechanically at authoring time. It would prevent the class of incident from recurring. Not by detecting it faster next time. By making it impossible to deploy.

The DERP framework's Prevention step currently asks: "how do we make the system more foolproof?" The answer it reaches for is better detection. The answer it should also reach for is declared invariants that prevent the class of change from entering the pipeline. Detection catches the next instance. Declaration prevents the entire class.

The ratchet that makes the system self-improving

The human catches it once, and the knowledge should become a machine-enforced rule so it's caught forever.

Every SEV review produces knowledge: this class of config change, applied to this class of service, under these conditions, causes this class of failure. That knowledge currently becomes better health checks, better fingerprinting, better detection tooling. It improves the speed of the next reaction.

The ratchet: that knowledge also becomes a declared invariant. A rule checked at config-authoring time, before the config enters the propagation pipeline. The class of change that caused the incident can no longer be authored. Not detected faster or caught earlier in the rollout. Prevented from existing.

Each SEV review permanently expands the set of things the machine prevents, permanently shrinking the set of things the behavioral pipeline has to catch. Over time, the behavioral pipeline handles fewer incidents — because more of them are blocked before they reach the pipeline.

Meta's behavioral monitoring gets better with each incident (better health checks, better signals). The invariant layer would get broader with each incident (more rules, more classes of change prevented). The first improves reaction time. The second reduces the number of things to react. Both are needed. Meta has the first.

Completing Meta's architecture

Meta has:

Config-as-code in a monorepo — configs are authored as code, versioned, and reviewable. The infrastructure for declared invariants already exists. It's the same repo, the same authoring pipeline, the same review process.
Fleet-wide propagation in seconds — the Transmission layer is fast and reliable.
Behavioral monitoring at scale — canary, progressive rollouts, health checks, meta-analysis for correlated failures. The reactive Control Unit is industry-leading.
Incident culture that improves systems — DERP, blame-free reviews, systematic learning from each failure.

The missing elements:

Declared invariants on configs — human-authored rules checked at authoring time, before the config enters the propagation pipeline. Not behavioral. Not "deploy and watch." Deterministic and proactive. "This config must satisfy these properties" — checked the same way a type checker checks code, before it compiles. In practice, this is static analysis for configs. Meta already has one of the best static analysis teams in the industry. Pysa catches security vulnerabilities in Python. Gleam catches privacy violations across the codebase. The tools and the discipline exist. They haven't been fully pointed at the config domain yet. The config monorepo, authored in Python/Starlark, is the kind of structured, analyzable artifact that static analysis was built for. The gap is the coverage.
The ratchet — every SEV review produces not just better detection but a new invariant. Each incident permanently prevents its class from recurring.
Cross-config verification — invariants that span configs, so a change to a shared-library config that is safe in isolation but creates a conflict with a service-level config is caught at authoring time, not after both have propagated. In a fleet at Meta's scale, many of the worst outages are combinatorial: Config A is safe. Config B is safe. A+B is a SEV-0. A behavioral pipeline that tests each config independently will pass both. A declarative layer that can link configs during verification. Checking cross-config invariants the same way a linker checks cross-module symbol resolution catches the combination before either config propagates. This is the compound-risk problem from security (two safe-looking IAM policies that combine into a privilege-escalation path) applied to configuration: two safe-looking configs that combine into an outage. Per-config health checks can't see it. Cross-config invariants can.

The behavioral pipeline stays exactly as it is. It's the safety net for the invariants that don't exist yet, for the conditions that haven't been specified, for the failure modes nobody has encountered. Vassilev's NIST proof guarantees the behavioral pipeline will always have work to do, because no finite set of invariants catches everything. But each invariant that does exist catches its class definitively, at authoring time, before propagation. The invariant layer grows. The behavioral pipeline's job shrinks. The system gets safer with every incident — not just faster at reacting, but broader at preventing.

Meta is one layer away. They already have config-as-code in a monorepo with a review pipeline, the infrastructure for that layer is already built. The invariants would live in the same repo, authored in the same workflow, checked in the same pipeline. The hardest part — the config infrastructure, the propagation system, the monitoring, the incident culture is done. What remains is the declaration layer that makes the system proactive rather than only reactive.

References: Meta Tech Podcast, Episode 84: Configuration Change Safety with Ishwari and Joe. See also: Meta, "Capacity Efficiency at Meta: How Unified AI Agents Optimize Performance at Hyperscale" (2026) — a companion architecture with the same gap at a different layer. The formal basis for why behavioral monitoring has a ceiling: Vassilev, NIST/IEEE Security and Privacy (June 9, 2026). If you work on Meta's config safety infrastructure and have already explored declared invariants on configs, that's the conversation worth having.

Meta Built the Best Investigation Pipeline in the Industry. Here's the Layer That Completes It.

Bala Paranj — Fri, 26 Jun 2026 04:23:21 +0000

Meta's Capacity Efficiency architecture is further along the completeness spectrum than any AI agent system published this year. The comparison matters because it shows exactly where the industry's best work still stops short.

The dominant agent architecture — "Agent = Model + Harness," as described in LangChain's widely-read harness articles and OpenAI's harness engineering blog — has a model (the tool), prompts and AGENTS.md files (a weak engine), CI/CD (the transmission), self-verification (no independent control), and no enforced boundaries (no casing). The Harness is Half the Architecture diagnosed the gaps: no independent oracle, no declared intent, no coordination protocols, no subtraction discipline.

Meta's Capacity Efficiency architecture advances past that baseline in three specific ways. The remaining gap is smaller and more precise — which makes it more actionable.

First: the tools/skills separation replaces the undifferentiated "harness." Where the LangChain architecture lumps everything that isn't the model into one subordinate category, Meta separates capability (standardized tool interfaces — query profiling data, fetch experiment results, search code) from judgment (skills that encode domain expertise about what to look for and how to interpret it). That's a genuine Engine/Tool separation. The skills aren't prompts. They're encoded reasoning patterns of senior engineers, composable and reusable across offense, defense, and new capabilities. The harness article's "everything serves the model" frame doesn't describe what Meta built. Meta built tools that serve the system and skills that encode human judgment independently of any specific model.

Second: offense/defense on one platform is architectural unification the harness articles never attempt. Finding optimizations and catching regressions are the same structure — gather context, apply domain expertise, produce a resolution — differing only in the skills. Most organizations, and the harness articles, build these as separate concerns. Meta saw the shared structure and built one platform. Each new capability (conversational assistants, capacity planning, guided investigations) composes existing tools with new skills, requiring few to no new data integrations. That's composability through a shared Transmission layer — standardized interfaces, not a shared filesystem.

Third: FBDetect is independent detection, not self-verification. The harness architecture's approach to correctness is the model reviewing its own output. Meta's FBDetect is a separate system — behavioral monitoring that catches regressions as small as 0.005% in noisy production environments, independent of the coding agent that produced the change. That's closer to the independent Control Unit the completeness model requires than anything in the harness articles. It has correlated failure modes of its own (behavioral monitoring can only catch what manifests), but it is genuinely independent of the generator — which the harness's self-verification is not.

Skills encode how to investigate. Nothing declares what must be true.

The skills in Meta's architecture encode procedural knowledge. The reasoning patterns senior engineers developed over years. "Consult the top GraphQL endpoints for endpoint latency regressions." "Look for recent schema changes if the affected function handles serialization." "Check recent configuration deployments that could have caused a step change in resource usage."

These are investigation recipes. They tell the agent how to look for problems that have already manifested. They're encoded expertise about diagnosis and they're good at it.

What's absent is declarative knowledge. Statements about what must be true, regardless of whether a violation has manifested yet. "Serialization functions in this service must not exceed N milliseconds per call." "No single code change may increase fleet power consumption by more than X% without explicit approval." "This function must remain memoized — any change that removes memoization violates the performance contract."

The difference is the same difference the entire industry keeps missing: procedural knowledge is reactive. It tells you how to investigate after something went wrong. Declarative knowledge is proactive. It tells you what must hold, and a machine can check it before anything goes wrong.

Meta's skills are the best procedural knowledge system published anywhere. The declarative layer — invariants that prevent regressions before deployment rather than catching them after — doesn't exist in the architecture.

FBDetect catches what manifests. Silent violations are invisible.

FBDetect is behavioral monitoring. It observes production time-series data and detects step changes in resource usage. It catches regressions that produce observable signals. At 0.005% sensitivity, it catches very small signals. That's real and impressive.

But the class of problems it structurally cannot see is the class that compounds silently:

Sub-threshold accumulation. A code change that degrades performance by 0.004% — just below FBDetect's threshold. Then another. Then another. Each one invisible individually. After fifty such changes, the fleet is 0.2% slower, consuming measurable additional power, and no single regression was detected because none crossed the threshold. A declared invariant — "this function's P99 latency must not exceed N microseconds" — would catch each change at deployment time, before it enters production, before it compounds.

Structural violations with no immediate behavioral signal. A code change removes memoization from a function that was memoized for performance reasons. The function still works. Tests pass. No regression signal fires immediately because the workload that exercises the hot path hasn't peaked yet. When it does — during the next traffic spike — the regression appears as a sudden step change that looks like a load-driven failure, not a code-driven one. A declared invariant — "this function must remain memoized" — would have caught it at PR time.

Configuration-driven performance risk. A configuration change modifies a timeout, a batch size, or a retry policy in a way that degrades throughput under specific conditions. The conditions haven't occurred yet. FBDetect sees nothing because nothing has manifested. A declared invariant on the configuration — "batch size for this pipeline must remain between X and Y" — would catch the violation before deployment.

These are deducible problems. The answer is computable from the code or configuration alone, without waiting for production behavior. FBDetect is the best behavioral detection system in the industry. It cannot see what hasn't happened yet. Declared invariants can.

The ratchet that would make the system self-improving

Here's the pattern Meta's architecture repeats and doesn't close:

A code change ships. It introduces a performance regression.
FBDetect catches it. The AI Regression Solver investigates.
The solver produces a fix-forward PR. A human reviews it.
The human approves. The fix deploys. The regression is resolved.

That human, in step 3, just learned something: this class of change causes this class of regression. They now know that removing memoization from serialization functions in this codebase causes latency spikes. Increasing logging verbosity in this service causes CPU regressions. Changing batch sizes in this pipeline degrades throughput.

That knowledge should become a specification — a declared invariant that prevents the same class of regression from ever deploying again. "Serialization functions in this codebase must remain memoized." "Logging verbosity in this service must not exceed level N." "Batch size for this pipeline must stay within range X–Y."

Instead, it stays as a fixed PR. The regression is resolved. The knowledge evaporates. Next month, a different engineer makes the same class of change in a different function, and the cycle repeats: deploy, regress, detect, investigate, fix. The AI Regression Solver makes the cycle faster. It doesn't make the cycle shorter. The same class of error recurs because nobody converted the one-time fix into a permanent rule.

The ratchet: every regression fix becomes a declared invariant. The human catches it once. The machine enforces it forever. Each cycle through the defense pipeline permanently expands the set of things the machine prevents, permanently shrinking the set of things FBDetect has to catch. Over time, the defense pipeline handles fewer regressions. Because the specification layer prevented the regressions before deployment.

This is the same ratchet every safety-critical domain uses. Aviation doesn't just fix each incident. It converts each incident into a regulation that prevents recurrence. Nuclear doesn't just resolve each event. It converts each event into a technical specification the interlocks enforce. The investigation gets faster with each cycle (Meta has this). The prevention gets broader with each cycle (Meta doesn't have this — yet).

The offense side has the same gap

On offense — finding optimizations — the architecture is: gather context, apply encoded expertise, produce a candidate fix. The agent looks up opportunity metadata, documentation, past examples, specific files and functions, and validation criteria.

The validation criteria are the closest thing to declared invariants in the architecture. But they're per-opportunity, not systemic. An optimization that satisfies its validation criteria but violates a performance invariant elsewhere — introducing a latency regression in a downstream service while improving CPU usage in the target service is invisible to per-opportunity validation. It requires a cross-cutting invariant: "end-to-end latency for this user flow must not exceed N milliseconds, regardless of which service is optimized."

The same layer that prevents defensive regressions would also bound offensive optimizations: declared performance invariants that all changes. Regressions and optimizations must satisfy. The optimization is only valid if it satisfies the local validation criteria and doesn't violate any cross-cutting invariant. Without the invariant layer, every optimization is a local improvement that may be a global regression. The system relies on FBDetect to catch the global regression after it ships, rather than preventing it at PR time.

Completing Meta's architecture

Meta's architecture has:

Tools — standardized interfaces for data, profiling, code search, documentation. Present and excellent.
Skills — encoded domain expertise for investigation and resolution. Present and growing.
Detection — FBDetect, behavioral monitoring at 0.005% sensitivity. Present and industry-leading.
Resolution — AI Regression Solver producing fix-forward PRs automatically. Present and compressing investigation time by 20x.

What completes it:

Declared invariants — human-authored performance contracts that code and configuration must satisfy, checked mechanically at PR time, before deployment. Not behavioral. Not reactive. Deterministic and proactive.
The ratchet — every regression fix, once approved by a human, becomes a declared invariant the machine enforces on every future commit. Each defensive cycle permanently expands the prevention surface.
Cross-cutting verification — invariants that span services, so an optimization in service A that degrades service B is caught at PR time, not after both changes have deployed to production.

The tools and skills stay exactly as they are — they're excellent. FBDetect stays exactly as it is, it's the behavioral safety net for problems the invariants don't yet cover. The AI Regression Solver stays. It handles the regressions that make it past the invariant layer (Vassilev's proof guarantees some always will). What changes is that a growing layer of declared invariants prevents an increasing share of regressions from deploying in the first place, and each time the solver fixes one, the invariant layer grows.

The end state: a system that prevents more than it detects

Meta's stated goal is "a self-sustaining efficiency engine where AI handles the long tail." The current architecture approaches this from the detection side — catch more, investigate faster, fix automatically. That works, and it scales with better skills and better tools.

The invariant-first version approaches it from the prevention side — declare more, enforce mechanically, prevent before deployment. Each ratchet cycle moves a class of regression from "detected and fixed" to "prevented and never shipped." The long tail doesn't get handled — it gets shortened.

A self-sustaining efficiency engine that only detects and fixes runs forever at the same rate. There are always new regressions to catch. A self-sustaining efficiency engine that also prevents runs at a decreasing rate. Each cycle makes the next one smaller. The first is a treadmill. The second is a ratchet. Meta has the best treadmill. The ratchet is one layer away.

References: Meta, "Capacity Efficiency at Meta: How Unified AI Agents Optimize Performance at Hyperscale" (2026). The tools/skills architecture in that piece is the most sophisticated AI agent system published this year. The gap is the layer above it: declared invariants that prevent regressions before deployment, and the ratchet that converts each fix into a permanent rule. If you're on the Meta Capacity Efficiency team and you've already explored this direction, that's the conversation worth having.

272 Experts Named the Risks. Nobody Named the Mechanisms.

Bala Paranj — Thu, 25 Jun 2026 09:16:53 +0000

MIT's AI Risk Repository surveyed 272 international experts — researchers, practitioners, policymakers from MIT, Harvard, Oxford, Stanford, Tsinghua, national AI safety institutes, and industry using the Delphi method to answer a direct question: which AI risks are most severe, who is most vulnerable, and who is responsible for addressing them?

The headline finding: 18 of 24 AI risk domains carry at least a 10% probability of catastrophic outcomes within the next five years under current trajectories. Catastrophic meaning more than one million deaths, more than $100 billion in damage, or civilization-scale intangible harms like the collapse of democratic norms.

The five most severe risks: dangerous capabilities, competitive dynamics, weapons and cyberattacks, power centralization, and false information. Even under a scenario where pragmatic mitigations are implemented, the probability of catastrophic harm from multiple categories remained above 10%.

This is 272 experts saying: under current practice, the probability of catastrophic outcomes from AI is not small, and current mitigations are not sufficient to bring it below a tolerable threshold. The study is rigorous, the methodology is established, and the finding is clear.

Who is reading it?

The responsibility gap is the translation gap

The study's most structurally important finding isn't about severity. It's about who bears the risk versus who can do something about it.

AI users and the general public are most vulnerable to AI risks. General-purpose AI developers and governance actors are most responsible for addressing them. The study calls this a "responsibility gap" — the people who can act aren't the people who get hurt.

This is the same structural pattern that plays out in every safety-critical industry. The public is most vulnerable to aviation failures, pharmaceutical side effects, nuclear meltdowns. Engineers, manufacturers, and regulators bear primary responsibility for prevention. In those industries, the gap is bridged by mandatory standards, enforcement, liability, and a societal expectation of low risk tolerance. For AI, as the study notes, "comparable mechanisms are nascent or absent."

But there's a gap inside the responsibility gap that the study identifies but doesn't name: between the research that predicts the failures and the engineering teams that are building the systems. The developers who hold responsibility aren't reading the research that tells them their architectures are weak. The researchers who produce the findings aren't translating them into engineering decisions. Nobody in the organizational structure bridges the two. The Gap That Costs More Than Any Bug

The MIT study is itself an instance of the problem it describes. It is rigorous, authoritative, and written for researchers and policymakers. The engineering teams building agent systems — the teams whose architectural choices will determine whether these risks materialize are reading framework blog posts and benchmark results, not Delphi studies. The study says "competitive dynamics carry catastrophic risk." The engineering team sees "Top 30 to Top 5 on Terminal Bench" and ships the improvement. Same world, different information channels, no bridge.

Three findings that connect to specific architectural gaps

The study names risks. It does not name the engineering mechanisms that turn those risks into failures. Here's where the connection lives.

Multi-agent risks — named as catastrophic, unsolved in the dominant architecture

The study defines multi-agent risks as "risks from multi-agent interactions due to incentives or system structure, which can create conflict, collusion, cascading failures, selection pressures, new vulnerabilities, and a lack of shared information and trust." Experts assessed this as carrying catastrophic potential.

The leading agent framework lists multi-agent coordination as an open research problem. The team running the most ambitious agent-generated codebase writes that they don't yet know how architectural coherence evolves over time. The dominant architecture — Model + Harness — has no specification layer, no coordination protocols, and no mechanism for ensuring that independently-generated outputs are globally consistent. The Harness is Half the Architecture

Distributed systems engineering solved this problem decades ago with specifications as coordination protocols, contract enforcement, and interface boundaries. The architectural answer exists. It hasn't reached the teams building the systems the MIT study is warning about. That's the translation gap applied to a specific risk the study names as catastrophic.

Competitive dynamics — the second most severe risk, and the one driving architectural shortcuts

Experts ranked competitive dynamics as the second most severe risk category. The study defines it as "competition by AI developers or state-like actors in an AI race to maximize strategic or economic advantage, increasing the risk they release unsafe and error-prone systems."

This is the specific dynamic that produces the architectural shortcuts the current generation of agent systems is built on. Self-verification instead of independent verification. Because independent verification is slower and harder. Accumulation without subtraction — because generating more is easier than curating what belongs. Generation loops without verification gates between iterations — because gates slow throughput. Each shortcut is a competitive decision: ship faster by skipping the subsystem that would have caught the failure.

The study says this dynamic carries catastrophic probability. The engineering articles from the teams making these decisions say "these guardrails will almost surely dissolve over time" — treating safety mechanisms as temporary scaffolding to be removed once models improve, rather than as permanent peer subsystems of the architecture. Agentic Development Manifesto

AI security vulnerabilities — a named risk category that conflates four distinct problems

The study lists "AI security vulnerabilities and attacks" as a risk category. But it treats it as one thing. In practice, it's at least four:

Application code vulnerabilities — bugs in the source code (buffer overflows, injections). LLM scanning works here.
Application config — misconfigured settings the code correctly applies. Not a code bug.
Infrastructure code — IaC templates with misconfigurations. Linters and scanners work here.
Infrastructure config — the actual deployed state of cloud resources. Configuration posture, compound cross-resource risk, intent verification. A different class entirely.

The industry's current response: LLM-powered source code scanning covers the first category and is being presented as a comprehensive security solution. The other three categories need different tools with different epistemics: deterministic verification against declared invariants, graph evaluation of cross-resource paths, intent checking against human-declared rules. LLMs Can Find Bugs in Your Code. That's One Class of Security Problem.

The MIT study ranks the risk but doesn't make this four-way distinction, which means the teams reading the study won't realize that the security measures they're implementing cover one quadrant and leave three unaddressed. The risk is named. The mechanism is unnamed. The gap persists.

The map: each named risk to the missing element

There is a law — independently derived by engineering (TRIZ), cybernetics (Beer's Viable System Model), and economics (Co-opetition) — that says any viable system must contain five elements: a Tool (the generator — the model), an Engine (declared, machine-checkable intent), a Transmission (CI/CD plus machine-readable contracts), a Control Unit (the independent oracle that measures output against intent and feeds back a deterministic verdict), and a Casing (enforced boundaries the system structurally cannot cross). A system missing any one does not survive. The Harness is Half the Architecture

That gives the mechanism vocabulary the study lacks. Each risk MIT names is what failure looks like from the outside; the missing or weakened element is the mechanism on the inside that produces it.

MIT risk (named)	Missing / weak element	The mechanism the study doesn't name
Multi-agent risks (collusion, cascading failures, lack of shared trust)	Transmission + Engine	No contract layer or shared spec — independently-generated outputs fight over a mutable blackboard with nothing enforcing global consistency, so they collide and cascade.
Competitive dynamics (the race to ship)	Control Unit	The race deletes the independent verification gate; self-verification replaces it because gates slow throughput. An LLM grading an LLM is a second Tool wearing a checker's badge, not an oracle.
AI security vulnerabilities and attacks	Control Unit + Casing	Three of the four security quadrants — config, IaC, deployed infra posture — need a deterministic oracle against declared invariants and enforced boundaries. LLM source-scanning only checks the Tool's code output.
Dangerous capabilities	Casing	Capability is bounded only by advisory guardrails ("these will almost surely dissolve over time"), not by boundaries the structure makes uncrossable.
Weapons and cyberattacks	Casing + Control Unit	No enforced egress/permission boundary on what the generator may reach, and no independent check on what it is allowed to produce.
Power centralization	Casing (scope)	The boundary of the game is unenforced; market concentration is a Scope failure — the structure permits unbounded reach.
False / misleading information	Engine + Control Unit	No durable declared intent to measure against and no deterministic verdict — generation runs open-loop with nothing comparing output to ground truth.

Read down the middle column and the pattern is unmistakable: the Control Unit and the Casing are missing or advisory across nearly every catastrophic category. That is not a coincidence. It is the same structural hole, surfacing under seven different risk names. The study counts the symptoms; the law names the cause.

What the study gets right that the industry ignores

Three implications from the study that directly challenge current practice:

"Significant risks require substantial mitigations." Under most established risk-governance frameworks, a 10% probability of catastrophic outcome over five years is intolerable — triggering mandatory mitigation. The industry is treating these probabilities as acceptable background risk. They are not, by any established standard.

"Relying on developers' voluntary action alone is insufficient." The study says it plainly: "any individual developer that slows down to invest in safety bears competitive cost. Absent external constraints, AI companies have structural reasons not to act on risks." This is the competitive-dynamics risk stated as an incentive problem. The solution the study prescribes — "rules and people to enforce them" — is the same architectural answer the engineering discussion arrives at: mechanical enforcement of declared specifications, not voluntary guardrails. Cloud Security Has a Cynefin Problem

"Some risks may be difficult to address through guardrails on AI models alone." The study says structural dynamics like competition and market concentration "may call for measures like competition policy, labour protections, and governance arrangements alongside technical solutions." This is the systems-thinking argument applied at the societal level: the model is one subsystem, and wrapping it in better guardrails doesn't address risks that live in the interactions between subsystems.

The bridge that doesn't exist

The MIT study is the risk side. The engineering blog posts and framework architectures are the building side. The gap between "272 experts say this is catastrophic" and "the leading framework's architecture contradicts the research" is structural. Nobody's job is to carry the finding from one side to the other in language the other side acts on.

The study will be read by researchers and policymakers. The framework blog posts will be read by engineers. Neither group will read the other's output. The risks the study warns about will materialize through the architectural decisions the blog posts describe and the teams making those decisions will not have seen the study that predicted the outcome.

That's the gap. It costs more than any bug, because bugs are found and fixed. A structural gap between risk research and engineering practice produces failures that were predicted, preventable, and repeated. The same pattern that played out with Lamport and Paxos, with microservices and distributed systems, and now with AI agents and the research that already exists to prevent the coming failures. The Gap That Costs More Than Any Bug

The question is whether the engineering teams building the systems the study warns about will ever see the findings in a form they can act on before the failures arrive.

References: MIT AI Risk Repository, "Prioritizing the risks from Artificial Intelligence" (2026), Delphi study of 272 international experts.

Cloud Security Has a Cynefin Problem

Bala Paranj — Wed, 24 Jun 2026 08:46:51 +0000

This article provides a necessary framework for buyers to stop the tool sprawl by identifying that they are not just buying features, they are buying modes of reasoning.

Stave references describe an open-source project I work on. Claims about it are scoped deliberately and noted where they have limits. Cynefin is Dave Snowden's framework.

There's a recurring confusion in how teams assemble cloud security tooling. It's about how we keep applying the wrong kind of method to a problem — probabilistic inference where a definite answer was available, and rigid rules where the answer couldn't be known in advance. Dave Snowden's Cynefin framework names this mismatch precisely, and once you see it, the question "which tool do I need?" mostly answers itself — including the parts where the honest answer is "not the one I'm selling."

Complicated vs Complex

Cynefin sorts problems by the nature of cause and effect. Two of its domains carry this whole discussion:

Complicated — cause and effect are knowable. There's a right answer; finding it takes analysis or expertise, but it's deducible from what's in front of you. An experienced engineer (or a good engine) can work it out. The method is analyze, then respond.

Complex — cause and effect are only coherent in retrospect. The system is a tangle of interacting parts, and no amount of staring at any single artifact yields the answer in advance. You can't deduce it; you can only probe, sense, and respond — run experiments, observe what happens, form hypotheses. The answer, when it comes, is a best current explanation, not a proof.

Cynefin has other domains — Clear, where the answer is obvious; Chaotic, where you act first and think later; and a central Confused state where you don't yet know which domain you're in. The last one is where most buyers stand.

The mistake that wrecks tooling decisions is treating a Complex problem as if it were Complicated, or a Complicated one as if it were Complex.

Runtime incidents are Complex. Treat them that way.

A production incident in a live distributed system is the textbook Complex problem. Why did latency spike at 2am? The cause is some interaction of load, a deploy, a slow dependency, a cache change, and a traffic pattern — coherent only after you've reconstructed it. You cannot deduce it from any single source; you have to investigate.

This is the domain of AI investigation agents. Tools that connect to your observability, code, and infrastructure and reason across them to find root cause and warn about brewing failures. They build models, evaluate competing hypotheses, and land on a best explanation. One such agent reports something like 70%+ accuracy on novel incidents.

Cynefin point: that 70% is not a weakness. It's the honest ceiling of the Complex domain. When cause and effect are only knowable in retrospect, certainty isn't on the menu, because the problem doesn't have a deducible answer in advance. The logic these agents run is abduction — inference to the best explanation: "these symptoms are best explained by this cause." Abduction is definitionally uncertain; more than one cause can fit the same evidence, which is why the output is a ranked set of hypotheses with a confidence, not a verdict. The anomaly models lean on induction too — generalizing from many past data points — but it's the abductive step at incident time that sets the ceiling. Probabilistic inference is the correct instrument here. A tool that claimed 100% certainty about a novel incident's cause would be lying about the domain it's in. Probe, sense, respond — done well — is right for Complex.

The failure mode in this domain is the opposite one: applying rigid, pre-written rules to it. Static thresholds and runbooks are Complicated-domain tools — "if metric > X, alert" — and they fail in Complex environments precisely because you can't enumerate in advance the conditions that will matter. That's why threshold tuning is endless and runbooks are always one incident behind. It's a domain mismatch.

Config posture is Complicated. Treat it that way.

Now a different question: does this configuration satisfy a stated safety rule? Does this IAM policy grant a permission it shouldn't? Is this storage exposed in a way our policy forbids?

These questions have definite answers, and the answers are deducible from the configuration itself. This is Complicated, not Complex. Where the investigation agent reasons by abduction — best guess from evidence — config evaluation reasons by deduction: the conclusion follows necessarily from the configuration and the rule. There's no "probably." The config either satisfies the rule or it doesn't, and a deterministic engine can establish which — the same way, every time, reproducibly.

In this domain, reaching for probabilistic inference is the mismatch. A tool that tells you your config is "87% likely compliant" has thrown away certainty that was available. You don't want a hypothesis about whether your S3 bucket policy violates a rule; you want the verdict, and you want it to be the same verdict tomorrow so an auditor can re-run it. Determinism here isn't a limitation or a conservative choice. It's the method the domain demands. Using a model to answer a deducible question adds cost, latency, and doubt where none needed to exist.

This is the domain the tool I work on, Stave, is built for: deterministic evaluation of a configuration snapshot against a catalog of safety invariants, with no model in the loop. The point is that for a Complicated-domain question, it's correct, and inference would be the error.

Compound risk straddles the border

Here's where the framework forces an admission.

The most valuable risks in cloud security are often compound. They emerge from how resources combine, not from any single misconfiguration. A scanner checking one resource at a time can't see them. It's tempting to plant a flag and say "compound risk is our territory, deterministically." But Cynefin won't let me say it, because compound risk lives on both sides of the Complicated/Complex border, and which side a given risk sits on changes which tool is right.

Config-deducible compound risk is Complicated — and deterministic evaluation owns it. If a path's existence is fully determined by the configuration. This function has this role, this role can read this bucket, this bucket holds sensitive data — then the path is deducible from the configuration graph. No runtime observation needed. You can prove it exists in the snapshot by traversing the graph, and graph traversal is a deterministic computation, not a guess. This is legitimately the deterministic tool's domain, and it's the part scanners miss because they look at nodes, not edges.

Behavior-dependent compound risk is Complex — and it is not the deterministic tool's domain. If a path's existence depends on runtime state. Does this service invoke that one, is this code path reachable under real traffic, does this permission ever get exercised — then it is not deducible from configuration alone. It only becomes visible by observing the running system. That is the Complex domain, and the deterministic engine is blind to it by construction. Here the investigation agent's probe-sense-respond beats deterministic evaluation, because there is nothing to deduce — only something to observe.

So the honest claim a deterministic config tool can make is narrower than "we catch compound risk." It is: we catch compound risk that is deducible from the configuration graph. The moment a risk's existence depends on behavior, it has crossed into a domain where deduction has nothing to work with and inference is the right method. A config snapshot can prove a path is present in the configuration; it cannot prove the path is exercised in production, and it cannot prove the path is exploitable. There may be controls the snapshot doesn't capture. Those are different questions in a different domain.

Compound-risk story does not imply a reach the tool doesn't have. The reach it does have — config-deducible cross-resource paths, evaluated deterministically is real and is missed by per-resource scanners. That claim is strong enough without inflation.

The window closes when chaos hits

There's a fourth domain that sharpens when deterministic evaluation is even possible. Cynefin's Chaotic domain is where cause and effect are unknowable in the moment — no time to analyze, no stable state to reason about. An active breach can drag an otherwise-Complicated system into it: things are moving too fast and the system is too compromised to deduce anything. Snowden's prescription for Chaotic is blunt. Act first (contain, isolate, shut down) to force the system back into a domain you can reason in.

Deterministic config evaluation is not a Chaotic-domain tool. It does nothing for you mid-breach, when you're containing rather than deducing. Its window is before the slip. The value of evaluating config posture while everything is calm is that deduction is only available while the system is stable; once you're in chaos, the cost of analysis exceeds the value of time. The certainty (the configuration) still exists, but you can't afford to look at it while the house is burning, and you're down to acting. So config hygiene isn't "what saves you during the breach" — that's incident response, a different domain with different tools. It shrinks the deducible attack surface beforehand, so fewer paths are standing to be exploited into a chaos event in the first place. The tool that operates inside the Complex-to-Chaotic moment is the investigation agent, not the config evaluator — which, again, is the complementarity.

Why this isn't "which tool wins"

If you map the tools to the domains, the supposed competition dissolves:

Investigation agents are Complex-domain tools. Probabilistic by necessity. Right for "what's happening, what caused it, what will probably break."
Deterministic config evaluation is a Complicated-domain tool. Definite by construction. Right for "does our configuration satisfy the rules, including the deducible cross-resource paths."
Per-resource scanners are also Complicated-domain tools, but they only see one node at a time. They handle the simple deducible questions and miss the deducible combinations.

None of these substitutes for another, because they answer questions in different domains. The runtime risk that only manifests under load is invisible to the config tool. The config violation that's quietly out of policy while nothing's breaking is invisible to the runtime agent. Demanding that one tool cover both domains is the original Cynefin error wearing a procurement hat.

The buyer is in the Confused domain

Cynefin's central state — sometimes called Confused or Aporetic — is where you haven't yet figured out which domain your problem belongs to. That is where a security buyer stands when they say "we already run an investigation agent, why would we need anything else?" The question conflates two domains. They've covered Complex (runtime investigation) and assume it covers Complicated (config posture), or vice versa.

The useful move isn't to argue your tool is better. It's to disambiguate the domain — to help them see they're holding two different problems that demand two different methods. Once the Complex problem and the Complicated problem are named as distinct, the tooling question stops being a contest and becomes an inventory: which of these two problems do I have covered, and with the right kind of method for each?

That's the whole value of dragging Cynefin into a security conversation. It doesn't tell you which vendor to buy. It tells you which kind of answer a given question can even have and that, more than any feature comparison, stops you from buying a probabilistic answer to a question that deserved a definite one, or a rigid one to a question that was never going to sit still.

Stave is an open-source, deterministic config-evaluation tool I work on (Apache 2.0, early-stage). I've tried to keep its claims inside the Complicated domain where they belong; if you think I've drawn the Complicated/Complex border in the wrong place — a config risk I've called deducible that really needs runtime observation, or vice versa — that's the disagreement worth having. Cynefin is Dave Snowden's; errors in applying it are mine.

The Gap that Costs More than Any Bug. Why Billions of Dollars are Being Spent Solving Solved Problems

Bala Paranj — Tue, 23 Jun 2026 04:49:00 +0000

All citations are linked and verifiable. The Lamport, microservices, and AI-agent examples are well-documented. The structural argument about organizational gaps is the author's analysis.

The Gap

In 1998, Leslie Lamport published the Paxos consensus algorithm. A solution to the problem of getting multiple computers to agree on a shared state. It was correct, proven, and published in a peer-reviewed venue. Engineering teams building distributed systems needed it. Almost none of them used it, because the paper was written in a style that made it effectively invisible to practitioners. Three years later, Lamport re-published it as "Paxos Made Simple," opening with an admission: the algorithm, when stated in plain language, is very simple. It was always simple. The barrier was never the engineering team's ability to understand it. It was that the research was written in a language practitioners didn't read, published in a venue practitioners didn't visit, and nobody's job was to carry it across.

In the years between 1998 and 2001 and for years after — engineering teams built distributed systems that failed in ways Paxos would have prevented. The failures were real, expensive, and predictable. The research that predicted them was available. The teams that needed it didn't have it.

This is not a story about one paper. This repeats across decades, across technologies, and across industries. The same structural gap that delayed Paxos produced the microservices failure wave of 2014–2020. It's producing the AI agent failure wave right now. The mechanism is identical each time. This gap prevents technical insights from reaching the people who need them.

The structure of the gap

Every technology company has a recognized, funded, staffed layer between engineering and the end developer: developer relations, developer advocacy, developer experience, solutions engineering, technical writing. The function is understood: engineers build the product, this layer translates it into something developers can adopt correctly. There's a job title for it. There's a budget and a team. It exists because everyone accepts that a gap between "what the engineers built" and "what the developer understands" is a real, costly problem that doesn't solve itself.

There is no equivalent layer between research and engineering.

No role called "research translator." No "applied research liaison" who reads the papers, understands the engineering context, and tells the team: the assumption underneath your architecture was disproven at ICLR last year, here's what it means for your system. The researchers publish in academic venues for other researchers. The engineering teams read blog posts, watch conference talks, and follow what the leading frameworks do. The two worlds don't touch, and nobody's job is to make them touch.

Engineers think concrete to abstract. They start with a specific system, hit a specific failure, and generalize upward: our service kept failing, we added retries with backoff, that's a pattern, now we understand circuit breakers. The abstraction is earned from the concrete. Every principle they trust was learned through something that broke in production. This is the let it blow up in production then learn the lessons approach.

Researchers think abstract to abstract. They start with a formal framework, prove a property about a general class of systems, and publish the finding in general terms: "LLMs struggle to self-correct their responses without external feedback." The concrete application is left to the reader. The paper never says "your specific verification loop is broken" because the paper doesn't know your specific verification loop. It proved something about a class of systems. Connecting that class to a specific architecture is someone else's job — but that someone doesn't exist in the org chart.

The missing translation is concrete to concrete: this specific thing you built is a specific instance of this proven failure, and here's specifically what to build instead. The researcher won't write it because they don't know your system. The engineer won't write it because they don't read the paper. The company doesn't staff anyone whose job is to write it.

The microservices precedent

The microservices wave is the recent example.

Teams heard "decompose your monolith into small independent services" and started splitting. The pitch was compelling: independent deployment, team autonomy, technology diversity, scaling individual components. The surface-level idea was simple. The underlying reality — that they were building a distributed system and inheriting every problem distributed systems research had spent decades solving wasn't part of the pitch.

So they learned it the hard way. Service A calls Service B calls Service C, and C goes down. Without circuit breakers, the failure cascades backward and takes down everything. The team that split the monolith didn't know they needed circuit breakers because nobody told them "you just built a distributed system, and Nygard solved this in 2007." They discovered it in a 3am outage, learning in 2015 what had been published in Release It! eight years earlier.

Data that was consistent in one database was now spread across five services with eventual consistency, and the team found out during a production incident that two services disagreed about whether an order was placed. They didn't know about the CAP theorem or saga patterns. They just split the database along service boundaries because the blog post recommended it.

Every hard-won "microservices best practice" that emerged — circuit breakers, bulkheads, service mesh, distributed tracing, saga patterns, API versioning, contract testing was a re-discovery of something the distributed systems research community already knew. The industry spent roughly 2014 to 2020 — six years and enormous sums learning through production failures what had been published decades earlier. The research was available. The bridge didn't exist, so the learning happened through outages instead of through papers.

The microservices maturity curve worked — expensively, slowly, but it worked. Because the cost of failure was operational. An outage costs engineering hours and customer trust, but when the outage is over, the team is still there, the budget is still there, and they can iterate toward the correct architecture. The learning-from-failure model depends on having resources left to learn after the failure.

The AI agent gap — same pattern, worse economics

The AI agent industry is at the equivalent of 2015 in the microservices curve. The enthusiasm phase: agents solve everything, more agents means more productivity, build a better harness and the model handles the rest.

The research that predicts the failures already exists. Huang et al. (ICLR 2024) proved that large language models cannot self-correct reasoning without external feedback and that performance can degrade after self-correction. Vassilev (NIST, IEEE Security and Privacy, June 9, 2026) published a mathematical proof extending Gödel's incompleteness theorems to AI systems, demonstrating that no finite set of guardrails is universally robust. Decades of distributed systems research established that coordination between independent actors requires protocols, not shared storage.

Meanwhile, the leading agent framework's top-line improvement is built on self-verification. The model checking its own output — with the team calling models "exceptional self-improvement machines." They describe the exact failure mode Huang et al. predicted: the agent re-reads its own code, confirms it looks correct, and stops. Their fix is to prompt the model more aggressively to self-verify. No independent oracle is introduced. The most common failure of self-checking is addressed by more self-checking.

The same framework's architecture article lists multi-agent coordination as an open research problem. The exact problem distributed systems solved with specifications and protocols forty years ago and proposes no specification layer. OpenAI's own engineering team, running the most ambitious version of this architecture (a million-line, fully agent-generated codebase), writes: "What we don't yet know is how architectural coherence evolves over years in a fully agent-generated system." Five months in, 20% of their engineering time was spent manually cleaning up "AI slop."

The research predicts these outcomes. The engineering teams are experiencing them. The bridge between the two doesn't exist.

But this time the microservices "learn from failure" model breaks, because the economics are different. LLM API calls are a consumable resource. Every token spent is money gone, whether the output was correct or not. A team that runs hundreds of agents with self-verification loops and no subtraction discipline is burning tokens at a rate that has no equivalent in the microservices world. A microservice that fails and retries costs compute cycles. An agent that generates wrong code, self-verifies it as correct, generates more wrong code on top of it, loops many times, and then the team discovers it was wrong from iteration three. That team just paid for several iterations of worthless output, and that money is gone. They can't iterate toward the correct architecture with the same budget, because the budget was the token allocation and it's been consumed.

Companies that blew their annual API budget in a few months on agent-generated code that turns out to be architecturally unsound don't get to spend the remaining months learning and iterating. The budget is consumed, the output is wrong, and the correction requires spend they no longer have. The microservices gap cost time and pain. The agent gap costs companies their viability.

Why the gap persists

The gap is self-reinforcing because both sides are incentivized to stay on their side.

The engineer looks at "Top 30 to Top 5 on Terminal Bench" and that's a concrete number on a concrete leaderboard. It goes on a slide. It justifies the quarter's work. It feels like engineering because it has a measurement attached to it. Reading a paper that says the verification model is structurally unsound doesn't have a number, doesn't produce a dashboard, and doesn't feel like progress. It feels like interrupting progress. So it doesn't happen. The team optimizes the metric they can see rather than questioning whether the metric measures what matters. Benchmark scores go up. The architecture is still shaky. The dashboard is green.

The researcher looks at peer review, citations, and the next publication. Writing "Paxos Made Simple" doesn't count as a new contribution in most academic incentive systems. It's a re-explanation of existing work, and tenure committees don't reward re-explanation. So the accessible version arrives years late, after the engineering teams have already made the mistakes the original paper would have prevented.

The company that hired the engineering team hired them to build and ship. That's what they do, and they do it well. Nobody hired them to read ICLR papers on self-correction failure modes and assess whether their architecture contradicts the findings. That job doesn't exist in the org chart. The technical risk assessment against existing research — the thing that would catch "our top improvement is built on a contradicted assumption" before it ships isn't in anyone's role.

This is how companies build architecturally shaky systems with smart, capable, well-credentialed people doing what they were hired to do. The engineer's job is to build and ship. They build and ship. The researcher's job is to publish and get cited. They publish and get cited. The gap between the two isn't anyone's job, so nobody fills it, and the company inherits a technical risk that existing theory would have prevented, because the organizational structure has a hole where the risk assessment should be.

The cost of the missing bridge

The DevRel layer exists because companies learned the hard way that developers using their products wrong is expensive — bad adoption, support load, churn. The research-to-engineering layer doesn't exist because the cost of engineers building on contradicted assumptions hasn't been felt at industry scale yet.

It will be. When agent-built systems hit production at scale and fail in ways the research predicted, the post-mortems will trace back to this gap: the team didn't know the assumption they were building on had been disproven, because nobody's job was to tell them.

The cost scales with the industry. When distributed systems were niche, the Lamport gap cost individual companies individual outages. Now that every product is a distributed system, the gap costs billions annually in preventable failures. The same scaling is about to happen with AI agents: right now the self-verification gap costs individual teams individual bugs. When hundreds of companies ship agent-built production systems on the same contradicted assumptions, the cost will be industry-wide.

The agent failures will be harder to detect than the microservices failures, because they're silent. A microservices outage is visible: the system goes down, requests fail, users complain. An agent-built system producing subtly wrong code that passes self-verification is quiet. The system is green. The tests pass. The output looks plausible. The error surfaces months later as a security vulnerability, a logic bug in production, an architectural decision that compounds across the codebase. The distributed-systems failures were loud and fast. The agent failures will be quiet and slow — which means the learning-from-failure cycle will take longer and cost more.

The bridge costs almost nothing to build

This makes the gap so frustrating. The bridge isn't expensive or hard. It's an article, a translation, a sentence that connects a proven finding to a shipped architecture in language an engineer can act on. "Self-verification is not verification because the oracle is not independent of the generator" is that sentence. It says in one engineering sentence what the ICLR paper takes pages to establish in academic language. "The domain is different, the math is the same" is the translation of Vassilev's proof for an engineer who dismissed it as being about chatbot jailbreaking.

The work with the highest leverage in the entire chain — preventing millions in wasted spend by connecting a proven finding to a shipped product before the failure arrives is the work nobody hires for, budgets for, and nobody's job description includes.

The companies that staff this function or pay attention to the people doing it independently will save themselves the cost of re-learning solved problems through expensive failures. The companies that don't will spend that money on post-mortems that trace back to a paper nobody on the team read. Because nobody translated it into a sentence they could act on.

The research cited in this article: Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet" (ICLR 2024); Vassilev, NIST/IEEE Security and Privacy (June 9, 2026). The engineering artifacts cited: Trivedy, "The Anatomy of an Agent Harness" (LangChain, March 2026); "Improving Deep Agents with Harness Engineering" (LangChain, February 2026); Lopopolo, "Harness Engineering" (OpenAI, February 2026). If you know of an organization that has successfully staffed the research-to-engineering bridge as a defined role, I'd like to hear how they structured it — because the few examples that exist (Amazon's formal methods adoption, Netflix's resilience engineering publications) suggest the pattern works when it's resourced, and the question is why so few organizations resource it.

Seven Sections of 'React Faster.' Zero Sections of 'Prevent.'

Bala Paranj — Mon, 22 Jun 2026 11:21:57 +0000

Anthropic published "Preparing your security program for AI-accelerated offense" — seven sections of security recommendations from the team that builds Mythos, the model powering Project Glasswing. The document is thorough, well-organized, and maps to existing frameworks (SOC 2, ISO 27001, CISA CPGs).

It also prescribes one strategy, seven times: react faster with AI.

The timeline test

Map each section to where it operates on the timeline of a vulnerability's life:

Section	Timeline position	What it does
1. Close your patch gap	After vulnerability exists, after patch exists	Apply patches faster
2. Handle more reports	After vulnerability is found by someone	Triage findings faster
3. Find bugs before shipping	After code is written, in CI pipeline	Detect in CI (earlier detection, not prevention)
4. Find bugs in existing code	After code is deployed, sitting in production	Scan production code faster
5. Design for breach	After breach occurs	Contain damage faster
6. Reduce attack surface	After deployment, before attack	Inventory and prune faster
7. Shorten incident response	After breach is detected	Respond faster

Not one section operates at the point of creation — where the developer writes the code or configures the infrastructure. "Find bugs before you ship them" sounds upstream, but it isn't — it finds bugs after the developer wrote them, in the CI pipeline. The bug was created. The scan found it. That's earlier detection. Not prevention.

Prevention looks like: a declared invariant that makes the bug class impossible to create. A type system that eliminates buffer overflows by construction. A parameterized query that makes SQL injection impossible by construction. A policy check that rejects a configuration violating a declared rule before it reaches any pipeline. These mechanisms operate before the vulnerability exists — because they make the vulnerability impossible.

The word "prevention" appears once in the entire document. The word "declaration" appears zero times. The word "invariant" appears zero times. The word "specification" appears zero times.

"Prepare to handle a much higher volume of vulnerability reports"

Section 2 is the most revealing. Anthropic — the company building Mythos is telling you that AI will create more work.

More findings to triage. More patches to apply. More vendor reports to process. "Plan for an order-of-magnitude increase in finding volume." Their prescription: automate the triage with AI. Use AI to handle the flood that AI created.

This is the aftermarket feeding itself. A more powerful scanner produces more findings. More findings require more triage. More triage requires more AI. More AI requires more budget. The cost scales with the capability of the scanner — which Anthropic controls and improves every quarter.

The declaration approach produces the opposite dynamic. Each declared invariant reduces the finding volume. Because the vulnerability class is prevented from existing. There's nothing to find, triage or patch. The number of reports goes down over time. The triage queue shrinks. Each ratchet cycle makes the next cycle's workload smaller.

Anthropic's recommendation: prepare for 10x more findings. The declaration approach: reduce findings toward zero for every declared class. One strategy scales your costs with AI capability. The other shrinks your costs with each declaration.

AI prescribed for deterministic tasks

Throughout the document, every "AI can help" sidebar prescribes a frontier model for the task. Count them:

Triage alerts → AI
Deduplicate findings → AI
Check dependency redundancy → AI
Scan for vulnerabilities → AI
Generate patches → AI
Prune stale code → AI
Red-team your perimeter → AI
Hunt for misconfigurations → AI
Investigate every alert → AI
Draft postmortems → AI
Drive the detection flywheel → AI

Now ask: which of these tasks have deterministic alternatives?

Task	Anthropic prescribes	Deterministic alternative	Cost comparison
"Does this dependency have a known CVE?"	LLM call	Database lookup against CVE registry	$0.01+ vs $0.0001
"Does this security group allow 0.0.0.0/0 inbound?"	LLM analysis	Boolean check on the security group JSON	$0.01+ vs microseconds
"Is this credential older than 90 days?"	LLM triage	Date comparison	$0.01+ vs microseconds
"Does this IAM role have * permissions?"	LLM scan	String match on policy document	$0.01+ vs microseconds
"Are there duplicate dependencies in the lockfile?"	LLM analysis	Set intersection on package names	$0.01+ vs microseconds
"Is this endpoint receiving traffic?"	LLM pruning	Log query with timestamp filter	$0.01+ vs standard query cost

Each of these has a deterministic answer. Using an LLM to answer them creates Verification Debt — someone must check the AI's check, because the AI can be wrong. A boolean check on a security group JSON cannot be wrong. A date comparison cannot be wrong. A database lookup against the CVE registry cannot be wrong. Same answer every time. No verification needed. No debt accumulated.

The document prescribes the most expensive instrument for questions that have the cheapest answers. Because the document exists to demonstrate that a frontier model should be used for everything.

"Scan your own code with the same kind of model an attacker would use"

Section 3 prescribes the arms race: "You should scan your own code and systems with the same kind of model an attacker would use, before they do."

This is the most expensive possible security strategy. You scan. They scan. You scan faster. They scan faster. You upgrade to the latest model. They upgrade to the latest model. The cost scales with the speed of both sides. Neither side can stop because stopping means the other side gets ahead.

The declaration approach exits the arms race entirely. Declare what must be true. Verify mechanically. For every declared class, there's nothing for either side to find. You don't need to scan faster than the attacker for vulnerability classes that can't exist by construction.

The arms race has no equilibrium — each side's investment forces the other to invest more. The declaration approach has an equilibrium: each class declared is a class neither side ever spends resources on again. The ratchet makes the equilibrium compound.

The one section that almost gets it right

Section 5 — "Design for breach" — is the strongest because it's the only section that doesn't depend on finding vulnerabilities faster. Zero trust, hardware-bound credentials, short-lived tokens, service isolation by identity. These are architectural controls. They limit blast radius regardless of the vulnerability or how it was exploited.

And buried in section 3: "Prefer memory-safe languages for new code." This is the declaration approach — the language's type system declares "no buffer overflows" and enforces it by construction. Entire vulnerability categories eliminated. Eliminated, by declaration.

But it gets the same weight as "add SAST to your CI pipeline." The single most effective prevention mechanism available — eliminate entire vulnerability categories by construction is listed as one bullet among many, not elevated as the primary strategy.

The document treats prevention as a bullet point and detection as the architecture. The ratio should be inverted.

What's missing — the same three things

1. A declaration layer. No section recommends: "Write the properties your infrastructure must satisfy and verify them mechanically before deployment." The concept that a human could declare "no production database may be publicly accessible" and a machine could verify it on every configuration change — deterministically, at zero token cost is absent from the document.

2. The ratchet. No section recommends: "When you find a vulnerability class, convert it into a permanent machine-enforced rule that prevents the class from recurring." Section 7 mentions postmortems. But a postmortem that produces a document is not a ratchet. A postmortem that produces a declared invariant — checked mechanically on every subsequent change is a ratchet. The document prescribes postmortems. It doesn't prescribe converting them into declarations.

3. The quadrant distinction. The document treats all security as one domain — source code scanning, configuration checking, dependency analysis, alert triage, incident response — all handled by "a frontier model." But source code vulnerabilities, application configuration errors, infrastructure code flaws, and infrastructure configuration posture violations are four different problems with four different instruments:

Application × Code: LLM scanning adds genuine value — novel patterns, complex logic flaws
Application × Configuration: Schema validation and policy checks — deterministic, near-zero cost
Infrastructure × Code: IaC linters and policy engines — deterministic, near-zero cost
Infrastructure × Configuration: Declared invariants against runtime snapshots — deterministic, compound risk across resources

An LLM adds value in one quadrant. Deterministic checks add value in all four. The document prescribes LLMs for all four, because the document is written by the team that builds the LLM.

The structural bias

This document is a product placement.

It's structural. Anthropic's security team is recommending approaches that require Anthropic's model. Every "AI can help" sidebar — and there are eleven of them across seven sections — prescribes "a frontier model" for the task. The document exists to demonstrate that frontier models should be used for security work. Problems that have cheaper, deterministic, more reliable solutions are still framed as LLM tasks — because acknowledging that a three-line policy check is better than a frontier model would undermine the thesis the document exists to support.

This doesn't mean the recommendations are wrong. Many are sound. Patching faster is good. Triaging faster is good. Scanning before shipping is good. But the recommendations are incomplete — systematically, predictably, in the direction that favors the product Anthropic sells.

A complete set of recommendations would include:

Declare what must be true — invariants verified mechanically, at zero token cost, before deployment
Verify deterministically where possible — policy checks, schema validation, type systems for questions with binary answers
Scan with AI where necessary — novel code patterns, complex logic flaws, uncertain questions where probabilistic analysis adds value
Ratchet — every AI finding that represents a known class becomes a permanent declaration, reducing the AI's future workload

That's the three-layer architecture: declare, detect, ratchet. Anthropic's document covers layer two (detect) extensively. It omits layer one (declare) entirely. It doesn't mention layer three (ratchet) at all.

The result: a security program built on these seven sections will scan faster, triage faster, patch faster, respond faster — and never reduce the volume of work, because nothing prevents the vulnerability classes from recurring. Each quarter, Anthropic improves the model. Each quarter, the scan produces more findings. Each quarter, the triage queue grows. Each quarter, the security team needs more AI budget to handle what AI created.

The declaration layer is how you step off the treadmill. It's the section Anthropic didn't write — because it's the section that makes their product less necessary.

This article responds to Anthropic's "Preparing your security program for AI-accelerated offense" (April 2026). The three-layer architecture (declare → detect → ratchet) applied to cloud security in Cloud Computing Is Missing One Component. Everyone Builds the Wrong Five.. The four-quadrant grid (Application/Infrastructure × Code/Configuration) is detailed in The Aftermarket She Diagnosed is the Aftermarket She Prescribed.

The Aftermarket She Diagnosed is the Aftermarket She Prescribed

Bala Paranj — Sun, 21 Jun 2026 06:47:17 +0000

Jen Easterly's Glasswing analysis opens with the sharpest diagnosis of cybersecurity published this decade:

And later:

The diagnosis and the destination is correct.

The prescription doesn't match either one.

What is Glasswing

Anthropic's Project Glasswing finds vulnerabilities in codebases and assists with remediation. In Easterly's own framing, it offers the potential to "identify vulnerabilities more quickly" and "reduce the cost, time, and complexity of fixing them — assist with root cause analysis, generate candidate patches, prioritize risk, and accelerate testing and deployment."

This is the aftermarket she diagnosed, accelerated by AI.

Finding vulnerabilities faster is still finding. Fixing them cheaper is still fixing. Generating candidate patches is still remediating. Every one of these activities happens after the vulnerability exists — in the code, in production, in the codebase of a systemically important financial institution, JP Morgan Chase. The vulnerability was created. It was deployed. It persisted. Then the AI found it.

That's a faster aftermarket. Not the end of the aftermarket.

The cure she named but didn't prescribe

"Security built in upstream, not bolted on downstream." That sentence describes a specific architecture — one that exists today, has been proven for decades, and doesn't require a frontier AI model to implement.

Built in upstream means: declare what must be true before the code is written or the configuration is deployed. "No public S3 buckets in production." "No IAM role may assume cross-account access without MFA." "No API endpoint may accept unauthenticated requests." "No dependency with a known critical CVE may be deployed." These are declarations — human-authored statements of what the system must satisfy, expressed in a form a machine can check.

Not bolted on downstream means: verify the declaration mechanically at the point of creation — before the code ships, before the configuration propagates, before the vulnerability exists to be found. A type checker that prevents buffer overflows at compile time. A policy engine that rejects a configuration violating a declared invariant before it reaches production. A contract test that blocks an API change that breaks a declared interface. These are deterministic verification gates — not models forming opinions, but mechanical checks producing binary verdicts: pass or fail.

The architecture is:

Human declares what must be true (the specification — upstream, slow, requires domain judgment)
Machine verifies every change against the declaration (the gate — downstream, fast, deterministic, on every commit)
The ratchet converts each newly discovered vulnerability class into a new declaration. So the class is permanently prevented, not just found and fixed faster next time

Every safety-critical domain does this:

Domain	Human declares	Machine enforces
Aviation	Pilot sets heading and altitude	Flight computer enforces envelope — prevents unsafe states at machine speed
Nuclear	Engineers declare safety limits	Automated interlocks enforce — shut down the reactor before a human reads the gauge
Trading	Risk managers declare position limits	Pre-trade checks enforce on every order — no order executes unchecked
Software (the cure)	Security team declares invariants	Verification gate checks every change — no deployment violates the declaration

Aviation regulator does not ask a pilot to find envelope violations after the flight and fix them next time. The flight computer prevents the violation from occurring. That's "built in upstream." Glasswing finds the violations after the flight landed and offer to help patch the plane. That's "bolted on downstream" — faster, with AI, but still downstream.

"The same categories of flaws we have seen for decades"

Easterly makes this point herself. It's the most damning evidence for the declaration approach over the discovery approach:

If the vulnerability categories are known, predictable, and preventable — then the declarations can be written today. "No buffer overflow" is a property Rust enforces by construction. "No SQL injection" is a property parameterized queries enforce by construction. "No public S3 bucket" is a property a three-line policy check enforces before deployment. "No cross-account IAM trust without MFA" is a property a CEL predicate evaluates against the configuration snapshot.

These aren't novel problems requiring a frontier model to discover. They're known problems requiring a declaration to prevent. Every vulnerability Glasswing finds in a "predictable, preventable" category is a vulnerability that a declared invariant would have blocked before it existed.

AI that finds a SQL injection in production code is doing useful work. A parameterized query that makes SQL injection impossible by construction is doing better work — at zero token cost, zero remediation time, zero human-in-the-loop overhead.

"Remediation is the real challenge"

Easterly argues that discovery was never the bottleneck — remediation was. Finding the vulnerability is the easy part. Understanding root cause, developing a fix, testing it, ensuring it doesn't break functionality, deploying it across complex systems — that's the hard, expensive, human-heavy part. Glasswing makes that part faster.

This is correct for vulnerabilities that already exist. It's irrelevant for vulnerabilities that were prevented from existing.

A declared invariant that prevents a class of vulnerability at creation time has zero remediation cost. The vulnerability was never created. There's nothing to root-cause, nothing to patch, nothing to test, nothing to deploy. The remediation challenge Easterly correctly identifies disappears, because the declaration made it unnecessary.

The distinction the article misses: the most effective remediation is prevention. The most cost-effective patch is the one that was never needed. The most efficient vulnerability disclosure is the one that never happened because the class was declared impossible.

"Not the end of cybersecurity as a mission"

Easterly's closing is right: even with Glasswing, cybersecurity doesn't end. Even with declared invariants, cybersecurity doesn't end. No finite set of declarations catches everything. This was formalized mathematically by Vassilev's NIST proof (June 2026), extending Gödel's incompleteness theorems to AI and security systems.

The architecture isn't "declare everything and you're safe." It's:

Declare what you know — the known categories, the predictable flaws, the preventable vulnerabilities. These are the classes Easterly herself says we've known about for decades. Declare them. Verify them. Prevent them.
Detect what you don't know — behavioral monitoring, AI-assisted discovery, Glasswing-class tools. These find the vulnerabilities no declaration has been written for yet. This is the aftermarket's permanent role — catching what the declarations don't cover.
The ratchet — every vulnerability the aftermarket discovers becomes a new declaration. The class is permanently prevented. The aftermarket's job shrinks. The declaration layer grows. Each cycle makes the next one smaller.

Glasswing is valuable in layer 2 — discovering what the declarations don't yet cover. But without layer 1, Glasswing runs forever at the same rate, finding the same predictable, preventable categories Easterly says we've known about for decades. With layer 1, Glasswing focuses only on the novel. The classes nobody has declared yet, which is a much smaller, much more valuable set.

When the most credible expert has the same blind spot as the market

Jen Easterly ran CISA — the nation's Cyber Defense Agency. She led the Secure by Design initiative. She pushed the technology ecosystem toward greater security, resilience, and accountability more effectively than anyone in a government role in the last decade. When she writes about cybersecurity, she speaks from deeper operational experience than virtually anyone in the industry.

And she has the same blind spot as every vendor, every framework, and every AI company in the market.

The blind spot is in the mental model the entire cybersecurity industry uses. The frame is: threats exist → find them → fix them → repeat. Defend, detect, respond. The entire discipline — from CISA's mission statement to SOC 2 controls to every vendor's pitch deck — is organized around the reactive cycle.

The declaration approach — declare what must be true, verify mechanically, prevent by construction — comes from a different discipline entirely. Systems engineering. Formal methods. TRIZ. Control theory. Type systems. These disciplines have been preventing failure classes by construction for decades. Aviation doesn't ask pilots to find and fix envelope violations after the flight. Nuclear doesn't ask operators to detect and remediate interlock failures after the reactor event. The prevention frame exists. It's proven. It's been in production for fifty years.

Cybersecurity has never intersected with it. Because the discipline was built as an aftermarket — Easterly said this herself — and the aftermarket frame shapes every prescription that comes out of it. When you've spent your entire career defending, detecting, and responding, every new tool looks like a better way to defend, detect, and respond. Mythos looks like a faster defender. Glasswing looks like a better detector. AI-assisted triage looks like a faster responder. The frame makes everything look reactive — because the frame is reactive.

The declaration layer is invisible from inside the reactive frame. She can't see it — because the frame she operates within doesn't have a category for "make the vulnerability class impossible by construction." The frame has categories for: find it, fix it, contain it, respond to it. Not: prevent it from existing.

This is why the four-quadrant grid, the cost comparison table, the ratchet, and the cross-domain evidence matter. They introduce concepts from outside the reactive frame — from systems engineering, from aviation, from formal methods — that the cybersecurity frame doesn't contain. The argument is: the most capable expert, operating within a reactive frame, will produce a reactive prescription — regardless of how much experience they have. The blind spot is real. The frame explains why it exists. The prescription she's offering to the market reinforces the reactive frame for everyone who follows her lead. When the most credible voice in cybersecurity says "AI will fix this," the industry listens. And the declaration layer — the layer that would eliminate the aftermarket she diagnosed — gets buried under another cycle of faster detection.

The real signal in Glasswing

There's a conflation in Easterly's framing that obscures where the cure applies and where it doesn't.

"Software quality" is four different problems

Easterly frames the crisis as a "software quality problem." That framing collapses four distinct domains into one bucket. Each domain has different discovery mechanisms, different prevention tools, and different verification approaches:

	Code	Configuration
Application	Source code bugs — buffer overflows, SQL injection, logic errors	App-level settings — authentication config, session management, API permissions
Infrastructure	IaC templates — Terraform, CloudFormation, Kubernetes manifests	Runtime cloud config — IAM policies, S3 bucket policies, security groups, network ACLs

Glasswing operates in one quadrant: Application × Code. It finds source code vulnerabilities — the buffer overflows, the injection flaws, the logic errors. That's real and valuable work. It's also one-quarter of the problem.

Mythos reads source code. It reasons about source code. It finds patterns in source code that match known vulnerability classes. It generates patches for source code. Every capability is scoped to one cell of the grid: Application × Code. It cannot evaluate whether your IAM policy grants excessive cross-account access — that's Infrastructure × Configuration. It cannot detect whether your S3 bucket policy combined with your Cognito identity pool creates a privilege escalation path — that's compound risk across Infrastructure × Configuration resources. It cannot verify whether your Terraform template violates your organization's security policy — that's Infrastructure × Code. It cannot check whether your application's authentication configuration matches your security requirements — that's Application × Configuration.

Mythos is the most powerful source code analysis model ever built. Source code is one cell. The grid has four. Three cells where the majority of cloud breaches originate are invisible to it. The hype positions Mythos as the future of cybersecurity. The grid positions it as the future of one-quarter of cybersecurity. The other three-quarters need a different instrument: declared invariants verified against configuration, not a model reading source code.

The DDP Law breach — fined £60,000 by the ICO after a ransomware attack — had root causes exclusively in the Infrastructure × Configuration quadrant: no firewall, no MFA, unpatched systems, a dormant user account active for years. Every root cause was a boolean check against a declared rule. No AI needed. No source code scanning would have found them. They're not code quality problems. They're configuration posture problems, deducible from the infrastructure itself.

Compound cross-resource risk lives at the intersection of quadrants. A Cognito identity pool (Application × Configuration) combined with an IAM trust policy (Infrastructure × Configuration) combined with an S3 bucket policy (Infrastructure × Configuration) creates a privilege escalation path that no single-quadrant tool sees. The risk is in the combination — the edges between resources, not the nodes. Glasswing scanning source code doesn't see it because the vulnerability isn't in any source code. It's in the relationship between three configurations across two quadrants.

The exploit chain doesn't stay in one quadrant

Breaches don't respect quadrant boundaries. A typical 2026 breach crosses all of them:

Infrastructure × Configuration: A slightly over-privileged IAM role — broader trust than intended, never reviewed after the initial setup
Application × Configuration: A misconfigured OIDC provider — authentication settings that permit an unintended flow
Application × Code: A logic flaw that allows session hijacking — the source code vulnerability

Glasswing finds and fixes step 3. Steps 1 and 2 remain a loaded gun. The source code is patched. The IAM role is still over-privileged. The OIDC provider is still misconfigured. The next logic flaw or the next developer who introduces one walks straight through the same infrastructure path because the architecture was never fixed.

This is why configuration risk is a graph problem, not a pattern-matching problem. An LLM reads code and matches patterns against its training data. Configuration risk lives in the relationships between resources — the edges of the graph, not the nodes. "Does this IAM role, combined with this trust policy, combined with this bucket policy, create an unauthenticated path to sensitive data?" is a graph reachability question. You don't need an AI to guess whether a graph is connected. You need a solver to prove it isn't.

Deterministic reasoning engines — CEL predicates, Z3 constraint solvers, Soufflé/Datalog for graph reachability — answer these questions at the correct level of abstraction: mechanically, exhaustively, and with mathematical certainty. An LLM forming an opinion about whether a configuration graph contains a reachable path is using the wrong instrument for the question. The graph either contains the path or it doesn't. That's a computation, not a judgment call.

Intent mismatches live in the gap between what was configured and what was meant. A security group that allows 0.0.0.0/0 inbound on port 22 may be intentional (a bastion host) or a misconfiguration (an application server). No source code scanner can distinguish intent from error — because intent was never declared. A declared invariant ("no production server may accept SSH from 0.0.0.0/0") makes the check trivial and deterministic.

The "software quality problem" framing leads to a "better source code scanning" prescription — which addresses one quadrant and leaves three unprotected. The declaration approach works across all four quadrants:

Application × Code: type systems, memory-safe languages, parameterized queries prevent vulnerability classes by construction
Application × Configuration: schema validation, policy checks verify app settings against declared rules before deployment
Infrastructure × Code: IaC linters (Checkov, tfsec) verify templates against declared policies before apply
Infrastructure × Configuration: declared invariants checked against runtime configuration snapshots — the quadrant no source code tool sees

Glasswing makes one quadrant's aftermarket faster. Declared invariants prevent vulnerabilities in all four quadrants before they exist. Both are needed. Only one of them covers the full surface.

The four-quadrant grid is the best case

The grid above assumes a mature organization where infrastructure is defined as code, configurations are version-controlled, and changes flow through CI/CD pipelines. That's the best case. The reality in most organizations is worse:

ClickOps. Infrastructure configured through the AWS console, Azure portal, or GCP dashboard. No Terraform, CloudFormation or code at all. Someone clicked through a UI to create IAM roles, security groups, S3 bucket policies. The infrastructure exists only as runtime state — not in any repository, not version-controlled, not reviewable by any source code scanner. Mythos cannot scan what was never written as code. The Infrastructure × Code quadrant is empty. Everything lives in Infrastructure × Configuration as runtime state that nobody declared, nobody version-controlled, and nobody can verify without snapshotting the live environment.

Shadow scripts. One engineer wrote a bash script three years ago that rotates credentials, manages DNS, or configures backup policies. It's on that engineer's laptop. It's not in any repo. Nobody else knows it exists. When that engineer leaves, the script keeps running or stops running and nobody knows until something breaks. This is undeclared intent: someone had a reason for the script, but it was never expressed in a form anyone else can verify.

Tribal knowledge. "Dave knows how the production database failover works." "Sarah set up the VPN configuration." "The security group on the legacy account was configured by someone who left in 2023." The configuration exists. The intent behind it is gone. Nobody can distinguish a deliberate security exception from a forgotten misconfiguration, because the intent was never declared.

Manual configuration drift. An engineer configured a security group correctly through IaC six months ago. Last Tuesday, someone opened port 22 through the console during an emergency and never closed it. The IaC template says the port is closed. The runtime state says it's open. No source code scanner sees the drift — because the drift isn't in the source code. It's in the gap between declared state (IaC) and actual state (runtime configuration).

In these environments, which are most environments, the four-quadrant grid overstates the problem's tractability. Mythos's limitation isn't just "one quadrant out of four." It's "one quadrant out of four, and in many organizations, there is a fifth quadrant that exists because the infrastructure was never written as code in the first place. This is the invisible case: shadow IT."

The declaration layer becomes even more critical in these environments. A declared invariant — "no production security group may allow 0.0.0.0/0 inbound on port 22" — can be checked against a snapshot of the runtime state regardless of whether the configuration was applied through Terraform, the AWS console, a shadow script, or a manual change nobody documented. The invariant doesn't care how the configuration got there. It checks whether the configuration satisfies the rule. That's the only verification mechanism that works when the source of truth is the runtime environment, not a codebase Mythos can scan.

"Defenders must understand root cause, develop a fix, test it"

Easterly frames the remediation challenge as: understand root cause → develop a fix → test it → ensure it doesn't break functionality → deploy across complex systems. She then argues AI will make each step faster. This frames the defender's job as a diagnostic chain — understand, then act.

Viable systems don't work this way.

A thermostat doesn't understand thermodynamics. It compares temperature to setpoint and acts. An aircraft interlock doesn't understand aerodynamics. It detects a parameter exceeding a limit and overrides the pilot. A circuit breaker doesn't understand electrical engineering. It senses current exceeding a threshold and trips.

A viable system regulates itself in a changing environment without fully understanding the cause of failure. It doesn't need root cause analysis to prevent damage. It needs declared boundaries and the ability to act when they're violated. The root cause analysis happens later by humans, at human speed, for learning and improvement. But the system was already protected because the boundary was declared and the response was mechanical.

This is the primary function of any control system: regulate, then understand — not understand, then regulate. Easterly's framing inverts the order. She says defenders must first understand, then fix. The viable-system model says: first prevent the damage (the declared boundary catches the violation mechanically), then understand the cause (humans analyze at human speed for future improvement).

The ratchet connects both: the human's understanding — gained after the fact, at human speed — becomes a new declared boundary that prevents the class from recurring. The system didn't need to understand the cause in real time. It needed the boundary. The understanding came later and made the boundary set grow.

Glasswing accelerates the "understand, then fix" chain. Declared invariants eliminate the need for the chain entirely — for every class that's been declared. Both have a role. But positioning AI as the solution to the remediation bottleneck assumes defenders must always understand before they act. Viable systems act first and understand later.

AI cannot solve problems that require deterministic answers

There's a deeper issue with Easterly's prescription that the four-quadrant grid exposes: she's proposing a probabilistic tool for problems that require deterministic answers.

An LLM reading source code and forming an opinion about whether it contains a vulnerability is probabilistic. It's pattern-matching against training data. It can be wrong. It can miss vulnerabilities. It can hallucinate vulnerabilities that don't exist. Its verdict is an opinion with a confidence score, not a proof.

The problems in three of the four quadrants don't need opinions. They need verdicts:

"Does this IAM policy grant cross-account access without MFA?" → Yes or no. Deterministic. Computable from the policy document. No model needed.
"Does this S3 bucket allow public read access?" → Yes or no. Deterministic. Computable from the bucket policy. No model needed.
"Does this Terraform template create a security group with 0.0.0.0/0 inbound on port 22?" → Yes or no. Deterministic. Computable from the template. No model needed.
"Does the combination of this Cognito pool, this IAM trust policy, and this S3 bucket policy create an unauthenticated path to sensitive data?" → Yes or no. Deterministic. Computable from the three configurations. No model needed — but requires compound reasoning across resources.

Using an LLM to answer questions that have deterministic answers is using the wrong instrument. It's measuring temperature with a poem instead of a thermometer. The poem might be approximately right. The thermometer is exactly right. Every time. At a fraction of the cost.

This creates what should be called Verification Debt: when you use a probabilistic tool to answer a deterministic question, you need a human to check the AI's check. The AI says "this S3 bucket is probably public." A human must verify: is it actually public? The AI says "this IAM role probably has excessive permissions." A human must verify. Each probabilistic answer generates a verification task for a human — which is the review bottleneck Easterly was trying to eliminate. The declaration approach eliminates the debt entirely: "no public S3 buckets" is checked mechanically, produces a binary verdict, and requires zero human verification. The violation is either present or it isn't. No probability. No debt.

AI has a role: the uncertain questions. "Is this code pattern likely to cause performance issues under load?" "Does this API design follow security best practices?" "Is this error handling sufficient for production use?" These are judgment calls where a model's pattern-matching adds value because there's no deterministic answer.

But Easterly's prescription doesn't distinguish between questions that have deterministic answers and questions that require judgment. She prescribes AI for both. The result: an expensive, probabilistic tool answering questions that a three-line policy check answers definitively — while the three-line policy check doesn't exist because nobody built the declaration layer.

"Reduce the cost, time, and complexity of fixing them"

Let's take Easterly's claim at face value and score it against the alternative:

Metric	AI-assisted remediation (Glasswing)	Deterministic prevention (declared invariants)
Cost per check	$0.01–$0.50 per LLM call (model inference, token cost, API overhead)	$0.0001 or less (a policy evaluation is CPU microseconds, no API call, no tokens)
Time to resolution	Minutes to hours (find → root cause → generate patch → test → deploy)	Zero. The vulnerability was never created. There is nothing to find, root-cause, patch, test, or deploy.
Accuracy	Probabilistic — can miss vulnerabilities, can hallucinate false positives, requires human validation	Deterministic — same input, same answer, every time, no validation needed
Scales with volume	Cost scales linearly with codebase size and scan frequency	Cost is near-constant — adding a new invariant costs one declaration; checking it costs microseconds per evaluation
Handles compound risk	Poorly — LLMs reason about one file at a time, not across resource relationships	Natively — Deterministic engines (CEL, Z3, Soufflé, Datalog) are built for compound reasoning across configurations
Reduces to zero	Never — AI always has a nonzero error rate and nonzero cost per scan	Approaches zero for every declared class — each invariant eliminates its class permanently

AI reduces cost, time, and complexity. Deterministic prevention eliminates them — for every class that has been declared. Reduce and eliminate are different words with different outcomes and different economics.

Easterly says "for the first time, AI offers the potential to reduce the cost, time, and complexity of fixing them." For three of the four quadrants, deterministic approaches already beat AI on all three metrics — at a fraction of the cost, at zero time (prevention, not remediation), and at zero complexity (a boolean check, not a diagnostic chain). AI cannot reduce time to zero because it operates after the vulnerability exists — finding and fixing takes time regardless of the speed of AI. Prevention reduces time to zero because the vulnerability never exists. There is no time between "vulnerability created" and "vulnerability fixed" when the vulnerability was never created.

The economics are stark: an organization running Glasswing against a million lines of code pays for every scan in tokens. An organization running declared invariants against configuration snapshots pays microseconds of CPU per evaluation. The first cost scales with volume. The second is near-constant. At enterprise scale — millions of lines, thousands of configurations, continuous scanning — the cost difference is not marginal. It's orders of magnitude.

AI has a role in quadrant one (Application × Code) where the questions are complex — buffer overflows in novel code patterns, logic errors in unfamiliar architectures, zero-day vulnerability classes nobody has declared yet. That's real value. But prescribing AI for all four quadrants — including the three where deterministic checks produce better results at near-zero cost is prescribing the most expensive instrument for problems that have the cheapest solutions.

The Silver Bullet Fallacy

Easterly's article makes one argument: Mythos has arrived. It will solve cybersecurity.

This is the silver bullet. The single technology that eliminates the problem. Fred Brooks named this fallacy in 1986: "There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement in productivity, reliability, or simplicity." Forty years later, the argument repeats with a different technology name.

Cybersecurity is a software quality problem → Mythos finds and fixes software quality issues → therefore Mythos solves cybersecurity. Each step sounds reasonable. The chain is broken.

Step one is correct but incomplete. Cybersecurity is four different quality problems across four quadrants, not one. Mythos addresses one quadrant.

Step two is correct but narrow. Mythos finds and fixes source code issues. It cannot find configuration posture issues, compound cross-resource risk, or intent mismatches — because those aren't in source code.

Step three doesn't follow. A tool that addresses one-quarter of the problem cannot solve the whole problem, regardless of how powerful it is within that quarter. A perfect source code scanner running on the DDP Law infrastructure finds zero issues. Because every vulnerability was in configuration, not code. The infrastructure is breached while the scanner reports all clear.

Every silver bullet in cybersecurity history followed the same arc:

Era	The silver bullet	What it actually addressed	What it missed
2000s	Firewalls	Network perimeter	Application-layer attacks, insider threats
2010s	SIEM	Log correlation and alerting	Prevention, configuration posture
2015s	Cloud-native scanners (CSPM)	Individual resource misconfiguration	Compound risk, intent mismatches
2020s	AI-powered detection (XDR, CDR)	Behavioral anomaly detection	Deducible configuration violations
2026	Mythos/Glasswing	Source code vulnerabilities	Configuration posture, compound risk, intent verification — three of four quadrants

Each generation solved one class of problem and was marketed as the solution to all classes. Each generation's limitation became the next generation's market opportunity. Mythos is following the same pattern — powerful in its quadrant, blind to the other three, marketed as the answer to cybersecurity.

The alternative to a silver bullet is a complete system. Not one tool that does everything. Five elements, each serving its function, each covering its quadrant. The specification layer declares what must be true across all four quadrants. The verification gate checks every change deterministically. The behavioral detection layer (where Glasswing lives) catches what the declarations don't yet cover. The ratchet converts each discovery into a new declaration. The casing enforces boundaries and prevents accumulation.

No single element solves cybersecurity. No single tool covers all four quadrants. No single model — however powerful — replaces the declaration layer, the verification gate, and the ratchet. The silver bullet is always the same fallacy: one element elevated to the status of a complete system. Mythos is a sub-system. It's not the system.

The honest counter-point — and the synthesis

There's a reason Glasswing is popular in 2026: humans are bad at declaring.

Writing CEL predicates for a multi-cloud environment is difficult. Authoring Rego policies across hundreds of AWS services is error-prone. Maintaining a corpus of invariants that covers every configuration pattern an organization deploys requires sustained effort that most security teams don't have the bandwidth. The declaration layer should exist. In most organizations, it doesn't — because declaring is hard.

This is Easterly's implicit argument: AI will handle the mess because the declarations don't exist. If nobody is going to write the invariants, then a model that finds the violations is the next best thing. That's a legitimate position — pragmatic, grounded in the reality that most organizations don't have the discipline or capacity to build a complete declaration layer.

But it concedes the aftermarket permanently. If the declarations never get written, the model runs forever — finding the same predictable, preventable categories Easterly says we've known about for decades. The system never learns. Each scan is a new expense. Each finding is a new remediation task. The treadmill runs at AI speed instead of human speed, but it's still a treadmill.

The synthesis of both positions is the ratchet — and Mythos has a role in it:

Use AI to generate the deterministic invariants that then render the AI unnecessary for that class of bug.

Mythos finds a SQL injection pattern → a human reviews the finding → the finding becomes a declared invariant ("no concatenated SQL in database queries") → the invariant is enforced deterministically on every commit → Mythos never needs to find that class again. Mythos finds an over-privileged IAM role → a human reviews the role → the finding becomes a declared invariant ("no IAM role may have * permissions on production resources") → the invariant is checked against every configuration snapshot → Mythos never needs to find that class again.

Each cycle: AI discovers, human reviews, declaration is authored, deterministic gate enforces. The AI's workload shrinks. The declaration layer grows. The cost of verification drops toward zero for every class that's been declared. The AI focuses on the new classes nobody has declared yet — which is a smaller, cheaper, more valuable set each cycle.

This is the role Easterly should be prescribing for Glasswing: not the permanent solution, but the discovery engine that feeds the declaration layer. Glasswing finds. Humans declare. Deterministic gates enforce. The ratchet turns. Each cycle permanently reduces what Glasswing needs to find. That's not "the beginning of the end of cybersecurity as we know it." It's the beginning of cybersecurity as it should have been built: human judgment upstream, machine enforcement downstream, AI in the middle discovering what hasn't been declared yet and getting less necessary every cycle.

The real signal

Easterly frames Glasswing as "a signal of something far more consequential: a shift in how we might fundamentally reduce cyber risk at scale." She's right that it's a signal. But the signal isn't "AI can find and fix bugs faster." The signal is: if the most powerful AI model in the world is finding the same categories of preventable vulnerabilities that have existed for decades, then the problem was never discovery and the solution is not better discovery.

The solution is what she said in her opening paragraph: security built in upstream. Declared invariants verified at creation time. The aftermarket reserved for what the declarations can't cover — which, as the declarations grow, becomes an increasingly small set.

Glasswing is the best aftermarket tool ever built. The declaration layer is how you stop needing it for the classes you already know about. Both exist. Both are needed. Only one of them ends the cycle Easterly correctly diagnosed. And it's the one she described in her opening and didn't prescribe in her conclusion.

References: Jen Easterly's Glasswing analysis (LinkedIn, June 2026); Anthropic, Project Glasswing; Vassilev, NIST/IEEE Security and Privacy (June 9, 2026) — mathematical proof that no finite set of guardrails is universally robust. The three-layer architecture (declare → detect → ratchet) applied to cloud security in Cloud Computing is Missing One Component. Everyone Builds the Wrong Five.

The Viability Test Every AI-Dev Architecture Fails

Bala Paranj — Sat, 20 Jun 2026 11:37:43 +0000

This article builds on the harness response article The Harness is Half the Architecture. The five-element framework draws from TRIZ's Law of System Completeness (Altshuller, extended by Savransky and Mann), applied here to AI-assisted development.

The law underneath the diagnosis

A previous article argued that the dominant agent architecture — "Agent = Model + Harness" is missing its other half: independent verification, declared intent, coordination protocols, and subtraction discipline. The Harness is Half the Architecture

That article diagnosed the gaps. This one prescribes the architecture. A structural law about what a working system requires, drawn from a framework that analyzed millions of patents to identify what makes engineered systems viable.

A working system has five essential elements. If any element is missing, the system does not work. If any element fails, the system does not survive. You cannot trim an essential element to ship faster. You can only replace it with something that serves the same function. Deleting it produces a non-viable system — which is the current agent architecture state.

The five elements are not new ideas. They've been identified independently across three separate fields — engineering (TRIZ), cybernetics (Beer's Viable System Model), and economics (Nalebuff and Brandenburger's value-net model). Three frameworks built from different data, arriving at the same five-part structure. That convergence is evidence the decomposition is real, not an artifact of one school's vocabulary.

Elements of a Viable System

The five-element template is not an architecture. It is a completeness law — a domain-neutral blueprint of the elements any viable system must contain. TRIZ calls it a Law, Beer calls it a Viable System Model, Nalebuff and Brandenburger call them the elements of a game. Aviation calls the same structure envelope protection. Nuclear calls it defense in depth. Control theory calls it a closed-loop regulator. None calls it an architecture.

A specific realization — fly-by-wire, reactor interlocks, pre-trade risk checks, or the AI-dev stack below — is an architecture: one way to instantiate the five elements. So the claim here is not "here is the right architecture" but the stronger, testable one:

This matters because "our architecture is better" invites "says who?" But "the viability invariant that seven unrelated domains already satisfy, and your architecture doesn't" is a different kind of claim. It's falsifiable: show the two missing elements are present, and the claim falls. Nobody has shown that, because they aren't present. This includes comparison of the current AI architecture by OpenAI, Anthropic and LangChain.

The five elements of a complete AI-dev system

Every working engineered system has these five elements. Let's take a look at these elements for AI-assisted development.

1. The Tool — the model

The model is the working tool. It's the value-adding primary activity. The thing that produces the artifact. Code, infrastructure templates, documentation, tests. This is the focus of the harness article and the industry invests in it most aggressively.

In the current architecture, the model is treated as the system. Everything else is "harness" — support infrastructure for the primary component. The law says otherwise: the tool is one of five. Tool is not the system. It is not even the most important element. A working tool without a control unit is a machine that produces output nobody can verify. A working tool without an engine is a machine that runs without direction. The model is essential. It is not sufficient.

2. The Engine — declared intent

The engine is the driving force. In AI-assisted development, the engine is the specification — the human-authored declaration of what correct means, what the system must satisfy and the intent behind the work.

Without a specification, generation is undriven. The model produces output, but toward what? A prompt is a proto-specification. It has intent in it, but it's ephemeral, ambiguous, and discarded after use. A specification is durable, precise, versioned, and mechanically checkable. It's the difference between telling someone what you want once in conversation and writing it down in a contract both parties can refer.

The engine powers implementation. The spec drives generation. Without it, the model runs but goes nowhere — which is the failure mode of "vibe coding," where generation feels productive but the output doesn't converge toward a defined target because no target was defined.

3. The Transmission — delivery and contracts

The transmission carries the engine's energy to the tool's output. In AI-assisted development, the transmission has two layers:

The delivery rail — CI/CD, GitOps, Infrastructure as Code. The mechanism that moves a change from commit through build to deploy. This is the part most teams have, and have well. It's fast, automated, and reliable.

The contract layer — machine-readable contracts, schemas, interface definitions, and structured exports between agents. When multiple agents work on a shared codebase, the transmission between them isn't a shared filesystem — it's declared constraints each agent's output must satisfy. Coordination through specifications, not shared state.

The transmission is present in most current architectures. It works. That's the problem — a fast, reliable transmission with no control unit faithfully delivers unverified changes at machine speed. CI/CD without a verification gate is the postal service delivering bombs with perfect reliability. The transmission isn't broken. The control unit that should ride on it is absent.

4. The Control Unit — the independent oracle

The control unit measures output against the specification, issues a deterministic verdict, and feeds corrections back into generation. This is the element the current architecture is missing.

The control unit is not the model reviewing its own output. Self-verification is correlated with the generator's blind spots — Huang et al. (ICLR 2024) established that it degrades rather than improves reasoning. The control unit must be independent of the generator and must operate at a higher level of logical certainty than the tool it verifies. You don't verify a bridge with a poem — you verify it with physics. You don't verify probabilistic output with another probabilistic system — you verify it with a deterministic one: a type checker, a property-based test suite, a contract enforcer, a CEL predicate evaluator, a Z3 proof — anything that is mechanical, deterministic, and uncorrelated with the model's failure modes.

It's bidirectional, not just a gate. The oracle doesn't merely pass or fail output. It feeds corrections back into generation — the generate → verify → fix loop. A failed assertion tells the model what failed and why, steering the next generation attempt toward the specification. The control unit governs the tool; it doesn't just inspect the output.

It operates on the transmission, not beside it. Verification isn't a separate pipeline. It's a gate that attaches to the CI/CD rail. Every change that travels the transmission passes through the oracle. Strip the gate and the transmission faithfully delivers unverified changes. The oracle rides the rail.

5. The Casing — boundaries and continuity

The casing is the connection between the system and its environment. In AI-assisted development, it has two faces:

Boundaries — Parnas-style information hiding, hexagonal architecture, module isolation. The casing around each component that prevents agents from reaching across boundaries into modules they don't own. Without boundaries, agents cross them at the first opportunity, and the system loses the architectural integrity that makes independent verification possible.

Continuity — the stance that the system assumes its own incompleteness and compensates through continuous monitoring and update. Vassilev's NIST proof (June 9, 2026) formalized this: no finite set of rules is universally robust. The casing holds the system against an adversarial, changing environment — not by claiming completeness, but by continuously expanding coverage and accepting that gaps will always exist.

The casing also includes the subtraction discipline — the boundary between what belongs in the system and what dilutes it. Scope management. Named essence. The force that prevents accumulation from becoming bloat. This isn't trimming an essential element (the law forbids that). It's trimming scope and features to keep the system coherent — the difference between removing a brake system (non-viable) and removing a feature that blurs the product's identity (increased ideality).

In practice, this is the power to say no — and in 2026, it's a cost-of-survival issue, not a design preference. Agentic bloat — where agents add ten thousand lines to solve a ten-line problem — is a major driver of spiraling inference bills. Every unnecessary line generated is tokens burned, surface area expanded, and verification load increased. A casing without subtraction is a system that accumulates indefinitely, and the bill for that accumulation arrives monthly in the inference invoice. The subtraction discipline is the element that bends the cost curve: less generated, less verified, less maintained, less attacked.

The diagnosis using the law

Map the current "Model + Harness" architecture against these five elements:

For diagrams, refer: https://gist.github.com/sufield/3d511936af9f80914f7e8622e0e0b1cb

Strong and Present:

Tool (the model) — heavily invested, rapidly improving, the focus of the industry.
Transmission (CI/CD) — mature, fast, reliable. Most teams have this.

Strong and Absent:

Control Unit (independent verification) — the system strongly needs it but it's completely absent. Replaced by self-verification, which is not verification. The most critical missing element.

Weak and Absent:

Casing (boundaries + continuity) — both poorly understood and absent. No enforced module boundaries for agents, no continuous-monitor stance, no subtraction discipline. The industry doesn't yet recognize this element needs to exist.

Weak and Present:

Engine (intent/specification) — present as prompts and AGENTS.md files, but ephemeral and not mechanically checkable. A proto-engine, not a real one.

Per the law: if any element is missing, the system does not work. The current architecture has a powerful tool, a fast transmission, and a weak engine — but no control unit and no casing. By the law's definition, it is an incomplete system. It produces output. It cannot verify that output is correct. It cannot maintain architectural integrity over time. It cannot distinguish what belongs from what dilutes.

The Law of Non-Uniform Evolution names which element lags and why: subsystems evolve at different rates. The tool (generation) evolved fastest — models improved dramatically in capability, speed, and cost. The transmission (CI/CD) was already mature. The engine (specification) is emerging but weak. The control unit (verification) barely exists. The casing (boundaries) is absent. The system's capability is constrained by its weakest element, not its strongest. This is the reason why a more powerful model makes the problem worse, by generating more unverified output faster.

The complete architecture

  Developer                                                            Deployed
   Intent ──────► ENGINE ────────► TRANSMISSION ────────► TOOL ──────► Software
  (spec,          (spec-            (CI/CD,              (model,
   contracts,     driven             GitOps,              generation)
   invariants)     dev)              contracts)
                                        │
                                        │ ◄── CONTROL UNIT rides the rail
                                        │     (oracle: verify, gate, steer)
                                        │
                          ┌─────────────┴─────────────┐
                          │ CASING                    │
                          │ boundaries, continuity,   │
                          │ subtraction, drift guards │
                          └───────────────────────────┘

The model generates. The specification drives generation toward a declared target. The transmission delivers changes. The oracle verifies each change against the specification before it passes — and feeds corrections back when it doesn't. The casing holds the system's architectural integrity against the environment and against its own tendency to accumulate.

Every element is a peer. None serves the model. Each serves the system. A failure in any one is a failure of the system's primary function — producing correct, intent-aligned software — regardless of the strength of the other elements. The model's excellence cannot compensate for an absent oracle, any more than a powerful engine compensates for failed brakes.

Multiple agents at once — the concurrency test

The five-element law asserts completeness for one agent. The case that matters in practice is N agents editing the same system simultaneously — the scenario the harness article lists as "an open research problem." The completeness law answers it, and the answer is simpler than the framing of "orchestrating hundreds of agents" suggests.

The core principle: agents don't overwrite each other's progress because they never work on the same thing. The problem is decomposed so each agent works independently on a bounded task, owns a bounded module, and communicates with other agents only through interfaces. This is Parnas's information hiding applied to agents: program to an interface, not to an implementation. Each module has a contract. Agents produce output that satisfies their module's contract. New functionality composes through the interfaces. Existing features are reused, not rewritten.

This is not a new idea. It's the same decomposition discipline that makes microservices, Unix pipelines, and library ecosystems work: bounded units, declared interfaces, composition through contracts. The reason it looks like an "open research problem" in the harness frame is that the harness frame has no specification layer — and without declared interfaces, agents have no boundaries, so they inevitably step on each other. The solution isn't a smarter orchestrator. It's the boundaries and contracts that make orchestration unnecessary.

Every web developer has already experienced it at work. A frontend team and a backend team start a project on the same day. Nothing exists yet — no frontend, no backend. They work in parallel from day one, independently, without overwriting each other's progress. How? They agree on the REST API contract first. The frontend team builds against the contract. The backend team builds behind it. Neither needs to know how the other works. Neither can corrupt the other's module. They compose through the interface. When both sides are done, the system works — not because someone orchestrated their keystrokes, but because both sides satisfied the same contract.

Replace teams with agents and the architecture is identical. Agent A builds the backend behind the API contract. Agent B builds the frontend against it. They don't coordinate through a shared filesystem. They don't need an orchestrator watching both. They compose through the declared interface. The "open research problem" of multi-agent coordination is a problem every engineering organization solved the moment they split work across teams with a contract between them. The only reason it reappears as unsolved for agents is that the harness frame has no concept of a contract.

The five elements map onto this directly:

Shared Engine = the coordination protocol. All agents target the same declared spec. The spec defines the interfaces, the module boundaries, and the contracts. Agents conform to one shared set of declarations rather than negotiating with each other.

Deterministic Transmission = coordination through interfaces, not shared state. Agents communicate by producing structured output through declared interfaces — never by writing to a mutable shared blackboard where concurrent writes race. Same input produces byte-identical output. Every contribution is provenance-tracked and diffable. Parallel agents are safe because they're separated by interfaces, not competing on shared files.

Per-agent Control + meta-level oracle on the composed result. Each agent verifies its own output against its module's contract. The meta-level oracle is the safety net: it verifies the composed result — the assembled system after all agents' outputs are integrated through their interfaces — against the cross-cutting invariants that no single module's contract can express. Compound reasoning, transitive closure, cross-resource path analysis. This catches the one thing decomposition alone can't: two modules each satisfying their own contract but composing into a system that violates a cross-cutting property.

Boundaries = mechanical isolation. Enforced at build time, module boundaries mean agents on different modules physically cannot corrupt each other. Drift guards stop agent A from re-introducing what agent B deleted.

Why it scales. N agents = N viable five-element sub-systems, each owning a bounded module behind an interface. The system of agents is itself a viable system one recursion level up, held together by the shared spec and composed through the declared interfaces. You don't orchestrate them imperatively. You decompose the problem, declare the interfaces, and let each agent self-regulate against its own contract.

What it guarantees and what it doesn't. It guarantees consistency: no globally-invalid composed state ships, because agents can't overwrite each other (decomposition) and the composed result is verified against cross-cutting invariants (meta-level oracle). It does not guarantee throughput: agents may contend on interface definitions or serialize at the composition gate. The law yields a viable multi-agent system, not an optimal-throughput one — throughput is a separate optimization layered on top. And there's one hard dependency: the meta-level oracle must reason across the composed output (compound, transitive), and the spec must be expressive enough to encode the cross-module invariants.

Agents don't need orchestration. They need decomposition, interfaces, and contracts — the same things that make any modular system work. The missing piece was never a smarter coordinator. It was the specification layer that defines the boundaries agents work within.

Why the harness frame can't discover this

"Agent = Model + Harness" is "the tool plus everything else." That frame was a transitionary metaphor from an era that assumed the model was the center of the universe and everything else existed to serve it. In 2026 we know better: the contract is the center of the universe. The model is one element — the tool — in a system whose viability is determined by the spec it builds against, the oracle that verifies it, and the boundaries that contain it. The harness frame collapses four distinct elements — engine, transmission, control unit, casing — into one subordinate category. It guarantees under-investment in three of them, because the frame only has vocabulary for "things that serve the model." The control unit doesn't serve the model — it governs it. The casing doesn't serve the model — it contains it. The engine doesn't serve the model — it drives it. None of these are discoverable from inside a frame that asks "what does the model need?" They're only discoverable from a frame that asks "what does the system require to produce correct software?"

The law answers that question: five elements, each present, each a peer, each essential. That's the complete architecture. Everything else is an incomplete system generating output it cannot verify, toward a target it hasn't declared, inside boundaries it doesn't enforce — at machine speed.

You might ask: the architecture is clear, but can it work at the scale the industry is building toward — hundreds of agents, billions of tokens, thousands of changes a day? The honest answer: the architecture is correct, and performance is an optimization layered on top of a correct architecture. That's the right order. Optimizing an incorrect architecture — self-verification with no independent oracle, shared filesystem as coordination, no specification to verify against — is optimizing the wrong thing faster. The teams treating multi-agent coordination as an "open research problem" aren't stuck on performance. They're stuck on the architecture — because the frame they're working in has no vocabulary for the two elements that solve it. The engineering challenge of making a compound-reasoning oracle fast enough for production scale is real work. It is not research. It is the kind of engineering that happens after the architecture is right, not before.

The system does not care who sits in the Tool slot. It does not care if a human is typing code at a keyboard or an agent is generating it without touching one. The five elements are the same. The interfaces are the same. The contracts are the same. The verification is the same. The boundaries are the same. A viable system requires an Engine, a Transmission, a Tool, a Control Unit, and a Casing — regardless of whether the Tool is a person or a model. That is why the solution was already known: every organization that successfully coordinates human teams through contracts, interfaces, and independent review has already built a complete system. Replacing the human with an agent doesn't change the architecture. It changes the speed. And speed without the other four elements is the definition of the problem, not the solution.

The completeness law: Altshuller's Law of System Completeness (TRIZ), extended by Savransky (fifth element: casing) and Mann (comparison with Beer's Viable System Model and Nalebuff/Brandenburger's Co-opetition). The independent convergence of three frameworks on the same five elements is the evidence the decomposition is structural. The recursion property (every viable system contains viable sub-systems) is Beer's contribution and grounds the multi-agent concurrency treatment. Applied here to AI-assisted development; applied separately to cloud security posture in Cloud Computing is Missing One Component. Everyone Builds the Wrong Five.

The Agentic Development Manifesto

Bala Paranj — Fri, 19 Jun 2026 10:40:23 +0000

Manifesto for Agentic Development

We are uncovering better ways of building software with AI agents. Through this work we have come to value:

Declared intent over inferred behavior

Verified properties over reviewed code

System coherence over unit throughput

Named essence over accumulated features

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agentic Development Manifesto

Our highest priority is to deliver software whose correctness can be demonstrated mechanically, by a verifier independent of the generator. The tool that wrote the code cannot be the oracle that confirms it is correct.
Specifications, contracts, and invariants are the coordination protocols for agents. Without them, more agents means more conflict, not more throughput.
Welcome changing requirements — but version the specification before changing it. Agents working against different versions of the truth produce split-brain systems.
The most reliable gate on AI-generated code is not a human reading it but a machine verifying it against declared properties. Human judgment belongs upstream — in deciding what correct means — not downstream in reading what a model produced.
A specification that no one enforces is a wish. Enforcement is mechanical or it is absent. CI is the only reviewer that never skips a check under deadline pressure.
Code is a liability; capability is the asset. Measure properties verified, not lines generated. A codebase that grows without a corresponding growth in verified properties is accumulating unmanaged risk.
The best architectures, requirements, and designs emerge from teams that know which problems are deducible and which are emergent — and refuse to apply the wrong method to either.
Working software is necessary but not sufficient. Working software that satisfies declared invariants is the measure of progress.
Simplicity — the art of maximizing the amount of work not generated — is essential. The near-zero cost of generation makes disciplined subtraction more valuable, not less.
When you can name what your product essentially is, delete what dilutes it — including working code. A product becomes stronger by getting smaller when what remains is the essence.
The best agent-assisted teams maintain two distinct practices: rigorous process for the unit (the spec, the skill, the bounded task) and probe-sense-respond for the system (integration, observation, human judgment at the seams). Neither substitutes for the other.
At regular intervals, the team asks not "how much did we generate" but "how much uncertainty did we retire, and how much of what we built belongs."
Moving human judgment upstream does not mean abandoning the ability to go deep. When mechanical verification fails — and it will — the human must still be capable of understanding the system well enough to diagnose what no gate caught. Judgment that cannot descend into detail is not judgment; it is hope.

The Agile Manifesto was a cure for rigidity — rigid processes, slow delivery, organizations that couldn't adapt. It solved those problems. The Agentic Development Manifesto is a cure for chaos — cheap generation, scarce verification, and systems that grow faster than any human can comprehend. Different era, different disease, different medicine. The problems the Agile Manifesto solved are not the problems we have.

Cloud Computing is Missing One Component. Everyone Builds the Wrong Five.

Bala Paranj — Thu, 18 Jun 2026 11:32:05 +0000

Your car has an engine, a transmission, wheels, a steering wheel, and a cruise control. Remove the cruise control and the car still drives — but YOU become the cruise control. You watch the speedometer, compare it to the speed limit, and adjust the pedal. The car is functionally complete. You're the missing component.

Cloud computing works the same way. It has engines: Lambda, Kubernetes controllers, Terraform apply. It has transmission: CI/CD pipelines, GitOps, APIs that carry intent to infrastructure. It has tools: cloud APIs that touch resources. It has an interface: the CLI, the console, the IaC files.

What it's missing is the control unit — the component that senses the current state, compares it to the declared intent, and signals when they diverge. Without it, YOU are the control unit. You read the AWS console, compare it to what you intended, and file a Jira ticket when something's wrong.

The cloud is a car without cruise control. You're the speedometer, the comparator, and the pedal.

Except it's worse than that. A car travels at 70 mph. A human can react at 70 mph — the speed mismatch is manageable. Cloud infrastructure operates at the speed of packets traveling through fiber: a misconfigured IAM role is exploitable the instant it's deployed. A public S3 bucket is discoverable by automated scanners within minutes. A credential leaked to a public repository is harvested by bots in seconds.

The human control unit operates at the speed of: read an email alert (minutes), open a dashboard (minutes), triage the finding (minutes to hours), decide if it's real (hours), open a Jira ticket (minutes), assign it to a team (hours), wait for the fix (days), verify the fix (hours).

Infrastructure speed:    Misconfiguration exploitable in seconds
Scanner speed:           Finding appears in minutes to hours
Human speed:             Triage → decision → fix → verify in days

The gap between exploitation and correction: days to weeks
The gap between deployment and exploitation: seconds

The human isn't just the weakest link in the control loop. The human is incapable of being the control unit for a system that operates at this speed. It's a physics problem — biological response time cannot match electronic propagation speed. Asking humans to be the comparator for cloud infrastructure is like asking a pedestrian to be the cruise control for a jet.

This is a losing system by design. Because the system assigned the control function to the one component that can't operate at the system's speed.

And speed is only the first disqualification. Humans have at least four structural limitations that make them unsuitable as control units for cloud infrastructure:

They get tired. Alert fatigue is not a metaphor — it's a biological response. After the 50th alert in a shift, the human stops reading them. The 51st alert is the one that matters. The control unit stopped functioning three hours ago.

They're not available. The infrastructure runs at 3am on a Saturday. The human doesn't. The misconfiguration deployed at 3:07am is exploitable by 3:08am. The human reads the alert at 9am Monday. The system was uncontrolled for 54 hours.

They have skill gaps. Cloud IAM has 17,000 actions. No human knows all of them. The misconfiguration that composes a Cognito identity pool, an IAM trust policy, and an S3 bucket policy requires expertise across three services. The engineer who deployed the Cognito pool doesn't understand S3 bucket policies. The engineer who wrote the bucket policy doesn't understand IAM trust chains. The compound risk lives in the gap between two engineers' knowledge — and neither one sees it.

They don't compose. A human reviewing one finding can assess it. A human reviewing 200 findings cannot mentally compose them to detect that findings #47, #112, and #189 form a compound attack path. The composition requires evaluating every pair and triple of findings for shared trust relationships. For 200 findings, that's 1.3 million triples. The human reviews them sequentially. The control unit must compose them simultaneously.

A thermostat doesn't get tired. It works at 3am. It knows exactly one thing (is the temperature different from the setpoint?) and it knows it perfectly. It composes with other thermostats without coordination. It is the simplest possible control unit — and it's more reliable than any human at the one job it does.

Cloud security needs a thermostat, not a more alert human.

The thermostat your cloud doesn't have

Your home has a furnace, ductwork, and vents. Without a thermostat, you're the control system — you feel cold, walk to the furnace, turn it on, feel warm, turn it off. The furnace works. The ducts work. The vents work. You're the missing component.

Now imagine someone sells you a smart thermometer — it measures the temperature and beeps when it's too cold. You still walk to the furnace. You still turn it on. You still decide when to turn it off. The thermometer added a sensor but didn't close the loop. You're still the control system. You just have a louder alarm.

That's what every cloud security product is today. A thermometer with an alarm — relabeled as a thermostat. Scanners sense the current state. Dashboards display findings. Alerts fire in Slack. The vendor calls this "continuous monitoring" and "automated response." But the human still triages the alert, decides if it's real, figures out what to do, opens a Jira ticket, assigns it to a team, waits for the fix, and re-scans to verify. An alert is not control. An alert is notification that control is absent. The product added a sensor and a speaker. The loop is still open. The human is still walking to the furnace.

A thermostat is different. It has three things a thermometer doesn't: a setpoint (72°F — what you DECLARED), a comparator (is the current temperature different from the setpoint?), and a signal (tell the furnace to act). You declare your intent once. The system closes the loop. You're out of it.

Thermometer with alarm (today's scanners):
    Sensor: "it's 58°F"  →  Alert: "it's cold!"  →  Human decides  →  Human acts

Thermostat (what's missing):
    Setpoint: 72°F  →  Sensor: 58°F  →  Comparator: divergence  →  Signal: furnace ON
    No human in the loop.

Cloud infrastructure has the furnace (Lambda, Kubernetes — they execute), the ductwork (CI/CD, APIs — they carry changes), and the vents (cloud resources — they touch the environment). Every security product adds a better thermometer — more sensors, louder alarms, prettier dashboards. But the human is still walking to the furnace.

What's missing is the thermostat: the component that knows what you want (declared invariants), measures what you have (observed state), compares them deterministically (evaluation), and signals the correction path (exit codes that CI/CD acts on). Declare your intent once. The pipeline enforces it on every push, every PR, every scheduled run. The human declared the setpoint. The system closes the loop.

Stave as thermostat:
    Setpoint: 2,650 invariants (declared once)
    Sensor: observation snapshot (captured by existing collectors)
    Comparator: stave apply → exit 0 (matches) or exit 3 (diverges)
    Signal: CI/CD pipeline blocks the merge, triggers rollback, fires alert
    Human: declared intent once → out of the loop

That's the missing component. A thermostat that closes the loop.

The five components every system needs

There's a law in systems engineering — TRIZ's Law of System Completeness. This law establishes the number and functionality of the principal parts of any autonomous technological system.

Component	What it does	Car example
Engine	Source of energy, authority, or purpose	Internal combustion engine
Transmission	Converts engine output into a form the tool can use	Gearbox + driveshaft
Tool	The part that contacts and changes the environment	Wheels on road
Interface	Surface through which a human supplies intent	Steering wheel + pedals
Control unit	Senses, compares, and corrects — closes the loop	Cruise control + ABS + traction control

A system missing any component can't operate autonomously. A human (or another system) must supply the missing part. As the system evolves, each missing part gets internalized, until the system is complete and operates independently.

Where cloud computing is stuck

Cloud evolved four of five components over the last fifteen years:

Phase	What emerged	Cloud example
Phase 0	Human is the whole system	Hand-written scripts, manual deploys, manual safety checks
Phase 1	Transmission emerged	APIs, CI/CD, GitOps, IaC — carry intent but don't judge it
Phase 2	Engine emerged	Lambda, Kubernetes controllers, Terraform apply, IAM policy engine — execute instructions but don't judge correctness
Phase 3	Control unit — still missing	Humans remain the primary verifier

TRIZ identifies this sequence as a universal pattern in the evolution of technological systems: human components are dislodged in a predictable sequence — transmission first, engine second, control last. Transmission is dislodged first because it requires the least autonomy — carrying things from A to B is a mechanical replacement. Engine is dislodged second because execution requires more autonomy but still follows instructions. Control is dislodged last because it requires the most autonomy — it must sense, compare against declared intent, and decide whether the output is correct. That last step requires something no mechanical replacement can infer: what the human meant. Until the human declares intent in a form the machine can evaluate, the human remains the control unit by default. Cloud computing is stuck at the point this law predicts: transmission and engine are fully mechanized, and the human is still the comparator, because control requires declared intent, and the industry hasn't built the declaration layer.

Visualised as the five-component system:

System Completeness

The mismatch is predictable from the law: when the Engine and Transmission exist but the Control unit doesn't, propagation is fast but detection is slow. Changes deploy globally in seconds. The human who should have caught the misconfiguration finds out hours or days later — if they find out at all.

This explains every recurring pattern in cloud security: breaches that persist for months before detection. Misconfigurations that propagate across regions before anyone notices. Drift that accumulates because nobody's comparing the current state to the declared intent continuously.

The cloud has a powerful engine and a fast transmission connected to nothing that checks whether the output is correct.

The obvious fix and why it's an illusion

The obvious fix: build a product that internalizes all five components. A single platform that collects, evaluates, remediates, and monitors. Every cloud security vendor claims this:

Vendor product (claims all five):
    Engine:       Built-in rule engine         ← exists
    Transmission: Built-in collectors          ← exists
    Tool:         Built-in remediation         ← claimed
    Interface:    Built-in dashboard           ← exists
    Control:      Continuous monitoring loop   ← claimed

Look closer at Control and Tool. What vendors call "continuous monitoring" is alerting — sense and notify. An alert is not control. An alert is notification that control is absent. The thermometer beeps. The human walks to the furnace. The vendor labeled the beep "control."

What vendors call "remediation" is auto-fix for a handful of simple cases — disable a public bucket, rotate a key. For anything compound, ambiguous, or risky, the remediation is: open a Jira ticket. A Jira ticket is not remediation. It's a request for a human to remediate. The vendor labeled the ticket "tool."

Strip the labels and look at what happens when a finding fires:

Vendor "control loop" in practice:
    1. Scanner detects misconfiguration          (sense — real)
    2. Dashboard shows finding                   (alert — not control)
    3. Alert fires in Slack                      (louder alert — still not control)
    4. Human triages alert                       (human is the comparator)
    5. Human decides if it's real                (human is the decision-maker)
    6. Human opens Jira ticket                   (human initiates correction)
    7. Another human fixes it days later         (human is the actuator)
    8. Scanner re-scans to verify                (sense again — loop took days)

That's not a control loop. That's a notification pipeline with humans at every decision point. The "Control" component in the vendor's five-component claim is a sensor relabeled as a controller. The "Tool" component is a ticket system relabeled as an actuator.

The cloud isn't stuck between Engine and Control because vendors haven't built Control. It's stuck because what vendors CALL Control is alerting — and alerting is the symptom of missing control, not the solution.

The resolution: supply only the missing piece

The cloud already has four of the five components:

Engine:        ✅  Lambda, Kubernetes, Terraform, IAM policy engine
Transmission:  ✅  CI/CD, GitOps, APIs, IaC
Tool:          ✅  Cloud APIs that touch resources
Interface:     ✅  CLI, console, IaC files
Control:       ❌  Missing — humans are the comparator

Four components exist and are mature. They don't need to be rebuilt inside a security product. They need to be CONNECTED to the missing fifth component.

The missing component isn't a product. It's a function: sense the current state, compare it to declared intent, signal when they diverge. Sense → Compare → Correct.

Split that function across the boundary:

Control sub-step	Who supplies it
Sense (capture current state)	The operator's existing collectors — Steampipe, AWS Config, Terraform state, custom exporters
Compare (evaluate against declared intent)	The missing piece — a deterministic comparator that reads observations and evaluates invariants
Correct (act on the divergence)	The operator's existing CI/CD — GitHub Actions, Jenkins, ArgoCD, PR review, ChatOps

The only component that doesn't already exist in the operator's environment is the comparator. Everything else — the collectors that sense, the CI/CD that corrects, the cloud APIs that act — is already running.

Supply the comparator. Connect it to what exists. The five-component system is complete — assembled from the operator's existing stack plus one new binary, not rebuilt from scratch inside a monolith.

What the comparator looks like

# Sense: the operator's existing collector captured a snapshot
ls observations/
# s3-2026-05-16.obs.json  iam-2026-05-16.obs.json

# Compare: the missing piece — deterministic evaluation
stave apply --observations ./observations --now 2026-05-16T00:00:00Z
# Exit 0 = intent matches reality
# Exit 3 = divergence found (12 findings, 3 compound chains)

# Correct: the operator's existing CI/CD acts on the result
# GitHub Action blocks the PR. ArgoCD triggers rollback. Slack alert fires.

The comparator is a pure function: files in, findings out. It doesn't collect (the operator's Steampipe does that). It doesn't remediate (the operator's CI/CD does that). It doesn't monitor continuously (the operator's cron job or GitHub Action schedule does that). It COMPARES — the one function the cloud was missing.

The system completeness map

TRIZ component	Inside the comparator	In the operator's existing stack
Engine	2,650 controls + 585 chains (declares what must be true)	—
Transmission (consumer)	Adapters that read observation JSON	—
Transmission (producer)	—	Steampipe, AWS Config, custom collectors
Tool	—	Cloud APIs, Terraform, Kubernetes, CI/CD
Interface	CLI with exit codes + JSON output	—
Control: Sense	—	Collector cron jobs, on-commit triggers
Control: Compare	`stave apply`, `stave diff`, `stave gaps`	—
Control: Correct	—	GitHub Actions, Jenkins, ArgoCD, PR review

The complete system exists. It's just not a single product. The comparator supplies the missing component — the Engine (what must be true) and the Compare step (does reality match). Everything else was already running.

Why this is better than vertical completeness

Property	Vertically complete product	Comparator + existing stack
Credentials	Required — the product collects and remediates	Not required — the comparator reads files
Blast radius	Unbounded — the product modifies infrastructure	Zero — the comparator can't change anything
Failure modes	Many — daemon, agent, dashboard, API connections	One — the binary crashes (and it's a pure function, so restart it)
Lock-in	Total — replace the product, replace everything	Minimal — replace the comparator, keep your collectors and CI/CD
Adoption cost	Deploy the product, integrate every layer	Add one step to existing CI/CD
Component reuse	None — the product rebuilds what you already have	Full — uses your existing Steampipe, your existing CI/CD, your existing cloud APIs

The vertically complete product rebuilds four components that already exist so it can supply the fifth. The comparator supplies the fifth and connects to the four that exist. Same completeness. Fraction of the mechanism.

The reconciliation loop you don't have to build

The original design for this architecture was vertically complete. A Kubernetes-style reconciliation loop that would sense, compare and correct. Declared invariant → observed infrastructure → API calls to fix violations → loop.

It was cut. Kubernetes proves the pattern works. It was cut because the remediation half requires understanding what "fix" means for every resource type, needs credentials to act, and has unbounded blast radius when the "fix" is wrong.

Removing the remediation loop accidentally produced a better architecture. The comparator is a pure function: deterministic, reproducible, composable, provable. A reconciliation loop with API calls is none of those things — it has side effects, race conditions, and blast radius.

The operator's existing CI/CD is the remediation loop. It's battle-tested. It has rollback. It has approval gates. It has audit trails. Rebuilding it inside a security product would be worse than using it.

Supply the missing component. Don't rebuild the components that already work.

Tips for Founders

If you're building a developer tool and find yourself rebuilding components your users already have — their CI/CD, their monitoring, their cloud access, their change management — stop and ask: which component is missing?

The TRIZ Law of System Completeness says: a system needs five components to operate autonomously. It doesn't say: one product must contain all five. The five components can span multiple systems. The product's job is to supply the MISSING one and connect to the rest.

A well designed product is the one that does one thing the ecosystem can't do — and trusts the ecosystem for everything else. The messiest product is the one that rebuilds the ecosystem inside itself so it can control every layer.

Cloud computing is missing a control unit. Supply the control unit. Don't rebuild the engine, the transmission, the tool, and the interface inside it.

The comparator described here — 2,650 controls, 585 compound chains, deterministic evaluation, exit codes for CI/CD, no credentials, no network, no persistent state — is Stave, an open-source Risk Reasoner. It supplies the missing component. Your existing stack supplies the rest. Try it: bash examples/demo-ai-security/run.sh

Review is the Symptom. Specification is the Fix.

Bala Paranj — Wed, 17 Jun 2026 10:19:27 +0000

Addy Osmani published Agentic Code Review the most data-rich assessment of the AI code-review crisis to date. The Faros numbers are: 861% more code churn, defect rates from 9% to 54%, review duration up 441%, and zero-review merges up 31%. Because reviewers simply could not keep pace. The GitClear finding distills the whole problem into one ratio: 4x the code for 10% more delivered value.

The diagnosis is correct. Writing got cheap. Understanding didn't. The bottleneck moved to verification. Every number confirms it.

The prescription — review better, review smarter, tier by risk, run heterogeneous AI reviewers, keep the human on the merge button is sound operational advice for the world as it exists right now. Teams should follow it. It will help.

It is also a human-scale solution to a machine-scale problem. Generation runs at machine speed. Review runs at human speed. No amount of improving human review closes a gap where one side accelerates and the other is fixed. The article's own data proves this: review duration up 441% because humans can't read faster, zero-review merges up 31% because humans gave up. They're signs that review as a primary verification mechanism has hit a ceiling that better process cannot raise. You cannot solve a machine-scale problem with human-scale approaches.

Solving the problem at symptom level

The article accepts that agents generate code at 4x volume and asks: how do we review it? Every solution flows from that question — triage, tiering, AI-assisted review, smaller PRs, circuit breakers for high-maintenance changes.

The question it never asks: why is 4x code being generated before anyone declared what correct means?

If 4x the code produces only 10% more delivered value, then roughly 75% of what was generated and what reviewers must now process produced no value at all. That is a generation problem. The article proposes a better filter instead of asking why the generation volume is high.

A specification — a human-authored declaration of what the output must satisfy, checked mechanically does two things the review-centric model cannot:

For developers who find "specification" abstract: you already do this when you write a type signature, a property-based test, a schema, a contract test, or an interface definition. Formal methods, type-driven development, design-by-contract — these are the established disciplines that make specifications concrete and enforceable. The idea is not new. Applying it as the primary verification mechanism for agent-generated code is new.

This is not the 200-page requirements document from the waterfall era that was obsolete before anyone wrote a line of code. It failed because it was a human-readable document that machine did not enforce. Written once and never updated, separated from the code it described. Specification here is the opposite in every dimension: small, mechanical, enforceable declarations that live in the code and run on every commit. A type signature is a specification. A contract test is a specification. A property assertion is a specification. An interface definition is a specification.

They're in the repo, versioned and run in CI. They fail the build when violated. They don't go stale because they execute. They don't get ignored because the machine enforces them. The waterfall specification was a document humans were supposed to read. This specification is a constraint machines are required to check. Same word, opposite mechanism, opposite failure mode.

Agile's core contribution was the fast feedback loop: build a small increment, get feedback immediately, adjust. A type check that fails on commit is a faster feedback loop than a human reviewer who takes 441% longer to respond. A contract test that runs in CI on every push is a faster feedback loop than a code review that gets skipped 31% of the time. Machine-enforced specifications are Agile's fast-feedback principle applied at the architectural level — tighter loops, faster signals, every commit, no exceptions. The waterfall specification failed because it was slow feedback. This specification succeeds because it is the fastest feedback in the system.

It constrains generation before code exists, so the agent builds toward a declared target rather than generating plausible-looking output that a human must later evaluate for intent.
It enables mechanical verification at machine speed, so the deducible questions ("does this satisfy the contract?") are answered by a deterministic gate, not by a human reading diffs.

Review is required when you have no specification. It is the manual, expensive, tiring reconstruction of intent that was not written down. The article's own best insight — that agent code lacks intent and the reviewer must reconstruct it is one sentence away from the fix: write the intent down first, as a specification, and verify against it mechanically. The article reaches for decision logs on PRs. The fix is specifications before generation.

4x the code is the subtraction discipline's absence, measured

The GitClear number — 4x output, 10% more value is the most important figure in the article, and the article underreads it.

If you generate four times the code and only a tenth of it produces additional value, you have an accumulation problem, not a review problem. Every unnecessary line generated is: tokens burned, review time consumed (the 441% increase), churn created (the 861% increase), and defect surface expanded (the 9%-to-54% jump). The review crisis is downstream of the generation crisis. Better review cannot fix it because the input volume is the cause.

The alternative is the subtraction discipline: maximize the work not generated. A specification that declares what correct means constrains the agent to produce what's needed — not plausible-looking code that a human must evaluate. Fewer lines generated means fewer lines to review, fewer defects to catch, less churn to manage, and lower inference cost. The article's own numbers prove the case for specification-first development more than they prove the case for better review.

Review is not verification

The article treats review as the verification layer. That conflation is the heart of the problem.

Review is a human reading code and forming a judgment. It is subjective, it is tiring, it scales at human reading speed which the article correctly notes has not changed since we started staring at screens. It produces opinions, not verdicts. Verification is a deterministic check of output against a declared property. It does not fatigue, it scales at machine speed, and it produces verdicts — pass or fail, the same answer every time, reproducible on demand.

The article's data proves the distinction: review duration up 441% because humans can't read faster. Zero-review merges up 31% because humans gave up trying. A verification gate — a type checker, a property-based test suite, a contract enforcer would not have slowed down. It would have checked every PR, at machine speed, against declared properties, without increasing review time, fatigue or "zero-verification merges" because a machine doesn't skip checks.

The article mentions CI and tests but treats them as support for review — the wall that holds while humans do the real work. The inversion the data demands is: verification is the primary gate. Review is for the questions verification can't answer. Deducible questions (does this satisfy the contract, does this match the type, does this violate an invariant) go through the deterministic gate. Only the questions that require human judgment (is this the right change to build, does this architectural choice make sense, is this the right abstraction) go to a person.

That split is required to survive the volume. Not by reviewing 4x code 441% slower. By routing the deducible questions to a machine that handles them at machine speed, and reserving human attention for the uncertain questions that require it.

The underlying design principle is separation in space: the system needs both human judgment and machine speed, but not in the same step. Humans in the enforcement loop are the weakest link. They get tired, skip and slow to 441% of baseline. Machines in the judgment loop are the weakest link. They lack business context, they can't declare intent, they confidently agree with their own errors. The resolution is to separate them in space: humans upstream, declaring intent and providing the judgment that no model has the context to make. Machines downstream, enforcing the declared intent at machine speed on every change, without fatigue, without skipping, without the 31% zero-review collapse. Slow and fast, each where they belong. The human's value is not reading diffs — it is deciding what correct means. The machine's value is not forming opinions — it is enforcing declared properties mechanically, on every commit, at the speed generation demands. Mixing them in the same step — a human reading machine-speed output line by line — is the contradiction the 441% number measures.

When a human does review, when judgment is required on something the machine can't yet check that judgment doesn't have to stay human-scale. Every insight a reviewer produces that can be expressed as a rule becomes a specification the machine enforces on every future commit. The human catches it once. The machine catches it forever after. Each review cycle permanently shrinks the pool of things requiring human judgment and permanently grows the pool of things mechanically enforced. Review stops being a recurring cost and becomes a one-time investment that compounds — each human judgment, once converted to a specification, never needs to be made again. The system gets smarter over time without getting slower.

This is not a novel design. Every domain that hit the same wall — machine speed exceeding human capacity to review and approve — arrived at the same separation. The pattern is a blueprint, not an opinion:

Domain	The speed problem	Human role (slow, upstream)	Machine role (fast, downstream)
Aviation	Flight dynamics exceed human reaction speed	Pilot declares intent (heading, altitude, approach)	Flight computer enforces envelope protection — prevents unsafe states at machine speed, regardless of pilot input
Nuclear	Reactor dynamics too fast for human monitoring	Engineers declare safety limits (technical specifications)	Automated interlocks enforce limits — shut down the reactor before a human could even read the gauge
Trading	Trades execute in microseconds	Risk managers declare position limits and loss thresholds	Pre-trade risk checks enforce on every order at machine speed — no order executes unchecked
Manufacturing	Assembly lines too fast for human inspection of every unit	Engineers declare tolerances (specifications)	Automated quality gates measure and reject — sensors enforce what a human eye cannot keep up with
Autonomous vehicles	Vehicle moves faster than human reaction time	Engineers declare safety constraints (maintain distance, stay in lane)	Control systems enforce at sensor speed — every millisecond, not every glance
Software (2026)	Agents generate code faster than humans can review	Human declares intent as specification	Deterministic gate verifies every commit against declared properties at machine speed

In every case the solution is the same: remove the human from the enforcement step where they are the bottleneck, and move them to the declaration step where they provide irreplaceable judgment. The machine enforces what the human declared. No aviation regulator asks a pilot to read every control-surface adjustment and approve it. No nuclear regulator asks an operator to review every sensor reading and sign off. They declare the envelope. The machine enforces it. The same separation that made fly-by-wire safe, reactors survivable, and trading non-catastrophic is the separation software has not yet made — and the 441% review-duration increase is the cost of not making it.

Missing intent is a specification problem

The article's best insight is that agent-generated code lacks intent. The reviewer is "the first human being to ever lay eyes on this code," and they must reconstruct a rationale that was never written down. The article frames this as a tooling problem — capture the agent's reasoning as a decision log on the PR, and the reconstruction cost disappears.

That is a step in the right direction and one step short of the fix.

A decision log captures the agent's reasoning about how it implemented the task. It does not capture the human's judgment about what the task should have produced. The agent's reasoning is about its choices — why this data structure, why this API call. The intent that matters is upstream: what did the human want this change to accomplish, what properties must it satisfy, what invariants must it preserve?

That intent, captured as a specification before generation begins, does two things a decision log cannot:

It gives the agent a declared target — not "implement this feature" (a prompt) but "the output must satisfy these properties" (a spec). The agent generates toward a known target rather than producing plausible output a reviewer must evaluate.

It gives the verification gate something to check against. A decision log helps a reviewer understand. A specification lets a machine verify. The 441% review-duration increase exists because reviewers are doing manually, per-diff, what a specification-and-verification system would do mechanically, per-commit, at machine speed. In a specification-first world, the human's job is requirement engineering — declaring what correct means, what properties must hold, what invariants the system must satisfy. Not reading diffs. Not checking syntax. Not reconstructing intent from code. Defining intent before code exists, in a form machines can enforce.

Heterogeneous AI review is still models reviewing models

The four-reviewer experiment — 93.4% non-overlapping findings across CodeRabbit, Greptile, Sentry Seer, and Cursor BugBot is interesting data. Different tools catch different bugs. Heterogeneity helps. The article correctly argues for running multiple reviewers with different strengths.

But heterogeneous AI review is still probabilistic review of probabilistic output. Huang et al. (ICLR 2024) established that models cannot self-correct reasoning without external feedback and that performance can degrade after self-correction. The article acknowledges the risk — "broadly correlated blind spots, especially when they come from the same family, confidently agreeing in the same places" — and calls it "borrowed confidence."

The fix for borrowed confidence is not more diverse models. It is a different kind of instrument — one that is deterministic, independent of all generators, and checks output against declared properties rather than forming an opinion about it. A type checker doesn't have blind spots correlated with GPT-5. A contract enforcer doesn't fatigue. A property-based test doesn't "confidently agree" with the generator — it either passes or fails, based on properties a human declared.

AI reviewers are useful. Run them. They catch real bugs. But they are sensors, not oracles. The oracle is the specification plus the deterministic gate. The sensors help. The oracle decides.

The loop is closing — and nobody is asking what's inside it

The article describes "loop engineering" — automating review into the generation loop so an agent writes, a judge agent reviews, and the loop continues. The article correctly identifies the risk: a closed loop of models with no human anywhere is "borrowed confidence" where "the system's certainty becomes yours, and nobody actually understood anything."

The proposed fix: "the human moves up a level."

But moving the human up doesn't fix the closed loop — it just means the human sees less of what the loop produces. The loop is still models reviewing models. The models still have correlated failure modes. The output is still probabilistic. The verdicts are still opinions.

What fixes the loop is introducing an element that is not a model: a deterministic verification gate inside the loop, between iterations, checking each iteration's output against declared properties before the next iteration builds on it. If iteration three violates a property, the gate catches it before iterations four through twenty compound the error. That is not a model reviewing a model. It is physics checking the bridge.

The article's data proves this is needed. The Faros numbers — 861% churn, 242.7% more incidents — happens when the loop runs without a deterministic gate. The code churns because nothing mechanically prevents it from drifting. The incidents rise because nothing mechanically verifies correctness between iterations. Better review inside the loop doesn't fix it, because review already failed to scale.

Writing got cheap. Understanding didn't. Specification makes understanding durable.

The article's closing line is right: "your job is to deliver code you have proven to work." But proving code works is not the same as reviewing it until a person feels confident. Proof requires a declared standard (the specification), a mechanical check (the verification gate), and a reproducible verdict (pass or fail, same answer every time).

Review is how you prove things when you have no specification. It is the most expensive, least scalable, most error-prone way to establish that code is correct. It is the only option when nobody declared what correct means. The moment you declare it — as a type, a contract, a property, an invariant — the deducible portion of the review burden transfers to a machine that handles it at machine speed, without the 441% slowdown, without the zero-review merges, without the borrowed confidence of models agreeing with models.

The article's data is the best evidence published this year that the review-centric model is collapsing under the weight of machine-speed generation. The fix is not better review. It is making the intent explicit before generation, so that verification — mechanical, deterministic, tireless — can do the work that review was never built to do at this volume.

Writing got cheap. Understanding didn't. But understanding doesn't have to be reconstructed from every diff by a tired reviewer at 441% the old cost. It can be declared once, up front, as a specification and then verified mechanically, at machine speed, on every change, forever. That is how you make understanding scale with generation. Everything else is a more expensive way to not keep up.

This is a direct response to Addy Osmani's article on code review in the age of AI agents (2026). The data in that piece is the best in the field and the diagnosis is correct. The gap is in the prescription: review-centric solutions treat the downstream symptom while the upstream cause — generating code before declaring what correct means — continues unchecked. The formal basis: Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet" (ICLR 2024). If you think review scales to machine-speed generation without a specification layer underneath it, that's the specific disagreement worth having.

Predict, Don't Enumerate — But What About the Questions that Have Answers?

Bala Paranj — Tue, 16 Jun 2026 09:07:12 +0000

Michael Roytman's "Predict, Don't Enumerate" makes a well-argued case that the security industry's approach to vulnerability management is broken. Static severity scoring (CVSS) can't survive the volume of findings that AI-powered discovery is producing. EPSS — a predictive model that estimates the probability a vulnerability will be exploited in the next 30 days — is a better signal for triage. Anthropic endorsing it publicly matters because it makes a private consensus visible. The policy recommendations (rewrite SLAs by exploitation probability, change what the board sees, invest in telemetry feedback loops) are sound operational advice.

All of that is correct. If you're running a reactive vulnerability management program and triaging a backlog, EPSS is a better tool than CVSS for deciding what to fix first. You should use it.

The issue is what the article frames as the end state and what that framing makes invisible.

Knowing is not better predicting

The article borrows a distinction from Dan Geer and Dave Aitel: a "pointing machine" enumerates findings without understanding context; a "knowing machine" understands how code behaves in a particular environment and recognizes what turns a hazard into a risk. It then maps "knowing" onto prediction — EPSS as the clearest example of a knowing machine.

But prediction is not knowing. A prediction is a better-grounded guess. EPSS returns a probability — a statement about what attackers are likely to do across the internet in the next 30 days. It's useful. It's a better signal than a severity score. It is still a guess. A sophisticated, data-driven, continuously-updated guess. But a guess about attacker behavior, not knowledge of your system's state.

A knowing machine, in any honest reading of Geer and Aitel's distinction, would know whether a path exists from the internet to your customer database through your actual configuration. That's not a prediction. It's a deducible fact about a configuration graph. It's either there or it isn't, and determining which doesn't require a model trained on global exploitation patterns — it requires traversing the graph of your own infrastructure.

The article redefines "knowing" as "better predicting" and presents the evolution as complete: from pointing (enumerating by severity) to knowing (predicting by exploitation probability). But there's a third category the article never considers — verifying — and it answers a different kind of question entirely.

Two kinds of questions, two kinds of answers

The security questions a team faces aren't all the same kind of question, and they don't all have the same kind of answer.

Genuinely uncertain questions: Will this vulnerability be exploited in the next 30 days? Is this anomalous login a credential theft? Is this traffic pattern an attack? These depend on attacker behavior, which is unknowable in advance. The honest answer is a probability. Prediction is the right tool. EPSS belongs here.

Deducible questions: Does our configuration violate our own rules? Does a path exist from an unauthenticated entry point to sensitive data through our actual trust relationships? Does this IAM policy grant a combination of permissions that creates a privilege-escalation vector? These are fully determined by the configuration itself. The answer isn't a probability — it's a verdict. The path either exists or it doesn't. The policy either violates the rule or it doesn't. Determining which is a computation, not a forecast.

The article's framework sees only the first kind. Its entire pipeline — find vulnerabilities, predict which ones matter, fix those — is built for uncertain questions and gives useful answers to them. But it routes deducible questions through the same prediction pipeline, and that's where certainty gets thrown away.

A compound misconfiguration that creates an unauthenticated path to sensitive data is wrong regardless of whether EPSS gives it a high exploitation probability. It's wrong by construction, provably, from the configuration alone. If no attacker has exploited that class of misconfiguration in the last 30 days, EPSS assigns it a low score. The prediction model says it's low priority. The configuration says it's a breach waiting to happen. The prediction is correct about attacker behavior and silent about system state — because system state isn't what prediction models measure.

This is the gap. Not a flaw in EPSS. A category error in routing every security question through a prediction framework, including the questions that have definite answers.

The reactive assumption

The article's entire flow is reactive: scan → find → prioritize → remediate. The improvement it offers is better prioritization — react to the right things, in the right order, based on exploitation probability rather than severity scores. That's a real improvement to a reactive pipeline.

But it's still a reactive pipeline. The vulnerabilities exist in production. The findings pile up. The team triages. The question is always "which of these existing problems should we fix first?" — never "does our configuration satisfy the rules we declared before these problems existed?"

The proactive alternative — verify configuration against declared invariants before deployment, so violations never reach production to become findings in the first place is not considered. The article improves how fast and accurately you react without ever asking whether the reaction loop is the right architecture.

For the genuinely uncertain questions, a reactive loop is the only option. You can't proactively prevent an exploitation you can't predict. But for the deducible questions, the reactive loop is a choice, not a necessity. You can verify, before deployment, that your configuration doesn't create the compound paths, the permission escalations, the policy violations. You can catch them when they're configuration errors, not when they're findings in a backlog.

A team that verifies deducibly-wrong configurations before deployment and uses EPSS to prioritize the uncertain remainder has a smaller backlog, a higher signal-to-noise ratio on the findings that remain, and fewer tokens spent on remediating things that should never have existed. A team that routes everything through prediction treats the deducible and the uncertain identically, and pays for it in volume, triage time, and remediation churn.

Local context is deducible, not predictable

The article correctly identifies that global prediction isn't enough — you need local context: asset inventory, topology, reachability, deployed controls. Then it proposes training a local model on that context to produce enterprise-specific probabilities.

But most of what it lists as "local context" isn't uncertain. It's your own configuration. Asset inventory is a fact. Topology is a fact. Reachability through your trust relationships is a graph computation. Whether a control is deployed is a boolean. These aren't inputs to a prediction model — they're inputs to a deterministic verification. You don't need a model to tell you whether a path exists from the internet to your database through your network configuration. You need a graph traversal. The answer is a fact, not a forecast.

Training a model on your own configuration to predict your own risk is routing a deducible question through a prediction framework. It produces a probability where you could have had a verdict. The probability might be correct. But it's less than what was available — and less than what an auditor, a regulator, or a board should accept when the definitive answer was computable.

The article says "a scanner can't tell apart" two organizations with the same CVE but different exposure. That's true of a scanner that checks one setting at a time. It's not true of a tool that evaluates the full configuration graph — reachability, trust relationships, permission chains — deterministically. The distinction isn't between global prediction and local prediction. It's between prediction (however localized) and verification (however comprehensive).

The volume argument proves too much

The article's strongest argument is volume: AI-driven discovery is producing orders of magnitude more findings, the count will grow, and human-scale triage can't keep up. Therefore: predict, prioritize, and fix what matters.

This is correct for the uncertain portion of the backlog. But the volume argument also proves the case for verification, not just prediction — and the article doesn't notice.

If the volume of findings is growing exponentially, then the cost of triaging, prioritizing, and remediating them is also growing exponentially. Every finding in the backlog costs triage time, prediction-model compute, and remediation effort. A finding that was deducibly preventable — a configuration violation that verification would have caught before deployment — is a finding that should never have entered the backlog. Every such finding that does enter the backlog is triage time, prediction compute, and remediation effort spent on something that had a definitive answer and didn't need a probability.

Verification reduces the input to the prediction pipeline. Fewer deducibly-wrong configurations reach production → fewer findings enter the backlog → the prediction model's job gets smaller and its signal-to-noise ratio improves. Prediction and verification aren't alternatives. Verification makes prediction tractable at the volumes the article is worried about.

The article frames the future as "more findings, better prediction." The sustainable version is "fewer preventable findings (because verification caught them) and better prediction for the remainder (because the backlog is smaller and cleaner)." The first version scales cost linearly with findings. The second bends the curve.

The Vassilev connection the article should have made

The article cites Jonathan Spring's work tying vulnerability enumeration to the halting problem — for any sufficiently complex system, there are always more undiscovered flaws. That's correct research, correctly cited. But the article draws a narrow conclusion: since you can't enumerate all flaws, predict which ones matter.

Vassilev's NIST proof (June 9, 2026), extending Gödel's incompleteness theorems to AI systems, says prediction via finite rules is also incomplete. No finite model — no matter how well-trained, how localized, how continuously updated — catches everything. The prediction model has a ceiling for the same mathematical reason the enumeration model has a ceiling: both are finite systems operating over unbounded spaces.

The conclusion neither Spring nor Vassilev's proofs support is "so we need a better prediction model." The conclusion they do support is: since neither enumeration nor prediction can be complete, the system must assume its own incompleteness and compensate through continuous verification against declared properties — exactly Vassilev's prescribed "continuous-monitor-and-update" model.

Verification doesn't escape Gödel either — no finite set of invariants catches every misconfiguration. But each invariant it does check, it checks definitively. And the catalog grows. That's the architecture Vassilev prescribes: not universal robustness (formally unattainable) but continuous expansion that raises the cost of finding the next gap for the attackers. Vassilev's prescribed economic equilibrium is explicitly about making the cost of finding new exploits exceed the attacker's resources.

The direction that leads somewhere better

The article's recommendations are good operational advice for the reactive model. Here's what they look like when you add verification:

Rewrite the SLA — yes, by exploitation probability for the uncertain findings. But also add a verification tier: deducibly-wrong configurations that violate declared invariants get a different SLA entirely, because they don't need prediction — they have verdicts. A compound misconfiguration that creates a path to sensitive data is not "priority based on exploitation probability." It's a configuration violation, deterministically identified, with a known remediation.

Change what the board sees — yes, exploitability-weighted exposure for the prediction-managed portion. But also show verified posture: how much of our configuration is within declared invariants, where are the gaps, what percentage of the deducible risk surface is covered? That metric is deterministic, reproducible, and auditable — which is what boards and regulators want.

Invest in telemetry — yes, the feedback loop between prioritization and exploitation is essential for the prediction model. But also invest in the specification layer: the declared invariants that define what the configuration must satisfy. A prediction model without specifications triages findings. A verification engine with specifications prevents them.

Fix the compliance conversation — yes, move from severity to probability for the uncertain findings. But also offer the auditor something no probabilistic model can: a deterministic verdict that a specific configuration satisfies a specific rule, reproducible on demand, same input same output. Auditors don't want probabilities for questions that have answers. They want the answer.

The future isn't "predict, don't enumerate." It's verify what's deducible, predict what's uncertain, and know the difference. Prediction is the right tool for attacker behavior, which is unknowable in advance. Verification is the right tool for configuration posture, which is fully determined by your own infrastructure. Routing deducible questions through a prediction framework doesn't make the answer better. It makes the answer worse — a probability where a verdict was available. The teams that separate the two will have smaller backlogs, clear signal, and a posture they can prove rather than estimate.

For the visuals that makes the concepts clear: https://gist.github.com/sufield/a55bb7d2ace9b267f8972eb2260c6446

References: Roytman, "Predict, Don't Enumerate" (O'Reilly Radar, June 4, 2026); Vassilev, NIST/IEEE Security and Privacy (June 9, 2026); Geer and Aitel, "Pointing Machines vs Knowing Machines" (Lawfare, 2025); Spring, vulnerability enumeration and the halting problem (CMU SEI). If you think prediction covers the deducible questions adequately — that a probability is sufficient where a verdict is available — that's the specific disagreement worth having.