If you’re using AI coding CLIs like Claude Code, Copilot CLI, OpenCode, or Codex, this article is for you.
Most developers use these tools in an interactive way. You give a task, watch the AI work, correct it when needed, and move forward. This is the familiar human-in-the-loop (HITL) style of AI-assisted coding.
But there’s a more powerful approach emerging — one that lets your AI coding agent work autonomously, without constant supervision.
This approach is often called “Ralph”.
Ralph runs your AI coding CLI inside a loop. You define what needs to be done. Ralph decides how to do it — and keeps going until the job is finished.
This is long-running, autonomous, AFK (away-from-keyboard) coding.
This article explains how it works, why it works, and how to use it safely.
This is not a quickstart. If you want setup instructions, start elsewhere. This is about thinking correctly about autonomous AI coding.
The Core Idea: Ralph Is Just a Loop
AI coding has gone through a few phases:
- Vibe coding
Letting the AI write code with minimal checking. Fast, but quality often suffers. - Planning-first coding
Asking the AI to plan before coding. Better structure, but limited by context size. - Multi-phase prompting
Breaking work into phases and writing a new prompt for each phase. Scales better, but requires constant human input.
Ralph simplifies everything.
Instead of writing a new prompt for every phase, you run the same prompt repeatedly in a loop.
Each loop iteration:
- Reads what still needs to be done
- Reads what’s already been done
- Chooses the next task
- Explores the codebase
- Implements one feature
- Runs feedback checks (types, tests, lint)
- Commits the result
The key shift is this:
The agent decides what to work on next — not you.
You define the end state. Ralph figures out the path.
Two Ways to Run Ralph: HITL and AFK
There are two practical modes:
1. HITL (Human-in-the-Loop)
- Run one iteration at a time
- Watch what the agent does
- Intervene if needed
This feels like pair programming with an AI.
It’s the best way to:
- Learn how Ralph behaves
- Refine your prompt
- Build trust in the system
2. AFK (Away-From-Keyboard)
- Run Ralph in a loop for a fixed number of iterations
- Walk away
- Review the results later
AFK mode is where real leverage comes from — but only after your prompt and safeguards are solid.
Always cap iterations.
Infinite loops with probabilistic systems are dangerous.
A good progression:
- Start with HITL
- Refine the prompt
- Go AFK only when confident
- Review commits afterward
Define Scope Like a Product, Not a Task List
Ralph works best when you define what “done” means, not how to do it.
Think in terms of requirements, not steps.
Instead of:
- “Add API”
- “Then update UI”
- “Then write tests”
Describe the end state.
A powerful approach is to use structured PRD items, for example:
{ "category": "functional", "description": "New chat button creates a fresh conversation", "steps": [ "Click the New Chat button", "Verify a new conversation is created", "Confirm welcome state is visible" ], "passes": false}
When the requirement is satisfied, Ralph marks passes: true.
Your PRD becomes:
- Scope definition
- Progress tracker
- Stop condition
Why This Matters
If scope is vague, Ralph may:
- Loop forever finding “improvements”
- Declare completion too early
- Skip edge cases it decides are unimportant
Be explicit about:
- What files must be included
- What counts as complete
- What edge cases matter
You can even adjust scope mid-run by changing the PRD.
Track Progress Between Iterations
AI agents forget everything between runs.
To solve this, Ralph should maintain a simple progress file (for example, progress.txt) that is committed to the repo.
This file tells the next iteration:
- What was completed
- What decisions were made
- What files changed
- What blockers exist
This avoids expensive re-exploration of the entire codebase and dramatically improves efficiency.
Once the sprint is done, delete the progress file. It’s session-specific, not permanent documentation.
Feedback Loops Are Non-Negotiable
Ralph’s code quality depends entirely on feedback loops.
Examples:
- Type checking
- Unit tests
- Linting
- UI tests
- Pre-commit hooks
The rule is simple:
If feedback fails, Ralph does not commit.
Great engineers don’t trust their own code — they verify it.
The same discipline must apply to AI agents.
This isn’t an AI trick.
It’s just good software engineering, enforced consistently.
Small Steps Beat Big Changes
Large changes delay feedback. Delayed feedback kills quality.
For Ralph, this is even more important because:
- Context windows are limited
- Long contexts degrade output quality (“context rot”)
Trade-off:
- Very small steps → higher quality, slower progress
- Very large steps → faster progress, more risk
For AFK runs, bias toward smaller PRD items.
For HITL runs, you can afford slightly larger chunks.
Quality compounds. Speed without quality does not.
Tackle Risky Work First
Left alone, Ralph will often choose:
- The first task
- The easiest task
That’s human behavior too — but experienced engineers know better.
High-priority work:
- Architecture decisions
- Integration points
- Unknown or risky areas
Low-priority work:
- UI polish
- Cleanup
- Easy wins
Use HITL mode for risky architectural work.
Use AFK mode once the foundation is solid.
Fail fast on hard problems. Save easy wins for later.
Be Explicit About Code Quality Expectations
Ralph doesn’t know whether your repo is:
- A prototype
- Production software
- A public library
You must tell it.
Example guidance:
- “This is production code. Maintainability matters.”
- “This is a prototype. Speed matters more than polish.”
- “This is a public API. Backward compatibility matters.”
Also remember:
The codebase itself is a stronger signal than your instructions.
If your repo is messy, Ralph will amplify that mess — quickly.
Autonomous agents accelerate software entropy unless you actively fight it.
Use Docker Sandboxes for AFK Runs
AFK Ralph can run commands and modify files.
That’s powerful — and risky.
Running Ralph inside a Docker sandbox:
- Isolates your system
- Prevents access to sensitive files
- Limits damage from runaway behavior
For HITL runs, sandboxes are optional.
For AFK or overnight runs, they’re essential.
Cost: You Do Have to Pay
Autonomous AI coding isn’t free.
But even HITL Ralph provides value:
- Same prompt reused
- Less cognitive overhead
- Better flow
AFK Ralph costs more, but the leverage can be massive.
Right now, we’re in a unique phase:
- AI capabilities are extremely high
- Market compensation hasn’t fully adjusted yet
If you use these tools well, the ROI can be exceptional.
Make Ralph Your Own
Ralph is just a loop — which makes it infinitely flexible.
You can:
- Pull tasks from GitHub Issues or Linear
- Open PRs instead of committing directly
- Run specialized loops
Examples:
- Test coverage loop
- Linting cleanup loop
- Code duplication loop
- Entropy cleanup loop
Any task that looks like:
“Inspect repo → improve something → report progress”
…fits the Ralph model.
Only the prompt changes. The loop stays the same.
Final Thought
Ralph isn’t magic.
It’s discipline, automation, and feedback — applied relentlessly.
Used carelessly, it accelerates chaos.
Used well, it gives you focus, leverage, and time back.
I’m looking forward to seeing how you build your own versions of Ralph — shipping code while you’re away from the keyboard.