GenAI development techniques — overview and comparison¶
1. Executive summary¶
As of October 27, 2026, AI-assisted development includes structured methodologies, multi-agent frameworks, autonomous loops, and enterprise workflows. This comparison examines how each approach directs coding agents through context, artifacts, verification, and governance.
The comparison groups methodologies by workflow, with context engineering as a cross-cutting practice.
The skills ecosystem supports these approaches. Reusable skills are becoming versioned, updatable packages instead of loose file collections.
Two channels distribute them. Cross-agent installers, such as skills.sh's npx skills, copy editable files into supported agents. Native plugin marketplaces for Claude Code, GitHub Copilot, and Codex install managed bundles inside one runtime; update policies vary. mattpocock/skills and addyosmani/agent-skills ship through both paths. Choose one path per library per agent to avoid duplicates.
Some libraries now bundle an orchestrating mode alongside their skills. pstack/poteto-mode (canonically the pstack/ directory in cursor/plugins) reads an incoming request, selects from a set of playbooks, and dispatches the library's other skills as each step needs them. That blurs the line between a skill library and a workflow framework.
Most of what we examined lacks signing, attestation, and lockfile-style pinning. The skills layer is supporting infrastructure, not an additional methodology category. Star counts are dated awareness signals; they do not establish production adoption.
Choose an approach based on the task, coordination needs, and governance requirements. A solo prototype and a regulated enterprise project need different levels of structure.
The three-layer model: model, runtime, methodology¶
The comparison distinguishes three layers:
Scroll horizontally to view the full diagram.
- Model capability — what the underlying LLM can reason about, plan, and execute reliably, holding everything else constant.
- Execution runtime / harness — the tool loop around the model: context assembly, tool calls, retries and recovery, permissions, sandboxing, and state across turns. This layer itself spans a range:
- No harness — direct API calls; the caller writes the loop.
- Thin generic harness — a deliberately minimal, model-agnostic loop, such as
SWE-agent/mini-swe-agent, a roughly 100-line agent built as a hackable research baseline rather than a product. - First-party runtime — a vendor-maintained product such as Claude Code, Codex CLI, or GitHub Copilot, which bundles tool access, sandboxing, approval modes, and multi-turn state behind a single surface.
- Development methodology — the process layered on top: GSD's phases, Squad's charters, HVE's RPI workflow, or BMAD's agile simulation. Some methodologies prescribe mandatory sequencing or controls, such as Superpowers' skills and HVE's constraint-based gates. The runtime still executes the work.
Our view. As models improve, checkable tasks need less rigid upfront workflow. For a bounded repository task with tests, lint, or a reviewable diff, a capable model and runtime increasingly handle planning and tool sequencing without an added methodology.
Execution harnesses still do necessary work. Claude Code and Codex CLI manage sandboxing, approval modes, and conversation state (Claude Code docs; Codex CLI). Unlike a thin harness, they do not require you to implement that logic yourself.
Interpreting capability metrics. METR's time horizon measures the human completion time of tasks a model can finish at a given reliability, commonly 50%. It measures task difficulty at that threshold, not unattended autonomy or merge-ready work.
METR fits a logistic success curve against human task duration and reports where that curve crosses the chosen probability. The method says nothing about whether a human reviewer would accept the output.
METR also ran a companion study of SWE-bench Verified PRs. Roughly half of the patches that passed the automated grader were not actually merged by real maintainers, even after adjusting for noise in human review. Benchmark graders miss regressions, style drift, and incomplete fixes. Agents, unlike human contributors, were not given a chance to revise after feedback.
Use capability figures as evidence about the measured tasks, not as guarantees of unattended autonomy or mergeability.
Examples from this research pass. GPT-6 Astra and Claude Opus 5.5 are frequently cited for strong repository-task results. Each result comes from the vendor's own agent runtime, not a bare model call, so it reflects both model and runtime. We found no same-harness, same-benchmark comparison between them, or an independent METR-style time-horizon figure for either exact model. Treat the vendor-reported scores as lower-confidence signals, not independently reproduced capability measurements.
A practical decision rule:
- Start with the model and its native runtime (Claude Code, Codex CLI, Copilot, or similar). This is often enough for a bounded, clearly specified task with independent checks.
- Add skills for expertise the model does not reliably apply: a convention, domain pattern, or house style.
- Add a methodology for coordination or decision traceability: multiple agents, multiple people, or a record of why a change was made.
- Strengthen governance, audit trails, approval gates, and cost caps as autonomy, duration, potential impact, or compliance risk increases.
Use the comparison below when the added structure addresses a gap in your workflow. See Choosing Your Approach for examples by scenario.
2. Comparison matrix¶
The ratings are qualitative judgments based on the research, not benchmark scores. Where a technique spans a range, the table uses a representative value.
| Dimension | GSD | BMAD | Spec Kit | OpenSpec | Squad | Ralph | Superpowers | HVE | Context Engineering |
|---|---|---|---|---|---|---|---|---|---|
| Approach | Spec-Driven | Multi-Agent | Spec-Driven | Spec-Driven | Multi-Agent | Autonomous Iteration | Skill-Based | Enterprise SDLC | Practice |
| Human Control | Semi-autonomous | HITL | HITL | HITL | Semi-autonomous | AFK / HITL | Semi-autonomous | Phased | HITL |
| Setup Complexity | Minutes | Hours | Minutes | Minutes | Hours | Minutes | Minutes | Hours–Days | Minutes |
| Tool Compatibility | 20 documented host profiles with capability negotiation; Copilot defaults to sequential inline execution | Multi-tool; Web Bundles are planning surfaces, not CLI parity | Multi-tool with many pre-baked prompts | Broad native/pre-baked support; runtime parity not verified | GitHub Copilot | Tool-agnostic AI CLI pattern | Multi-tool methodology | GitHub Copilot | Tool-agnostic practice |
| Scale | Solo–Small team | Solo–Enterprise | Solo–Small team | Solo–Small team | Small team–Enterprise | Solo | Solo–Small team | Large team–Enterprise | Solo–Enterprise |
| Predictability | High | High | Medium–High | Medium–High | Medium | Low–Medium | High | High | Varies by implementation |
| Context Management | Fresh agent per task; waves for parallelism | Agent personas + structured workflows | Spec files as context anchor | Change folders as context anchor; spec deltas track requirement evolution | Charter files + decision ledger + history | Fresh context each loop iteration; git as memory | Skill files as behavioral modules; token-light bootstrap (~2K tokens); lazy skill loading via CLI search; subagents for implementation | Clear context between RPI phases; research docs persist in files | Rules files layered by scope (8-layer model) |
| Quality Gates | Moderate (verification per phase) | Comprehensive (QA agent, readiness checks, retros) | Moderate (analyze + checklist commands) | Moderate (proposal approval, validate --strict, verify command) | Moderate (reviewer rejection protocol, ceremonies) | Basic (tests/linting as backpressure) | Comprehensive (mandatory skills, TDD enforcement, two-stage code review, pressure-tested compliance) | Comprehensive (validated artifacts, lint/build/test, review phase) | None (practice, not a system) |
| Governance | Light | Moderate | Light | Light | Moderate (decisions ledger, reviewer lockout) | None | Light | Heavy (constraint-based, audit trails, policy-as-code) | None |
| Learning Curve | Medium | High | Low–Medium | Low | Medium–High | Low | Medium | High | Low |
| Ecosystem Maturity | Active successor v1.19.0; archived predecessor retained its metrics | v6.12.4; active modules and community | v1.2.3; GitHub-backed, past 1.0, composable extensions | v1.15.0 stable; prerelease channel exists | v1.1.0 stable; v2.0.0 prerelease channel active | Canonical guide is static; ralph-orchestrator v2.10.1 | v7.0.1; large audience and active releases | v3.2.2 stable; v3.3 prereleases and newer repo activity | Established practice; skills packaging now standardized |
| Cost | Free (API costs for AI tool) | Free (API costs for AI tool) | Free (API costs for AI tool) | Free (API costs for AI tool) | Free (API costs for Copilot sub) | Free (API costs — can be high for long loops) | Free (API costs for AI tool) | Free (Copilot subscription) | Free |
| Open Source | Yes (MIT) | Partial (open source, trademark on name) | Yes (GitHub official) | Yes (MIT) | Yes (MIT) | Yes (technique is open; plugin is official) | Yes (MIT) | Yes (MIT) | Yes (community-driven) |
3. GitHub star history¶
Frameworks with GitHub repositories — star growth over time:
GSD's chart starts with the active successor repository; the archived predecessor retains its separate history. Ralph and Context Engineering are not included because they have no single comparable repository.
4. Decision guide¶
For guidance by team size, project type, industry, and activity, see Choosing Your Approach. Before choosing a methodology, run the layer check: check whether the model and its native runtime already meet your needs.
| If you want... | Use | Why |
|---|---|---|
| The simplest possible setup | Ralph | A bash one-liner. No framework, no dependencies, no configuration. Define a prompt, run the loop. |
| Structured solo development with clear phases | GSD | Five-step Discuss → Plan → Execute → Verify → Ship workflow with fresh task context. |
| A full agile team simulation | BMAD | Specialized roles, modular workflows, scale-adaptive planning, and optional unattended iteration. |
| GitHub-backed spec-driven development | Spec Kit | GitHub's official SDD toolkit. Works with Copilot, Claude Code, Gemini CLI. Minimal footprint, strong institutional backing. |
| Parallel multi-agent orchestration with persistent memory | Squad | Named agents with charters, shared decisions, ceremonies, and Ralph-style work monitoring. |
| Enterprise governance and audit trails | HVE | Microsoft ISE's constraint-based RPI workflow, validated artifacts, and policy-as-code. |
| To improve an AI tool's context without adopting a framework | Context Engineering | Rules files (copilot-instructions.md, .cursorrules, CLAUDE.md) record project conventions. Start here before committing to a framework. |
| A disciplined individual workflow with TDD and reusable skills | Superpowers | Mandatory skills enforce systematic development across several tools. |
| Reusable skills without a mandatory methodology | Skills and Agent Frameworks | Choose a library, installer, and distribution model independently of your development process — see Choosing a Skills Approach. |
| To run AI agents overnight on mechanical tasks | Ralph | AFK mode with max-iteration and cost caps. |
| Lightweight spec-driven development for existing codebases | OpenSpec | Brownfield-first, change-centric workflow with delta specs and broad multi-tool support. |
| Tool-agnostic methodology that works with any AI CLI | Ralph or Context Engineering | Ralph works with any CLI that doesn't cap tool calls. Context engineering practices apply to every tool. |
5. Category summaries¶
Spec-driven development — GSD, Spec Kit, OpenSpec¶
GSD Core continues the archived original project with a five-step loop and a multi-runtime installer. Spec Kit is GitHub's project-level specification toolkit, now past 1.0 at v1.2.3 with composable extensions for integrations, hooks, and bundled bug-fixing and idea-assessment processes. OpenSpec is the v1.15.0 brownfield specialist, using change folders and delta specs, and now ships standalone binaries that don't require Node.js. OpenSpec writes vendor-neutral skills to .agents/skills/, but remains a spec-driven methodology rather than a skills library.
Skill-based development — Superpowers¶
Superpowers uses skills as mandatory workflow controls. The v7.x brainstorming skill examines the request before choosing how much planning it needs. A subagent reviews full designs as their future implementer. Version 7.0.0 also added an Antigravity Marketplace plugin. Independently selectable libraries such as mattpocock/skills and addyosmani/agent-skills do not prescribe that lifecycle.
Multi-agent orchestration — Squad, BMAD¶
BMAD uses specialized roles, structured phases, and modules. Its v6.12 line decides how much process a change needs after investigating it and adds evidence-backed review triage. Squad reached v1.1.0 stable in October; its v2.0.0 prereleases focus on GitHub Agentic Workflows (gh-aw) lifecycle integration. Both add coordination at the cost of simplicity.
Autonomous iteration — Ralph¶
Ralph runs an AI coding agent in a bash loop, using tests as backpressure and git commits as memory between iterations. Geoffrey Huntley created it and named it after Ralph Wiggum from The Simpsons ("keep going despite always making mistakes"). It has no built-in governance, agent roles, or structured phases. It supports unattended runs, but results are unpredictable — Huntley calls it "deterministically bad in a nondeterministic world". It works best on greenfield projects with clear completion criteria.
Enterprise AI-native SDLC — HVE¶
HVE adds constraint-based governance and the Research → Plan → Implement → Review workflow for enterprise teams. Its latest verified stable release is v3.2.2. Prereleases and newer repository contents are separate; neither establishes what shipped in the stable package. See the HVE guide for the dated inventory.
Cross-cutting: context engineering¶
Context engineering remains the foundational practice. Rules files are still fragmented by tool, but skills packaging has converged on the vendor-neutral Agent Skills specification. Basic skill content is portable; optional features and execution semantics still vary across runtimes.
Skills and agent frameworks¶
The skills market supports the methodologies in this comparison. Agent Skills defines the format; mattpocock/skills, addyosmani/agent-skills, and anthropics/skills supply content (see Skill Libraries). skills.sh and native plugin marketplaces provide discovery, installation, and updates (see Distribution and Governance); runtimes execute the skills.
A managed plugin can update automatically without local review. A CLI-vendored copy (npx skills@latest add ...) stays editable but updates only when requested. The examined distribution paths lacked signing, attestation, and lockfile-style pinning.
Some libraries also add routing. pstack/poteto-mode, distributed in the pstack/ directory in cursor/plugins, dispatches requests across 23 playbooks and the library's other skills (see Orchestrating Modes). Superpowers adds a mandatory development methodology. See Choosing a Skills Approach to compare these options.
6. Complexity vs. speed spectrum¶
OpenSpec sits between Superpowers and Spec Kit in this comparison: it adds change-level specifications but is lighter and more change-centric than Spec Kit's project-level phase gates.
Scroll horizontally to view the full diagram.
The spectrum moves from low-ceremony solo work toward enterprise coordination and governance. It is qualitative: neither startup speed nor predictability was measured on a shared benchmark. Use the comparison matrix for quality gates and predictability rather than reading position as a guarantee.
| Approach | Structure added | Typical setup | Tool scope |
|---|---|---|---|
| Context Engineering | Rules files | Minutes | Any tool |
| Ralph | Bash iteration loop | Minutes | Any AI CLI |
| GSD | Five-step workflow + execution waves where supported | Minutes | Multi-tool |
| Superpowers | Skills + TDD + subagents | Minutes | Multi-tool |
| OpenSpec | Change-centric specs + deltas | Minutes | Multi-tool |
| Spec Kit | Specs + plans + tasks | Minutes | Multi-tool |
| Squad | Multiple agents + persistent memory | Hours | Copilot |
| BMAD | Full agile simulation | Hours | Multi-tool |
| HVE | RPI + agents + governance | Hours–Days | Copilot |
GSD negotiates dispatch against documented host capabilities. Execution waves apply where parallel dispatch is available; on Copilot, GSD Core defaults execution to sequential inline mode.
7. Navigation — deep-dive documents¶
Each technique page covers its workflow, strengths, limitations, suitable uses, ecosystem, and comparisons.
Decision guide¶
- Choosing Your Approach — Which technique for which situation. By team size, project type, industry, and development activity.
Spec-driven development¶
- GSD (Get Shit Done) — Active successor workflow at
open-gsd/gsd-core; original repository archived. - Spec Kit — GitHub's official SDD toolkit at v1.2.3.
- OpenSpec — Change-centric SDD with delta specs and broad multi-tool support.
Multi-agent orchestration¶
- Squad — Coordinator-based multi-agent orchestration with persistent memory and casting.
- BMAD — AI-driven agile framework with specialized roles and modular workflows.
Autonomous iteration¶
- Ralph — Autonomous bash-loop methodology. Tests as backpressure, git as memory.
Skill-based development¶
- Superpowers — Mandatory skills methodology with TDD and review enforcement.
Enterprise AI-native SDLC¶
- HVE (Hypervelocity Engineering) — Microsoft ISE's RPI workflow and constraint-based governance.
Cross-cutting¶
- Context Engineering — The practice of structuring project context via rules files across an 8-layer model.
Skills and agent frameworks¶
- State of the Skills Market — Taxonomy, what's changing, and links into the rest of this category.
- Skill Libraries —
mattpocock/skills,addyosmani/agent-skills,anthropics/skills,vercel-labs/agent-skills, and watchlist collections. - Orchestrating Modes —
pstack/poteto-mode, canonical-source and port-drift caveats. - Superpowers — Mandatory skills methodology with TDD and review enforcement.
- Distribution and Governance — Specification, progressive disclosure, marketplaces vs. vendored installs, provenance, and rollout guidance.
- Choosing a Skills Approach — Decision guide across the whole skills layer.
8. Further reading¶
- Research Methodology — How this comparison is researched, evidence labels, and update policy.
9. Projects to consider next¶
These projects were relevant to the August 8, 2026 research pass and have not been re-verified for this update; they are not Tier 1 methodologies.
| Priority | Projects | Why to watch |
|---|---|---|
| Must consider | OpenHands, Open SWE, Goose, Cline | Active products, platforms, runtimes, or architectures. None exposed a portable methodology in this research pass. Open SWE had no releases or tags. |
| Maybe | Aider, OpenCode, Continue, Kilo Code, Pythagora/GPT Pilot, Roo Code | Runtimes or historically important coding-agent workflows. Include if future research finds distinct methodology beyond tool usage. Roo Code also needs verification because the observed repo was archived. |
| Watchlist | AutoGPT, SWE-agent | Relevant to autonomous-agent history, benchmarks, and code repair, but broader in scope or less recently verified than the techniques compared here. |
OpenHands is now past 1.0, Goose moved to the aaif-goose organization, and Cline ships separate core and desktop release trains. These status changes do not by themselves justify methodology pages.