It Just Shows Up

Since publishing the Sidekick post, I keep getting the same question. Leadership asked it most recently: why did this one stick when so many internal AI tools don’t? We’ve built a few of those ourselves, agents that looked great in a demo and stalled right after.

My answer was embarrassingly mundane. Sidekick shows up where engineers are already working. Label a ticket and, a few minutes later, an analysis lands as a comment in the tracker. You don’t install or log into anything, and you don’t need to remember another tab. We didn’t set out to solve adoption this way. Sidekick began as a CI pipeline, and CI left us nowhere else to put the result.

That constraint probably saved us. Most internal tools collect an adoption tax before they help anyone. You get access, install something, learn the interface, then remember to use it the next time you have a problem. We asked skeptical engineers to do none of that. For most of them, Sidekick first appeared as an analysis on a ticket already in their queue, sometimes saving an hour of investigation. They learned its name after it had helped them.

The best evidence that it stuck came later. Teams started asking for it to run by default. When the code review agent went down for maintenance, we got questions about where it went. People noticed when it stopped showing up.

Anthropic’s AI-native SDLC playbook helped me explain why that worked. Agents sped up the build phase, but planning, review, and deployment still wait on people. Sidekick agents help with ticket triage and PR review without changing either workflow. An on-call engineer opens the same ticket as before and finds a diagnosis already in it.

The playbook goes much further. Every stage commits an artifact the next stage reads, until the whole lifecycle runs as a loop. We’re building in that direction too, but adopting the whole system up front asks developers to change how they work before any one part has earned their trust. It also asks teams to understand and own all of it at once.

Read closely, the playbook’s rollout is more modest than its vision. Each play lists its prerequisites, and the advice is to run every step by hand before wiring the steps into a loop. I doubt we would have been that patient if we’d started from that vision. But we didn’t have to be. We had a queue of tickets nobody had time to read, and the fastest thing to ship was a markdown comment on each one.

My version of an AI-native SDLC looks much less dramatic: keep the tools people already use and improve what shows up in them. Tickets can arrive pre-triaged, and PRs can carry a first review. CI failures can include a diagnosis beside the stack trace. The complicated work stays in the harness while developers keep using the tracker and PR page they already know.

Anthropic mostly follows the same instinct. Its artifact chain is markdown in git, review findings land on the PR, and its security play exports findings so the tracker a team already uses stays the system of record. The new files, intent.md and spec.md, are where it asks for new habits. I’d add those once the existing flow has proved useful.

Sidekick has started to change the workflow. It now proposes fixes for some of what it finds, as a pull request someone still has to review and merge. That was an easy sell, because the read-only version had been useful for months. The playbook describes the same progression: start with read-only diagnosis, then let agents act only through gated routes like a PR.

Put the agent inside work developers already do, then expand when they ask for more. The fastest way to change how developers work turned out to be not asking them to.