Most teams try to make AI useful by improving prompts. On Teamdeck, the bigger lever was making the repository describe itself, then putting teeth behind the description.
In about nine weeks we moved Teamdeck’s stage estate onto Temporal, Pulumi, and ECS while product work continued. Sixty pull requests. Median open-to-merge time of 1.2 hours. Roughly 37,000 lines of plans, specs, ADRs, and runbooks beside the code. Production cutover is still ahead. The point of publishing now is the process, not a finished migration claim.
Full metrics and sequencing live in the Teamdeck AI SDLC case study. The greenfield counterpart is nini.bot: same harness class, different estate. Below is what the Apptension SDLC actually enforced.
Code generation is the easy half. What made agent-driven change safe was a process with teeth: machine-readable conventions, written plans before code, and gates enforced by CI rather than by intention.
The repo has to be readable by a machine
The highest-leverage artifact is a hard-capped entry point that holds only basics plus a map to the docs tree. Three properties matter:
- A bindings table. Default branch, branching strategy, code host, CI provider, verification commands, commit convention, PR title format. Concrete values in one place.
- A docs map, not docs. Each row says what a document holds and when to read it. Missing docs you need become part of the task.
- The map evolves in the same PR as the structure it describes. A drifting map is worse than no map.
Path-scoped conventions attach to the file you are about to edit. Tribal knowledge becomes something an agent (and a human) can load on demand. This is the same spine we install for client teams on the Agentic SDLC portal and walk through in the delivery process.
Design before code, written down, every time
The workflow is generic: understand, plan, implement, verify, document. Non-trivial work gets a written spec first. Multi-week programs get phase plans. Choices that constrain the future get ADRs with rationale and rejected alternatives.
Why this matters more with an agent than without: a plan is what you review before tens of thousands of lines exist. Reviewing intent is cheap. Reviewing a finished implementation of the wrong intent is not.
ADRs get amended rather than rewritten. The document records how thinking moved, which is exactly what a future agent needs and what an overwritten document destroys. On Teamdeck that produced 30 phase plans, 20 design specs, 7 ADRs, and 6 runbooks in the same window as the code.
Gates, not vibes
The program ran against explicit go/no-go gates with written entry criteria. An agent cannot start a phase whose entry criteria are unmet, because the roadmap and plan files say so.
The worker-platform gate is the clean example: a hands-on spike against real workloads, a scorecard, and a recorded decision to Temporal Cloud for stage and prod. Managed RabbitMQ alternatives were evaluated and rejected with reasons, not dismissed. That sequencing call (workers first, account cutover later) came from a human review conversation, not from the model.
If you are scoring your own org, use the same four dimensions we use in enablement work: flow, quality, control, and economics. The agentic enablement playbook and the maturity instrument make that concrete.
CI that enforces the process, and is itself tested
Enforcement is not documentation. It is workflows and scripts:
- PR titles must be Conventional Commits plus a closing keyword, because the squash subject is the only commit message that reaches the release line.
- Only the release line merges into master. A branch merged straight to master builds no image, so production would ship without the change. The failure mode is silent. A required check exists because of that silence.
- Versions are computed from Conventional Commit subjects, never hand-typed.
- Merging into a release line auto-deploys stage. Board cards move themselves.
- Automated first-pass review runs on every PR so human attention goes to judgment calls.
- Provider drift detection catches failure modes preview cannot see.
Thirteen gate scripts ship with thirteen test files. When automation keeps an agent honest, the automation has to be trustworthy first.
The trust model: AI in CI is a supply-chain surface
Review jobs read untrusted input (the diff, the PR body) and hold no write token. The only write-scoped job checks the validator out from the base SHA, never the head, so the pull request under review cannot edit the validator that runs against it. Workflows are default-deny. Writes go through a dedicated GitHub App token with rotation documented in a runbook.
Review and triage support two provider paths behind a repository variable. The model is runtime configuration, not an architectural commitment. Costs and capabilities move monthly; a process that requires a PR to change provider will not track them.
What the agent is bad at (and what the process does about it)
Do not write an article that claims the loop is frictionless. Three patterns kept repeating on Teamdeck:
- Confidence is uncalibrated. An agent will state a merge-triggered workflow works before anything has triggered it. Answer: verification blocks that want real command output, and a “left undone” block that wants the truth.
- Preview is not proof. A Pulumi provider major can preview clean and fail on apply. No amount of diff review catches that. Answer: apply majors against stage before merge, plus drift detection.
- Defaults drift from house style. Comment density, vacuous tests, and over-eager scope expansion needed corrections written into repo rules, or they regress.
Half of agent friction is not model capability. It is environment assumptions baked into generic instructions. One bindings-table line fixed two hours lost talking to the wrong git remote. That is the humble version of the same lesson: make the repo tell the truth.
Measured effects (stage-safe)
- 60 PRs in about 5.5 weeks of GitHub-native history, median open to merge 1.2 hours, p90 12.4 hours.
- Documentation stopped being a follow-up. It grew alongside the code (~37k lines of plans, specs, ADRs, runbooks).
- Product development continued in parallel: 57 commits of ordinary feature work from other authors, no feature freeze.
- RabbitMQ decommission: 142 files, net deletion of roughly 2,300 lines, replaced by nine Temporal task queues.
Production is not cut over yet. Cost parity and deploy wall-clock comparisons wait for measured post-cutover numbers. That honesty is part of the process story.
How this maps to Agentic SDLC for your org
The parts of the SDLC people treat as bureaucracy (a written plan, a recorded decision, a title convention, a required check) turn out to be the load-bearing parts once an agent is doing the typing. They convert a fast writer into a safe one.
If you are evaluating enablement for an engineering org of roughly 15 to 300 engineers with a sponsor:
- Start with the Agentic SDLC offer: two-week install, six-month managed adoption, client-owned harness.
- Walk the public instruments: process, measurement, ROI, scorecard.
- Compare proof shapes: greenfield product vs legacy platform modernization.
- For the economics framing of AI coding adoption (not this estate specifically), see chasm, debt, trust, and proof and measuring agentic engineering ROI.
