Closing the Loop: AI-Native SDLC Feeds Production Reality Back to R&D

Production Feedback Must Become Formal R&D Input

The development lifecycle does not end at release. Runtime metrics, user feedback, tickets, and incidents continuously supply new facts. If these facts only drive ad-hoc fixes without flowing back into requirements, design, rules, and tests, teams will repeatedly solve the same class of problems. The final link of AI-native SDLC is not automatic repair of everything, but enabling production facts to continuously correct the development baseline.

Continuing the batch-import example: after launch, the system showed no errors, yet users reported "large files stuck processing." Monitoring showed normal API success rates, but the oldest queue task had waited 40 minutes and database write latency kept rising. These signals must not stay in monitoring platforms and ticket systems. Once confirmed, they should become new problem definitions, change intents, or risk records linked to affected versions, runtime evidence, and owners. This chain turns the maintenance phase from merely handling live issues into the entry point for the next development cycle.

Deterministic Mechanisms First for Anomaly Detection

AI can analyze complex logs and correlate multi-source evidence, but not every anomaly needs model judgment. Task backlog count, oldest task wait time, on-time completion rate, database connection usage, and failure ratio can all be detected with explicit metrics and thresholds. Deterministic mechanisms are easier to test, reproduce, and audit, and they avoid alert flakiness from model output variance.

AI is better suited post-alert to assist with:

Aggregating relevant versions, metrics, logs, distributed traces, and task states.

Proposing candidate explanations against dependency topology and recent changes.

Finding similar historical incidents and existing runbooks.

Identifying conflicts and gaps in current evidence.

Generating improvement intents for owner review.

Candidate explanations are not root-cause conclusions. Simultaneous metric shifts only indicate correlation; they still require call-chain evidence, state evidence, reproduction, or fault injection to verify.

Different Risks Enter Different Automation Paths

Production feedback cannot all trigger automatic code changes, nor can it all rely on manual triage. The article proposes a five-level model based on risk and evidence completeness:

Record only — save facts and wait for trend formation; example: occasional low-impact alerts.

Read-only diagnosis — auto-collect evidence and generate candidate analysis; example: single-batch task latency rising but still within target.

Propose change — create issues, design suggestions, or candidate code changes; example: confirmed insufficient retention of failure details.

Execute pre-approved runbook — mitigate impact within explicit conditions and permissions; example: isolate anomalous worker node and rebuild consumer.

Human decision — handle high-risk, unknown-state, or irreversible actions; example: reconciliation discovers duplicate writes requiring customer data correction.

The path is chosen by jointly considering business impact, action side-effects, evidence credibility, and recoverability. An agent must not promote a read-only diagnosis to a production change just because confidence is high; permissions and tools must enforce that it can only perform actions allowed by the current path.

Incident Facts Must Convert to Protected Regressions

Assume the confirmed root cause: a single large file was split into oversized database batches, causing lock contention that prevented task backlog from recovering within the target time. Article 04 discussed why failure criteria must not be lowered alongside implementation. Production incidents provide the most valuable failure facts. Before changing code, teams should construct a test that reproduces the problem's data scale and concurrency, fixing task wait time, database behavior, and expected results.

Otherwise, a development agent might lower concurrency, adjust alert thresholds, or shrink test data to make current checks pass without truly solving the production problem.

Production facts only become development assets when they enter executable regressions.

One Incident May Modify Assets at Different Layers

Not every problem should be solved with more code. If the business never defined an import completion SLA, first add the requirement and SLO. If the platform lacks backlog metrics, first add observability. If a Skill guided the agent to an unsafe approach, correct the Skill and re-evaluate historical tasks. This demonstrates the value of a complete artifact chain: runtime problems can return to the true decision-owning layer.

Incident Records Must Link Evidence, Decisions, and Remediation

An incident report with only a timeline and summary quickly loses utility. A sustainably useful incident record must at minimum associate:

Affected users, business outcomes, data, versions, and environments.

Confirmed facts, unverified hypotheses, and their evidence.

Remediation actions, authorizers, and actual outcomes.

Root causes, contributing factors, and long-term assets needing updates.

Remediation owners and evidence required to confirm closure.

Agents can help organize scattered evidence and check whether remediation items link to real changes, but they must not generate the report, approve the conclusion, and declare remediation complete on their own.

Feedback Loop Must Prevent Unbounded Accumulation

Not every log, alert, and user opinion deserves a place in the product plan. Teams need to deduplicate, tier, and aggregate feedback: occasional low-impact events can be trended; repeated manual handling should be prioritized for platformization; single events involving security, funds, or data consistency may immediately block releases.

Improvement items also need exit conditions. Once a problem is closed by requirement clarification, design correction, regression testing, and runtime evidence together, the task should end. If it cannot be resolved long-term, the residual risk, compensating measures, and re-review date must be explicit — not left to grow an infinite backlog.

AI-Native Loop Does Not Mean Unattended Development

Feeding production feedback back into R&D does not mean agents can independently observe production, judge root cause, modify code, and auto-deploy. A reliable loop still relies on distinct responsibilities:

Observability and platform provide trustworthy runtime facts.

Agents organize evidence, propose candidate diagnoses and change suggestions.

Architecture, development, and testing roles respectively correct design, implementation, and verification.

Release gates control changes entering production.

Business and operations owners judge risk and actual effect.

AI reduces the cost of information gathering, mechanical implementation, and repetitive checks — it does not remove accountability from the organization.

Small Systems Can Start with One Feedback Loop

Low-risk small projects can begin with a single real problem: let an alert or user feedback link to a specific version, create an improvement task, add a regression test case, complete the fix, and observe the new version's result. There is no need to build automated root-cause analysis and auto-repair platforms first. First prove that production facts are not lost when tickets close, then gradually add automated evidence collection, problem classification, and pre-approved remediation.

Summary

Production incidents must not stop at service restoration and ticket closure. Only when the facts, causes, and corrective actions from incidents flow into requirements, design, rules, code, and tests does the system become truly more reliable. AI-native development is not about making every phase unattended; it is about letting information, evidence, and responsibility flow continuously across the entire lifecycle. Code generation is just one link; software that can be continuously delivered, operated, recovered, and improved is the ultimate outcome.