Skip to content
Back to case studies
NDA-safeGenAI / AI2026

AI-Driven Development

Ad-hoc AI coding → governed Claude Code delivery loop with standards, app KBs, skills, commands, Jira context, and PR review gates.

Role
Forward Deployed AWS & GenAI Platform Architect
Context
Enterprise / Data & AI (NDA)
Duration
6+ weeks foundation and rollout design
Team
Architecture working group + pilot engineering team

Tech stack

  • Claude Code
  • Anthropic
  • Atlassian MCP
  • Jira
  • Confluence
  • Bitbucket
  • Markdown
  • Obsidian
  • Playwright
  • Azure DevOps
  • AWS Secrets Manager
  • Java
  • React
  • TypeScript
  • Python
Executive summary

Business problem and production context.

Business problem

The client wanted to move from AI as a small coding assistant toward AI-assisted delivery on real enterprise tickets. The risk was not model quality alone. Without repo standards, app memory, ticket structure, guardrails, and rollout sequencing, AI could generate code that compiles but does not fit the system, misses team conventions, or creates governance gaps.

Architecture decision

Designed the AI-driven delivery substrate: developer-facing standards, working-group program library, per-team application knowledge base, Claude Code slash commands, skill architecture, Jira/Confluence context flow, session logs, PR-review gates, and phased rollout from proof of concept to multi-team adoption. The approach kept human design and review as the quality gate while giving AI enough structured context to write useful implementation code and tests.

Result

Before and after.

AI usage model
BeforeAd-hoc assistant
AfterGoverned delivery loop
Context source
BeforeDeveloper memory
AfterCLAUDE.md + app KB + standards
Developer flow
BeforeManual coding first
AfterAI writes, developer reviews
Rollout path
BeforeTool adoption unclear
AfterPOC → pilot → tests → multi-team
Architecture

One command takes a ticket from loaded context to a reviewed pull request and an updated app knowledge base.

The developer workflow from ticket to reviewed pull request and knowledge base update. Source hosting and CI are not shown.

Reference design

A design the engagement produced, not a running system.

  1. 1. Work intake

    • Jira

      Supplies the ticket

    • Confluence

      Supplies linked design context

    • Atlassian MCP

      Brings Jira and Confluence context

  2. 2. Context

    • Repo instructions (CLAUDE.md)

      Per-repo rules for the agent

    • Org coding standards

      Enforceable rules for review

    • Application KB

      App memory kept in git

  3. 3. AI loop

    • Claude Code dev-start command

      Runs the whole loop

    • Skills

      Load standards, refresh KB

    • Checks with capped fix loop

      Verify tests and implementation

  4. 4. Review and memory

    • Pull request

      Carries the change to review

    • Developer review

      Final quality gate

    • Session log and KB diff

      Record what changed and why

How it works, step by step

  1. 1The developer runs one dev-start command with a Jira ticket or a work description.
  2. 2Claude Code reads the repo instructions, org coding standards, the ticket, linked Confluence design and the app KB.
  3. 3It confirms intent with the developer, then writes tests and implementation and runs checks in a capped fix loop.
  4. 4It opens a pull request, and the developer reviews and approves the change.
  5. 5It proposes a KB diff and a session log, which the developer confirms before the work counts as done.

Guardrails

  • Intent confirmed before any code changes
  • KB and session log updates confirmed before work is complete
  • Developer review stays the final quality gate
  • Org coding standards loaded at task start
  • Fix loop on failing checks is capped
  • Phased rollout from proof of concept to pilot, tests, then multiple teams

Considered and not used

  • Many separate commands: One dev-start loop so developers do not forget wrap-up steps or split context across sessions.
  • Confluence-only knowledge base: Git stays the source of truth for developer memory; Confluence is a mirror for nontechnical readers.
  • Hidden hooks for context loading: Deferred until the workflow was understood; hidden loading is harder to debug during adoption.
What Rahul owned

My part of the work, separate from the team's.

The team behind the engagement is in the facts row above. These are the parts I was responsible for, and the artifacts that show the work.

Owned scope

  • AI-driven delivery system architecture connecting tickets, design context, repo instructions, app memory, implementation, tests, pull requests, and KB/session-log updates
  • Developer-facing standards and command/skill patterns so Claude Code worked from organization-specific rules instead of generic coding advice
  • Rollout model from proof of concept to pilot, AI-authored test maturation, and multi-team adoption with developer review as the quality gate

