Change Workflows — Features, Defects, Tests, and Modernization
Define distinct operating patterns for the most common code changing workflows.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
The chapter in one pass.
- Purpose: Define distinct operating patterns for the most common code-changing workflows.
- Best for: Engineers and leaders turning a workflow catalog into executable contracts.
- Prerequisites: Autonomous Engineering Workflow Catalog.
- Reading time: 15 minutes.
- You will learn: The different evidence and stop conditions for features, defects, tests, refactors, dependencies, and migrations.
- Keep three ideas: reproduction precedes repair; tests require fault sensitivity, not line count; and modernization must preserve explicit invariants.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Draw separate state and evidence paths for a feature, a defect, and a schema migration. Use the same runtime but different intake, criteria, gates, rollback, and production observation.
3. Enduring Principle
Give each workflow a proof shape
Feature delivery begins from an approved outcome, explicit non-goals, behavioral assertions, rollout, and customer measure. Verification includes requirements coverage, regression, security, operability, and production outcome.
Defect remediation begins with a reproducible failure or an explicit statement that reproduction is unavailable. Preserve the failing fixture, identify root cause, introduce a regression test that fails before the fix, implement the smallest sufficient change, and verify adjacent behavior. A disappearing symptom without causal evidence is not a root-cause fix.
Test generation and maintenance begins from risk, change impact, missing behavior coverage, or a broken test. Evaluate assertion quality, fault sensitivity, determinism, isolation, duration, and maintenance cost. Mutation or deliberate fault injection can show whether the test detects the failure it claims to guard.
Technical-debt reduction begins with a measured constraint: change amplification, defect concentration, dependency risk, build duration, cognitive load, or unsupported technology. Preserve behavioral invariants and compare the named measure before and after. “Cleaner code” alone is not an accepted outcome.
Dependency remediation binds vulnerability, lifecycle, or compatibility evidence to the exact dependency graph. Verify transitive changes, licenses, build artifacts, runtime behavior, rollback, and known breaking changes.
Modernization and migration inventory consumers, schemas, data, compatibility windows, dual-read or dual-write behavior, backfill, verification, cutover, and rollback. Irreversible steps require human risk acceptance and restore evidence.
Keep implementation and verification independent
For material changes, validators should use requirements, fault models, static analysis, integration environments, or tests not authored solely by the implementer. The objective is to reduce correlated error, not to require a different model for every check.
8. Notes and lessons learned
Workflow specialization should live in explicit contracts and verification, not in opaque agent personalities. That makes the same runtime useful without pretending every engineering claim is identical.
9. Interview and discussion questions
- What evidence distinguishes a defect fix from symptom suppression?
- How do you prove an agent-generated test is useful?
- Which measure can justify technical-debt work?
- When is a migration too irreversible for autonomous execution?
- What validator independence is appropriate for a low-risk refactor?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence