Every optimization tool, security scanner, and architecture review produces the same artifact: a list of things that are wrong. The list is accurate, prioritized, exported to a ticket system — and then it waits, because a finding is not a fix. It is homework, assigned to an engineer who already has a sprint. The gap between "we know" and "we changed it" is where cloud waste and misconfiguration actually live, and the way to close it is to change what a finding is: not a description of a problem, but a runnable, reviewable piece of infrastructure code that resolves it.
A finding without a fix is homework
Trace the life of a typical finding. A scanner flags an unencrypted volume or an oversized instance. A ticket is created. The ticket names a problem, not a change, so the assigned engineer must reconstruct context: which stack owns this resource, which Terraform module declares it, what the correct parameter is, what else references it. That reconstruction is the expensive part — often hours per finding — and it is why backlogs of hundreds of known, mechanical issues persist for quarters. Nothing about the finding was hard to fix. It was hard to start fixing.
The scale of the resulting gap is documented. Flexera's 2026 report puts wasted cloud spend at 29% — the first rise in five years — in an industry where every waste category it counts is detectable by tooling that already exists. Gartner's projection that through 2026, 99% of cloud security failures will be the customer's fault — misconfiguration, not provider compromise — describes the same phenomenon in security: known problems, unclosed. Detection is solved. Closure is not.
Generate the fix with the finding
Remediation as code inverts the artifact. For each finding, the system generates parameterized CloudFormation or Terraform that implements the correction: the resized instance type as a variable with the recommended value defaulted, the encryption flag enabled, the security-group rule narrowed to the observed source ranges, the lifecycle policy that expires the orphaned snapshots. Parameterization matters — the engineer reviewing the change can adjust the target instance size or the retention window without rewriting anything, which keeps the human decision in the loop without re-imposing the blank-page cost.
Generation must respect how the environment is actually managed. Resources under existing IaC get a change to the source module or a targeted override, not a competing stack that drifts from the repo. Unmanaged, console-created resources — every enterprise has them — get net-new templates that also bring the resource under management, turning remediation into a stepwise import of the estate into code. Either way, the deliverable is the same shape: a diff a human can read.
The unit of remediation is not the ticket. It is the reviewed diff.
The review-and-apply workflow
Because the fix arrives as code, it flows through the pipeline engineers already trust, and the finding's lifecycle becomes a change lifecycle:
- Finding generated — with evidence attached: the metrics, configuration state, and cost data that justify it.
- Fix generated — parameterized IaC, scoped to exactly the resources in the finding.
- Owner review — the service owner reads the diff and the plan output, adjusts parameters if context demands, and approves or rejects with a recorded reason.
- Apply through the pipeline — the same CI/CD path as any other infrastructure change, with its existing controls.
- Verify and close — the environment is re-queried; the finding closes only when live state confirms the fix, and the savings or risk reduction is measured, not estimated.
Guardrails: diffs, approvals, rollback
Generated code is a proposal, never an action. Three guardrails keep it that way. First, plan diffs are mandatory: every fix ships with its terraform plan or CloudFormation change set, so the reviewer sees the exact blast radius — including the resource replacements and dependency effects that a prose ticket would never surface. Second, approvals are explicit and tiered: low-risk classes (tagging, lifecycle policies, nonproduction resizes) can run on single approval; anything touching production availability or security boundaries requires the owner plus a second reviewer, exactly as policy would demand of a human-authored change. Third, rollback is pre-generated: the revert diff exists before the apply does, so undoing a change is another one-approval operation, not an incident-time improvisation. Under these guardrails, a generated fix is governed more tightly than most hand-written hotfixes ever were.
Weeks to minutes
The compression is not in the apply — pipelines were always fast. It is in everything before it.
| Step | Finding as ticket | Finding as code |
|---|---|---|
| Context reconstruction | Hours per finding, by the assignee | Done at generation time |
| Authoring the change | Hand-written, error-prone | Generated, parameterized |
| Review input | Prose description | Diff plus plan output |
| Scheduling | Next sprint, at best | Minutes of reviewer attention |
| Verification | Manual, often skipped | Automatic re-query of live state |
| Typical elapsed time | Weeks to quarters | Minutes to days |
When the marginal cost of closing a finding falls this far, behavior changes upstream too: teams stop rationing which findings deserve tickets, backlogs stop being risk-acceptance registers, and continuous review — of cost posture and security posture alike — becomes operationally affordable for the first time.
Where humans stay in the loop
Remediation as code does not remove human judgment; it concentrates it where it pays. Machines are better at reconstructing context, writing correct boilerplate, and re-checking state. Humans remain decisive at exactly three points: setting the policy that defines what may be auto-generated and what approval each class requires; reviewing the diff, because only the owner knows about the failover requirement or next week's launch; and accepting risk when the right answer is "don't fix this," recorded as a decision rather than left as backlog sediment. That division holds even as autonomy grows — a system trusted to auto-apply a narrow class of fixes earned that trust through accumulated approved diffs, and the audit trail of proposals, approvals, and reverts is precisely what makes the arrangement defensible to a regulator.
This is how Caelion Meridian delivers every recommendation: evidence-backed findings with parameterized CloudFormation or Terraform attached, reviewed and applied through your own pipeline, read-only until policy says otherwise. To see your backlog turned into diffs, request a private briefing.