AI-powered remediation has its barrier
AI makes the problem visible, but the fix is still cumbersome…
Developers and security teams want automated, policy-enforced fixes in their workflow.
Modern cloud infrastructure is defined in Terraform and CloudFormation. Storage buckets, IAM roles, networking rules, and databases are provisioned through code and deployed through version control. When misconfigurations appear, teams need reliable fixes aligned with internal policy, cloud provider guidance, and compliance standards. Security engineers need consistent enforcement across repositories, clear severity prioritization, and traceability to frameworks such as CIS, NIST, and SOC 2. Platform teams need predictable code changes with documented operational impact. Developers expect feedback inside the tools they already use, without adding friction to their workflow.
The problem with AI remediation today
AI tools can draft code changes, but developers cannot merge a fix until they understand the policy behind it, see how it fits their codebase, and review it through the same process they already use for shipping code.
Surface-level suggestions: AI tools can describe what might be wrong, but the output often lacks the policy, target, and surrounding code context needed to understand the exact change.
Missing codebase context: A fix can look correct in isolation while still conflicting with existing patterns, modules, dependencies, or team standards.
Unclear review path: Suggestions often stay in a chat, dashboard, or report instead of becoming a clear diff that can move through an IDE, pull request, or CI check.
Inconsistent output: The same type of problem can produce different fixes each time, which makes review harder and reduces trust.
Extra developer work: Developers still need to interpret the suggestion, check the code, create the fix, validate it, and route it through review.
Enter Gomboc.ai: automated remediations built into your workflow
Gomboc connects to repositories, understands policy requirements, identifies policy findings, and uses AI to generate structured code fixes. These fixes are delivered through existing Git workflows, so developers can address findings inside the tools they already use. Security teams define policy standards and control release timing, ensuring remediation aligns with organizational requirements. The portal provides centralized visibility across findings, fixes, exceptions, and outcomes, creating a complete and traceable record from detection to resolution.
The IDE
Gomboc integrates into VSCode through the Gomboc Fix Reviewer, which evaluates Infrastructure as Code in real time while it is being written. When a policy violation appears, the developer sees a clear explanation and the exact configuration required to resolve it, directly inside the file. The issue is described in simple terms, the required change is shown inline, and the fix can be applied immediately with full visibility into what is being modified. The logic is deterministic, which means the same violation in the same context always produces the same structured correction. This makes the outcome predictable and easy to review. By resolving issues at the moment they are introduced, teams keep their code aligned with policy from the start and reduce friction later in the review and deployment process.
Git
For existing violations, Gomboc generates a merge-ready pull request directly in GitHub or GitLab. The pull request clearly shows which rules were triggered, which resources are affected, and the exact code changes required to resolve them. Each change includes a short explanation next to the diff, so the developer understands what is being modified and why. The fix is already structured and complete, and the developer’s role is to review and approve it, just like any other change. Remediation moves through the same workflow the team already trusts, without adding extra steps.
Turning scan results into reviewable remediation
With remediation this complex, teams need one place to see the rule, affected files, risk, exception path, and generated code change before moving forward.
Researching each rule from logic to policy coverage
Teams can search for a rule by title or ID, inspect its risk, severity, audit logic, remediation behavior, and code examples, and trace how it connects to related policies, classifications, and security standards.
❤️ by devs and security teams
…so how did we get here?
Understanding where findings stalled before fixes
We started by studying what happened after a policy finding appeared across the tools teams already used: the portal, IDE, pull requests, CI checks, tickets, and planning boards. The finding was visible, but the context around it was split across places. Engineers still had to connect the policy requirement, affected target, surrounding code, and delivery path before the work could move forward.
The research showed that the slowdown came from manual translation between a finding and a fix. Each surface showed part of the picture, but no single artifact carried the full context. That shaped the redesign around a clearer output: a structured fix that could bring the policy, target, code change, and next action together.
Designing around the workflow engineers already use
We studied how engineering teams make production decisions after a finding turns into a proposed change. The strongest pattern was Git-based collaboration: pull requests already carry the discussion, ownership, approvals, CI results, and change history teams use to decide what can move forward.
This gave us a clearer product direction. Remediation had to enter the same path as production code, because a fix that only lived in the portal still left engineers to recreate the work inside the IDE, pull request, or CI pipeline. The portal could organize findings, fixes, exceptions, and outcomes, while the code-level work needed to appear where engineers review and ship changes.
From there, each surface had a specific role: the portal showed visibility across remediation work, the IDE placed the fix next to the affected code, Git carried discussion and ownership, and CI confirmed whether the change was safe to move forward.
Making deterministic AI fixes ready to ship
After we understood that fixes needed to move through the developer workflow, the IDE became the clearest place to design the AI experience. This is where developers already see the code, understand the affected target, and decide what change should happen next.
The goal was to make AI useful at that exact moment. A general AI assistant can suggest a possible change, but remediation needs a more specific action. The fix has to connect the policy finding to the code in front of the developer, then apply the expected correction in a consistent way.
In the IDE, that meant showing the finding, the affected code, and the fix action together. The developer could see why the target was flagged, choose the deterministic fix, and continue through the same workflow into Git and CI. The AI experience became less about asking for help and more about applying a structured correction where the work was already happening.
The Design Challenge
The challenge was to design a product experience where a policy finding could become a usable fix across Portal, IDE, Git, and CI. The fix had to carry the context teams needed to act: the affected target, the policy requirement, the proposed correction, the reason for the change, and the next workflow step.
Developers needed code-level context, platform teams needed consistency across repositories, and security teams needed visibility into progress. The design had to connect those needs across surfaces while keeping the fix close to the workflow where engineering decisions already happen.
The “Aha” Moment
We started by designing around the portal because it gave teams one place to see findings, fixes, exceptions, and progress. As we mapped the workflow, we saw that engineers still returned to the editor, pull request, and CI checks when it was time to make the actual change. The portal helped teams understand what was happening, while the fix needed to live where engineering work moved forward.
That shifted the product direction: the output needed to become a fix, rather than another finding. AI could help reason through a policy finding and suggest a correction, but teams still needed the result to behave like production code: specific, consistent, syntax-aware, and repeatable.
This is where ORL, Gomboc’s Open Remediation Language, became central. ORL evaluates policies in code, finds the exact target, and applies deterministic transformations. It turns policy requirements into concrete code changes with the same output for the same input.
The key insight became: AI helps identify the path to a fix, while ORL makes the fix dependable enough to move through the workflow.
Deeper Dive: The Gomboc Fix Reviewer (IDE)
The Gomboc Fix Reviewer operates directly inside the editor while a developer is writing infrastructure code. It analyzes the Infrastructure as Code file in real time and highlights the exact configuration block that triggered a policy rule. In the side panel, the developer sees three connected pieces of information. First, the policy rule that was triggered, which clarifies the standard the configuration relates to. Second, a short explanation describing what the rule requires and why the configuration needs adjustment. Third, the exact code update required to resolve the issue. Because the explanation and the code change appear together in the same context, the developer can quickly understand the requirement and apply the correction directly within the file they are editing. The fix follows deterministic logic, meaning the same violation in the same context produces the same structured update, which maintains consistent behavior across repositories and makes the outcome predictable during review.
The Explanation Layer
Each fix includes a short explanation that connects the policy rule, the infrastructure configuration, and the code update required to resolve the issue. Showing these pieces together helps developers understand why the change is needed and how the update addresses the rule. This keeps the reasoning visible during review and helps teams apply policy requirements through normal engineering workflows.
Deterministic Fix Generation
Every remediation follows deterministic logic, which means the same violation in the same configuration always produces the same structured code update. This keeps fixes consistent across repositories and makes the result predictable for developers reviewing the change.
Initial Thinking
Early design exploration approached remediation from a security perspective, where violations appeared as structured findings connected to policy rules and proposed fixes. This model helped security teams understand which infrastructure resources triggered a rule and what change was required. Feedback from engineering teams revealed a different expectation. Developers and platform engineers preferred resolving issues through their existing DevOps workflows, where infrastructure changes move through code editing, pull requests, and review. This insight shifted the design direction toward embedding policy context, explanations, and code updates directly within developer environments, allowing remediation to move through the same workflows teams already use to build and maintain infrastructure.
The Output
The final system turns a policy violation into a structured code change that moves through the same workflow engineers already use to manage infrastructure. Developers see the issue while writing code, review the required update, and apply the fix as part of normal code review. This keeps policy enforcement, infrastructure changes, and developer workflows aligned in a single process.