The Discipline Gap. Is Spec-Driven Development the Answer?

Abstract

AI has collapsed the cost of writing software and left the cost of governing it untouched. The result is a new discipline, Agentic Engineering, whose scarce resource is not capability but trust, and whose central act is turning engineering judgement into something a machine executes on every run. What follows is a mental model for it (three eras, four realities, five pillars), a way to measure and govern autonomous delivery, and, in an appendix, the accelerator we built at Parser to prove the argument is operational today.

When talking about AI applied to software development I can not recall how many times I heard the word “Co-Pilot”, so I believe starting with a real Pilot anecdote will be appropriate.

On the 30th of October 1935, at Wright Field in Ohio, the U.S. Army Air Corps gathered to watch Boeing’s new long-range bomber, Model 299, the aircraft that would become the B-17, take off. It climbed, stalled, and crashed, killing two people including the pilot. He was no novice pilot; he was the chief of flight testing, among the most capable aviators alive. The aircraft, the investigators concluded, was too much airplane for one man to fly from memory. « I keep returning to this story because our industry is standing in a similar place where those pilots stood ».

The fix was not a better pilot. It was not a simpler aircraft. It was a piece of paper [0]. As Atul Gawande retells it in The Checklist Manifesto, Boeing’s test pilots wrote a short pre-flight checklist: pull the elevator lock, set the flaps, trim the tabs. With it they flew the same aircraft some 1.8 million miles without a serious accident. Judgement, written down, executed the same way every time [1].

Agentic Engineering is again another software’s checklist moment, but for AI agents instead of humans.

The checklist did not replace the pilot. It encoded decades of aviation experience into a repeatable sequence that every pilot executed before every flight. Agentic Engineering plays exactly the same role for autonomous software agents. Instead of reminding humans what to verify, it reminds machines what they must know, what they may do, what they must never do, and what evidence they must produce before acting. The checklist became part of the cockpit. Agentic Engineering makes engineering discipline part of the agent.

In this article, I use Agentic Engineering to refer specifically to the engineering discipline around autonomous software development and delivery. The broader engineering of agentic systems across domains may eventually extend beyond software, but software is where the discipline is emerging first. Then, Agentic Engineering is the discipline of reliably transforming human intent into trustworthy machine execution. It is not the art of prompting models; it is the engineering of the context, constraints, governance and evaluation that allow autonomous systems to operate predictably at production scale.

AI has made software generation abundant. The engineering discipline? Not so much.

For decades, software engineering optimised the production of code. Today, code is increasingly produced by agents «specifically by coding harnesses instrumenting frontier reasoning models». The competitive advantage is shifting from writing software to governing how software is created.

For two years the industry argued about capability: can the model write the function, navigate the repository, hold enough context. Those questions are increasingly resolved as engineering problems rather than research problems. The binding constraint has moved somewhere less comfortable. It is no longer whether the agent can produce a change, but whether the organisation can account for it: trace it to a requirement, verify it against a standard, reproduce the process that created it, and demonstrate to a regulator or an acquirer that it happened under control rather than under improvisation. More importantly, providing the trust it will not break in production.

This is the discipline gap. It shows up as a precise pattern: velocity rises, confidence falls [25]. Teams ship faster and trust less. Review becomes theatre because no human reviews the whole diff reliable enough as fast the code is created without creating a review bottleneck [3]. Two engineers on the same codebase, with the same agentic code harness, produce work of wildly different rigour, because the only variable that mattered was how each happened to prompt. The industry named the failure mode “vibe coding” [24], but misfiled it as a tooling problem [4]. It is not. It is the absence of a discipline between human intent and machine execution.

The discipline gap exists because engineering knowledge is still documented instead of executable.

Across organisations adopting AI-assisted software engineering we have seen the same pattern repeat: the successful transformations invested less in selecting models and more in engineering the operating system around those models. What follows is what that discipline looks like, and why it is about to matter more than the model you choose.

