Your Software Has a Pulse

Your app deployed last Tuesday. You haven't looked at it since.

You told yourself it's fine because the CI went green. You told yourself you'd check the metrics later. You didn't. Something is probably drifting right now and you have no idea.

I know this because I ran software the same way for a decade.

Most software is dead on arrival. Not broken — dead. It deploys, it runs, it serves requests. But it doesn't know if it's healthy. It doesn't know if users are happy. It doesn't know if the feature you shipped last Tuesday actually solved the problem you built it for. It sits there, static, waiting for a human to look. And humans don't look.

What Dead Software Looks Like

You've seen it. You've probably built it.

Dead software gets deployed and forgotten. The CI pipeline goes green, Slack says "deployed to prod," and everyone moves on to the next ticket. Nobody asks: did latency change? Did error rates move? Are users still completing the onboarding flow? Is the thing we built actually being used? Did the business metric we were targeting move?

The answers exist. They're in your logs, your analytics, your APM tool. But nobody's looking — because looking requires a human to stop what they're doing, open a dashboard, remember what "normal" looks like, and decide if something's off.

That's not a process. That's hope.

What Living Software Looks Like

Living software has vital signs. Something is always checking them. Three layers.

Health — is the system functioning? Latency, error rates, uptime. Most teams have some version of this. But there's a difference between alerts and awareness. An alert fires when something is already broken. Awareness means catching drift — latency creeping up 15ms over a week, error rates going from 0.01% to 0.05%. Humans catch fires. Agents catch drift. An agent says "latency on the checkout endpoint has increased 22% over 5 days, no deploy correlates, investigate?" A human says "the site is down."

Impact — is it doing what it's supposed to? Health tells you the system works. Impact tells you if it matters. Feature shipped. Deploy was clean. No errors. But did anyone use it? Did conversion change? Most teams never close this loop. Feature goes out, ticket gets marked done, nobody checks if it accomplished anything. Six months later someone looks at the data and realizes the feature had zero impact — but by then you've shipped 40 more features on top of it. Living software tracks impact continuously. An agent correlates deploys with business metrics and tells you when a feature isn't working.

Evolution — is it getting better? Dead software is maintained. Someone fixes bugs on their schedule, when they get around to it. Living software evolves. The agent notices a performance regression and proposes a fix. It sees an API endpoint being called in patterns that suggest the client is working around a limitation — and flags it. It detects a feature flag that's been on 30 days with positive metrics and proposes removing it. We're doing pieces of this today.

The Era Nobody's In Yet

In The Death of the PR, I laid out three eras of software feedback. Most companies are in Era 1 with some Era 2 sprinkled in. Almost nobody has actually entered Era 3.

Era 3 isn't about removing humans. It's about changing what humans do. In Era 1, humans are reviewers — they read code and approve deploys. In Era 2, humans are supervisors — they watch agents work and intervene when needed. In Era 3, humans are policy setters — they define what healthy looks like, and agents close the loop against those definitions.

You don't manually adjust your thermostat every five minutes. You set it to 21°C and the system maintains it. If temperature drifts, the system corrects. You only intervene when you want to change the target.

That's what living software feels like. You set the targets — latency under 200ms, error rate below 0.1%, activation above 40% — and the system works toward them. You intervene when you want to change direction, not when you need to babysit execution.

What I'm Actually Running

I have an AI agent on my team. His name is Rafiki. He runs on a Mac mini. He's connected to our GitHub, AWS, monitoring, Slack.

He's not a chatbot. He's not an assistant I ask questions to. He's a teammate who does work.

Every morning he checks production metrics. Monitors deploys. Watches for drift. When something's off, he tells me. When a deploy goes out, he runs smoke tests and checks if user metrics moved. He writes code, runs E2E tests, monitors the results.

Is he perfect? No. He makes mistakes. He misses context sometimes. He occasionally proposes things that don't make sense.

But he's always watching. He doesn't get tired. He doesn't context-switch. He doesn't check the dashboard only when he remembers to.

The code we ship has a pulse because Rafiki is the nervous system. And here's what I've realized: the agent isn't the product. The feedback loop is the product. The agent is what makes the loop fast enough to matter.

The Full Picture

Across this series, the argument has been simple.

Shift left — challenge the intent before you write code. Is this the right thing to build? What evidence supports it? Catch bad assumptions before they become bad code.

Shift right — verify the outcome after you deploy. Did metrics move? Is the system healthy? Did it solve the problem you said it would?

Automate the middle — push to main, auto-deploy, E2E tests, progressive rollout. Fast, automated, not where humans should spend their time.

The old model put all human energy in the middle: reading diffs, approving PRs, debating variable names. The new model puts human energy at the edges: deciding what to build and defining what success looks like. Everything in the middle runs itself.

What To Do Next

Define your vital signs. Not just uptime — business metrics. What does "healthy" actually mean for your product? Write it down. Latency targets. Conversion baselines. Activation rates. Revenue per user.

Automate the watching. Set up something — an AI assistant, a monitoring bot, a script — that checks those vital signs and tells you when something drifts. Not when it's broken. When it starts to drift.

Close the loop. When the agent finds something, it shouldn't just alert you. It should propose what to do. "Latency increased 20% since Tuesday's deploy. Here's the likely cause. Here's a proposed fix." You decide. The agent executes.

Measure loop speed. How long from "something changed" to "we know about it" to "it's fixed"? That number is your competitive advantage. Shrink it.

Your software doesn't have to be dead. It can monitor itself, respond to change, and get better over time. The tools exist. The patterns work. The question is whether you'll keep pretending a human reading a diff once a week is enough.

Also in this series: Branches Are Dead. Here's What Replaced Them. · The Death of the PR