Your Organization Is a Tactical Tornado

In A Philosophy of Software Design, John Ousterhout describes the “tactical tornado” — a prolific programmer who churns out features at impressive speed while leaving a trail of complexity for everyone else. The tactical tornado doesn’t write bad code on purpose. They just never pause long enough to think about what comes next.

Every organization now has one. It writes code 24 hours a day, never gets tired, and never asks whether the thing it’s building belongs in the codebase.

Tactical by Default

Facundo Olano articulated this problem precisely in February 2026: LLMs enforce tactical programming by default. Not because they lack capability, but because the interaction model demands it.

You give the model a task. It produces a diff. You accept or reject. Next task.

This is the textbook definition of tactical programming — working one task at a time, optimizing for the immediate change, never lifting your eyes to the system-level view. The diff-by-diff interaction model doesn’t accommodate strategic thinking. There is no moment in the loop where the model considers whether this feature should exist, whether the abstraction is right, or whether the current change contradicts a decision made three sprints ago.

A skilled developer using an LLM strategically can compensate for this. They bring the strategic context the model lacks. But that requires deliberate effort — and the entire pitch of AI coding tools is that they reduce effort. The path of least resistance is tactical. Most people follow it.

When an individual programmer works tactically, the damage is local. When every developer in an organization generates code through a tactical interface, the damage compounds. You don’t have one tactical tornado. You have a weather system.

The Throughput Illusion

The data supports this. CircleCI’s 2026 analysis of 28 million workflows found that feature branch throughput increased 15% — but main branch throughput decreased 7%. More code generated. Less code shipped.

LinearB’s study of 8.1 million pull requests tells the same story from a different angle: AI-generated PRs had a 32.7% acceptance rate versus 84.4% for manually written ones. CodeRabbit found that AI code creates 1.7x more total issues per change.

These numbers describe an organization that is producing more output while delivering less value. That is what a tactical tornado looks like at scale.

The temptation is to treat this as a quality problem — AI code needs better review, better testing, better guardrails. But that misses the structural issue. The code isn’t just low quality. It’s low quality in a specific way: it solves the immediate problem without considering the system it lives in.

The Bottleneck Shift

Olano’s second essay makes a related point using Amdahl’s Law. The formal application is imprecise — Amdahl’s Law describes fixed workloads, and software development is adaptive — but the intuition is exactly right.

Coding represents perhaps 20-30% of the software development value stream. Even if you make coding infinitely fast, you improve the total throughput by at most 30%. The bottleneck shifts to everything else: specification, design, review, integration, deployment, monitoring.

Make coding 10x faster, and you get roughly 1.22x faster overall. The math is unforgiving.

This is what organizations are experiencing. Developers generate code faster than reviewers can evaluate it. The review queue grows. Merge conflicts multiply. Integration testing becomes the constraint. The organization has accelerated the cheap part and congested the expensive part.

The METR study from 2025 showed developers were 19% slower with AI assistance while believing they were 24% faster. That perception gap isn’t confusion. It’s the feeling of generating output quickly while the actual delivery pipeline chokes on the volume.

The Wrong Question

Most organizations responding to these signals ask: “How do we review AI code faster?”

This is the wrong question. It preserves the assumption that code review — humans reading diffs line by line — is the right control mechanism. It was already imperfect. Research consistently shows human code review catches between 15% and 60% of defects, depending on the study. Now add non-deterministic output at volumes that exceed human reading speed.

Olano proposes an alternative: shift rigor upstream to specifications and downstream to test suites. Don’t review the code. Review the spec. Verify the behavior.

This is directionally correct and practically incomplete.

The Thoughtworks technology retreat in February 2026 converged on a similar insight: “TDD is the strongest form of prompt engineering.” If you define the expected behavior before generating code, the tests themselves become the specification and the verification mechanism simultaneously.

GitHub released Spec Kit, an open-source toolkit for specification-driven development. Addy Osmani at Google stated it plainly: “If your PR doesn’t contain evidence it works, you’re not shipping faster — you’re moving work downstream.”

But here’s the problem the spec-driven advocates don’t fully address: who writes the specs? If the LLM writes them, who reviews them? If humans write them, you’ve moved the bottleneck from code review to spec review. And if AI writes the tests, you need a way to verify that the tests actually test what matters — which is itself a review problem.

