DEV Community

Cover image for How I Built an AI-Governed SDLC for Teams Using Claude Code and Cursor, All Running Locally on Docker
Saurabh
Saurabh

Posted on

How I Built an AI-Governed SDLC for Teams Using Claude Code and Cursor, All Running Locally on Docker

#ai #opensource #devops #architecture

The Problem I Was Trying to Solve

AI coding assistants have fundamentally changed how developers work. Claude Code, Cursor, GitHub Copilot; your team is already using them, whether officially sanctioned or not.

But here's what nobody's talking about: what happens after the AI-generated code lands in your repo?

A few hard questions I kept hitting as an architect:

  • How do you know an AI tool didn't leak a secret or API key into source code?
  • How do you enforce guardrails on what Claude Code or Cursor is allowed to do in your codebase?
  • How do you measure AI adoption ROI - not vibes, but actual metrics?
  • How do you give security and compliance teams an audit trail for AI-assisted changes?

I didn't find a ready-made answer, so I built one.

What I Built: AI-Governed SDLC

The idea was simple: wrap AI-assisted development in an observable, policy-enforced pipeline; without sending a single byte to the cloud for governance purposes.

Here's the full architecture:

┌─────────────────────────────────────────────────────────────────────┐
│                     LOCAL WINDOWS WORKSTATION                        │
│                                                                       │
│  ┌──────────────┐    ┌──────────────┐    ┌─────────────────────┐   │
│  │  DEV-1       │    │  DEV-2       │    │   GITEA (Local Git) │   │
│  │  Claude Code │───▶│  Cursor AI   │───▶│   + Webhooks        │   │
│  └──────────────┘    └──────────────┘    └────────┬────────────┘   │
│                                                    ▼                  │
│  AI Config Files:                        ┌─────────────────────┐   │
│  • CLAUDE.md    (guardrails)             │   JENKINS (CasC)    │   │
│  • .cursorrules (guardrails)             │   • detect-secrets  │   │
│  • .claudeignore                         │   • Semgrep SAST    │   │
│  • .cursorignore                         │   • AI Policy Check │   │
│                                          │   • pytest + cov    │   │
│                                          └────────┬────────────┘   │
│                                                   ▼                  │
│                                          ┌─────────────────────┐   │
│                                          │   Prometheus + Loki │   │
│                                          │   Grafana (3 boards)│   │
│                                          └─────────────────────┘   │
│  AI AGENTS (CrewAI):                                                 │
│  Code Review Agent | Test Gen Agent | Architecture Review Agent      │
└─────────────────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Let me walk through every layer and the architectural decisions behind them.

Layer 1: AI Guardrail Configs (Before a Single Line is Committed)

The first, and most underrated, layer is controlling what the AI tools are allowed to do in your repo. This happens before any code leaves the developer's machine.

CLAUDE.md

Claude Code respects a CLAUDE.md file in the repo root. Think of it as your AI's onboarding doc and rules of engagement combined. Mine includes:

  • Coding standards and patterns to follow
  • Files and directories that are off-limits (.env, secrets, infra configs)
  • The tag convention: every AI-assisted commit should include [AI-ASSISTED] in the message
  • A reminder of what this codebase does, so context isn't lost

.cursorrules

Cursor reads .cursorrules - same concept, different format. I define security rules, architecture patterns to honour, and frameworks to stay within.

Why This Matters Architecturally

Most teams think AI governance starts at the pipeline. It doesn't. It starts at the IDE. These config files are your first line of defence. They're also version-controlled, reviewable, and enforceable through PR policy.

Layer 2: Jenkins CI/CD - The Automated Quality Gate

Every push from either developer (simulated via Git worktrees for the PoC) triggers a Jenkins pipeline configured as code via casc.yaml. Zero-click provisioning.

The pipeline runs six stages in order:

Stage 1: detect-secrets (Secret Scanning)

