Home / Explainer
Explainer · 3 minutes · with sound

Your backlog, turned into review-ready merge requests.

Every platform team has work it knows it should do, and never gets to. This film shows what the assistant does with that work, what lands on your desk, and why you stay in control. The names in the film are examples, and the numbers in the merge request (MR) come from an example run.

About 3 minutes, narrated. Captions are available in the player. The full text is below. Narrated by River. Listen to the Daniel version →

Transcript

The backlog that quietly rots

Every platform team has a list of work it knows it should do.

Upgrades. Migrations. Monitoring. Cleanup.

The work is important, but it is never urgent. So it waits.

Meanwhile, your GitOps repository quietly rots. A chart falls behind. A memory request is a guess.

Small problems pile up, and become outages.

What you really get is time

GitOps Assistant does the boring part of that work.

It reads the changelogs, gathers the metrics, writes the change and tests it.

Your engineers review a finished change, not a research task.

Your leads see the backlog shrink, without new hires.

The business gets current, efficient, reliable and secure infrastructure.

What lands on your desk

Here is what lands on your desk.

No new dashboard. Only merge requests, in the tools you already use.

Each one is small, and fixes one thing. A second reviewer has already checked it.

An upgrade, with the release notes read.

Monitoring for a service nobody watched.

Memory sized from real usage, not a guess.

And where the reviewer found a gap, the merge request waits for you.

One MR, up close

Look at one up close.

In this example, a service asks for far more memory than it uses.

Thirty days of metrics show the real peak.

A safety clamp in code keeps the new value above it.

All the evidence is in the merge request.

Rules, judgement, guardrails

Three layers do the work.

Deterministic rules, when the answer is known. Plain code, no AI model required.

For example, in an upgrade, code renders your configuration on the old and the new version. It finds the exact changes.

Then judgement, where it helps. An AI model looks at those changes.

What do they impact? And what must you do to make them safe?

The same split applies to all the work it does.

And guardrails. Code checks every answer, against your real cluster.

If the assistant does not know, it says so.

You decide what ships

Doing it all by hand equates to using a shovel. Safe, but slow.

A general AI agent with access to your infrastructure is like using a bazooka.

It is powerful. But you need a lot of experience and protection to guide it without collateral damage.

You keep the responsibility. But you hand your data to a third party.

The assistant is like a scalpel. One precise cut for each job, and you control what information is exposed.

It can propose. You get all the context to decide what ships, and to accept the responsibility.

Draft merge requests only. Read-only access to your clusters.

Getting started with the assistant

Getting started? The assistant can start by looking at one of your repositories.

Nothing changes. A dry run shows what it would propose.

GitOps Assistant. Automate the boring parts. Keep the decisions.