Finding the Right AI coding Workflow

February 9, 2026

Introduction

My search for the right AI workflow started a few weeks ago when I discovered the Ralph Wiggum loop technique. Before that, I was using Claude the traditional way, sitting behind it, manually optimizing prompts, babysitting every command. But when I discovered Ralph, I saw the benefit of letting the AI work autonomously.

The idea of having Claude work for hours without me watching over it? That's what led me to dive deeper into this technique.

Before getting into my journey, let's talk about what the Ralph Wiggum loop actually is.

The Ralph Wiggum loop is a technique in AI-assisted development that gained traction in early 2026. It enables autonomous coding agents to iteratively work on tasks until completion, without human intervention.

Created by Geoffrey Huntley, it started as a simple while loop and evolved into plugins and patterns for tools like Claude Code. The promise? Run it overnight, wake up to working code.

Attractive, right? But here's what I didn't expect was the weeks of iteration it would take to find what actually works.

Phase 1: My First Implementation

My first attempt was heavily inspired by Matt Pocock's implementation. The idea: define features as json PRDs (Product Requirements Documents), let Claude implement stories one by one.

Here's what I built:

.ralph/
├── prompt.md           # Instructions for Claude
├── prompt-plan.md      # Planning mode prompt
├── ralph.sh            # Main loop (runs until complete)
├── ralph-once.sh       # Single iteration
├── ralph-plan.sh       # Feature planning
├── prd.json            # Story template
├── progress.txt        # Context between iterations
└── implementations/    # Feature folders (gitignored)

The workflow was simple:

  1. Define stories in prd.json with acceptance criteria with the help of Claude
  2. Run ralph.sh which loops through stories
  3. Claude picks the highest priority story where passes: false
  4. Implements it, runs checks, commits, updates progress file
  5. Outputs <promise>COMPLETE</promise> when all stories pass

The key insight: progress.txt gave Claude context between iterations. Each run, Claude would read what happened before and continue from there.

It worked. I could run it overnight and wake up to commits. But there was a problem.

The implementations folder was gitignored. My PRDs, progress files, all the context, none of it was committed. When I wanted to switch to my VPS to continue working remotely, I couldn't. All the context was stuck on my local machine.

I also didn't like having just a JSON file for the specs.

Phase 2: The Huntley Playbook

Time to go back to the source. I read Geoffrey Huntley's original Ralph playbook and rebuilt everything from scratch.

The new approach was better for me:

├── specs/                    # Requirements (committed!)
│   └── feature-name.md
├── IMPLEMENTATION_PLAN.md    # Task list (gitignored, disposable)
├── PROMPT_plan.md            # Planning mode
├── PROMPT_build.md           # Build mode
└── loop.sh                   # Orchestration

