Read the Issue Tracker, Not the README: Researching Before Building an AI Ops Tool

Description and use

The author studied competitors’ issue trackers, identified key gaps, and used them to design a more trustworthy AI Ops tool, setting up governance before coding.

Problem

Assuming an empty field for a Kubernetes AI Ops tool led to wasted effort; existing projects already addressed the problem.

Outcome

By researching issue trackers, the author avoided duplicating existing solutions, identified actionable gaps, and built a more trustworthy, well‑governed AI Ops tool.

Workflow

• 1. Conduct research on competitors’ issue trackers
• 2. Identify four key gaps: unbounded cost, lack of suppression, partial remediation verification, GitOps conflicts
• 3. Translate gaps into design choices (fingerprinting, suppression CRD, verification outcomes, pull‑request writes)
• 4. Name the project after confirming no conflicts
• 5. Set up repo governance (branch protection, signed commits, Dependabot, OpenSSF, SBOM, Helm chart) before writing code

Evidence

The first useful thing research did was kill my assumption that this was an empty field.

Source

Four findings changed the design: Cost is unbounded. Suppression does not exist. Verification of remediation is partial. Cluster writes break GitOps shops.

Source

I ended up with eight of these, written down as a table: the evidenced gap on the left, my answer on the right.

Source

Before writing a single controller, the repo got: Branch protection on main, required signed commits, Dependabot, OpenSSF Scorecard, governance docs, release automation, Helm chart.

Source