Field Note · 2025
Rebuilding the SDLC Around AI 🤖
The tools we build software with now change every few weeks — a new model here, a new framework there, an agent that suddenly does half your job. Instead of fighting that, we’ve been rebuilding our whole software development lifecycle around it: one shared context that everything feeds from, and a fleet of Claude skills doing the heavy lifting between the humans. Here’s the shape of it.
The continuous context loop 🔄
The core idea is a single, shared context that everyone builds from. Strategy feeds it, product and engineering both build from it, and — crucially — whatever ships flows back into it. Architecture decisions, business strategy, personas, the product roadmap: it all lives in one place (for us that’s Notion, Linear and Figma), and Claude skills run across the whole thing.
Product turns that context into specs and tickets; engineering turns tickets into shipped code; and the loop closes when shipped work updates the shared context — so the next spec is written against what’s actually live, not what we hoped was live six months ago. Strategy just keeps feeding the top of the loop.
Engineering principles for an AI-driven SDLC
Before automating anything, we wrote down the principles we didn’t want to lose. Building resilient, production-grade systems in an era of monthly framework, language and model change means being deliberate about what’s allowed to change and what isn’t.
Build decoupled & agnostic
Keep everything model- and platform-agnostic — we lean on things like the AI SDK and OpenTelemetry so we’re never married to a single vendor. Reserve the right to pivot your stack and your models, use production signals to decide when, and be ready to swap out large parts of the stack quickly to stay competitive.
Best practices still apply
Agents writing the code doesn’t magically make the product stable, secure or scalable. Scaling, logging, security, readable classes and testable code are still the groundwork. We start the process at the CLAUDE.md level and build on it — encoding the lessons from Clean Code, Clean Architecture and Systems Design straight into the CLAUDE.md so every agent inherits them.
Introduce AI with guardrails
Define the steps every agent must take to inform itself before a task, and back them with a skills system plus evals — linters, security tests, the lot. Version your skills and prompts, manually traffic-light your PR-review skills, and retrain them on good and bad examples.
And own your prompts: if it isn’t in the repo, the rules aren’t yours. Build that feedback loop on day one, not day one hundred.
Build good skills
A skill is only as good as how reliably it fires and how little damage it can do when it does. Four things matter:
- Descriptive — the description is the activation signal. No match, no skill, and an invisible skill is a useless one.
- Specific — one skill trying to cover too many workflows either fires for the wrong task or never fires at all.
- Concise — keep a skill’s markdown under ~500 lines; they burn context just like code does.
- Secure — be careful with credentials, files, environment variables and database access.
The product side: humans own intent, AI accelerates 🧭
On the product side, humans stay firmly in charge of intent and the AI skills just make execution faster. Every feature flows through the same human-directed, observable pipeline:
- Author product strategy — the PM sets where to play and how to win, pressure-tested against proven strategy frameworks. (Notion)
- Create spec — a create-spec skill shapes a structured spec from strategy and live context, gated on any open questions. (Notion · Claude Code)
- Critique spec — a critique-spec skill scores every spec against a quality rubric. Quality at speed. (Claude Code)
- Shape & approve — the PM owns scope and intent, then locks the spec for build.
- Generate wireframes — new screens, including edge, error and empty states, generated from the live design system over MCP. (Figma · Claude Code)
- Approve & polish designs — the designer polishes the screens and the PM signs off before any engineering begins. (Figma)
- Generate tickets — well-crafted, complete tickets handed to engineering against shared standards and rubrics. (Linear · Claude Code)
- Adjust & publish — the PM owns the work and stays accountable for quality and strategic alignment.
The engineering side: 3 checkpoints, 5 agents 🛠️
Once tickets exist, engineering runs as a mostly-autonomous pipeline with humans at just three checkpoints and agents doing the rest — five of them, end to end:
- Break down tickets (AI) — Claude Code turns product tickets into technical tasks. (Linear · Claude Code)
- Approve tickets (human) — the tech lead signs off before any code is written. (Linear)
- Scaffold tests (AI) — a test agent pulls the acceptance criteria straight from the ticket and writes the tests first, TDD-style.
- Plan implementation (AI) — a planning agent drafts an implementation plan with security and architecture context baked in.
- Review & iterate on the plan (human) — the engineer refines the plan and pair-programs with Claude to build it. (IDE/CLI)
- Security scan (AI) — SAST and DAST analysis catches vulnerabilities before merge.
- Code review (human) — an engineer validates logic, security and architectural fit, then sends feedback. (GitHub)
- Deploy & monitor (AI) — continuous deployment with AI-driven observability and bug fixes. (CI/CD · AI Ops)
So what does this actually buy us?
None of this removes the humans — it concentrates them where judgement actually matters: strategy, scope, the plan, and the final review. The agents handle the mechanical middle, and because everything they touch flows back into the shared context, the system gets a little sharper every time something ships.
That’s the whole bet: keep the taste and the accountability human, and let the loop do the grind. 🔁