Every major shift in software engineering has separated enduring ideas from transient tools. Programming paradigms outlived languages. Object-oriented design survived IDEs. DevOps survived cloud vendors. Agentic Engineering should survive today’s models. That is why we invest in disciplines rather than dependencies.

Looking back. Three eras of software engineering

Software engineering has passed through three eras, and each was defined by a different scarce resource which drove major bottlenecks.

Manufacturing did not become industrial by hiring better craftsmen. It became industrial by designing better production systems. Agentic Engineering is that same transition for software.

We call them “Realities” because every major technological shift eventually exhibits the same economic pattern: when one constraint disappears, another becomes the new bottleneck. AI has dramatically reduced the cost of generating software. The constraint has simply moved upward: from production to trustworthiness governance. And most of Agentic Engineering is optimising context rather than maximising it.

The fourth reality is the least intuitive. Tools improve in steps; systems compound «generating accumulative gains». As models capabilities converge becoming commodities, Engineering systems will rise as a competitive advantage.

Think of the difference between buying a faster laptop and building a better software factory «or a better SW production process». The laptop makes one engineer faster today. The factory makes every engineer and every future laptop more productive tomorrow. Engineering systems compound because every new capability strengthens the entire system rather than replacing what came before. Models, IDEs and coding agents will change every few months. Specifications, reusable Skills, evaluation suites, governance policies and engineering knowledge will continue making every new generation of tools more valuable. That is why the durable competitive advantage will belong to organisations that invest in engineering systems rather than engineering tools.

This is not unprecedented. Cloud providers converged on the same infrastructure primitives; programming languages converged on the same expressive power. Each time, advantage moved upward: from the tool to the system built on it. AI is following the same trajectory. The organisations that win the next cycle will not be the ones with marginally better prompts; they will be the ones with a better engineering system wrapped around commodity intelligence.

Spec-Driven Development (SDD) has emerged as one of the earliest practical disciplines of Agentic Engineering, much as Agile became the discipline of distributed software delivery.

Although today’s SDD ecosystem includes GitHub Spec Kit [14], OpenSpec [15], BMAD [16], AI-DLC [17], CoStrict [18], GSD [19 ] , KIRO [20] and other emerging approaches, they increasingly converge on the same architectural principles: specifications as the source of truth, reusable Skills, executable governance, evaluation-driven quality gates and explicit context management. The tools differ; the discipline is converging.

Google and Kaggle reached a similar conclusion from the production side of the industry, framing SDD as the discipline that makes AI-generated code production-grade rather than merely plausible [2].

Why today’s AI projects struggle

Organisations are investing heavily in the left-hand column below but much less in the right, then wondering why velocity never converted into trustworthy delivery.

The left column is real and necessary, but it is the part the market already commoditises for you. The right column is the part no vendor ships and every serious transformation has to build. Projects stall not because the model was too weak, but because nothing governed what it produced. As an example, the industry spent two years discussing Prompt Engineering to later discover that prompts are only a small part of a broader discipline: Context Engineering.

Engineering knowledge made executable

« Knowledge that merely exists can be forgotten. Knowledge that executes cannot. »

Fred Brooks split software’s difficulty into two kinds: the accidental, which better tools can attack, and the essential, which they cannot [23]. AI is the largest attack on accidental complexity in a generation. Governance is essential complexity. No model removes it. It only raises the impact of getting it wrong.

Every major shift in software engineering changed where engineering knowledge lived.

• Early software engineering relied primarily on individual experience and expertise.
• Frameworks encoded recurring engineering solutions and patterns into reusable libraries.
• DevOps encoded operational knowledge into automated pipelines and infrastructure.
• Agentic Engineering encodes engineering judgement into executable governance that every autonomous agent follows by default.

The trend is clear: engineering knowledge has progressively moved from human memory into executable systems. Agentic Engineering is simply the next step in that evolution.

