Growth vs Polish Phases: Phase Switching for Agentic Development

If you never switch modes, entropy wins. Growth without stabilization is just sophisticated destruction.

Author: James Phoenix | Date: February 2026

Summary

Continuous agentic development needs explicit phase switching between growth mode (new features, architecture exploration, tolerated loss increase) and polish mode (no new features, only loss reduction, regressions forbidden). Make the switch mechanical, not emotional. Trigger it based on loss signals, not feelings. This prevents the #1 failure mode of autonomous dev: building an impressive wreck.

The Problem: Continuous Growth Without Stabilization

When a worker agent churns through tasks continuously, it operates in permanent growth mode by default. New features, new modules, new abstractions, every cycle.

This feels productive. Issue count goes up. Lines of code go up. Features accumulate.

But without stabilization pauses:

Week 1:  10 modules, clean boundaries
Week 4:  30 modules, some boundary leaks
Week 8:  60 modules, dependency tangles, flaky tests
Week 12: 90 modules, "don't touch that file", regressions every cycle

Entropy grows linearly with output volume. Without explicit counterpressure, the system decays even as features ship.

Two Phases, Hard Boundaries

Growth Phase

Goal: Expand system capability. Ship features. Explore architecture.

Not allowed:

• Ignoring failing tests
• Skipping type checking
• Disabling lint rules

Quality gates still run. But the loss tolerance is higher. You accept that L_total may increase temporarily because new code introduces new surface area.

Polish Phase

Goal: Reduce loss. Harden the system. Eliminate regressions.

Not allowed:

• New features
• New abstractions
• New modules
• Large rewrites
• Architectural changes

The agent’s scope is deliberately restricted. This implements decaying step size mechanically.

Phase Invariants

Each phase has hard invariants that agents must satisfy.

Growth Phase Invariants

1. All quality gates pass (types, lint, tests)
2. Every new feature has acceptance criteria
3. L_unknown is tracked (new untested code is logged, not hidden)
4. No regressions on existing features (new code can fail, old code cannot)

Polish Phase Invariants

1. L_total(t+1) <= L_total(t)          (loss must not increase)
2. regressions == 0                     (no previously fixed bugs return)
3. diff_size(t+1) <= diff_size(t)       (changes get smaller)
4. no new modules or abstractions       (scope is frozen)
5. L_unknown must decrease              (every cycle reduces uncertainty)

If a polish cycle violates any invariant, the cycle is rejected. The agent must try again with a smaller, safer change.

Phase Switching Triggers

Make switching mechanical. Define triggers in advance.

Growth to Polish Triggers

Switch to polish when ANY of these fire:

Polish to Growth Triggers

Switch back to growth when ALL of these are true:

The asymmetry is intentional. It is easy to enter polish (one trigger). It is hard to exit (all conditions must be met). This creates a bias toward stability.

Measuring Phase Health

Growth Phase Health Metrics

Polish Phase Health Metrics

Churn Analysis

Track which files are touched most frequently across cycles:

interface FileChurn {
  path: string;
  touchCount: number;     // times modified in last N cycles
  lastModified: string;
  avgDiffSize: number;    // average lines changed per touch
}

// Hotspots = high churn, high diff size
function findHotspots(churn: FileChurn[]): FileChurn[] {
  return churn
    .filter(f => f.touchCount > 5 && f.avgDiffSize > 50)
    .sort((a, b) => b.touchCount - a.touchCount);
}

Hotspots during polish phase = problem. The agent keeps touching the same files without resolving the underlying issue.

The Understanding Lag Rule

If I stopped the worker today, could I explain the whole system to another senior engineer in a week?

If the answer drifts toward “maybe not,” the system has outpaced your comprehension. Enter polish immediately.

Understanding lag is the most dangerous form of tech debt because it is invisible until you need to make a critical decision. During a production incident, you need to understand the system you built. If the agent built it faster than you can learn it, you have a liability, not an asset.

Practical check: After each growth phase, spend 30 minutes reading the diffs. If you cannot follow the reasoning, the growth phase went too long.

Integration with 24/7 Dev Strategy

Phase switching integrates naturally with autonomous night shifts:

Monday-Wednesday:  Growth phase (human + night shift agents build features)
Thursday:          Switch trigger fires (regression or plateau)
Thursday-Friday:   Polish phase (agents reduce loss, human reviews)
Weekend:           Polish continues (agents harden, human reviews Monday AM)
Monday:            Evaluate. If exit conditions met, resume growth.

Phase-Aware Ticket Labeling

Labels:
  - "growth-ready"   → Feature tickets for growth phase
  - "polish-ready"   → Bug fixes, test additions, refactoring for polish phase
  - "phase-agnostic" → Documentation, config changes (either phase)

Night shift agents only process tickets matching the current phase.

Phase Switching in CLAUDE.md

Encode the current phase directly in agent instructions:

## Current Phase: POLISH

### Phase Rules
- No new features or modules
- Only fix existing issues
- Every change must reduce L_total
- Regressions are forbidden
- Max diff size: 100 lines per commit
- Every fix must include a test

### Exit Criteria
- L_total < 5 for 3 consecutive cycles
- Zero regressions for 5 cycles
- All L_unknown items resolved

Switch the CLAUDE.md block when the phase changes. The agent inherits the constraint set for the current phase.

Common Failure Modes

Permanent Growth Mode

Symptom: Never switching to polish. “Just one more feature.”

Result: Impressive feature list, fragile system, increasing regression rate, declining velocity.

Fix: Set a hard rule. Every 2 weeks of growth requires 1 week of polish. Non-negotiable.

Permanent Polish Mode

Symptom: Never switching back to growth. “It’s not stable enough yet.”

Result: Diminishing returns. Polishing code that works. Ship paralysis.

Fix: Set a hard exit condition. If L_total has been flat for 5 cycles and regressions are zero, growth resumes.

Phase Bleed

Symptom: Agent sneaks features into polish phase (“while I was fixing this bug, I also added…”).

Result: Polish phase never converges because scope keeps expanding.

Fix: Reject any diff that adds new public APIs, new modules, or new dependencies during polish. Make this a lint check.

Key Insight

Make phase switching mechanical, not emotional. Define triggers in advance. Bias toward polish (easy to enter, hard to exit). The discipline has to scale with the power.

Related

• 24/7 Development Strategy – Scheduling phases across autonomous shifts
• Synthetic Loss Functions – The loss function that drives phase decisions
• Swarm Convergence Theory – Polish phase implements decaying step size
• Early Linting Prevents Ratcheting – Why early constraints prevent growth-phase debt
• Constraint-First Development – Constraints tighten during polish phase
• Clean Slate Trajectory Recovery – When to abandon and restart rather than polish
• Incremental Development – Small validated increments within each phase