Exogenesis / Drift Taxonomy

Drift Taxonomy

Recurring patterns of semantic drift observed in prompt-driven software generation. These are not random accidents — they are anticipatable failure modes that appear consistently across experiments.

Constraint Drift

Constraint words like "tiny", "simple", "minimal", or "clean" are reinterpreted loosely during implementation.

Pattern
The prompt uses a strong limiting word. The implementation keeps the aesthetic of minimalism but inflates scope or adds silent complexity.
Example
A prompt for a "tiny pomodoro timer" produces an app with long breaks, skip buttons, notification systems, and session history.

Product-Identity Drift

The implementation shifts from the intended product category to a neighboring but different one.

Pattern
The right-looking feature set is built, but the product is conceptually organized around the wrong primary object.
Example
A budget tracker becomes an expense tracker. A todo app with notes becomes a notes app with tasks.

Practice-to-Tool Drift

A prompt describing a human ritual, practice, or experience is reframed as an information management tool.

Pattern
The implementation optimizes for managing entries instead of supporting the lived activity the prompt is really about.
Example
A prompt for a meditation practice companion becomes a meditation session logger.

Hidden-Domain-Truth Suppression

Important domain-specific truth is recognized or inferable, but remains hidden in implementation choices instead of becoming an explicit user-facing constraint.

Pattern
The agent makes a domain-sensitive choice silently, without surfacing that it made a choice or that alternatives exist.
Example
A prayer time calculation method is chosen without surfacing which method or that multiple methods exist. Palette accuracy limits are not shown to the user in a ceramics workflow.

Surface-over-Substance Drift

The implementation invests more energy in visible polish than in the thing the product actually depends on.

Pattern
Themed visuals are strong. Substance or depth is shallow.
Example
A beautifully styled app with animated transitions but broken core logic or missing essential validations.

Scope Inflation

The implementation expands the problem space beyond what the prompt requires.

Pattern
Features, settings, and capabilities appear that were never requested, often justified by the agent as being "useful" or "expected."
Example
A prompt for a countdown timer produces an app with customizable themes, sound selection, multiple timer presets, and statistics.

Silent Default Selection

The agent chooses a default in an ambiguous area without surfacing that choice as meaningful.

Pattern
The prompt leaves something genuinely ambiguous. The agent resolves the ambiguity by picking a default and implementing it as though it were specified.
Example
The prompt says "save data" without specifying where. The agent silently chooses localStorage over a file, a database, or cloud sync, without noting this was a decision.

Plan Substitution

An intermediate implementation plan becomes more authoritative than the original prompt.

Pattern
The agent interprets the prompt, generates an internal plan, the plan reframes the product, and the implementation faithfully follows the plan instead of the original intent.
Example
A prompt for a "minimal todo app with markdown notes and preview" is reframed as a "markdown editor with task management" — the agent's plan reorganizes the product around the wrong concept.

Dependency Drift

The implementation introduces dependencies, frameworks, or architectural weight that are misaligned with the stated simplicity or speed posture.

Pattern
A prompt requesting something lightweight or simple results in an implementation that pulls in heavy frameworks, build tools, or complex architecture.
Example
A prompt for a "simple single-page tool" produces a multi-file React project with a build pipeline, state management library, and component framework.

Legitimate Divergence

Not every difference between implementations is drift. A legitimate divergence is a difference that represents a valid design choice in an area the intent artifact did not constrain.

A difference is legitimate divergence only when all three conditions hold:

  1. The intent artifact does not specify or imply a preference in this area
  2. The difference does not conflict with any protected value, invariant, or forbidden state
  3. The difference does not alter the product's identity, center of gravity, or trade-off posture
Examples
CSS color scheme choices, localStorage vs IndexedDB when the artifact specifies persistence but not mechanism, file organization, UI layout decisions like sidebar vs top-nav, stack differences when the artifact specifies capability not technology.

Without a legitimate divergence category, the drift taxonomy risks becoming a confirmation lens — every difference gets classified as drift, inflating the apparent significance of intent discovery. Legitimate divergence is a healthy finding.

Non-Drift Evidence

Not every important finding is a drift finding. Experiments also surface positive evidence patterns:

  • Regeneration fidelity — an intent artifact guides recovery after implementation loss
  • Verification emergence — explicit intent naturally reveals what must be tested
  • Artifact-level convergence — independent agents produce similar implementations from the same intent artifact
  • Hidden correctness surfaced — domain truths become explicit user-facing constraints instead of silent implementation choices

Reporting Guidance

When labeling drift in a field note:

  • Use the most specific drift category available
  • If multiple apply, list the primary one first
  • Do not force every difference into a drift category
  • Before classifying a difference as drift, first evaluate whether it is legitimate divergence
  • Note when a branch converged instead of drifted
  • Note when a result is better described as regeneration, verification, or artifact-level alignment evidence
See Drift in Field NotesExplore Vocabulary →