Evidence note: Almost everything described below comes from two kinds of source, and they are not equivalent. The first is self-description: public repository documentation, project READMEs, and vendor engineering blogs, where the verifiable fact is that the project or company said it, not that the behaviour has been independently reproduced. The second is this site’s own pipeline records, which are measurements rather than claims but are also not independent verification of anyone else’s work. No third-party audit, reproduction, or benchmark run supports the framework descriptions here. Specific counts, sizes, and performance figures are marked where they appear.
"agentic-sdlc" Is Now a Repository Name: Independent Developers Converging on the Same Term
The clearest sign that a phrase has escaped the whitepaper stage is that unaffiliated people start using it as a directory name. Several public repositories now carry the name agentic-sdlc outright, with others using the same label for what each author describes as an AI-agent-driven software development lifecycle. A curated list of agentic AI tooling on GitHub collects work in the same territory.
What that convergence does not establish is a shared definition. Whether these repositories describe a coherent, common concept — or four authors reaching independently for a convenient name — is open. The repositories are their own and only source for what they contain; no independent survey has been located that compares their models against one another, and nothing here should be read as confirming that "agentic SDLC" denotes one thing. The term’s spread is observable. Its content is not yet fixed.
Agents as Core Contributors: Building, Testing, and Deploying From Scratch Through to GitHub Actions
The framing common to these projects, as far as their own documentation goes, is that AI agents are positioned as core contributors — participants in building, testing, and deploying software rather than autocomplete attached to a human author. This is a description drawn from the projects themselves and has not been independently corroborated; it should be read as how the authors characterise their intent.
The most concrete version of the claim is a worked example: a multi-agent URL shortener project presented as running from scratch through to deployment via GitHub Actions. Reports that such implementations carry a project end-to-end are, at present, the authors’ own accounts. What is missing from the public record is the part that would make the claim load-bearing: how much of the run was unattended, how often it needed a human to unstick it, and what the failure modes looked like. Those are the numbers that distinguish a demonstration from a delivery method, and they are not published.
What the Orchestration Engines Are Made Of: Dependency Graphs, Gates, Governance, Observability
Where these projects describe internals, four components recur: a dependency graph to order the work, gates to stop it, governance rules to constrain it, and observability to see it. That recurrence is a pattern in self-descriptions, not a verified architectural consensus — no independent teardown of these orchestration engines has been located, and it remains open whether the four components mean the same thing across implementations.
The vocabulary is worth noticing anyway, because it is borrowed wholesale from pipeline engineering rather than from machine learning. A dependency graph is a build-system idea. A gate is a release-management idea. Observability is an operations idea. None of it is new; what is new is the claim that it can be pointed at a non-deterministic worker. That is precisely the claim that needs evidence, and it is the one the source material is thinnest on. For a broader treatment of how these pieces are being assembled, see this site’s overview of how AI agents are rebuilding the software lifecycle beyond CI/CD.
The Assumption That Breaks: CI/CD Pipelines Were Written for Humans Who Write the Code
The argument motivating most of this work is that existing continuous integration and delivery pipelines carry a buried assumption — that a human wrote the code, and therefore that a human can be held to account for it, asked what they intended, and expected to have read what they submitted. The suggestion is that the assumption fails once agents are generating changes inside real delivery pipelines. This argument appears in the process documentation of the projects discussed here and has not been independently evaluated; it is a stated rationale rather than a demonstrated failure.
The mechanism it points at is nonetheless specific enough to test. Review capacity, branch protection, required approvals, and code ownership rules are all rate-limited by human attention, and all of them assume the submission rate is bounded by how fast people type. Whether that bound actually breaks in practice — and at what volume — is an open empirical question that none of the available sources answer with data.
Six Steps, Five Gates, and a Production Feedback Loop: How One Platform-Agnostic Framework Defines a Sign-Off
The most explicit attempt at an answer among the sources is a process framework published as part of a command-line tool. According to its own process documentation, the framework is gate-driven and consists of six steps, five gates, and a production feedback loop, and is designed to be platform-agnostic across GitHub, GitLab, Azure DevOps, and Jira (evidence level: the project’s own repository documentation; the step and gate counts are as stated by the author and have not been independently verified).
The more interesting assertion in the same documentation is about proof rather than structure: every gate is described as backed by real evidence sitting in the repository — actual pull requests, actual issue comments, actual recorded gate sign-offs — rather than by a checklist someone ticked. Stated as the author’s own claim about their own repository, this is checkable in principle by anyone who reads it, though no third-party confirmation has been located.
That design choice matters more than the numbers. A gate whose passage leaves no artifact is indistinguishable from no gate at all, and the difference only becomes visible during an incident review months later. This site has examined the same problem in its treatment of gates, roles, and evidence in agent-driven delivery.
"Continuous AI" and the Consulting White Papers: Vocabulary Without an Implementable Governance Framework
The same documentation makes a pointed criticism of the field it is entering: that GitHub has supplied the term "Continuous AI" and that PwC has published on the "Agentic SDLC," but that neither has supplied a governance framework anyone can actually implement. The verifiable fact is that the framework’s author makes this argument in the project’s own documentation; whether the characterisation of GitHub’s and PwC’s material is fair is not something the sources here settle, and readers should treat it as one practitioner’s assessment of competing work rather than a neutral survey finding.
The criticism is worth separating into two parts, because they have different weight. That large organisations have published vocabulary is easy to confirm. That the vocabulary lacks an implementable governance layer is a judgement — and one made by a party with an obvious interest in the gap existing. It is a reasonable prompt for scepticism in both directions: toward the white papers, and toward the claim that they are empty.
From CI/CD to AI/CD to Autonomous Delivery: What Each Step Would Have to Prove
The same framework proposes a progression, according to its documentation: from CI/CD to AI/CD — Agentic Integration and Continuous Delivery — and eventually to AI/AD, Autonomous Delivery. The naming is the author’s own and is stated here as their proposal, not as an industry roadmap.
Taken as a hypothesis, each step carries a distinct burden of proof, and the sources do not show any of them being discharged. The first step would need to demonstrate that agent-authored changes can move through integration with defect rates comparable to human-authored ones. The second would need evidence that gate sign-offs remain meaningful when the entity requesting the sign-off is also the entity that wrote the change. The third — autonomous delivery — would need something none of the available material provides: a record of what happens when the loop is wrong and nobody is watching. The progression is legible as a design direction. As a claim about achievable stages, it is entirely open.
Five Focused Reviewers on Your Own Machine: The Case Against Hosted Pull Request Bots That Flood, Black-Box, and Arrive Too Late
A narrower project attacks one slice of the problem. AgentCheck is presented by its authors as an open-source local subagent for Claude Code that runs five focused code reviewers covering logic, security, style, guidelines, and product (evidence level: the project’s own repository description; the reviewer set is as the authors state it, without independent testing of what each reviewer catches).
The design rationale is a critique of the hosted alternative. The project’s author argues that hosted pull request review tools — the comparison drawn is to Cursor Bugbot — flood pull requests with noise, run as a black box, and solve problems too late and without access to the tools in the developer’s own environment. This is the author’s stated argument, published alongside a competing product, and none of the four criticisms has been independently measured. The timing objection is the one with the most obvious force: a finding delivered after a change is proposed costs more to act on than the same finding delivered while the change is being written. The environment-access objection is close behind, since a reviewer that cannot run the project’s tests is guessing. For a contrasting view from the hosted side, see this site’s coverage of GitHub Copilot code review’s expansion to bot-authored and very large pull requests.
Review as Trade-Offs, Knowledge Sharing, and Accountability — Not Style Policing
Underneath the tooling argument is a claim about what review is for. The same author holds that code review should be about trade-offs, knowledge sharing, and accountability — not policing style, naming quirks, or trivial regressions. This is a normative position, not a finding, and it is not independently corroborated; it is presented here as the author’s stated view.
It is also the position most in tension with automation. Style, naming, and trivial regressions are exactly the categories a machine reviewer handles well, and trade-offs, knowledge sharing, and accountability are exactly the categories it handles worst. If the position is right, then a reviewer agent is best understood as clearing the floor rather than doing the work — and the risk is that a team measuring review by comment volume mistakes a clean floor for a reviewed change. No evidence in the available sources settles whether teams actually make that mistake, but the structure of the incentive is visible without data.
Expensive, Slow, and Silent on Root Cause: The Limits of End-to-End Agent Benchmarks
Google’s developer blog has published an argument that end-to-end agent benchmarks — SWE-bench is the named example — are expensive to run, slow to complete, and lacking the root-cause diagnostics that would explain where an agent’s logic broke down. This criticism appears in Google’s own developer blog post on evaluating and guarding AI coding agents and has not been independently assessed here; it reflects a vendor’s position on a benchmark widely used to evaluate that vendor’s competitors as well as its own systems, which is worth holding in mind.
The diagnostic complaint is the substantive one. A pass-or-fail score on a repository-level task tells a team that something went wrong across a run that may have involved dozens of tool calls, but not which call was the error. Debugging against such a signal means re-running an expensive evaluation after every change and inferring causes from aggregate movement — which is a slow way to learn anything.
Behavioral Evaluations Instead: Unit-Style Assertions on Tool Calls and File Modifications
The alternative recommended in the same post is behavioral evaluation: fast, local, unit-style tests that assert on discrete intermediate actions — that a specific tool was called, that a particular file was modified — rather than on final string equality against an expected output. As with the criticism above, this is Google’s published recommendation and is reported here as such, without independent validation of the results teams get from it.
The appeal is easy to see for anyone who has written tests. Asserting on intermediate actions turns an opaque trajectory into a sequence of checkable steps, which is the same reason unit tests are cheaper to debug than integration tests. The unexamined cost is also the familiar one: assertions on intermediate actions bind the evaluation to a particular way of solving the problem, and an agent that finds a better route fails a test it should pass. Whether that over-specification problem bites in practice is not addressed in the material available.
Micro-Checks Beside Macro Benchmarks: Changing System Prompts and Models Without Regression Risk
The practical promise attached to behavioral evaluations is operational rather than scientific: building inexpensive micro-checks alongside the macro benchmarks is said to let a team iterate on system prompts and upgrade models without regression risk. This claim is not independently corroborated, and the phrase "without regression risk" deserves particular scepticism — a test suite reduces regression risk in proportion to its coverage, and no source here quantifies the coverage such micro-checks achieve.
The weaker version of the claim is more defensible and more useful. A model swap or prompt edit currently forces a team to choose between shipping blind and paying for a full benchmark run. A cheap local suite changes that choice into a cheap first signal followed by an expensive confirmation only when the signal is ambiguous. That is a meaningful improvement in iteration cost even if it eliminates no risk at all.
Eighty Runs of One Pipeline, Counted Out: 506 Drafts, 10,399 Claims, 21,424 Scored Topics
Against that backdrop, it is worth putting real numbers from a running gate-driven pipeline next to the frameworks that describe one. The figures below come from PlayAgit’s own pipeline records covering 80 runs between 2026-08-28 and 2026-09-12, as of 21:55 UTC on September 12, 2026. They are measurements of one system, not independent verification of anyone else’s.
Across those 80 runs (PlayAgit’s own records, 2026-08-28 to 2026-09-12), the quality gate reviewed 506 drafts: 357 were published, 112 were sent back to revise, and 37 were rejected outright. Roughly three in ten drafts, in other words, failed to pass on presentation — which is the number that makes a gate legible as a gate rather than a formality.
The claim-level figures from the same 80 runs are less comfortable. Across 2,700 research dossiers holding 10,399 individual claims, 391 were independently cross-checked and 1,722 were primary-attested (PlayAgit’s own pipeline records, 80 runs, 2026-08-28 to 2026-09-12). That is about 3.8 percent of claims with independent corroboration and about 17 percent attested by the subject’s own official source, leaving the large majority in neither category — which is exactly why the hedging in the sections above is not decoration.
Selection is where the largest volume is discarded. Of 21,424 scored topics in those same 80 runs, 8,065 were held before production and 10,079 rejected, with 3,280 going forward (PlayAgit’s own pipeline records, 2026-08-28 to 2026-09-12) — about 15 percent of scored topics surviving to production. The intake feeding that funnel was 18,586 topic candidates discovered across 4 categories from 213 distinct source hosts over the same 80 runs and the same dates.
Coding Time Is No Longer the Long Pole: The Bottleneck Moved to Capturing Decision Context
A claim that recurs across several of these projects is that in agentic development, coding time has stopped being the long pole in the lifecycle, and the constraint has moved to capturing and retaining decision context — why a thing was built the way it was. This is a widely repeated practitioner observation in the source material rather than a measured result, and it is not independently corroborated.
It is also the claim most likely to be true for structural reasons that do not require evidence to see. An agent that can produce a module in minutes still cannot recover the reasoning that ruled out three earlier designs, and every session that begins without that reasoning re-litigates it. The cost does not show up in throughput metrics; it shows up as the same argument being had repeatedly, with nobody noticing the repetition.
Fresh Context Windows Per Phase, Persistent Context Across Sessions: Two Answers to the Same Shortage
Two projects answer the context problem from opposite directions. cc-pipeline is described by its author as orchestrating Claude Code through a loop of spec, research, plan, build, review, fix, reflect, and commit — giving each step a fresh context window by way of the Claude Agent SDK. Distillery goes the other way: an MCP server presented by its author as giving AI coding sessions persistent, shared team context, built as 50,000 lines of Python — 16,000 production, 25,000 test, 7,000 documentation — in just over a week (evidence level: the author’s own repository description; the line counts and the development timeline are self-reported and unverified).
A third strand treats context engineering as standalone tooling for coding agents rather than a feature of any single pipeline.
The two approaches are not actually in conflict. Fresh windows per phase solve contamination — a planning step that inherits a build step’s dead ends. Persistence across sessions solves amnesia. A system needs both, and the interesting unanswered question is what gets carried across the boundary between them, which none of the sources specifies in operational detail.
About a Dozen Projects, Including One Failure: What an Autonomous Spec-to-Commit Loop Reports Honestly
The cc-pipeline author’s own account is unusually candid about scope and outcome: the autonomous pipeline is reported as having been run on about a dozen projects, with successes and at least one acknowledged failure — an attempt at a Kirby-style platformer. The author also reports having first tried driving agent phases with tmux and send-keys before moving to the Claude Agent SDK, and explicitly does not recommend the tmux approach. Both are the author’s own reports about their own work; neither the project count nor the failure has been independently verified.
The reported failure carries more information than the successes. A dozen projects with no failures would suggest either a narrow task selection or a reporting filter; one named failure in roughly a dozen attempts is at least a plausible rate. What the account does not provide — and what would make it genuinely useful — is why the platformer attempt failed, whether it was a specification problem, a tooling problem, or a limit of the loop itself. The rejected tmux approach is a smaller but cleaner data point: a driving mechanism tried, found wanting, and reported as such rather than quietly dropped.
Structure Over Prompt Chains: Bidirectional Inter-Agent Messaging, Async Event Buses, Unified Fallback Validation, Tiered Routing
Google’s developer blog has also published an analysis of what separated the strongest entries in its Startups AI Agents Challenge, reporting that the best submissions leaned on foundational software engineering patterns rather than raw model power. The post identifies four recurring patterns: bidirectional MCP for communication between agents, asynchronous event buses for parallel execution, strict unified validation applied to model fallbacks, and tiered routing to minimise expensive inference calls. This is a vendor’s retrospective on its own competition, with no published methodology for how "strongest" was determined, and the pattern list has not been independently confirmed.
The associated conclusion — that prioritising structural engineering over simple linear prompt chains yields workflows that are more resilient, lower in latency, and more cost-effective — is presented as an observation rather than a measured comparison, and the sources give no figures behind any of the three benefits. The unified-validation pattern is the one worth flagging for anyone designing a system: a fallback path that validates differently from the primary path is a silent correctness hole that only opens under load. Coordination patterns of this kind also appear in domain-specific systems, such as the lead-agent and specialized-subagent structure described for cybersecurity work.
Ten Thousand Agents at 25KB Each: Why Container-Heavy Infrastructure Prices Parallelism Out
The cost argument against heavyweight infrastructure is made most directly by Jido, an Elixir agent SDK whose documentation describes a target of running roughly 10,000 agents at about 25KB each, and which its authors state was written so that language models could code and operate their own agentic flows — including a Workflow Design Life Cycle (evidence level: the project’s own repository documentation; the agent count and per-agent footprint are design targets stated by the authors, not measured results from a third party).
The complementary claim is that frameworks demanding process-heavy infrastructure — Docker, Kubernetes — make large-scale parallelism expensive enough to be impractical. This is a widely asserted position rather than a corroborated one, though the underlying arithmetic between a lightweight process and a container is not controversial. Stack Overflow’s blog has examined the broader question in a piece on the economics of agent scale. What none of these sources establishes is whether 10,000 concurrent agents is a workload anyone actually has, as opposed to a capability worth having in reserve.
Roles, Explicit Handoffs, and Living Documentation for Stateless Agents
The organisational answer running through several of these frameworks is to adapt traditional lifecycle roles for workers that have no memory — using specialized roles, explicit handoffs between them, and living documentation that carries state the agents themselves cannot hold. VibrationPlan is one project working in this direction. The general characterisation is drawn from project self-descriptions and is not independently corroborated.
Simon Willison has documented a set of agentic engineering patterns covering similar ground, and has written that vibe coding and agentic engineering are converging more than he would like — an observation attributed to him, offered as his assessment rather than a measured trend. That discomfort is the useful signal here: the role-and-handoff apparatus exists precisely to keep a disciplined practice distinguishable from an undisciplined one, and its value depends entirely on whether the handoffs are enforced or merely documented. This site has looked at the same structures in more detail in its examination of how agentic SDLC frameworks use review roles, delivery gates, and shared context.
Certification Tracks, Leadership Guidance, and the Team-Topologies Problem Behind the Platform
The institutional layer is forming faster than the evidence base underneath it. Reports indicate that GitHub offers a certification track, GH-600, titled "GitHub Certified: Agentic AI Developer," covering the building, orchestrating, evaluating, and governing of AI agents alongside modern lifecycle practices; the existence and syllabus of this certification have not been confirmed against a primary vendor announcement here and should be treated as unverified. Similarly, OpenAI is reported to have published guidance under the title "Building an AI-native engineering team," aimed at engineering leaders integrating agents into the lifecycle — a document that has evidently circulated widely enough to attract a community Persian translation, though the original’s contents are not corroborated here.
A more structural framing comes from the argument that building the platform and the codified rules behind an agentic lifecycle is fundamentally a team-topologies problem — that is, a question of which team owns the paved road, not which tool gets adopted. This is one practitioner’s framing, presented as such. In a similar register, Andi Gutmans, described as head of Agentic Data Cloud at Google, is reported to have discussed judgment, code review, and data activation in the first part of a two-part Leaders of Code conversation, and token cost, return on investment, and platform infrastructure for AI-first teams in the second; no primary record of that conversation is among the sources consulted, and the attribution should be treated as unverified. Certifications and executive interviews are lagging indicators of vocabulary, not leading indicators of working practice.
How we apply this in Vision
The frameworks above describe gates. PlayAgit’s own pipeline runs them, and the resulting counts are what shape editorial policy here — with the caveat, stated once and meant throughout, that these are measurements of one system, not independent verification of anything described above.
The single most influential figure is the corroboration rate. Across 80 pipeline runs between 2026-08-28 and 2026-09-12, PlayAgit’s own records show 2,700 research dossiers holding 10,399 claims, of which 391 were independently cross-checked and 1,722 were primary-attested. That is why this article separates three tiers of sourcing rather than one: at roughly 3.8 percent independent corroboration, treating a sourced claim as a verified claim would misrepresent the large majority of what the pipeline collects. The tiering is not editorial caution in the abstract — it is a direct response to a measured ratio.
The draft gate is calibrated against a similar reality. In those same 80 runs (PlayAgit’s own records, 2026-08-28 to 2026-09-12), the quality gate reviewed 506 drafts and returned 112 to revise while rejecting 37, publishing 357. A revise-or-reject rate near three in ten is the working evidence that the gate is doing something; a gate that passed everything would leave no trace in the counts at all, which is exactly the failure mode the evidence-backed sign-off designs described earlier are built to prevent.
Selection pressure is applied earlier and harder than the draft gate. Of 21,424 scored topics across those 80 runs, PlayAgit’s own records for 2026-08-28 to 2026-09-12 show 8,065 held before production and 10,079 rejected, with 3,280 reaching production — drawn from 18,586 topic candidates discovered across 4 categories and 213 distinct source hosts in the same period. Holding is used more readily than rejecting because a topic without sufficient sourcing today is frequently a usable topic once a primary announcement lands.
The output those gates permitted, over the same 80 runs and the same dates, was 403 published posts by PlayAgit’s own records — 211 of them new and 83 updates to existing pieces. The proportion of updates is the number that changed practice most: revisiting a published article when better evidence arrives turns out to be a larger share of the work than the framework literature, focused as it is on producing new artifacts, tends to account for.