Building Your SRE Agent Practice

Practical frameworks for working with AI coding assistants

Graham Russell

January 28, 2026

This is Part 2 of a two-part series. In Part 1, I explored how AI tools amplify engineering judgment for small platform teams. In this post, I’ll share the practical frameworks and validation practices we use to work with AI agents as teammates.

Building a platform team? We’re actively hiring SREs who want to work at the intersection of infrastructure and AI. If these frameworks resonate with you, let’s talk.

What We Learned

Working with AI tools as force multipliers has taught us several key lessons:

Your role has shifted from writing code to validating code—AI generates, you prove it works
Always ask “could this be a managed service?” before building anything
Use AI to explore multiple approaches in parallel, then choose based on proven functionality
“Production-ready” is context-dependent—match the solution complexity to the problem complexity
Maintenance burden matters—choose what you own carefully
Lean team constraints force better decisions—limited attention means prioritizing what actually matters
Unix primitives are powerful—compose existing tools rather than building new ones
Proof is non-negotiable—whether you wrote it or AI wrote it, you must demonstrate it works
AI tools amplify judgment, not replace it—faster exploration enables better decisions

The Pragmatic Decision Framework

When faced with a new automation task, I use this framework to guide my thinking:

0. Is there a managed service that does this?
   ├─ Yes → Use it. Your time is more expensive than the subscription.
   └─ No → Continue

1. Can existing tools orchestrate this?
   ├─ Yes → Compose existing tools, upgrade if needed
   └─ No → Continue

2. Is this a one-off or recurring task?
   ├─ One-off → Keep it simple
   └─ Recurring → Continue

3. Will this need complex error handling or state management?
   ├─ Yes → Use a robust application framework
   └─ No → Continue

4. Will multiple engineers need to extend this frequently?
   ├─ Yes → Use team's primary language and patterns
   └─ No → Simpler approaches are fine

5. How much of my attention budget will maintaining this consume?
   ├─ High → Choose simpler approach (or managed service)
   └─ Low → Original plan is fine

6. Can I debug this quickly under pressure?
   ├─ No → Simplify it
   └─ Yes → Good to go

7. Does building this create competitive advantage?
   ├─ No → Strong signal to buy instead of build
   └─ Yes → Building might be justified

The Solo SRE Corollary: When in doubt, choose the solution that minimizes your future cognitive load. Your future self will thank you.

The Team Topologies Corollary: Even if you’re a team of one, you can still apply platform team thinking by ruthlessly outsourcing undifferentiated heavy lifting to managed services, and focusing your limited attention on what actually matters to your business.

The Path Forward: Building an SRE Agent Practice

This isn’t just about one security scanner or any single project. It’s about developing a practice of working with AI agents as teammates—with the same standards you’d have for human engineers.

Simon Willison wrote about this perfectly in “Code Proven to Work”: Your job isn’t to write code anymore—it’s to deliver code you have proven to work.

This applies equally to code you write and code Claude Code generates. The shift is fundamental:

Old role: Write code → Hope it works → Debug when it breaks

New role with AI: Generate multiple approaches → Test them → Choose proven solution → Validate continuously

The Two-Part Proof System

Following Simon’s framework, whether I write the code or Claude Code generates it:

1. Manual Testing: I personally run the code, verify it works, and document the results

Run it against real data, verify output matches expectations
No code gets deployed without terminal output proving it works

2. Automated Testing: Every change includes tests that fail if the code breaks

Claude Code made writing these tests trivial
But I still verify the tests themselves actually work
Tests aren’t a substitute for manual proof—they’re reinforcement

The critical insight: Claude Code generates code. My job is to prove it works. That’s the force multiplier—fast generation paired with rigorous validation.

The SRE Agent Practice in Five Steps

Use AI tools to rapidly prototype alternatives (generation is cheap)
Prove each approach works (validation is your job)
Compare implementations based on verified functionality (not theoretical benefits)
Make decisions based on proven code (not assumptions or LLM confidence)
Build habits of validation that scale as your team grows (these skills transfer to reviewing human PRs)

As Simon notes: “Your job is to deliver code you have proven to work.” Whether that code came from your fingers or Claude Code’s doesn’t matter. The proof is your responsibility.

As an SRE on a small team, Claude Code isn’t replacing me—it’s letting me operate like a three-person team until we can build that team for real. But each member of that virtual team needs to deliver proven code. I’m the QA gate.

Practical Tips for Working with AI Agents

Start with Exploration, End with Validation

When approaching a new problem:

Ask AI to explore multiple approaches - Don’t commit to a solution too early
Request working prototypes - Not just descriptions or pseudocode
Test each approach - Run them against real data
Compare trade-offs - Use actual metrics (lines of code, dependencies, startup time, complexity)
Choose based on evidence - Not on what sounds best

Treat AI Output as a First Draft

AI-generated code is like a colleague’s PR:

Review it carefully - Don’t assume it’s correct
Test it thoroughly - Make it prove itself
Understand it completely - You’ll be maintaining this
Refine as needed - AI gets you 80% there, you finish the last 20%

Build Your Personal Framework

Everyone’s constraints are different. Build your own decision framework by:

Tracking what works - Keep notes on successful patterns
Learning from mistakes - When did complexity hurt you?
Refining your instincts - AI helps you explore, but you develop the judgment
Sharing with your team - These patterns become team knowledge

Conclusion: AI as Your SRE Force Multiplier

The best code is the code you don’t have to write. The best dependency is the one you don’t have to manage. The best complexity is the complexity you can avoid.

AI tools don’t change these truths—they help you discover them faster.

As an SRE on a small team, attention is my scarcest resource. Every technical decision is an investment of future attention. Complex systems require more attention to maintain. More dependencies require more attention to update.

Claude Code as a force multiplier lets me:

Explore multiple solutions without spending weeks on each
Compare trade-offs with actual implementations instead of theoretical arguments
Make informed decisions about complexity vs simplicity
Operate at team-level velocity while building the actual team

The next time you reach for a framework, a library, or a “proper” architecture pattern, pause and ask:

Who’s going to maintain this?
Is the complexity solving a real problem or a theoretical one?
Can I use AI tools to explore simpler alternatives before committing?

Use AI tools to amplify your judgment, not replace it. Choose tools that match the problem. Optimize for maintainability. Ship value, not just code.

If you’re an SRE who appreciates pragmatic thinking, understands how AI tools amplify engineering velocity, and wants to help us build a proper platform team as we scale, we’re hiring. Let’s build infrastructure that future-us will thank us for—with AI tools as our force multipliers.