Code Learned to Write Itself. Now Software Development Must Learn to Record Decisions

The release that stalled after the code was ready

Imagine that a team gives a task to a coding agent in the morning and receives a working diff with tests by lunch. The release should happen tomorrow. Then the team discovers incomplete acceptance criteria, an old specification that disagrees with the solution, a security review scheduled for Thursday, and a restriction nobody can explain anymore.

The code is ready. The work is not. Anthropic’s AI-Native SDLC Playbook begins with this paradox. When Build contracts from weeks to hours, the old process does not accelerate as a whole. It simply reaches Plan, Test, Deploy, and Maintain sooner—stages that still move at human speed.

Anthropic bends the pipeline into a loop

A traditional SDLC resembles a relay race. An idea moves to a product manager, requirements to an architect, design to an engineer, and code to QA and release teams. Each role receives a document, ticket, or link and tries to reconstruct what the previous person meant.

Anthropic asks teams to stop treating Plan, Design, Build, Test, Deploy, and Maintain as six isolated rooms. In an AI-native SDLC they form one loop: an accepted outcome starts the next stage, while a production incident returns to the beginning as new intent.

People do not disappear from the process. They move above the loop, setting direction, approving intent, accepting risk, and handling exceptions. Agents take the work that can be repeated, verified, and handed forward without another meeting.

• Plan: the original problem becomes intent that both a person and an agent can understand.
• Design: accepted intent becomes requirements and a technical specification constrained by company standards.
• Build: an agent creates the plan, code, tests, and supporting documentation.
• Test: checks and evals run continuously instead of only at a stage boundary.
• Deploy: agentic review handles standard checks while people focus on regulated and critical decisions.
• Maintain: agents monitor operational signals, diagnose problems, and return them to a new cycle.

Every decision needs to leave a memory

In Anthropic’s model, each stage ends with a saved artifact that the next agent can read and a person can review: intent, specification, plan, diff with tests, pull request with review findings, or incident record. The revision history becomes an audit trail showing who requested the change, what the agent produced, and who approved it.

The principle matters more than the file format. A company can keep intent in Git, Jira, or another system if it defines the source of truth and links related objects. Trouble begins when the ticket is separated from the decision, the specification from the implementation, and the reason for a change from its recorded history.

We call it “Context → Generation → Context”

Two months before Anthropic published its playbook, Laplace founder Alexander Nekrashenko described the same problem from an engineering team’s perspective. When an agent generates a thousand lines in an hour, system understanding no longer emerges automatically through the work of writing code. A team can receive a working result while losing the knowledge of why the system was built that way.

The proposed new loop is “Context → Generation → Context.” Before generation, the team gathers the task, constraints, architecture, and rules for the agent. After generation, it returns decision rationale, task links, change descriptions, and new product knowledge to the work systems. The next iteration starts from that recorded context instead of investigating the code again.

Anthropic formalizes this principle across the complete SDLC. Intent, specification, plan, diff, review findings, and incident record become consecutive carriers of context. The formats differ, but the objective is the same: prevent understanding from disappearing between generation, review, and the next iteration.

Laplace works one level above the code

A coding agent sees the repository. The reason it needs to change the code usually lives somewhere else. A customer complained in one system, a product manager created a task in another, requirements changed in Confluence, an architectural exception was discussed in a meeting, and the previous implementation can only be reconstructed from GitHub.

Laplace is building a team layer across those gaps rather than another code generator. Inside a workspace, digital employees receive approved sources, a defined role, and tools. One reconstructs feature context, another checks the brief, and a third prepares a release package. Recurring work can run on a schedule, while consequential actions stay with a person for approval.

• Jira provides tasks, statuses, comments, participants, and work history.
• Confluence contains requirements, decisions, procedures, and project documentation.
• GitHub links requirements with issues, pull requests, diffs, and implementation files.
• Workspace documents add specifications, spreadsheets, presentations, and other supporting material.
• Context Audit reveals incomplete tasks, documentation gaps, weak links, and unresolved decisions.
• Digital employees collect, verify, and transfer context for a specific process role.

Laplace does not replace an IDE, CI/CD platform, or coding agent. Its role is to make company context available to a managed digital team and reduce information loss between people, agents, and systems.

Monday. The request has not become a task yet

The new loop does not begin with “build this feature.” On Monday, the team first captures intent: whose problem this is, which outcome matters, which systems are affected, where the boundaries sit, and what remains unknown. In Anthropic’s model, a product owner reviews that draft before it becomes the basis for design.