stage('Secret Scanning') {
    steps {
        sh 'detect-secrets scan --baseline .secrets.baseline'
    }
}
Enter fullscreen mode Exit fullscreen mode

If a developer, human or AI, hardcodes a password, API key, or connection string, this stage BLOCKs the pipeline. Full stop. No exceptions.

I deliberately tested this in the PoC:

echo 'DB_PASSWORD = "super-secret-password-123"' >> app/src/main.py
git add . && git commit -m "feat: add database connection"
git push origin feat/dev1-auth-module
# → detect-secrets fires. Pipeline BLOCKED.
# → secret_leak_attempts_total metric increments in Grafana
Enter fullscreen mode Exit fullscreen mode

That last part, the metric incrementing in Grafana, is what makes this governance, not just a check.

Stage 2: Semgrep SAST

Static analysis runs on every push. Findings are categorised by severity and pushed as metrics:

sast_findings_total{severity="high"}
sast_findings_total{severity="medium"}
sast_findings_total{severity="low"}
Enter fullscreen mode Exit fullscreen mode

Stage 3: AI Policy Check

This stage verifies that AI-assisted commits are tagged correctly (the [AI-ASSISTED] convention). It's lightweight but creates the audit trail compliance teams need.

Stage 4: pytest + Coverage

Automated tests run, and test_coverage_percent is pushed to Prometheus. If you're using the AI Test Generation agent (more on that below), coverage trends are visible in real-time.

Stage 5 & 6: Metrics Push + Notification

All metrics flow: Jenkins → Prometheus Pushgateway (:9091) → Prometheus (:9090) → Grafana (:3001)

Layer 3: CrewAI Agents - Agentic SDLC Roles

This is where it gets interesting. Three CrewAI agents handle roles that traditionally require senior human bandwidth:

Code Review Agent 

poetry run python agents/code_review_agent.py \
  --branch feat/dev1-auth-module \
  --output reports/review-dev1.md
Enter fullscreen mode Exit fullscreen mode

Reviews the diff against architectural standards, security patterns, and codebase conventions. Outputs a structured Markdown report.

Test Generation Agent 

poetry run python agents/test_gen_agent.py \
  --source app/src/ \
  --output app/tests/generated/
Enter fullscreen mode Exit fullscreen mode

Generates pytest test cases for existing source code. In my benchmarks on the sample app, this agent consistently pushed coverage above 70% on the first run.

Architecture Review Agent 

poetry run python agents/arch_review_agent.py \
  --readme README.md \
  --output reports/arch-review.md
Enter fullscreen mode Exit fullscreen mode

Reviews architectural decisions documented in the README against best practices. Useful for PoC validation and ongoing ADR (Architecture Decision Record) hygiene.

The key architectural decision here: agents are invoked as scripts, not as part of the main pipeline. This keeps the CI pipeline fast and deterministic, while agentic tasks run on-demand or asynchronously.

Layer 4: Grafana Observability - Three Dashboards

Grafana is auto-provisioned from grafana/dashboards/ - no manual import needed. Three dashboards, each targeting a different stakeholder:

Dashboard 1: AI SDLC Health

For engineering teams and DevOps. Shows:

  • Pipeline pass/fail rate over time
  • SAST findings trend by severity
  • Secret leak attempt count
  • Test coverage percentage trend
  • Pipeline duration (a proxy for developer feedback loop speed)

Dashboard 2: Adoption & ROI

For engineering leadership. Shows:

  • ai_suggestions_accepted_total vs ai_suggestions_rejected_total - acceptance rate tells you how well-calibrated your AI tools are
  • Developer adoption trends over time
  • AI-assisted commits as a percentage of total commits

Dashboard 3: Governance & Compliance

For security, risk, and compliance teams. Shows:

  • Policy violations timeline
  • Guardrail enforcement events
  • Audit trail of AI-assisted changes (every [AI-ASSISTED] tagged commit)

This last dashboard is the one that gets architecture review sign-off in enterprise contexts. Auditors don't want to hear "we're using AI responsibly" - they want to see a dashboard.

