Agentic SDLC

The problem

Coding agents are useful because they can operate across many parts of a repository. The same flexibility creates risk: hidden assumptions, accidental refactors, stale context, false “done” states, expensive CI loops and side effects that are hard to audit.

My approach is to engineer the workflow around the agent instead of relying on a perfect prompt. The harness used on internal projects turns recurring engineering lessons into explicit rules, checks and source-of-truth files.

Core principles

• Understand before editing: inspect repository state, relevant files and existing user changes first.
• Classify the change: distinguish spike, bounded change and architectural work.
• Bound scope explicitly: document affected files, dependencies, risks and executable verification criteria.
• Write success is not proof: after important remote writes, read back the source of truth.
• Green is not semantic correctness: a passing build, artifact or screenshot is evidence only when it proves the contract that matters.
• Checkpoint long work: publish logical remote checkpoints so future runs resume from authority, not memory.
• Fast loop, heavy final gate: use cheap checks during iteration and reserve expensive evidence for the release candidate.
• Turn failures into system knowledge: recurring mistakes become rules, automated checks, templates or architecture.

Reference lifecycle

1. Read repository + source-of-truth context
2. Preserve existing user changes
3. Classify: spike / bounded / architectural
4. Write a small change plan
5. Implement the smallest coherent unit
6. Validate near the real behavior
7. Run fast quality gates
8. Publish a remote checkpoint for long work
9. Read back important remote writes
10. At release candidate:
    - full CI
    - build/export
    - security checks
    - visual QA / runtime evidence
11. Review diff + artifacts
12. Record what remains unverified
13. Convert recurring failures into harness improvements

Why evidence is first-class

Agent workflows fail when status becomes a substitute for truth. A screenshot can show the wrong route. A file can exist but contain stale data. A deploy API can return success while the remote state differs from what was intended. A test suite can be green while it verifies the wrong contract.

Fast vs. full CI

On Project Fit, normal draft iteration uses a fast pull-request gate for lockfile integrity, linting, formatting, TypeScript, unit/integration checks and harness validation. Heavy exports and visual evidence run at an explicit final gate instead of every checkpoint.

This protects both quality and cost: the release gate is not weakened, but heavyweight evidence is not repeatedly paid for before a real release candidate exists.

Safety boundaries inside products

The same thinking applies to AI-enabled product features. On a current product, AI-generated interpretation is intentionally separated from canonical product authority. Factual progress, access control, billing, identity and other critical state remain server-authoritative; AI receives bounded context and cannot silently become the source of truth.

Where I want to push this further

• Typed contracts between planning, implementation, review and deployment agents.
• Stronger policy checks around side-effecting tools and secret-bearing operations.
• Automated provenance linking claims to tests, screenshots, logs or remote read-back.
• Reusable adoption patterns engineering teams can understand, customize and teach internally.
• Metrics that separate “more code produced” from actual throughput, reliability and review quality.