Driving Self Evolution
Driving Self-Evolution
Given a system description (architecture, codebase, metrics, or capability list), produce three artifacts:
- Improvement Proposal — specific, actionable change with rationale
- Optimization Report — current-state analysis with measured/estimated impact
- Evolution Roadmap — phased plan sequencing improvements over time
Example invocation: "Analyze our recommendation service (Python, monolith, 200ms p95 latency, no caching layer) and produce the three outputs."
Progress:
- Step 1: Gather system context (architecture, metrics, constraints, goals)
- Step 2: Identify capability gaps (what's missing vs. what's needed)
- Step 3: Identify architecture weaknesses (coupling, scalability, single points of failure)
- Step 4: Discover optimization opportunities (performance, cost, maintainability)
- Step 5: Rank findings by impact vs. effort
- Step 6: Draft Improvement Proposal(s) for top-ranked items
- Step 7: Draft Optimization Report summarizing current state + findings
- Step 8: Draft Evolution Roadmap sequencing all findings into phases
- Step 9: Review outputs for consistency (roadmap references proposals; report justifies both)
Step Details
Step 1 — Context gathering. Ask only if critical info is missing (e.g., "no latency/throughput data provided — proceeding with qualitative analysis only"). Otherwise proceed with available data; don't stall on clarifying questions.
Step 2-4 — Discovery. Look across three lenses simultaneously:
- Capability: missing features, unhandled edge cases, absent observability
- Architecture: tight coupling, scaling ceilings, single points of failure, outdated patterns
- Optimization: redundant computation, missing caching, inefficient data access, resource waste
Step 5 — Ranking. Use Impact (High/Med/Low) × Effort (High/Med/Low) to prioritize. Always surface quick wins (High Impact, Low Effort) first.
Step 6-8 — Drafting. Use the exact output formats below. Keep each proposal self-contained — a reader should understand it without reading the whole report.
Improvement Proposal
- Problem: [what's wrong or missing today]
- Proposed Change: [concrete action]
- Rationale: [why this fixes the problem]
- Impact: [High/Med/Low] | Effort: [High/Med/Low]
- Risks: [what could go wrong / tradeoffs]
- Success Metric: [how to verify it worked]
### Optimization Report
Current State
[brief summary of system as analyzed]
Findings
| # | Area | Issue | Impact | Effort |
|---|---|---|---|---|
| 1 | ... | ... | H/M/L | H/M/L |
Recommendations
[ranked list, quick wins first]
### Evolution Roadmap
Phase 1 (Now — quick wins)
- [item] — [expected outcome]
Phase 2 (Next — structural improvements)
- [item] — [expected outcome]
Phase 3 (Later — strategic evolution)
- [item] — [expected outcome]
Dependencies & Sequencing Notes
[what must happen before what, and why]
Example 1: Input: "Monolithic e-commerce backend, single Postgres DB, no read replicas, deploy takes 45 min, no feature flags."
Output:
- Improvement Proposal: "Add read replica for product catalog queries" (High Impact, Med Effort, reduces DB contention)
- Optimization Report: findings table listing deploy time, DB bottleneck, missing feature flags, each ranked
- Evolution Roadmap: Phase 1 = read replica + feature flags (quick wins); Phase 2 = deploy pipeline optimization; Phase 3 = service decomposition
Example 2: Input: "AI agent with 5 tools, no memory between sessions, frequent redundant API calls."
Output:
- Improvement Proposal: "Introduce response caching for idempotent tool calls" (High Impact, Low Effort)
- Optimization Report: notes redundant calls as top cost driver, no-memory as capability gap
- Evolution Roadmap: Phase 1 = caching; Phase 2 = session memory layer; Phase 3 = cross-session learning/personalization
- Always tie every proposal to a measurable success metric — vague improvements ("make it better") are not acceptable output.
- Prefer 3-5 high-quality findings over 15 shallow ones.
- Explicitly separate "quick win" from "strategic" items in the roadmap — stakeholders need both horizons.
- When data is sparse, state assumptions explicitly rather than inventing false precision.
- Keep proposals technology-agnostic when the input doesn't specify a stack; don't assume languages/frameworks not mentioned.
- Don't produce a roadmap that includes items never mentioned in the report or proposals — everything must trace back.
- Don't rank everything as "High Impact" — differentiation is the point of ranking.
- Don't skip the Risks field in proposals; every change has a tradeoff, even if minor.
- Don't conflate capability gaps (missing functionality) with optimization issues (existing functionality is slow/wasteful) — keep them distinct in analysis even though outputs combine them.
- Avoid generic boilerplate advice ("improve testing", "add monitoring") unless grounded in the specific input context.