The Responsible AI Metrics Model

The full metrics schema:

Metric What It Measures
ai_suggestions_accepted_total AI suggestions merged to repo
ai_suggestions_rejected_total AI suggestions discarded
ai_policy_violations_total Guardrail config triggers
sast_findings_total{severity} SAST findings by severity
secret_leak_attempts_total detect-secrets pipeline findings
test_coverage_percent pytest-cov output
ai_agent_review_score 0–100 score from code review agent
pipeline_duration_seconds End-to-end pipeline time
pipeline_success_total Successful pipeline run count

These aren't vanity metrics. The acceptance ratio and policy violation count together tell you whether your AI configs are well-calibrated; if rejection is high, your guardrails are too restrictive; if violations are high, they're too loose.

Setup in 10 Minutes (After Prerequisites)

Prerequisites: Docker Desktop, Python 3.11, Poetry, Semgrep, detect-secrets, Claude Code CLI.

# Clone the repo
git clone https://github.com/saurabh-oss/ai-sdlc-poc
cd ai-sdlc-poc

# Install dependencies
poetry install

# Configure your environment
cp .env.example .env
# Edit .env - add your Anthropic API key for agents

# Bring up the full stack
docker compose up -d
Enter fullscreen mode Exit fullscreen mode

Services spin up at:

Full step-by-step setup is in STEP_BY_STEP_SETUP.md.

To seed the Grafana dashboards with demo data for a presentation:

poetry run python scripts/seed_demo_data.py
Enter fullscreen mode Exit fullscreen mode

Key Architectural Decisions and Trade-offs

Why Jenkins, not GitHub Actions?
Enterprise on-prem teams often can't use cloud-hosted runners. Jenkins + CasC gives you a fully declarative, version-controlled pipeline that runs in Docker with zero cloud dependency. Also, Jenkins is where most enterprise pipeline engineers already live.

Why Gitea, not a real Git host?
Same reason. The PoC simulates a fully air-gapped environment. Gitea gives you webhooks, PR flows, and a familiar UI without touching GitHub or GitLab.

Why CrewAI for agents?
CrewAI's role-based agent model maps cleanly to SDLC personas (reviewer, tester, architect). The role/goal/backstory schema makes agents easy to audit and explain to non-technical stakeholders, which matters when you're pitching this to a governance committee.

Why store metrics in Prometheus rather than a database?
Time-series is the right data model for pipeline metrics. Prometheus + Grafana is the defacto open-source observability stack. Adding Loki for log aggregation gives you correlated log + metric views in Grafana, essential when you're debugging why a specific guardrail fired.

What's Next

This is a PoC, intentionally. Things I'm considering for v2:

  • MCP integration: expose the CrewAI agents as MCP tools so Claude Code can invoke them directly from the IDE
  • PR-level agent commentary: post the code review agent's output as a Gitea PR comment automatically
  • Policy-as-code: move guardrail configs to a shared, versioned policy repo that all projects inherit from
  • Ollama support: swap Anthropic API for a local Ollama model for full air-gapped operation

The Bigger Point

AI coding tools are not a risk to be blocked, they're an acceleration to be governed. The SDLC wrapper matters as much as the AI tool itself.

Most teams are doing this backwards: adopting AI tools first, building governance second (or never). This PoC demonstrates that you can build the governance layer first and it actually makes AI tools more adoptable, because it gives security and compliance teams the visibility they need to say yes.

Repo: github.com/saurabh-oss/ai-sdlc-poc

If you're working on AI governance in your SDLC, or trying to get enterprise sign-off on AI coding tools, I'd love to hear what patterns you're using. Drop a comment below.

Saurabh Srivastava is a Senior Enterprise Architect with 16+ years of experience in enterprise architecture, AI/GenAI, and open-source tooling. Building in public at github.com/saurabh-oss. Follow on X: @sauvast | LinkedIn: linkedin.com/in/saurabh-tcs

Top comments (0)