How to Reconstruct Feature Evolution from AI‑Generated Sessions with a Feature Explorer

After repeatedly using Codex, Copilot, Claude and Qoder for code generation, the author observes that development speed has increased dramatically, but the product‑level view of feature evolution has become fragmented.

In the Routa workflow, an issue quickly becomes a Spec, followed by sessions, code, and validation results. When the pace of local progress accelerates, the team lacks a way to trace back the evolution process, not because of insufficient execution capacity but because there is no entry point that explains how the feature has changed.

Why does the feature look the way it does today?

Historically, Specs served as the demand hub, but now most substantial implementation changes reside in the session histories of AI agents (failed attempts, temporary interactions, API adjustments, repeatedly edited files). The author therefore asks whether the system can reconstruct the evolution that occurred after the Spec.

Spec as the Starting Point

Spec now acts as the primary entry for AI coding, defining task boundaries, constraints, and acceptance criteria so that agents know what to do and when a task is complete.

If the boundaries are not clearly defined before agents accelerate implementation, sessions may produce runnable code that diverges from product intent.

The problem is that Spec defines the start but does not preserve the evolution; many decisions (why an interaction was dropped, why an API return changed, why a file was rewritten) end up in issue comments, temporary validations, failed attempts, or agent sessions.

How Session History Scatters the Evolution

Looking under ~/.codex/sessions reveals rich information. For example, a session from 2026/04/15 contains four layers: session_meta – records working directory and environment. function_call – records files read and commands executed. agent_message – records intermediate judgments. task_complete – records the final conclusion.

One excerpt shows the agent locating routa-js/acp-process.ts and routa-js/tauri-bridge.ts, then concluding that “ready” must wait before binding a stream listener, otherwise early NDJSON frames are lost.

Sessions are organized by individual conversations, which is useful for debugging a single run but insufficient for tracking the long‑term evolution of a feature that spans multiple pages, APIs, or files.

Feature Explorer: Re‑linking History to the Current Feature

The proposed solution, called Feature Explorer , first asks “Which historical artifacts are worth bringing back for this feature?” rather than merely presenting a raw transcript.

Recovering Feature Boundaries

Feature Explorer shifts the recovery unit from a single session to the set of pages, APIs, and files that constitute the current feature.

In Routa, the design pipeline is:

Write feature boundaries in FEATURE_TREE.md.

Convert them into an indexable structure in feature-tree.index.json.

Expose the structure via /api/feature-explorer to the UI and runtime.

At the API layer, the system:

Reads frontmatter from FEATURE_TREE.

Retrieves the route/API table.

Merges structured results from /api/spec/surface-index.

Completes fields such as pages, apis, sourceFiles, relatedFeatures, and domainObjects.

This establishes a stable boundary before re‑attaching historical evidence, preventing the need to guess which transcript belongs to which feature.

Aggregating Historical Evidence

Once the feature boundary is fixed, the next step is to reorganize the scattered session data into a verifiable context. The goal is not to dump multiple raw sessions but to extract reads, writes, attempts, failures, and convergence steps that directly relate to the current feature.

This transforms session data from a passive log into an active “working context” that can be inspected for bottlenecks and next actions.

Agent‑Driven Analysis on Top of the Re‑organized Evidence

With the curated evidence, the system invokes an agent for the second‑level analysis. The client code ( feature-explorer-page.client.tsx) calls buildSessionAnalysisPrompt(), which gathers selected files, related sessions, tool diagnostics, and repository context into a prompt, then starts a new session using the specialist ID "file-session-analyst".

The analysis pipeline filters out noise (e.g., unchanged files), distinguishes direct reads/writes from related files, and highlights repeated reads, failed tool invocations, and other friction signals that affect the next development round.

The resulting prompt feeds the agent a concise, feature‑centric evidence package instead of a raw transcript, shifting the focus from “summarize history” to “identify bottlenecks and suggest the next precise step.”

Conclusion

Agentic coding dramatically speeds up local implementation, but without a higher‑level product perspective the project can lose overall coherence. By defining feature boundaries, extracting relevant session evidence, and letting agents reason on this curated context, teams can retain both speed and structural integrity.