Skip to content
Design partners

devopstech · an engineering workshop

Production engineering,
closed loop.

I build ICE, active defence for Kubernetes that only calls a problem fixed once the cluster proves it — and deusex, the autonomous development loop that builds it.

01In development · design partners wanted

ICE

Active defence for Kubernetes. ICE turns findings and drift into GitOps pull requests a person approves — and keeps the case open until a measurement taken after the merge proves the fix.

  • Writes only through pull requests — the operator has no write rights outside its own resources
  • Unknown counts as unmet; a failed source reports unmeasured, never clean
  • Three different detectors must agree before it proposes a runtime response

ICE overviewHow it worksDesign partners

  1. ObserveA read-only agent and your CI scans report facts out of the cluster.
  2. DetectPacks turn facts into findings — only if each says what to do, who does it and why it is sure.
  3. DecideA person approves a deterministic, digest-pinned change.
  4. DeliverThe operator opens a pull request in your GitOps repository.
  5. VerifyThe case closes only on a measurement newer than the merge.
Not measured since the merge? The case stays open and the loop runs again.

02Running around the clock on two projects · private

deusex

An autonomous development loop that turns a vision document into working, merged code. Agents plan, build, review and merge on a schedule; a person decides only the concept.

  • 4–18 October: 89% of ICE's merges came from the loop, with a 0.7 h median to merge
  • Rights held by tooling: the owner has read-only tools, the merge policy is a function
  • A machine never approves changes to the machine that approves changes

How deusex worksThe method

  1. PlanThe owner reads the board and prints one move. It has no write tools; a script carries the move out.
  2. BuildFive lines on models from four providers each take one item and open a pull request.
  3. JudgeA critic reads the diff. Merging needs its approval, green CI and the exact commit it reviewed.
  4. Merge policyWritten in code, not in a prompt: zero checks means “still running”, never “passed”.
  5. ConceptChanges to the method itself, or anything the critic is unsure of, wait for a person.
  6. Check what is liveA watcher tries the capability on the running system; an empty queue triggers a search for the next gap.
Every ten minutes ready work is handed out; every two hours the owner re-plans from what actually landed.

ArchiveKubeMeridian — Kubernetes observability for Grafana, archived in October 2026.

Writing

  1. Live needs evidence: how ICE keeps its own feature list honest

    A security product that promises to call the unverified unverified has to apply the rule to itself. Five capability statuses, a dated evidence mark that CI enforces, and the five rows that lost their live status the day after the gate landed.

  2. Merged is not deployed, deployed is not fixed

    Why ICE closes a security finding only on a measurement taken after the merge — and how Argo CD's sync revision, freshness cadences and Unknown-as-unmet keep the loop honest.

  3. The bottleneck is the human: a week when every agent worked and nothing shipped

    An autonomous development loop where every role behaved as designed — and two green one-line fixes waited six days. Why refusals by category never expire, and what deusex changed.

  4. What I haven't handed to the machine yet

    deusex runs most of my backlog around the clock; the goal is that I decide only the concept. As of October 2026, here is the honest remainder — what is solvable and just not done, and what no method will ever take off a person.

All posts

Work with me

Running Kubernetes in production? Get the ICE loop on your cluster before the public release — or talk to me about deusex, Kubernetes, observability, cost and SLOs.

or write to [email protected]

ICE and deusex are in active development · KubeMeridian is archived (Apache-2.0) · RSS