Continuing change without repeating initial setup
Once a product has an approved technical foundation, maintained specifications, and a known design direction, further development can follow a shorter cycle. The Product Engineer remains accountable for changes across a bounded portfolio of applications.
Stage 1. Specification and implementation enhancement
The Product Engineer may begin with a conversation, demonstration, or correction to working behavior. The agent implements within current approved instructions and capabilities while maintaining the intended-behavior context. The PE runs the product and iterates with concrete feedback; no polished per-feature document or universal document approval is required first. Consequential policy and risk decisions remain with their authorized owners. Maintenance without a behavioral effect needs proportionate quality checks, not a fictional new feature.
Incremental implementation is the default: agree a bounded capability, inspect the working result, and adjust before expanding. Define creative/UX, structural, functional, and content latitude explicitly, including what stays outside scope. Broad experiments and reversible prototypes can justify wider latitude when deliberately agreed. Read Defining Agentic Latitude.
Stage 2. Independent Spec-Based Testing
A separate verification context examines the relevant committed specifications, derives tests, and checks the changed application. It should cover the change and meaningful regression risks in adjacent behavior. Findings are corrected or explicitly dispositioned; changed behavior is retested.
Stage 3. Architect review as required
The architect reviews changes that meet the organization's risk or policy thresholds. Examples may include new integrations, permission changes, material architectural changes, or changes affecting shared enterprise libraries. Routine modifications within approved patterns may require less review. The Product Engineer does not waive mandatory reviews on personal preference.
Stage 4. UAT
Business stakeholders perform acceptance according to the organization's existing practices. The Product Engineer coordinates issues and records accepted behavior in the maintained specifications. Release and operations continue outside the SHAPE development cycle.
When the short cycle is insufficient
A fundamental redesign, a new system boundary, or major change to security responsibilities may warrant additional discovery, UX work, setup, and review similar to Cycle 1. The framework's purpose is to remove unnecessary repetition, not to ignore real technical or business risk.