Evidence artifacts

System architecture diagramSeven-process diagram setFour-step rollout planCommand and skill architectureApplication KB lifecycleStandards and onboarding vault
Constraints

What would fail first?

Every project has constraints. The useful work is naming them early enough that rollback, cost, and ownership are designed before an incident.

Enterprise fit

AI output had to fit existing teams, Jira, Confluence, Bitbucket, Azure DevOps, and review practices instead of requiring a new delivery platform.

Context reliability

Claude Code needed durable app memory, coding standards, ticket context, and design boundaries before touching implementation code.

Governance

The workflow had to preserve human approval, auditability, secret hygiene, and controlled rollout across multiple product teams.

Decision table

Trade-offs accepted on purpose.

Single command vs many commands
Chose one dev-start loop so developers do not forget wrap-up steps or split context across disconnected sessions.
Git KB vs Confluence-only KB
Kept git as source of truth for developer memory, with Confluence mirror for nontechnical readers.
Manual command vs hidden hooks
Deferred hooks until the workflow was understood; hidden context loading is harder to debug during adoption.
AI author vs developer author
Shifted developers toward reviewer/approver while keeping design, judgment, and final approval human-led.
Risk table

Production risks and how they were controlled.

AI generated code that compiled but did not fit existing patterns
Made CLAUDE.md, app KBs, and organization coding standards first-class context loaded before implementation.
Architecture working group
Developers forgot wrap-up and KB drift accumulated
Designed one dev-start loop with an explicit wrap-up gate for KB diff and session-log updates.
Developer + AI workflow owner
Broad rollout before the loop was proven
Sequenced POC, pilot code loop, test-loop maturation, and multi-team rollout as separate gates.
Program leadership
Implementation approach

Small steps, visible changes, fewer surprises.

  1. 01

    Mapped the target operating model: developer invokes a single Claude Code command, AI reads ticket/design/app context, confirms intent, writes code/tests, runs checks, opens a PR, then proposes KB/session-log updates.

  2. 02

    Split the system into three source-of-truth layers: developer-facing vault for standards and onboarding, private program library for roadmap/ADRs/skills/commands, and team KB vault for app memory and session logs.

  3. 03

    Designed organization-wide coding standards for Java, React/TypeScript, Python, API, database, and cross-language conventions so AI output could be reviewed against enforceable rules.

  4. 04

    Built the application KB pattern: app overview, ownership boundaries, architecture, dependencies, constraints, test state, integrations, database notes, and recent change history.

  5. 05

    Defined skills and slash commands including coding standards loading, KB create/refresh, and the dev-start loop that reads Jira, Confluence, repo instructions, and app KB before implementation.

  6. 06

    Added governance and rollout sequencing: proof-of-concept, pilot code loop, KB buildout, AI-authored test maturation, and multi-team rollout with developer review as the final quality gate.

Takeaway

What carries over to your system.

  • Enterprise AI coding fails when the model has no durable memory of the application. The app KB is the operating brain, not a documentation afterthought.
  • The best AI workflow still needs human gates. Gate 1 confirms intent before code; Gate 2 confirms KB/session-log updates before the work is treated as complete.
  • Standards must be short, enforceable, and loaded automatically. Generic language advice is noise; organization-specific rules are what make reviews consistent.
  • A phased rollout is safer than a platform announcement. Prove one real ticket, then one team, then tests, then multi-team adoption.

Rollback path

The rollout was reversible by phase: commands, skills, KB conventions, and team adoption could be paused or narrowed without changing Jira, Bitbucket, Confluence, Azure DevOps, or source-code ownership.

Cost considerations

No new infrastructure was required for the foundation. Cost decisions centered on Claude seats, bounded pilot scope, and avoiding hidden automation before the workflow proved useful.

Observability notes

Useful signals were PR quality, developer review friction, test pass/fail loop behavior, KB drift, session-log quality, and whether tickets carried enough structured context for AI implementation.

Services built on this work

Have a similar production problem?

Send the current architecture, bill concern, deployment pain, or GenAI reliability issue. I will help you find the first real bottleneck.

Rahul LadumorRequest the reliability auditContact form

Scroll or pinch to zoom, drag to move100%