In Laplace, a digital analyst or coordinator can collect related context from tasks, documentation, past decisions, and customer material, identify contradictions, and draft a structured problem statement. Context Audit can show what information is missing before work reaches engineering.

• Find the original request and affected users.
• Compare the task with current requirements and past decisions.
• Identify missing acceptance criteria, constraints, and owners.
• Prepare a structured brief for product and engineering.
• Leave requirements approval with the accountable person.

Wednesday. The code is ready, but understanding still needs review

By Wednesday, the specification becomes a plan, code, and tests. The coding agent is finally in its natural environment. Anthropic recommends keeping project rules in version-controlled instructions, running checks before claiming completion, and beginning a bug fix with a test that reproduces the failure.

Laplace can prepare the input context for that session: related requirements, decisions, tasks, pull requests, and relevant documents. After implementation, a digital employee can compare the diff with the original request, verify link coverage, and surface questions for review. Executing tests and editing code remain responsibilities of the coding agent and engineering toolchain.

Friday. A release ends with new memory, not the Deploy button

By Friday, the question is no longer whether the agent can press Deploy. The question is what may pass automatically and where the company must stop and make a decision. Anthropic gives standard checks to agents and preserves human attention for critical, regulated, and ambiguous changes.

In the current Laplace product, actions depend on the tools and workspace permissions available to an agent. Proposed changes can remain drafts until a person explicitly approves them. A digital release coordinator can assemble tasks, changes, documentation, and open questions into one release package, while accountable people make the release decision.

After release, a digital employee can regularly collect signals from connected sources, relate incidents to changes, and prepare context for the next task. A fully event-driven loop in which a production alert automatically creates intent and launches a chain of agents is not a current Laplace capability.

Where the elegant diagram meets reality

In a diagram, the loop closes with one arrow. Inside a company, those arrows cross legacy systems, different owners, security requirements, and accumulated Context Debt. AI-native SDLC is therefore an operating model rather than a feature that can be enabled with one switch.

• Laplace already connects work sources and supports specialized digital employees.
• Context Audit already helps identify Context Debt in available data.
• Laplace automations run one configured agent on a schedule through its available tools.
• Arbitrary event-driven orchestration across all six SDLC stages is not currently implemented.
• A unified Knowledge Graph and Process Discovery Agent are in development and are not available product features.

A practical adoption path is therefore to use Laplace alongside coding agents: first improve context and specific roles at the most painful handoffs, measure the effect, and then connect stages that have already proved reliable.

What a team can change on Monday

A team does not need to announce a transformation of all six stages on Monday. It needs to find one place where work repeatedly stops to reconstruct context and ask eight practical questions about it.

• 1. Choose one handoff: idea to brief, specification to development, pull request to release, or incident to new task.
• 2. Record a baseline for wait time, rework, missed requirements, and manual information search.
• 3. Define the source of truth and links between Jira, Confluence, GitHub, and supporting documents.
• 4. Run a Context Audit and repair critical gaps.
• 5. Create one digital role with bounded tools and a verifiable outcome.
• 6. Define the human approval point and accountability for the decision.
• 7. Compare the duration, completeness, and quality of the new process with the baseline.
• 8. Automate the next handoff only after the first produces stable results.

Frequently asked questions about AI-native SDLC

What is an AI-native SDLC?

It is a software development lifecycle in which AI participates at every stage, from capturing intent and designing a change through testing, release, and maintenance. Reviewable artifacts connect the stages, while people approve decisions that require judgment and accountability.

How is AI-native SDLC different from AI coding?

AI coding accelerates the creation and modification of code. AI-native SDLC redesigns the complete process around that acceleration, including planning, requirements transfer, verification, governance, release, and the return of production knowledge into the next cycle.

Does Laplace replace Claude Code?

No. A coding agent works directly with code and engineering tools. Laplace helps collect company context from work systems, identify gaps, and organize digital roles around the process.

Can Laplace automate the complete SDLC?

Not yet. Laplace supports specialized agents, connected work sources, Context Audit, and scheduled runs. Fully event-driven orchestration across all six SDLC stages is not a current product capability.

Which SDLC stage should a company start with?

Start with a transition where the team regularly loses time or context and can measure the result: preparing a brief, collecting context before development, checking implementation against requirements, or assembling a release package.