AI Coding Accelerates, But R&D Process Emerges as New Bottleneck

Coding Speedup Shifts Constraints to Upstream and Downstream Phases

Over the past year, the author observes that while AI can generate pages, APIs, data handling, and basic tests rapidly, delivery cycles are still blocked by unresolved requirements, unconfirmed design decisions, pending reviews, unavailable test environments, and missing release ownership. Code is no longer the primary bottleneck; the R&D process itself becomes the constraint because issues previously masked by long coding cycles now surface earlier and more concentrated.

A batch-import example illustrates the shift: the business wants to add "bulk import customer data" to an existing admin system. The happy path seems simple — upload Excel, parse, validate fields, write to database, return results. AI can produce this code quickly, but the team must still answer:

How to handle duplicate records?

What happens on partial failure — rollback or continue?

Is the operation idempotent?

How to process files larger than memory?

What concurrency controls are needed?

Which permissions are required?

These questions were not captured in requirements or design, so AI can only guess from local code. Faster implementation means wrong assumptions propagate into pages, APIs, databases, and tests at higher speed. Consequently, R&D constraints migrate from coding to the phases before and after it: unclear upstream causes accelerated rework; lack of downstream validation and gates turns generation speed into production risk.

Traditional SDLC Responsibilities

SDLC (Software Development Life Cycle) traditionally splits work into planning, design, development, testing, release, and maintenance. Each phase carries distinct responsibilities:

Goals & Scope : Why build, what to build, what not to build

Design & Trade-offs : System boundaries, state, interfaces, risk handling

Implementation : How to turn design into runnable software

Verification : Does implementation meet requirements? Is evidence credible?

Release : Is the current version allowed into the target environment?

Operations : How to detect, recover, and continuously improve issues

The problem is not whether these responsibilities are needed, but that many processes rely on manual information copying and handovers. Information degrades at each handoff, and problems only surface in the next phase. Simply adding AI agents to generate more artifacts in each phase does not automatically fix this fragmentation.

AI-Native SDLC Is Not One Agent Per Phase

Anthropic's AI-Native SDLC Playbook suggests a direction: let each phase produce artifacts readable by the next phase, and place project specs, reusable knowledge, automated checks, and human accountability into a single development chain. It is a vendor playbook, not a mandatory industry standard.

"AI-native" must not be reduced to: requirements agent writes requirements, design agent writes design, coding agent writes code, test agent runs tests, release agent auto-deploys. If those agents still operate with different interpretations, they merely automate the old handoffs — producing more output but also more contradictions.

What must change is how the R&D system connects:

Connect business intent, design, plans, and implementation with authoritative artifacts .

Represent status explicitly: confirmed, pending, blocked, done.

Generate independently verifiable evidence via separate toolchains.

Use permission and responsibility gates to decide phase transitions.

Let production facts feed back to modify original requirements, rules, and tests.

AI can handle massive organization, analysis, implementation, and checking work, but it cannot make unclear responsibilities disappear.

Artifacts, Evidence, and Responsibility Gates Replace Linear Handovers

An AI-friendly development process should run on three driving forces:

Artifacts: Business goals, requirement boundaries, design decisions, task plans, and acceptance criteria must have authoritative versions. Downstream roles read the current baseline, not private chat summaries.

Evidence: Code commits, test passes, pre-release demos, and production runs are facts at different levels; they cannot be replaced by an agent's "done" claim.

Responsibility gates: Design gaps return to architects or product owners; verification failures return to implementers; production risks are accepted by authorized people. Automation advances deterministic work but cannot substitute authorization and risk judgment.

A basic loop can be described as:

Make artifacts the execution baseline.

Let evidence drive state changes.

Let responsibility gates control real risk.

This loop is not infinite retry; each step changes artifacts, evidence, or task state.

Where SDD, Harness, Loop, and Graph Fit

Previous articles covered SDD (Spec-Driven Development), Harness (controlled agent execution environment), Loop (feedback-driven single-task convergence), and Graph (multi-task dependency orchestration). Placed in the full lifecycle:

SDD defines the spec that drives development.

Harness provides the sandbox for agents.

Loop converges a single task via feedback.

Graph organizes multiple tasks and their dependencies.

AI-native SDLC does not replace these methods; it decides how they enter the organizational R&D process. A failing local Loop may trigger a re-implementation at the development node; if acceptance criteria are missing, the task graph routes the issue back to the design node, while the release node stays blocked.

Automation Level Should Follow Risk

Not every stage needs the same autonomy level.

Development branch: Agents can read design, modify code, run tests, and iterate.

Pre-production environment: Data, dependencies, and permissions resemble real systems; automated actions need stricter scope.

Production environment: Data changes, permission changes, and irreversible side effects require controlled tools, short-lived credentials, and explicit authorization.

The process should stop auto-advancement when:

Requirements or design have gaps affecting business outcomes.

Verification evidence is missing, conflicting, or unlinked to the current version.

Acceptance standards would need to be changed to let the current implementation pass.

Release would introduce unaccepted production risk.

External system state is unknown, risking duplicate side effects.

Stopping is not failure; it is part of a controlled process. The real danger is letting undecidable problems continue to be guessed by the model.

Small Teams Don't Need a Full Platform First

AI-native SDLC does not equal buying or building a complex R&D platform upfront. For low-risk, small-scale projects, a minimal chain suffices:

One clear requirements and design baseline.

One set of executable tasks.

One independent test suite.

One protected release pipeline.

Issue tracking that traces back to accountable people.

Only when project count, role count, and operational risk grow does it become necessary to build unified artifact registries, task graphs, policy gates, evidence archives, and production feedback platforms. Tool complexity should follow collaboration and risk growth, not precede problems.

Summary

Faster AI coding does not make the software development lifecycle obsolete. On the contrary, as coding cost drops, the fractures between requirements, design, verification, release, and operations become more visible. AI-native SDLC aims to restructure not a single dev tool but the entire R&D chain:

1. Let artifacts become the execution baseline.
2. Let evidence drive state changes.
3. Let responsibility gates control real risk.

The next article will discuss the first foundation of this chain: why more specs are not better, and how business intent, design, plans, code, and evidence form a continuously executable artifact chain.