The honest answer is that specification-driven development solves part of the problem. It does not solve all of it. Marmelab’s critique found the approach “mostly unusable” for large codebases. The circular dependency between specs, code, and tests doesn’t disappear just because you reorder who writes what.

The Framing Question

The most valuable contribution from Olano’s essays isn’t the solution. It’s the question.

If we accept that AI-generated code is non-deterministic, produced faster than humans can review, and tactical by default — what organizational infrastructure must replace human line-by-line review?

This is not a tooling question. It is a governance question.

The answer involves multiple layers, none of which is sufficient alone:

Type systems and static analysis catch mechanical errors without human review. They already exist. Most organizations underuse them. Expanding their scope — stricter type policies, more aggressive linting, architectural fitness functions — captures a category of problems cheaply.

Tiered review strategies acknowledge that not all code changes carry equal risk. A configuration change and a payment processing change don’t need the same review rigor. Organizations that apply uniform review depth to all AI-generated code waste their limited human attention.

Specification as contract works when the system is well-bounded and the expected behavior can be expressed in tests. For CRUD operations, API integrations, and data transformations, this is powerful. For novel system design and cross-cutting architectural decisions, it’s insufficient.

Supervisory engineering — what Thoughtworks calls the “middle loop” — positions the human not as a code reviewer but as a system supervisor. The developer defines the intent, the constraints, and the acceptance criteria. The AI generates. Automated systems verify. The human intervenes only when automated verification fails or when the change touches architectural boundaries.

No single layer replaces human code review. The combination does.

The Organizational Decision

Here is the uncomfortable part: this cannot be an individual choice.

A developer who decides to skip code review and rely on specs instead is negligent. An organization that designs a verification infrastructure — type systems, automated testing, tiered review, architectural guardrails — and trains its teams to operate within it is making a strategic engineering decision.

The same action, individual versus organizational, is the difference between recklessness and governance.

Sonar’s 2026 survey of 1,149 developers found that 96% don’t trust AI code accuracy. This isn’t irrational skepticism. It’s an appropriate response to the absence of organizational infrastructure for verification. Developers don’t trust the code because their organizations haven’t built systems that make the code trustworthy.

The organizations betting that future AI will clean up the technical debt being generated today are making the same bet that every tactical tornado makes: someone else will fix this later. At the organizational level, “someone else” doesn’t exist. There is no cleanup crew coming.

What This Actually Requires

The fix is not “review more code” or “write better prompts” or “adopt spec-driven development.” The fix is restructuring what your organization treats as the unit of review.

Stop reviewing diffs. Start reviewing decisions.

The diff is an artifact. The decision is the thing that matters: should this feature exist? Does this abstraction serve the system? Is this change consistent with the architectural direction? Does the evidence show it works?

This requires three shifts:

From code review to decision review. The pull request is not a collection of changed lines. It is a proposal for a system change. Review the proposal: the specification, the test evidence, the architectural rationale. Let automated systems handle the mechanical correctness.

From uniform review to risk-tiered review. Not every change needs the same scrutiny. Build explicit policies: what triggers human review, what can be verified automatically, what requires architectural sign-off. Make these policies organizational defaults, not individual judgments.

From individual tooling to organizational infrastructure. AI coding tools are individual productivity tools bolted onto organizational processes that weren’t designed for them. The processes need to change. This means governance decisions about what gets auto-merged, what gets flagged, what verification evidence is required, and who is accountable when automated verification misses something.

These are not technical problems. They are organizational design problems. And they cannot be solved by the same task-by-task, diff-by-diff interaction that created them.

Your organization is already a tactical tornado. The question is whether you’ll build the infrastructure to govern the storm — or keep betting that the weather will fix itself.

This analysis draws on Facundo Olano’s essays “Tactical tornado is the new default” (Feb 4, 2026) and “—dangerously-skip-reading-code” (Feb 16, 2026), research data from CircleCI, LinearB, Sonar, METR, and CodeRabbit, and John Ousterhout’s A Philosophy of Software Design.

For organizations looking to move from tactical AI adoption to governed implementation, reach out to Victorino Group. We help engineering teams build the infrastructure that makes AI-generated code trustworthy — not by slowing down, but by restructuring what gets reviewed and how.