The Repository Becomes the Process: Rebuilding SDLC for the AI Era
Software engineering has never really been about writing code. It has been about preserving institutional memory, what a team knows about why a system works the way it does, what was tried and abandoned, what a customer actually needs versus what they said. Institutional memory does not live in a wiki, a meeting, or a person’s head anymore, or rather, it should not, because that is exactly where it used to live, and exactly why it kept decaying. A BA writes a BRD, a lead writes a tech spec, a developer reads both once, and from that point the actual source of truth becomes whatever is in the developer’s head plus whatever is in Teams. Six months later the BRD is a historical document, not institutional memory anyone can still use.
SDLC was never slow because a BRD or a tech spec took long to write. It was slow because the memory inside those documents decayed the moment anyone stopped looking at them, and because BRD sign-off, design sign-off, and spec sign-off were sequential gates, each waiting on a person’s calendar. AI collapses the drafting side of that gate from days to minutes, turning it from a scheduling problem into a review problem, and the two are not the same speed. But drafting speed alone does not fix the memory problem. Point Copilot or any coding agent at a codebase with no persistent memory and it will happily generate code fast, and get details wrong fast too, because it has no memory of what was decided, why, or what broke last time.
The idea running through everything in this document is Repository as Memory. For the first time, institutional memory can become part of the repository itself, as versioned files an AI agent reads before it writes a single line and updates, with human review, after every session. AI-assisted delivery is not about typing less. It is about making memory cheap enough to keep current every day, instead of once a quarter.
This is not free of the problems SDLC had. Memory still decays if nobody owns updating it. Reviews still get rubber-stamped under deadline pressure. What changes is the cost. A BRD in SharePoint that a PM updates once a quarter is normal, because updating it competes with everything else on a calendar. A BRD in Markdown, sitting in the same repo as the code, updated by an AI agent as a side effect of every session, costs almost nothing to keep current. The discipline required does not disappear, it moves from remembering to update the wiki to reviewing the diff the AI proposed to the memory itself.
Repository as Memory
Everything that used to live in SharePoint, a shared drive, or someone’s inbox moves into the repository as Markdown, versioned alongside the code it describes: business requirements in specs/brd/, architecture decisions in specs/tech/, team conventions in standards/, a running record of what each session learned in lessons/, and a map of the codebase itself in CODEMAP.md. None of these are documentation about the code. They are institutional memory the code depends on, read by the AI before every session and updated, with human review, after every session.
The design decision underneath all of it is simple: memory that lives next to the code gets read by the same tool that touches the code. Memory that lives in a wiki gets read by nobody, which is exactly what happened before.
Old world: Requirement -> Word doc -> Meeting -> Teams messages -> Developer's memory
Repository as Memory: Requirement -> BRD.md -> TECH.md -> CODEMAP.md -> Lessons.md -> Next AI session
The old chain loses fidelity at every arrow, a meeting summarises the Word doc, a Teams message summarises the meeting, and a developer’s memory summarises the Teams message, so by the time code gets written, several rounds of paraphrase sit between it and the actual requirement. The new chain is the same length, but every arrow is a file, versioned, reviewable, and read fresh by whatever touches it next, nothing summarises anything, it just gets passed forward whole.
BRD and tech spec as memory a machine can read
A BRD does not need prose written for an executive audience anymore, since the audience now includes an agent that has to derive acceptance criteria from it without asking a follow-up question every time. What makes a BRD usable as memory rather than a one-time artifact is its frontmatter: an id, an owner, a status, a link to the tech spec it feeds, and a source field recording what it was actually drafted from, a Word file, a meeting note, a screenshot, so a questioned requirement can be traced back to what it came from rather than a paraphrase of a paraphrase. That frontmatter is also what lets specs/INDEX.md be generated automatically instead of hand-maintained, closing one of the two places staleness used to creep in, the body still needs a human to keep it honest.
The tech spec is where an architect’s actual judgement becomes memory too. An AI cannot decide whether checkout state belongs in Redis or a session table, but once a person decides, the reasoning has to be written down, or the next session re-litigates the same decision from scratch, or worse, quietly reverses it. A tech spec’s brd field ties it back to the requirement it satisfies, and its module field ties it to the code it governs, closing the loop between why, what, and where.
Coding standards as memory of judgement calls
standards/coding-standards.md should skip anything a linter already catches, a formatter enforces indentation without anyone asking an AI to. What belongs here is memory of the judgement calls that vary team to team: naming conventions for hooks, how errors surface to the UI, when to use a repository pattern versus a direct query, how retries handle a flaky external call. Include the reasoning, not just the rule, an agent facing an edge case reasons better from “we do X because Y” than from a bare rule it has to apply mechanically.
How a PM actually uses this
“PM” covers two roles here, both curators of institutional memory rather than document writers, one curates what it says, the other curates what state it’s in.
A technical program manager curates content: what a feature should do and why. The input is rarely one clean sentence, usually a requirements doc, a Word file, an email thread, or a screenshot of a legacy screen. The PM shares that material, the AI drafts the BRD, and the PM’s job is no longer producing memory from a blank page, it is correcting it: pushing back on wrong acceptance criteria, tightening non-goals where the AI over-scoped, resolving open questions before engineering starts. Anything the source left ambiguous becomes an open question rather than a quiet assumption. Mid-sprint changes work the same way, instead of a Teams message, the PM has the AI append a dated, reasoned entry to the BRD, memory gets amended, not replaced by something that scrolls out of view.
A project manager running delivery curates state, not content, and is not writing BRDs. What they are accountable for is what shipped, when, and what is still open, and a status call is really just an attempt to reconstruct memory that already exists in the repository. Sprint plans stop starting from a blank page, since approved FRs already sit in specs/brd/, cross-referenced against CODEMAP.md and lessons/INDEX.md for sizing history, so the agent drafts a first pass before the team argues capacity, which stays a human call. Status reporting works the same way, every requirement’s position is already a ticket state tied to a real artifact, so the agent can generate an update straight from those states instead of chasing five people. The report is only as honest as the memory behind the board.
Repository as the Process
The second idea worth naming is Repository as the Process. Sign-off used to be a meeting where someone nodded at a document, planning used to be a ceremony that started from a blank page, and status used to live in someone’s memory until a stand-up asked for it. All three now run through the same mechanism: a pull request against the repository.
A requirement moves through one repeating flow, requirement intake, technical design, implementation, review, and session close, each stage producing a versioned artifact and a ticket state that mirrors it rather than a status someone has to remember to report.
What matters here is the shift in what “sign-off” means. A spec change is a branch, not an edit buried in a wiki’s version history. A PM or architect proposes a revised BRD or tech spec the same way an engineer proposes a code change, and the diff shows exactly what changed against the last approved version, not the whole document again, which is the real cycle-time win, not the AI’s drafting speed. Flipping a BRD’s frontmatter from status: draft to approved inside a merged PR leaves a reviewer’s name and a timestamp in git history, a far more durable record than a meeting note or a reply-all email nobody can find six months later.
The failure mode is the one code review already has, rubber-stamp approval, and it is worse for specs than for code. A reviewer skimming a diff for syntax errors is trained to actually look, while a reviewer skimming a Gherkin diff can miss that a requirement got quietly narrowed or a non-goal got dropped, since prose changes read as harmless in a way a broken build does not. The fix is the same one good engineering orgs already use for code ownership: a .github/CODEOWNERS entry mapping BRDs to the PM group and tech specs to the architecture group, so approval requires someone with actual authority over that content, not whoever had merge rights free that afternoon. Not every disagreement disappears into a PR thread either, a genuine dispute still needs a conversation, it just has to land somewhere afterward, a PR comment or a line in the tech spec’s architecture decision section, instead of evaporating the moment the meeting ends.
How a BRD change actually reaches the code
None of this should depend on someone remembering to manually ask the agent whether a spec changed, that would just be the old wiki problem wearing a new coat. A BRD change is itself a PR, so .github/CODEOWNERS already notifies the affected devs and architect the same way it would for a code change. The tech spec does not update itself, but it gets flagged: a CI check on merge to specs/brd/** walks CODEMAP.md, finds the dependent tech spec, and opens a lightweight follow-up noting the tech spec needs review, a flag, not an automatic edit, the architect still decides whether the change actually alters an architecture decision. In this starter kit, that flag always routes back into the planner stage rather than a separate CI-only path. The code itself catches up for free the next time someone starts a session on that module, since the standing instructions have the agent read the BRD and tech spec fresh every time rather than caching them. The only real gap is work already in flight when the change lands, which is exactly what the CODEOWNERS notification reaches mid-session, not just the next session that happens to start fresh.
Sprint planning under this model
The ceremony stays, what gets cheaper is the drafting that used to happen before the meeting. A PM walks into planning with FRs already sitting in specs/brd/ tagged approved, and CODEMAP.md already showing which modules each FR touches, so the agent can propose a task breakdown and pull sizing signal from lessons/INDEX.md for any module with comparable history. Sizing itself, and what fits this sprint’s capacity, stays with the team, capacity is a constraint about people, not files, and that is not a place to let AI substitute judgement.
Standups change more than planning does. “What did you do yesterday” stops being a recall exercise, a standup can point at yesterday’s lessons file instead. Retro folds into the weekly curation of lessons/INDEX.md this setup already requires, so it stops being the one time in two weeks people try to remember what went wrong.
The risk worth naming directly: fast drafting can look like fast commitment. A PM pressured for velocity will be tempted to promise a sprint’s worth of FRs because the BRD took twenty minutes instead of two days. Drafting speed and commitment speed are not the same thing, and the sprint boundary protects the team from one collapsing into the other, arguably harder now than before AI, since nothing external is slowing the PM down anymore.
Infrastructure is a module, not a separate track
Infrastructure sits inside this same model as another module type in CODEMAP.md, entered the same way as any feature module. What differs is not the model but two attributes: infra rarely has a business stakeholder writing a BRD, so the tech spec or an RFC of the same shape is the primary document, and the CODEMAP.md entry should carry blast radius and environment scope alongside ownership, since a shared VPC module carries different weight than one service’s deployment config.
The approval gate is where the difference bites. A checkout FR sized wrong costs a sprint, an infra change applied wrong can take a shared dependency down for every team on it. Drafting an infra RFC gets faster the same way a BRD does, but the human sign-off before touching a protected environment should not compress at the same rate, drafting speed and approval speed are two different dials, only one should move for a module carrying that much blast radius. Skills earn their keep more here than on app modules, because infra correctness is testable before anything ships, a skill that runs terraform plan and checks the diff against a baseline before handing it to a person does more than a standing instruction that only describes conventions. Lessons capture pays off most here too, since this is not a new idea for infra teams, it is the postmortem, done continuously instead of only after an incident.
The feedback loop: lessons as memory of near-misses
This is the part most AI-assisted setups skip, and the part that actually produces compounding speed rather than a one-time bump. At the end of a session, before context is lost, the agent generates a lessons file capturing what assumption turned out wrong, what took three attempts to get right, what pattern worked cleanly and is worth repeating.
This file is not a diary. Every entry should update a spec, update a standard, or get explicitly discarded as noise. lessons/INDEX.md is the curated summary a lead reviews weekly, folding durable lessons into standards and closing out the rest, without that curation step the folder becomes what old retro documents always became, written once, read never. Generating the file is the easy half, curating it into standards, deciding what actually generalises beyond one session, is the half that must not be skipped, and that judgement still sits with a person, not the agent that wrote the draft.
Making the memory machine-readable, without depending on the machine
The instructions layer is what makes any coding agent actually read all of this before writing code, and while the repository behind this article implements it with GitHub Copilot CLI, the mechanism itself is not specific to Copilot. Two ideas hold regardless of which tool eventually runs this.
The first is that standing instructions and on-demand skills solve different problems, and confusing them is what makes any tool’s context window rot. Instructions load on every request whether relevant or not, so they have to stay short, a pointer to memory rather than memory itself. Skills, or whatever the equivalent is called in a given tool, load only when a prompt matches what they describe, so they can afford to carry a full template or a script without costing anything on the sessions that never touch them.
The second is that memory has to stay cheap to search as it grows. A corpus of two hundred BRDs and eighteen months of lessons files breaks any instruction that says “check specs and lessons before writing code,” because that reads fine on day one and becomes a full-folder scan by month six. The fix is the same regardless of tool: an index file per folder, one line per document, and a rule that points the agent at the index, not the folder, so it fetches only the one or two files it actually needs rather than scanning everything to find them.
The repository provides one working implementation of both ideas, using GitHub Copilot CLI. The operating model itself is tool independent.
The codebase map itself
Indexing specs, standards, and lessons solves the document side of memory. The remaining cost is src/ itself: without a map, the agent finds the right module by listing directories and opening files until something looks relevant, the very full-scan behaviour this whole exercise is trying to remove. CODEMAP.md sits at the repo root, next to AGENTS.md, one entry per top-level module, four or five lines each, deliberately thinner than architecture documentation, no design philosophy, no diagrams. It is a router: given a task, it tells the agent which directory owns the work, which BRD and tech spec govern it, which instructions file applies, and who to flag if something is ambiguous, resolved before a single source file gets opened. Keeping it current is one line in the same session-close instructions the agent already follows, not a separate chore assigned to a person after the fact, which is what keeps it from going stale the way an unowned architecture wiki page always does.
Standards across repos, not just one
Everything so far assumes one repo with one standards/ folder, and that model holds until a platform team or a Cloud Center of Excellence needs a baseline to hold consistently across a few hundred repos, not one. Copy the file into each repo and it drifts the moment any team edits its local copy without the others knowing, the same staleness problem this whole document exists to solve, just relocated across an org instead of across a wiki. The fix is the same PR discipline run one level up: a canonical standards repo owned by the CCoE publishes a new baseline, a scheduled job opens a PR against each downstream repo’s standards/ folder, and a human in that repo still reviews and merges it, so a legacy service that truly cannot meet a new baseline yet can hold a documented exception rather than silently drifting out of sync.
Retraining the PM and the architect, not just the agent
The .github/ folder is the easy part. The heavy lift is a PM learning to actually read a diff instead of skimming it, and an architect treating a tech spec PR with the same seriousness as a production change, and neither is something a skill file can produce. This is the same transition engineering went through when code review stopped being optional, some engineers resisted it, and it held only because leads modelled the discipline for months. The same shift is now being asked of PMs and architects, and it will not stick from a single training session any more than code review did.
What works is pairing, not a workshop. The first two or three BRD PRs a PM reviews should be reviewed alongside an engineering lead, specifically to catch the rubber-stamp habit before it forms rather than after a bad spec has already merged, and this needs to be written into how the role is actually measured, because under sprint deadline pressure, anything not measured reverts to whoever has the least time that week. Someone concrete needs to own this for the first quarter, checking that curation is actually happening rather than left for later. Call it an adoption owner if nothing else fits, but name a person, because the file-based mechanisms in this document run on their own once written, and this is the one part of the model that does not.
Memory debt
The failure mode to watch for has a name too: memory debt. It looks exactly like technical debt, and behaves the same way. Specs, standards, and lessons quietly drift out of sync with each other while everyone assumes the AI is keeping them honest, and because instruction layers merge rather than override cleanly, the agent may follow whichever one happens to load with higher priority rather than the one that is correct. This is the same risk a stale BRD carried in the old model, just faster to accumulate and easier to miss, because nobody is manually re-reading a wiki page anymore to notice the contradiction.
The guardrail is the same one good engineering orgs already had for technical debt: nothing merges without a human reviewing the diff, spec files and lessons files are pull requests, not agent output trusted silently. The speed gain is real and substantial, sessions that used to require a kickoff meeting, a BRD walkthrough, and a tech spec review can now start from a PM’s plain-language description and produce a working draft within the hour. But the gain comes from removing the friction of re-explaining context every time, not from removing the judgement that used to sit in those meetings, that judgement still needs a person in the loop, applied to a diff instead of a discussion.
None of the velocity in this document arrives by installing a CLI. It arrives only if the PM drafting the BRD, the architect approving the tech spec, the engineer running the session, and the reviewer merging the PR are all working off the same memory, actually reading it, actually curating it, actually treating a merged PR as sign-off. One team following this while another keeps working off a Teams thread and a stale SharePoint page will not get the delivery speed this model promises, it will get a codebase where half the modules have a memory and half do not. The adoption is the delivery model, not a rollout detail attached to it. Skip it for a few teams to avoid an argument in a planning meeting, and an agent generating fast, wrong code with no memory of what broke last time is exactly what comes back, at a scale nobody has time to fix by hand.
Repository as memory, and repository as the process, are the same repository doing two jobs it was always meant to do. For decades, SDLC tried to preserve institutional memory through documents that people gradually stopped reading. AI does not change that purpose. It finally gives us a practical way to sustain it, and the repository stops being where software is stored. It becomes where the organisation remembers.
The full repository structure, file templates, agent definitions, and setup instructions are available at github.com/punitganshani/ai-delivery-starter.