For decades that knowledge has lived in three fragile places: in people, in documents, and in checklists, each depending on a human being present, paying attention, and choosing to comply. The senior engineer who knows why the payment path must never log the raw card number. The runbook nobody opens. The review checklist skimmed under deadline. That knowledge is real, and perpetually one resignation or one busy afternoon away from not being applied. « Now, more than ever, that brings an important automation opportunity. »

Agentic Engineering requires capturing it in executable form, encoded where the model reads it on every turn, applied whether or not anyone remembered. We call this Executable Engineering Knowledge: the specifications, roles, gates and trust rules are not files in a folder but organisational memory that runs.

Currently, this idea appears frequently under the name Context Engineering: the discipline of deciding exactly which information, memories, specifications, tools and constraints an AI system receives at each step. Agentic Engineering extends this concept beyond prompts into the complete software delivery lifecycle.

Software Engineering encoded business logic into software. Agentic Engineering encodes engineering judgement into software specifications.

This is the same lesson, one abstraction higher. The agents are capable enough; what fails is the discipline that executes on every run, whether or not anyone remembered. «Engineering judgement that lives only in a person’s head is one resignation, or one busy afternoon, away from not being applied.»

The Framework: Five pillars of Agentic Engineering

Simplifying Agentic Engineering to its root, five key questions remain. Each question is answered by one ‘pillar,’ which acts as a set of actionable rules that the system can use:

Together these are the Agentic Engineering Operating Model: the idea that turns engineering knowledge into Executable Engineering Knowledge. Its mechanisms are ordinary engineering discipline: a specification that changes only through a deliberate architectural decision; phases with explicit entry and exit conditions; named, reusable skills the agent invokes instead of reinventing; Definition of Ready and Done whose criteria are checked, not assumed. What is new is that all of it must now be expressed in a form an autonomous agent obeys by default, and compiled into whatever tool the team happens to use.

There is a sixth principle beneath the five: engineering disciplines should outlive the tools that execute them. That is why the operating model compiles to Claude Code, Codex, Cursor, Windsurf and the rest, rather than committing to any one of them.

Parser’s SDD Adoption Console, described in Appendix I, demonstrates how that operating model can be implemented consistently across projects, teams and AI coding platforms.

Figure 2 illustrates the architectural principle at the heart of Agentic Engineering: engineering discipline should be authored once, compiled automatically, and executed consistently everywhere. Rather than manually maintaining separate instructions for every coding agent, engineering knowledge becomes a single source of truth that is compiled into each AI coding harness while preserving the same specifications, roles, skills, trust model and governance. The result is a spec-first delivery lifecycle where every agent, regardless of vendor, operates under the same engineering discipline and produces evidence that is consistent, traceable and auditable by design.

In essence, most of that along with the code harness, is about providing the just-in-time minimum context required for an LLM to successfully perform a granular task without hallucinations.

Context that arrives too early increases noise. Context that arrives too late creates errors. The engineering challenge is therefore not maximising context, but optimising it.

From Idea to System. Operationalising Agentic Engineering

Knowing what the operating model looks like is not the same as producing one, consistently, across every engagement and every tool. That is the hard part, and it is what our Parser’s SDD Adoption Console operationalises, through three capabilities:

• Capture organisational intent: the engagement’s real constraints, elicited as structured signals rather than assumed.
• Compile engineering governance: a framework, its phases, gates and permitted tool access, chosen on evidence and applied uniformly.
• Generate executable engineering assets: a single source of truth compiled into every harness at once, internally consistent by construction.

‍

The Console is not the point; it is evidence of the philosophy. A capability that used to live in a few senior engineers’ heads now ships as a repeatable system, offline, in a single file, tailored to each client. The remainder of this article focuses on the principles behind that operating model; Appendix I shows how Parser’s SDD Adoption Console operationalises this architecture in practice, from organisational intent capture to the generation of a complete, tool-agnostic engineering bundle.

Organisational transformation

“A bad system will beat a good person every time”, W. Edwards Deming [5]

