Skip to content

Methodology

HELIX is an opinionated methodology for agentic software development. Named after the double helix of DNA, it encodes the idea that planning and execution are two complementary strands that happen simultaneously and feed back into each other. Neither is primary. Neither is sequential. They intertwine.

Why HELIX Exists

Three approaches to software development each make a different mistake:

  • Waterfall assumes you can plan completely, then execute.
  • Agile (in many implementations) assumes you can execute without planning.
  • Vibe coding / ad-hoc agentic development assumes agents can infer intent from code alone.

HELIX says: plan and execute simultaneously, at multiple levels of abstraction, with documentation as the shared context layer.

The Double Helix

HELIX operates as two interleaved cycles:

  • Planning helix: review, plan, validate — creates and refines beads (tracked work items)
  • Execution helix: execute, measure, report — claims beads, does work, records results, creates follow-on beads

These cycles run concurrently. A human can refine specs while an agent builds features. New requirements flow through the planning helix while implementation advances through the execution helix. The tracker is the shared state between them.

Progressive Abstraction Layers

Each layer is a lens at a different zoom level. Changes can enter at any layer and propagate up, down, or sideways.

LayerArtifactPurpose
DiscoveryResearch, competitive analysisUnderstand the problem space
VisionProduct VisionWhat is the thing? Why does it exist?
RequirementsPRDHigh-level features and constraints
SpecificationFeature Specs + Acceptance CriteriaWhat each feature does, how we know it works
DesignTechnical Designs, Solution Designs, ADRsHow to build it, what trade-offs we make
TestTest suites (from acceptance criteria)Executable assertions proving requirements are met
CodeImplementationThe software itself

Higher layers govern lower layers. Source code reflects what exists, not what should exist. When layers disagree, HELIX resolves by escalating to the governing source — not by guessing from code alone.

Phases

Work moves through five phases. These are not a sequential pipeline — teams regularly loop back as they learn.

PhaseDescriptionKey Activities
DiscoverExplore the problem spaceMarket analysis, competitive review, stakeholder research
FrameDecompose the problem into structured artifactsVision, PRD, Feature Specs, Acceptance Criteria
PlanEncode requirements as testable assertionsConvert acceptance criteria into executable tests
Build / IterateRed-green-refactor against testsImplement code to pass tests, respecting cross-cutting concerns
PolishSystematic optimization against metricsHypothesis-driven improvement, adversarial review, gap analysis

Multi-Directional Workflow

HELIX is not top-down. Changes can enter at any layer:

  • Top-down: Update the vision, and HELIX propagates through specs, designs, and implementation.
  • Bottom-up: See the output of a build, provide feedback, and HELIX routes corrections to the right layer.
  • Middle-out: Refine a feature spec because implementation revealed a missing requirement.
  • From running systems: Interact with the working software, provide unstructured feedback (“I don’t like how this looks”), and HELIX determines which abstraction layer the feedback applies to.

All of these flows use the same commands: helix evolve threads changes through the artifact stack, helix align reconciles drift, and helix run picks up the implementation work.

Artifact Graph

HELIX artifacts form a directed graph of relationships:

Vision ──→ PRD ──→ Feature Specs ──→ Acceptance Criteria
                        │
                        ├──→ Technical Designs
                        │
                        └──→ Solution Designs
                                    │
ADRs ←── Cross-cutting Concerns ────┘
  │
  └──→ Context Digests ──→ Execution Beads

This graph enables:

  • Impact analysis — when an artifact changes, identify which others are affected
  • Reconciliation — verify that dependent artifacts remain consistent
  • Context synthesis — a bead can pull in its full governance chain automatically

Cross-Cutting Concerns

Cross-cutting concerns are first-class artifacts in HELIX. They capture technology choices, quality attributes, and conventions that apply across multiple features:

  • Technology stacks: language, runtime, package manager, test framework
  • Quality attributes: accessibility, observability, internationalization
  • Conventions: linting, formatting, naming, error handling

Concerns are declared in the project and folded into every execution bead via context digests, so agents respect them without being reminded.

Adversarial Review

HELIX encourages adversarial review as a core practice:

  • After an agent completes work, a different agent (or different AI model) examines it against the artifact hierarchy
  • Reviews check: Does the implementation match the spec? Does the spec still align with the PRD? Are cross-cutting concerns respected?
  • Review findings become new beads in the tracker, feeding back into the planning helix