~/thilagan-digital
← back to logs

Part 9

Running an Autonomous Scrum Team: How I Manage AI Agents in the SDLC

homelabaisdlcagentops

When you are building a custom, multi-module homelab platform — hosting software you wrote yourself alongside integrated open-source tools — keeping the codebase from devolving into chaotic, undocumented spaghetti is already a massive challenge.

Introduce AI agents to write that software, and the challenge multiplies. If you give an LLM a massive, open-ended task like "build a dashboard to display my Proxmox and backup telemetry," you are practically begging for hallucinations, structural drift, and broken dependencies.

The fix wasn't a "smarter" model. It was a proven corporate engineering discipline: strict Agile project management. In my day job we run enterprise portfolios through Azure DevOps (ADO), which gives incredible flexibility for epic tracks, custom fields, and parent-child task relationships. For the homelab, hosted under the Thilagan-Digital GitHub organization, I wanted that same enterprise rigor — scaled down to GitHub Issues.

To do this, I built a fully automated SDLC run by specialized AI agents: a Technical Manager Agent, an Execution Agent, and an AI Scrum Master. Here is exactly how I organize, assign, and execute work across that autonomous software team to guarantee predictable delivery.

1. The Operational Hierarchy: Work Tracks

To keep the workspace from becoming a dumping ground of half-baked code, I divide all lab development into distinct Tracks of Work. Every issue created must belong to one of these:

  • Track 1: IaC & Provisioning — Terraform, Ansible, Proxmox SDN configurations.
  • Track 2: Edge & Ingress — Hetzner VM configuration, Tailscale ACLs, cert management.
  • Track 3: Custom Core Services — Proprietary Go/TypeScript APIs, dashboard modules.
  • Track 4: Telemetry & Agents — AgentOps integrations, alerting pipelines.

2. The AI Technical Manager: Structuring the Backlog

Rather than writing GitHub Issues myself, I act as the Product Owner. I feed high-level feature requirements to an AI Technical Manager Agent, whose only job is translating that intent into highly structured, bite-sized issues.

To prevent hallucinations, the Technical Manager adheres to a strict issue template. Every issue it generates must contain:

  • Title & Track — categorized clearly under one of the four active tracks.
  • Description — a clear, context-bounded explanation of why the change is needed.
  • Model & Effort Designation — which model to use (e.g. Claude for deep logic vs. Gemini for massive-context doc work) and the computed effort.
  • The Prompt to Run — the exact, optimized prompt the Execution Agent must consume.
  • Acceptance Criteria (AC) — a strict, testable Definition of Done (e.g. "Must return a 200 OK from /api/health with latency under 150ms").

A sample of what the Technical Manager actually outputs:

<!-- Sample AI-Generated GitHub Issue Template -->
## 📋 Task: Implement Secure Proxmox Node Shutdown API
* **Track:** Track 3 (Custom Core Services)
* **Assigned Model:** Claude Sonnet
* **Estimated Effort:** Medium (code generation + unit tests)

### 📖 Context
We need a custom microservice endpoint to allow our SRE agents to
gracefully cycle a Proxmox node when a hardware thermal threshold is
breached.

### 🤖 Execution Prompt
"Generate a TypeScript Express router file at `src/routes/power.ts` that
interacts with the Proxmox VE API..."

### ✅ Acceptance Criteria (Definition of Done)
- [ ] Endpoint `/api/power/shutdown` requires valid Bearer token authentication.
- [ ] Returns 202 Accepted and logs the action to console.
- [ ] Unit tests cover 100% of the route's error states.

3. The Execution Loop and the SME Checkpoint

Once an issue is assigned, the Execution Agent reads it, consumes the embedded prompt, writes the code in a local scratchpad, and opens a Pull Request in the Thilagan-Digital repository.

 [Issue Created] ──► [Execution Agent] ──► [Writes Code] ──► [Opens Pull Request]
                                                                  │
 [Merged & Closed] ◄── [Agent Verifies AC] ◄── [SME Review & Merge] ◄┘

This is where the most critical step in the entire workflow sits: the Subject Matter Expert (SME) review.

The golden rule: the AI does not merge its own code. Distinct work packages and a strict Definition of Done create predictable execution, but the PR review is handled by a human SME — in this case, me.

This mirrors exactly how we operate in my day job: AI code assistants produce impressive output, but senior engineers remain the safety net that audits PRs before they touch staging or production. The homelab takes that concept further by putting AI throughout the entire SDLC, but keeping this human-in-the-loop checkpoint is what stops a minor hallucination from taking down the whole Proxmox cluster.

4. The AI Scrum Master and Backlog Grooming

Once I review, approve, and merge a PR, the Execution Agent runs a final sweep: spinning up the service, validating the code against the Acceptance Criteria, and closing the issue only if every condition is met.

To keep the pipeline moving, a weekly AI Scrum Master Agent handles:

  • Checking all open issues for stale states or blocking dependencies.
  • Backlog grooming — scanning completed issues to suggest logical next tasks (e.g. "Now that the database model is locked down, we should groom the API endpoint tasks in Track 3").
  • Flagging any case where an agent closed an issue but bypassed Acceptance Criteria.

Why Breaking Down Work Prevents Hallucinations

LLMs are highly sensitive to context drift. Ask a model to write a complex application in one shot and its performance degrades as the conversation grows.

By partitioning work into targeted Tracks, letting an AI Technical Manager draft isolated, micro-scoped issues, and enforcing a manual SME review at the PR stage, a highly non-deterministic technology becomes a predictable, repeatable delivery engine.

What's Next?

With an automated SDLC now producing clean, validated code, the next logical step is infrastructure deployment itself. Coming up, we'll dive into how the AI-generated Ansible playbooks and Terraform configurations from Track 1 get used to bootstrap our bare-metal Proxmox hypervisors from a blank state.