Adopting Agentic Engineering is not a tooling change; it is an organisational one. Shifting to it requires an organisational transformation, moving beyond mere tooling updates. As the operational center of gravity evolves across five core areas, the focus shifts toward AI-native organisations:

Why this reaches the executive agenda

Auditability, before someone demands it. The EU AI Act, sector guidance and ordinary due-diligence increasingly ask how you know what your AI-assisted process actually was. A configured practice answers as a by-product of working: the spec was locked here, these gates applied, these criteria were checked before merge. That evidence either exists by construction, or it is reconstructed under pressure, which is when organisations discover the process was never there.

Consistency that does not depend on individuals. When rigour is a function of prompting habits, quality cannot be measured, delegated or reproduced. It walks out of the door when a strong engineer leaves. Encoding the process into the agent’s configuration converts individual discipline into organisational discipline. « I have inherited more than one codebase whose real design lived only in the head of someone who had already left ». Melvin Conway warned in 1968 that a system comes to mirror the communication structure of the organisation that builds it [6]. The corollary for our era: if governance lives only in individuals, the software will faithfully reproduce their absence.

Velocity that survives review. The commercial case for AI has always been throughput; the unspoken cost has been rework. Gates before merge move that discovery earlier, where it is cheap. The discipline is not there to slow the agent down; it is there to stop paying for the same work twice.

Measurement & governance

“You can’t control what you can’t measure.” Tom DeMarco [7]

What DevOps did for deployment metrics, Agentic Engineering must now do for engineering governance.

DevOps automated software delivery. Agentic Engineering automates software creation. One automated code movement; the other automates engineering reasoning. The first required CI/CD pipelines. The second requires executable engineering knowledge.

Claims about AI velocity are easy; evidence to prove it is not. A transformation you cannot measure is a transformation you cannot defend, to a board that funded it or a client auditing it. The established frameworks give useful outer scaffolding: DORA for delivery performance [8], SPACE for the human dimensions of productivity [9], and the NIST AI RMF for AI-specific risk [10] are worth tracking as examples a sceptical CTO already trusts. But they were built for a world where a human wrote the code, and they stop exactly where AI Engineering gets interesting.

So what should we actually measure?

Two categories matter more than any headline metric, because they are where machine-generated change either earns trust or loses it.

1. Coverage and traceability. When an agent can produce a hundred lines in a minute, tests stop being a chore and become the primary control surface. We hold the practice to layered coverage: unit tests for logic, integration tests for the boundaries between components, and end to end tests for the behaviour a user actually sees. We treat the ratio between them as a signal, not just the headline percentage. Coverage that is all unit tests and no integration is a comfortable lie, especially where all tests will also be automatically generated and sometimes agents find “innovative ways” to generate tests to pass in order to fulfill their goal of coverage [11]. More important than any number is traceability: every test traces back to a line in the specification, and every specification line has a test that proves it. That two-way link is what lets you answer the only question that matters in an audit: which requirement does this code satisfy, and how do we know it still does.
2. Evals, wherever GenAI is in the feature itself. A deterministic test asks whether the output equals the expected value. That question breaks the moment the feature contains a model, because the same input will not produce the same tokens twice. So wherever generative AI ships inside the product, and especially where agents make decisions and call tools, tests are not enough; the feature needs an evaluation harness. Evals judge behaviour rather than exact output: is the answer correct and grounded, did the agent choose a sensible tool path, did it stay inside its guardrails, did it degrade safely when the input was hostile. For agentic features this extends to tracing the decision path itself: capturing why the agent did what it did, which tools it called and in what order, so a non-deterministic run is still reconstructable after the fact. An eval that tolerates run-to-run variance in the tool sequence while still holding the outcome to a bar is the one genuinely AI-native gate, and it is non-negotiable once an agent can act [11].

