How I Built an AI-Driven SDLC with GitHub Copilot and Obsidian
For the past year, my team at JP Morgan Chase has been running an experiment: what happens when you pair GitHub Copilot with a structured, searchable knowledge base? The result is an AI-driven SDLC that takes work from JIRA intake to production code with dramatically less friction — and dramatically fewer meetings.
This post breaks down the workflow, what worked, and what I’d do differently.
The problem with tribal knowledge
Every engineering team runs on context that lives in people’s heads: why a component behaves the way it does, which edge cases broke production in 2022, what the acceptance criteria really meant. When that context isn’t written down, AI tools guess — and they guess confidently.
So we made a rule: if it isn’t in the knowledge base, it doesn’t exist. We use Obsidian as our shared brain — requirements, architecture decisions, API contracts, and postmortems all live there as plain markdown.
The workflow
Requirements intake
JIRA tickets are distilled into the knowledge base within a day of landing — stripped of ambiguity, linked to prior decisions.
PRD generation
Copilot drafts the PRD from that distilled context. A human edits; the AI accelerates.
Task decomposition
The PRD is broken into tasks with explicit acceptance criteria, each linked back to source docs.
Grounded code delivery
Engineers implement with Copilot reading the same documentation — no hallucinated APIs, no invented patterns.
Tests alongside code
Unit, component, and E2E suites are AI-generated in the same pass, which raised our regression confidence and removed QA as a bottleneck.
The knowledge base is the product. The AI is just the interface.
What I’d do differently
Start smaller. We tried to document everything at once, and the first month felt like a writing exercise instead of engineering. The compounding only kicked in once the knowledge base covered the 20% of context that answers 80% of questions.
Cycle time from requirements to production dropped meaningfully, and self-service releases — powered by CLI tooling for CDN publishing and feature flags — made deploys boring. Boring is the goal.
If you’re leading a team and sitting on years of tribal knowledge, that’s your moat. Write it down, point your tools at it, and let the machines do the remembering.