Paul Stack

An alert fires at 3am. Your on-call engineer opens their laptop, checks Grafana, tails the logs, traces what deployed in the last hour, diffs the config changes, checks whether an upstream dependency is having its own incident, searches Slack for the last time this happened, and reads half a runbook before they even understand what's wrong. Forty minutes of context-gathering before a single useful decision gets made.

An AI agent can do every one of those steps. Not better than your engineer — but without losing focus at 3am, or cutting corners once the investigation gets repetitive. Wire one into your alerting pipeline. When an alert fires, it pulls metrics, correlates logs, traces deployments and config changes, finds related past incidents, reads the runbook, and assembles a dossier that lands alongside the page. Instead of spending forty minutes gathering context, the engineer starts with it.

Vendors are starting to ship their own versions of this — Honeycomb Canvas, Dash0, and others. But a vendor's agent knows about the vendor's platform. It doesn't know your deployment pipeline, your change management system, or the five other tools your investigation actually touches. This talk shows how to build your own, wired into your stack, producing a dossier that's exactly what your organisation needs. Same structure every time, same sections, same layout — because a sleepy engineer at 3am needs a report they can read on autopilot, not a surprise.

The agent does not make the call. It gathers the evidence and presents it. Your on-call engineer decides what happens next — because they have taste, judgement, and the kind of contextual understanding you only get from knowing your systems, your team, and your business. The goal isn't to take the human out of the loop. It's to stop wasting their judgement on context-gathering and point it at the decision that actually matters.

Real demos, real alerts, real monitoring data. You're not being replaced. You're arriving with the first forty minutes already done.

At System Initiative, we don't write code. Not because we can't — because we decided not to.

Every line of code in our new project, swamp, is generated by an LLM operating within strict design guidelines we've crafted and maintained. We don't accept pull requests but we happily accept contributions. If you want to contribute, you open an issue, we discuss the problem, refine the design together and let the AI build it. This keeps the supply chain intact and trustworthy. That's not a gimmick, it's the thesis made real. This talk is about what it actually looks like to run an engineering team this way — the discipline it requires, the design guidelines that make it work, and what we learned building swamp: an AI-native automation CLI for operations teams.

What we've learned is that the quality of what the AI produces is a direct reflection of how well you can express what you want. Vague guidelines produce vague code but sharp constraints produce good code. That's true for swamp, and it's true for how we build swamp.

We'll cover:

• ​Why we made the decision to stop writing code and what changed when we did
• ​How design guidelines replace pull requests as the primary contribution mechanism
• ​What "architecture-first" means in practice when an LLM is your entire engineering team
• ​How swamp applies those same principles to operations — and why that matters as AI starts driving infrastructure decisions
• ​How AI gives you back the work you got into this industry to do — systems design, not syntax

​The future of software isn't humans writing less code, it's humans getting better at expressing what they want. We're living that experiment in the open, come see what we've learned!