A CLI companion, in progress. Measurement only sticks if it lives where the work happens. We are exploring a command-line companion to the Console that tracks these signals close to the code: coverage by layer, spec-to-test traceability, and eval scores across runs, and surfaces drift before it reaches a gate. It serves two audiences at once: engineers who live in the terminal and want governance as a command rather than a screen, and teams who prefer a UI, for whom the CLI is the engine the Console’s interface sits on top of. Same discipline, two front doors.

Governing what the agent can touch. Governance is the other half. Capability without constraint is the fastest way to turn an autonomous agent into an incident, so every external system the agent can reach sits on a Progressive Trust Model.

A necessary caveat on scope. The configuration layer does not write your software and does not supervise the agent that does; quality still depends on engineers who read diffs « especially those diff generated by AI to explain the changes and the impact of them without the need to look at every line of code » and refuse to wave through a gate that was not met. Nor does it replace judgement about whether an engagement needs this much process. A three-day prototype does not get a release gate. The ability to generate a lean practice is exactly what keeps the discipline honest. And there are serious engineers who read all this and think it premature, that today’s agents are still too weak to deserve heavy process, and that gates mostly slow good people down. On a weekend prototype, they are right. On anything that reaches production, « I have yet to see the discipline be the part a team later regretes ».

The next decade of software engineering

The history of software engineering is the history of raising the level of abstraction. Machine code to programming languages. Languages to frameworks. Frameworks to cloud platforms. Each step let us stop thinking about the layer below and build something larger on top. AI is the next abstraction.

But every previous abstraction eventually required discipline before it could scale. Structured programming, version control, CI/CD, infrastructure-as-code each arrived precisely when raw capability had outrun our ability to govern it. AI is reaching that same moment.

Organisations will not compete on which model they use. They will compete on the engineering system every model must operate within.

Models will evolve every six months. Engineering discipline may define the next decade.

Every generation of software engineering has been remembered not by the tools it used, but by the discipline it introduced. We believe AI Engineering is reaching that moment now.

We do not believe Agentic Engineering will be remembered for the models that generated the most code. It will be remembered for the discipline that made autonomous software delivery trustworthy. That is the transition we believe has already begun.

The checklist did not make the B-17 a lesser aircraft. It made it flyable. That is all any of this is trying to do. Not to constrain the machine, but to make what it produces something we can trust with our names on it.

Appendix I: The SDD Adoption Console

The article makes the argument. This appendix explains why we built a tool to prove it, and what that decision says about how Parser works.

This appendix is not included to showcase a product. It is included to demonstrate that the principles described throughout this article can be operationalised today: not in theory, but in a tool a client can run on Monday morning.

If Agentic Engineering is the discipline, SDD Adoption Console is our accelerator for it.

The tool that operationalises the operating model. We built it because we kept hitting the same wall on engagements: the discipline is real, but assembling a correct, coherent, portable configuration by hand takes an experienced engineer days, comes out different every time, and decays the moment someone edits a downstream copy. The Console compresses that work into an afternoon and makes the output consistent by construction.

We provide this tool to our clients to accelerate implementation rather than as a commercial product. Our focus remains on applying engineering discipline and sound judgement, which this tool is designed to operationalise. Its function is to demonstrate the practical viability of these concepts.

We built it because a principle you cannot operationalise is just an opinion. Anyone can argue that Agentic Engineering needs governance; being able to hand a client a working, tailored practice in an afternoon is the difference between a point of view and a capability.

That afternoon has a shape. A session is three decisions, and they only run in one direction: each one narrows the next. Get the first wrong and the rest inherit the mistake; get it right and the rest become fine-tuning. See Figure 4 for a more detailed overview of those decisions.

1. It starts by capturing organisational intent

The Console does not begin with a template. It begins with a short, structured conversation that turns an engagement’s real constraints: stack, compliance exposure, brownfield or greenfield, team maturity, into explicit context signals. This is the same intent-first discipline the methodology preaches, applied to its own configuration.

See Figure 5 for a simplified view, not the actual live user experience. The Parser’s SDD Adoption Console left panel shows the chat interaction to gather organisation context prior recommending a particular SDD Framework.