Key differences:

  • Specs are committed - requirements live in specs/*.md, synced everywhere
  • Plans are disposable - IMPLEMENTATION_PLAN.md can be regenerated anytime
  • Clear separation - planning mode analyzes specs, build mode implements tasks

The workflow became:

./loop.sh plan              # Generate plan from specs
./loop.sh build 10          # Run 10 build iterations

This solved the sync problem. Specs were committed, so I could switch machines and continue. The plan could be regenerated from specs.

With this implementation, I could have human-readable specifications I could work on directly.

But I wasn't satisfied. I kept tweaking.

The Tweaking Phase

What followed was weeks of iteration. Most of these changes happened in the prompt files (PROMPT_plan.md and PROMPT_build.md) that instruct Claude how to work.

Small improvements that felt necessary at the time:

  • Session Context: Added a section to IMPLEMENTATION_PLAN.md so Claude would know what happened in previous sessions. The plan prompt now required generating this context.
  • Verify commands: Updated the plan prompt so each task got a Verify: command with pass/fail checks. The build prompt would run these before marking tasks complete.
  • Done: [hash]: Modified prompts to link completed tasks to their commit hashes for traceability.
  • Task status conventions: Defined [ ] pending, [~] in progress, [x] complete, [!] blocked in both prompts.
  • Simplified prompts: Removed fictional specs like "use 500 parallel Sonnet subagents" (spoiler: Claude ignores these numbers entirely).
  • Spec-interview command: Added a Claude slash command to build specifications through a conversation with Claude. Instead of writing specs manually, I could have a discussion and let Claude generate the structured spec from our conversation.
  • App-interview command: Added a new Claude slash command for application-level planning before diving into feature specs.
  • Renamed to "eni": Moved everything from .ralph/ to .eni/ and made it my own.

Each tweak felt like progress. But I was still missing something. I wanted deeper integration with git and github. I was already sometimes writing some specs on GitHub when I wasn't behind the computer. I was also tracking issues there. Why not go all in?

Phase 3: The GitHub Issues Trap

The idea was elegant: ditch all the markdown files. Use GitHub issues as the source of truth. Track progress directly in commit messages.

I was already using GitHub for some feature specs and issue tracking. Why maintain a separate IMPLEMENTATION_PLAN.md when GitHub has a built-in issue tracker?

So I tried it. The process was the following:

  1. Create the detailed spec with the slash command and instead of writing it in the specs folder, create a GitHub issue with a spec tag
  2. Run the plan prompt which splits the spec into tasks - each task is a GitHub issue with a task tag and a tag for the feature name like "feature-x"
  3. The build prompt fetches tasks of the feature to build by filtering on the tag. After each task completes, it writes the progress in the commit message. The last 10 commits are piped into Claude at the start of each build session to give it context.

The result? Micro-ticket hell.

After breaking down a feature, I'd end up with 15-20 tiny issues. "Add email field." "Add validation." "Add error message." Each one cluttering the issues board.

The GitHub issues page became incomprehensible. Legitimate bugs and feature requests drowned in a sea of implementation details. I couldn't tell what was a real issue versus what was just Claude's todo list.

Also, it wasn't efficient for the agent to fetch issues each time.

The approach didn't scale. I needed something that lived in the repo but didn't pollute GitHub's UI.

Phase 4: Beads

Then I discovered Beads by Steve Yegge.

Beads is issue tracking that lives in your repo. No web UI. Everything stored in .beads/issues.jsonl and crucially, it's committed to git.

bd create "Add user authentication"    # Create issue
bd ready                               # See what's unblocked
bd update <id> --status in_progress    # Claim work
bd close <id>                          # Done
bd sync                                # Sync with remote

Exactly what I needed:

  • Git-native: issues sync like code
  • AI-friendly: CLI-first design works perfectly with Claude
  • No UI pollution: GitHub issues stay clean for real bugs
  • Dependencies: proper blocking with bd dep add
  • Committed: I can switch machines and everything follows

The workflow simplified to:

  1. Create spec via interview
  2. Run ./loop.sh plan <spec>: creates beads
  3. Run ./loop.sh build: implements tasks
  4. Review PR

Something that just works.

Beads also has some powerful features that make it even more useful: epics for grouping related issues, priority levels for ordering work, and proper task blocking so Claude knows what's ready to work on and what's waiting on dependencies.

The Real Lesson

Looking back, I spent weeks building workflows instead of building products.

Every tweak felt justified. Session context? Obviously needed. Verify commands? Essential for reliability. GitHub issues integration? Perfect for visibility.

But here's the truth: I could have shipped features with a much simpler setup. The marginal gains from each optimization didn't justify the time spent building them.

I was so focused on optimizing how I work with AI that I forgot to actually work with AI.

Why I Built This Into eniem.dev

This is exactly why eniem.dev includes "eni", my battle-tested AI workflow, pre-configured and ready to go.

The boilerplate ships with:

  • Authentication, payments, file uploads already done
  • Beads integration for issue tracking
  • Functional spec interviews built in
  • The whole planning → building loop ready to run

You don't need to spend weeks iterating on workflows. I already did that. Take what works and focus on building your product.

Stop tweaking. Start shipping.