Stage One — Planning

10.1 What Changes at This Stage #

Planning is where the agentic SDLC most often goes wrong, and it goes wrong quietly, because the error is an omission rather than a mistake. Organizations plan the delivery and do not plan the absorption.

The evidence in Section 3.3 is unambiguous that generation capacity rises faster than review capacity. A plan that assumes a 30 percent throughput improvement and staffs accordingly, without provisioning for a several-fold increase in review load, is a plan to accumulate unreviewed change. The Faros telemetry finding of pull requests merged without review rising 31.3 percent is not a description of bad engineers. It is the arithmetic consequence of raising the numerator and holding the denominator constant.

Three further planning assumptions require revision.

Cost is no longer a seat license. Per-seat list pricing for AI development tooling ranges roughly from $19 to $100 per developer per month, but observed total cost per engineer, combining license and consumption, commonly runs $200 to $600 per month for teams using both inline and agentic tooling—a four- to ten-fold multiple on the line item that appears in the procurement request.⁴⁰ The market has been shifting from seat-based to usage-based pricing, which converts a fixed cost into a variable one and moves it from a predictable annual commitment into something that behaves like cloud spend.⁴¹ The FinOps Foundation’s 2026 survey found 98 percent of organizations now managing AI spend, against 31 percent two years earlier, and ranked AI cost management as the single skillset teams most need to develop.⁴² Plan for AI cost as consumption, with an owner, a forecast, and an anomaly response—not as a software license.

Skill formation is a planning variable. The randomized trial cited in Section 2 found comprehension outcomes varying by usage pattern rather than by tool: patterns averaging below 40 percent on comprehension were delegation-style, asking the model to solve rather than to explain, while patterns at or above 65 percent involved generating and then interrogating, or requesting explanation alongside code.¹⁸ If a plan’s staffing model depends on junior engineers becoming senior engineers, the usage pattern the organization encourages is a delivery risk, not a cultural preference.

Upstream contribution may be constrained. Open source projects have diverged sharply on AI-authored contributions, and enterprises with upstream dependencies should know which posture their dependencies hold before planning work that requires upstream acceptance. The Linux kernel, Fedora, LLVM, the OpenInfra Foundation, OpenTelemetry, and Rocky Linux accept AI-assisted contributions subject to disclosure via an Assisted-by: commit trailer, with the kernel’s policy stating flatly that “AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin.”⁴³ QEMU declines contributions believed to contain AI-generated content; the Gentoo Council voted unanimously to forbid contributions produced with natural-language AI tools; NetBSD presumes such code tainted and requires explicit core approval.⁴⁴ These are incompatible governance postures, and a roadmap that assumes an upstream patch will be accepted may be planning against a project that will not take it.

10.2 Elements to Adopt #

An AI participation statement, per initiative. Before work begins, record which stages will involve AI participation, at which autonomy tier, and what that implies for review capacity, cost, and skill development. This is a short document, not a governance ceremony. Its value is that it forces the absorption question to be answered in writing at the point where staffing is still adjustable.

Absorption capacity modeling. Estimate review hours required per unit of delivered change under the planned AI participation, against senior engineering hours actually available. Where the model shows a deficit, the plan must resolve it—by lowering the autonomy tier, by investing in automated verification that reduces per-change review cost, by hiring, or by accepting a lower merge rate. Deferring the question to the team is how unreviewed merges happen.

Consumption forecast and unit economics. Establish cost per task, not cost per token, as the planning metric. Per-token prices for a fixed capability level have fallen rapidly—roughly fortyfold per year for the price to match a given performance threshold, though with a spread of ninefold to nine-hundredfold depending on task type, and that analysis dates from early 2025 and should be treated as such.⁴⁵ Agentic workloads consume dramatically more tokens per unit of work than conversational use, so falling unit prices coexist with rising bills. Forecast the bill.

Regulatory scoping. Determine at planning time which regimes apply to the system, and whether AI participation in its construction changes the answer. The EU Cyber Resilience Act’s reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026, on a cadence of a twenty-four-hour early warning, a seventy-two-hour notification, and a final report within fourteen days for an actively exploited vulnerability or within one month for a severe incident, with full application from December 11, 2027.⁴⁶ It is the first regime to make secure development lifecycle practice a market access condition rather than a procurement condition, and it does not care which agent wrote the code.

Vendor and model dependency scoping. Identify which model providers the initiative will depend on and confirm their deprecation policies before the architecture assumes them. Published notice commitments differ materially: one major provider commits to at least six months’ notice for generally available models and as little as two weeks for preview models; another commits to at least sixty days but publishes forward-dated “not sooner than” floors that the first does not.^47,48 Neither addresses behavioral change within a pinned snapshot, which is the risk Section 16 covers.

10.3 Controls #

10.4 Evidence to Request #

• The initiative record containing the AI participation statement and approved tier.
• The absorption model with its inputs and the source of its review-hour estimates.
• The consumption forecast alongside the previous period’s actuals, which is where forecasts are revealed as aspirational.
• Approval records showing the tier was signed at the required authority level rather than assumed.

10.5 Failure Modes #

• Planning the acceleration and not the consequence. The most common failure, and the one with the longest tail. It manifests three to six months later as a review backlog, a rising unreviewed merge rate, and an incident rate that nobody connects back to a planning assumption.
• Treating AI cost as a license line. Procurement approves a seat count, finance budgets a seat count, and the consumption bill arrives against a different cost center with no owner. This resolves badly and usually loudly.
• Assigning a tier by default. Nobody decides that the coding agent operates at A3; it simply arrives configured that way, and the first time anyone examines the question is during an incident review.
• Assuming the pilot’s economics. Pilots run with enthusiastic early adopters on greenfield work—the population and task type where measured gains are largest. Extrapolating those numbers to maintenance work in a mature codebase, where the strongest available RCT found a slowdown, produces a business case that cannot be met.³³