The Seven Stages: A Deep Dive into ADLC Workflow

The ADLC lifecycle is built on seven sequential stages, each with clear entry and exit criteria, evidence production, and decision gates. This article walks through a real example: implementing a new feature to export billing reports.

Stage 1: Intent and Context

A product manager posts: "Add ability to export monthly billing reports as CSV and PDF for customers. Needed by end of quarter for enterprise customers."

The workspace intent agent:

• Captures the request and classifies it as a feature request.
• Searches workspace history for related work (do we have report builders? PDF libraries?)
• Identifies stakeholders (product, engineering, compliance team).
• Flags any policy constraints (data retention, audit logging for exports).
• Routes to the next stage: planning.

Stage 2: Plan and Decompose

The planning agent now researches and decomposes the feature:

• Research viability: Are there existing PDF libraries? How much storage do we need? What are the GDPR implications of exporting customer data?
• Decompose into tasks: Create report schema, implement CSV export, add PDF rendering, wire UI buttons, add audit logging, write tests.
• Define acceptance criteria: "CSV export includes all fields, respects date filters, runs in <5 seconds for 1M rows."
• Estimate and sequence: Some tasks can run in parallel (CSV and PDF implementation), but both depend on the schema task.
• Flag assumptions: "Assumes billing data is immutable after 30 days. If this changes, export logic needs revision."

A human reviews the plan. If it makes sense, they approve and the plan moves to implementation. If the scope is too large or assumptions are questionable, they send it back to planning for revision.

Stage 3: Implement

The coder agent now picks up one task at a time, working in an isolated branch:

• Task 1: "Create report schema and database migration."
• The agent clones the repo, creates a feature branch, writes the schema definition, creates a database migration, and runs local tests.
• It maintains a review workpad: "Here's what I did, here are the files I modified, here are the edge cases I considered."
• When the task is complete, it creates a draft PR with the changes.

Then it moves to Task 2: "Implement CSV export." The process repeats. The agent may revise its own work in the same branch (fixing lint issues, improving tests) or ask for human guidance if it gets stuck.

Stage 4: Verify

The tester agent (or automated testing suite) now validates the implementation:

• Run unit tests: "Do the new export functions work with various inputs?" Coverage: 92%.
• Run integration tests: "Does the database schema apply cleanly? Do the new endpoints return the right data?"
• Run smoke tests: "Can I generate a CSV and PDF end-to-end? Do the files open in Excel and PDF readers?"
• Check policy compliance: "Are all exports logged? Do we avoid exporting PII outside the allowed scope?"
• Measure performance: "Does exporting 1M rows still run in <5 seconds?"

If tests fail, verification stops and the implementation stage loops back. If everything passes, all evidence is attached to the work item.

Stage 5: Review and Govern

Now a human review gate applies. The reviewer sees:

• The original intent and plan.
• The actual code changes, organized by task.
• Test results and coverage metrics.
• The workpad explaining design decisions.
• Any policy checklist items that were flagged.

The reviewer can:

• Approve: "Looks good. The implementation matches the plan, tests pass, no new risks."
• Request changes: "Please add validation to reject exports >1M rows. The query planning could return bad results without it."
• Reject: "This doesn't match the original intent. The PM said 'enterprise customers only' but this exports for all customers. Back to planning."

Stage 6: Deliver

If approved, the implementation moves to delivery:

• PRs are merged to main branch.
• Code is deployed to staging environment.
• Smoke tests run against staging to verify deployment.
• Feature flag is toggled for 5% of traffic (canary release).
• Errors and latency are monitored.
• Once stable, full rollout to 100%.

Stage 7: Observe and Learn

Finally, the system records what happened:

• Success metrics: The feature shipped on time. All tests passed. No production issues in the first week.
• Cost tracking: This task took 2 hours of planner time, 4 hours of coder time, and $0.12 in API costs. Future similar tasks cost roughly the same.
• Feedback: Customers loved the PDF export. CSV export is rarely used. Future work on formats should prioritize PDF.
• Learnings: "Our schema migration pattern worked well. Assumptions about billing data immutability held up. Testing strategy was effective."

This data is indexed and searchable. The next time a planner sees a similar feature request, it can query: "Has anyone built data export features? What did they learn?"

The Loop

This seven-stage cycle repeats for every feature, bug fix, and infrastructure change. Humans and agents collaborate at each gate. Evidence flows from one stage to the next. Decisions are reversible because they're documented. Learning compounds because outcomes are recorded.

The result: faster, more accountable, verifiable software delivery.

Read the full brief: ADLC Brief
Back to blog: All posts