2. It guides the choice of SDD framework

There is no single right SDD framework, and choosing by reputation is the most expensive early mistake a team can make. The Console scores the credible open-standard frameworks against the detected context and shows its working: OpenSpec [15], GitHub Spec Kit [14], Kiro [20] paired with the EARS requirements notation [12], AI-DLC [17], CoStrict [18] GSD [19] , SpecBoot (an OpenSpec Expansion) [13] and BMAD [16]. Each is a peer among the others, not a canonical standard, and a different engagement is just as likely to score OpenSpec or Spec Kit or any other higher.

The client sees why a framework was recommended, not just which one. That transparency is what lets the decision survive a sceptical client architect. See Figure 5 right panel for a simplified view of the SDD model weighting and recommended selection.

3. It is tool-agnostic, yet tailored to the client

This is the property that makes the Console defensible as an asset rather than a liability.

The engineering standards are authored once, in a neutral source, and compiled outward into whatever each coding agent expects: Claude Code, OpenAI Codex, Cursor, Copilot, Windsurf, Cline, Antigravity, OpenCode, Gemini CLI, Tabnine, and others.

The practice is agnostic to the tool, but tailored to the client’s chosen tools, phases and gates. When the market moves, and it will, the client regenerates instead of rewriting.

4. What it generates

The output is not a document; it is a complete, coherent engineering practice as files.

A typical bundle is sixty-plus artefacts: a spec state machine in this example built on the BMAD framework (any of the other frameworks above generates an equivalent one in its own idiom), the .ruler standards [21] and policy tree, six role agents, twenty-six phase-triggered skills [22], seven reference checklists, and the compiled native configuration for every harness, all generated together so nothing can silently disagree.

I want to highlight the importance of skills. Skills encapsulate engineering expertise the same way libraries encapsulate reusable code. Instead of every engineer, or every agent, reinventing the same review procedure, architectural analysis or security verification, these become executable capabilities invoked consistently across projects.

Many organisations start with that, which is a good starting point, but it is not enough. Still, agents profiles, checklists, inviolable and policies need to be added.

Why this signals leadership

Three things about how the Console is built matter more than any feature. It runs entirely offline, a self-contained application, with no external dependencies. You can inspect, compile and run it under your controls. Because much of its use happens inside client environments where neither connectivity nor data egress can be assumed. It is tool-agnostic by design, so it commits the client to a discipline rather than to a vendor. And we build the Console itself under the very methodology it generates: the same locked specification, the same phase gates, the same evaluation suite. When a methodology is not used by its own creators, it becomes a sales artifact rather than an authentic practice. This one is the latter, its own practice.

The Console is only one manifestation of a broader belief. AI Engineering will not be defined by the intelligence of its models, but by the engineering discipline surrounding them. We intend to keep building the systems that make that discipline practical.

References

[0] National Museum of the United States Air Force fact sheet on the Boeing Model 299/B-17; Boeing heritage/history pages; Gawande (2009), A Short summary in Dario Leone, Aviation Geek Club, 2022.

[1] Atul Gawande. The Checklist Manifesto: How to Get Things Right. Metropolitan Books, 2009. [Book]

[2] Lee Boonstra, Google & Kaggle. “Spec-Driven: Production-Grade Development in the Age of Vibe Coding.” Kaggle whitepaper, https://www.kaggle.com/whitepaper-spec-driven-production-grade-development-in-the-age-of-vibe-coding,

[3] Martin Monperrus, “The End of Code Review: Coding Agents Supersede Human Inspection”. (Jun 2026) [cs.SE] https://arxiv.org/abs/2606.13175

[4] Addy Osmani, Shubham Saboo, and Sokratis Kartakis, Google & Kaggle. “New SDLC with Vibe Coding: From ad-hoc prompting to Agentic Engineering” Kaggle whitepaper. https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding

[5] W. Edwards Deming. Part of Deming’s seminars/lectures (per the W. Edwards Deming Institute). Paraphrases from “Out of the Crisis”. MIT Press, 1986. [Book]

[6] Melvin E. Conway. “How Do Committees Invent?” Datamation, 1968. https://www.melconway.com/Home/pdf/committees.pdf

[7] Tom DeMarco. “Controlling Software Projects: Management, Measurement, and Estimation”. Yourdon Press, 1982. [Book]

[8] Nicole Forsgren, Jez Humble & Gene Kim. “Accelerate: The Science of Lean Software and DevOps”. IT Revolution, 2018. (DORA metrics). [Book]

[9] Nicole Forsgren et al. “The SPACE of Developer Productivity.” ACM Queue, 2021. https://cacm.acm.org/practice/the-space-of-developer-productivity/

[10] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100–1, 2023. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf

[11] Sokratis Kartakis, Aron Eidelman, Wafae Bakkali, and Meltem Subasioglu, Google & Kaggle. “Vibe Coding Agent Security and Evaluation” Kaggle whitepaper, https://www.kaggle.com/whitepaper-vibe-coding-agent-security-and-evaluation,, 5-Day Gen AI Intensive series.

[12] Alistair Mavin et al. “Easy Approach to Requirements Syntax (EARS).” 17th IEEE International Requirements Engineering Conference (RE’09), Rolls-Royce, 2009, pp. 317–322. https://ieeexplore.ieee.org/document/5328509

[13] Alvaro Moya, SpecBoot an OpenSpec extension, LIDR Academy, https://github.com/LIDR-academy/lidr-specboot, MIT License

[14] GitHub. spec-kit: “Toolkit to help you get started with Spec-Driven Development.” MIT licence. https://github.com/github/spec-kit

[15] Fission-AI. OpenSpec: “Spec-driven development (SDD) for AI coding assistants.” MIT licence. https://github.com/Fission-AI/OpenSpec

[16] BMad Code, LLC. BMAD-METHOD: “Breakthrough Method for Agile AI-Driven Development.” MIT licence. One example among the peer frameworks above, not the canonical standard. https://github.com/bmad-code-org/BMAD-METHOD

[17] AWS Samples. “AI-DLC: Collaborative AI-Driven Development Lifecycle.” MIT License, https://github.com/aws-samples/ sample-collaborative-ai-dlc, https://aws-samples.github.io/sample-collaborative-ai-dlc/concepts/workflows-and-blocks/

[18] CoStrict: “strict AI coder for enterprises, quality first.” Apache 2.0 licence. https://github.com/zgsm-ai/costrict

[19] GSD SDD framework, “Get Shit Done”, MIT License, Archived in Jun.2026. https://github.com/gsd-build/get-shit-done

[20] KIRO Spec-driven Development implemented as part of AWS KIRO IDE, based on AI-DLC, https://kiro.dev/docs/specs/

[21] Eleanor Berger, “Ruler: Centralise Your AI Coding Assistant Instructions”, Intellectronica, 2025. MIT licence. https://github.com/intellectronica/ruler

[22] Addy Osmani. agent-skills: “Production-grade engineering skills for AI coding agents.” MIT licence. Three skills in our bundle (doubt-driven-development, deprecation-and-migration, shipping-and-launch) are sourced from this repository. https://github.com/addyosmani/agent-skills

[23] Frederick P. Brooks Jr. “No Silver Bullet: Essence and Accident in Software Engineering.” IEEE Computer, 1987. [Book]

[24] Andrej Karpathy, 2025. First coined the “Vibe Coding” term in Twitter/X. https://x.com/karpathy/status/1886192184808149383

[25] Joel Becker et al. METR (Model Evaluation & Threat Research), “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (July 2025). https://arxiv.org/pdf/2507.09089

[26] Carson Denison et al. (Anthropic), “Sycophancy to Subterfuge: Investigating Reward Tampering in Language Models,” 2024. https://arxiv.org/html/2406.10162v3

‍