✓ Human-authored analysis; AI used for formatting and proofreading.
James Shore's article: You Need AI That Reduces Maintenance Costs has a line that should change how you evaluate every AI coding tool:
You need AI that reduces your maintenance costs.
Code is not an asset. It is a liability. Every line you add is something you now have to understand, debug, secure, and change for the rest of the system's life. Output speed is the cheap part. The expensive part dominates the lifetime cost of software. So an AI that makes you produce more code faster, without lowering the cost of living with that code, hasn't helped you. It has handed you a bigger liability, faster. The math only works when the AI reduces maintenance cost roughly in proportion to the productivity it adds.
That framing is usually applied to application code. It applies just as sharply to security work and it explains what an AI security tool should do.
The trap: AI that generates more findings
The obvious thing to build is an AI that produces more security output. Point a model at your cloud, let it reason about misconfigurations, and let it emit findings. More coverage, alerts and text.
This is the security version of generating more code. Each finding is not an asset. It is a liability:
- Someone has to read it.
- Someone has to decide whether it is real.
- Someone has to reproduce it to confirm it.
- Someone has to re-review it the next time the model phrases it differently.
- Someone has to defend it to an auditor or an executive.
A model that doubles your finding count doubles that review burden. If the findings are probabilistic, phrased a little differently each run, sensitive to the prompt, hard to reproduce, you have created a maintenance cost that recurs every single time you run it. You are paying expert attention over and over for an answer that never stabilizes.
Security teams do not have a shortage of output. They have a shortage of trustworthy, reusable judgment. More findings is the wrong axis.
The win: capture judgment once, rerun it forever
AI increases output. The goal is to preserve judgment.
The durable, expensive thing in security is the reasoning that decided a state was unsafe and why, and under what conditions. You want to capture that reasoning, review once, and never have to reconstruct from scratch again.
Stave is a way to turn cloud-security judgment into durable, deterministic invariants rules that say "this unsafe state must not exist" and evaluate them against point-in-time snapshots of infrastructure.
The contrast, on the maintenance-cost axis:
| AI-only security workflow | Invariant-based workflow (Stave) |
|---|---|
| AI generates findings | A human defines an invariant |
| More alerts | Fewer, higher-value unsafe states |
| Probabilistic, hard to trust | Deterministic output |
| Hard to reproduce | Snapshot-based repeatability |
| Prompt-dependent | Rule-based evaluation |
| Expensive to review again | Reviewed once, reused |
| Point-in-time answer | Time-aware evaluation |
Why an invariant is cheaper to maintain than a prompt
Consider a routine task: deciding whether an S3 bucket is dangerously exposed. Done by hand or by asking a model each time an engineer re-derives the same chain of questions on every review:
- Is the bucket public?
- Public via policy, or via ACL?
- Is a Public Access Block masking a latent exposure that becomes live the moment the block is removed?
- Has this unsafe state persisted long enough to matter for an SLA or a breach-notification window?
- Is the evidence clean enough to put in front of an auditor?
Ask an AI and you get a paragraph. You have to read it, trust it, and you will pay that cost again next quarter when someone asks the same question and the model answers slightly differently.
Capture it as an invariant and the knowledge stops being prose and becomes a contract: this unsafe state must not exist. The next review doesn't re-derive anything. The same rule runs against the new snapshot and produces a deterministic verdict with the evidence attached. The expert thought happened once. Every rerun after that is nearly free.
That is a maintenance-cost reduction, not an output increase which is Shore's test.
Where AI helps here
This means putting AI on the right side of the cost equation. AI is useful for the work around the invariant:
- drafting a candidate invariant from an incident write-up,
- explaining what a control checks in plain language,
- generating test cases and remediation text,
- summarizing a finding for a non-technical reader.
But the final answer depends on a deterministic evaluation. The engineer doesn't have to trust the model's prose. They review a rule, a snapshot, and an output. AI proposes, the invariant decides. That bound keeps the review cost from recurring.
The lock-in test
Shore makes one more point: if AI produces hard-to-maintain output, the cost stays after the AI is gone. You are left maintaining something you didn't fully design and can't easily change.
An invariant-based workflow passes that test because the durable asset was never the AI conversation. The durable assets are inspectable, version-controlled artifacts:
- the snapshot JSON (what the infrastructure looked like),
- the invariant (the rule, in YAML, reviewed and committed),
- the deterministic output (the verdict and its evidence),
- the golden tests that pin that output byte-for-byte.
Stave runs offline, with no credentials and no network call during evaluation so the same inputs always produce the same output. AI can assist in authoring any of these. But pull the AI out tomorrow and the system keeps working, because nothing foundational depends on it. You are maintaining a small set of rules and the evidence they produce.
The thesis
The future of AI in security is not more generated findings. It is maintainable security knowledge judgment captured in a form you can review once, rerun forever, and reason about without re-litigating it every quarter.
AI increases output. Stave preserves judgment.
In maintenance-cost terms, the only terms that matter over a system's life:
Stave turns AI-assisted cloud-security work into security rules you maintain once and rerun forever.
The move it enables is small to describe and large in consequence: from "ask the AI again and review another answer" to "run the invariant and inspect deterministic evidence." One of those costs grows every time you use it. The other doesn't.
How this relates to existing compliance mods
The cost-doesn't-grow property isn't unique to Stave. It's the core property of every deterministic check tool, including turbot/steampipe-mod-aws-compliance and its 540+ framework controls across CIS / PCI / HIPAA / NIST. Those benchmarks run the same SQL forever; the maintenance cost is fixed. The difference between framework mods and Stave isn't the maintenance-cost property; it's the axis of coverage. Framework mods cover the atomic-property axis (per-resource checks) with framework breadth Stave doesn't try to match. Stave's compound + ghost-reference axis AI-assisted operators specifically need beyond framework checks. The classes of failure that look "ask the AI" when you only have per-resource visibility but reduce to "run the chain" once the compound surface is named. Install both for the full deterministic-evidence picture. The comparison is ataws-compliance-mod.
Top comments (0)