I create modern web applications and custom digital tools to help businesses grow through technological innovation. My passion is combining computer science and economics to generate real value.
My passion for computer science was born at the Technical Commercial Institute of Maglie, where I discovered the power of programming and the fascination of creating digital solutions. From the start, I understood that computer science was not just code, but an extraordinary tool for turning ideas into reality.
During my studies in Business Information Systems, I began to interweave computer science and economics, understanding how technology can be the engine of growth for any business. This vision accompanied me to the University of Bari, where I obtained my degree in Computer Science, deepening my technical skills and passion for software development.
Today I put this experience at the service of businesses, professionals and startups, creating tailor-made digital solutions that automate processes, optimize resources and open new business opportunities. Because true innovation begins when technology meets the real needs of people.
My Skills
Data Analysis & Predictive Models
I transform data into strategic insights with in-depth analysis and predictive models for informed decisions
Process Automation
I create custom tools that automate repetitive operations and free up time for value-added activities
Custom Systems
I develop tailor-made software systems, from platform integrations to customized dashboards
Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.
Democratizzare la Tecnologia
La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.
Unire Informatica ed Economia
Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.
Creare Soluzioni su Misura
Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.
Trasforma la Tua Attività con la Tecnologia
Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.
Bari, Puglia, Italy · Hybrid
Analysis and development of computer systems through the use of Java and Quarkus in Health and Public Sector. Continuous training on modern technologies for creating customized and efficient software solutions and on agents.
💼
06/2022 - 12/2024
Software analyst and Back End Developer Associate Consultant
Links Management and Technology SpA
Experience analyzing as-is software systems and ETL flows using PowerCenter. Completed Spring Boot training for developing modern and scalable backend applications. Backend developer specialized in Spring Boot, with experience in database design, analysis, development and testing of assigned tasks.
💼
02/2021 - 10/2021
Software programmer
Adesso.it (prima era WebScience srl)
Experience in AS-IS and TO-BE analysis, SEO evolutions and website evolutions to improve user performance and engagement.
🎓
2018 - 2025
Degree in Computer Science
University of Bari Aldo Moro
Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.
📚
2013 - 2018
Diploma - Corporate Information Systems
Technical Commercial Institute of Maglie
Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.
Contattami
Hai un progetto in mente? Parliamone! Compila il form qui sotto e ti risponderò al più presto.
* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.
Ralph Wiggum: Autonomous Development with AI Loops
Imagine being able to describe a complex software development goal, press enter,
and come back hours later to find the work completed: code written, tests passing,
documentation updated. This is not science fiction, but the reality made possible by the
Ralph Wiggum technique, an approach that transforms Claude Code from an
interactive assistant into an iterative autonomous developer.
The name "Ralph Wiggum" comes from the Simpsons character known for his naive but
surprisingly effective persistence. The underlying philosophy is analogous: tirelessly
iterate on a problem, use failures as feedback to improve, and persist until the goal
is achieved. In this article we will explore this revolutionary technique in depth,
from its fundamental principles to real-world use cases that have produced
extraordinary results.
What You'll Learn
Understand the philosophy and principles of the Ralph Wiggum autonomous loop
Implement the basic loop and the advanced version with safety guards
Structure effective PROMPT.md files for autonomous loops
Apply TDD patterns within iterative loops
Manage costs, risks, and monitoring during long-running executions
Analyze real case studies: hackathons, contracts, and creative projects
Learn the slash commands dedicated to loop management
Determine when to use and when to avoid the Ralph Wiggum pattern
Series Overview
#
Article
Focus
1
Claude as Technical Partner
Setup and first steps
2
Context and Project Setup
CLAUDE.md and configuration
3
Ideation and Requirements
MVP and user personas
4
Backend and Frontend Architecture
Spring Boot and Angular
5
Code Structure
Organization and conventions
6
Advanced Prompt Engineering
Advanced techniques
7
Testing and Quality
Strategies and test generation
8
Professional Documentation
README, API, ADR
9
Deploy and DevOps
Docker, CI/CD, monitoring
10
Evolution and Maintenance
Refactoring and scalability
11
Real Project Integration
Claude Code in production
12
Claude Code CLI
Command line mastery
13
Agent Skills
Extending Claude Code
14
Specialized Subagents
Orchestrating specialized agents
15
Hooks and Automation
Event-driven automation
16
Ralph Wiggum Method (you are here)
Iterative autonomous development
17
BMAD Method
AI-driven agile methodology
18
Multi-Agent Orchestration
Coordinating agent teams
19
Claude Cowork
Working together with Claude
20
Security and Privacy
Protecting the workflow
21
Monitoring and Productivity
Metrics and performance
1. The Philosophy of the Autonomous Loop
The Ralph Wiggum technique is based on four fundamental principles that define
its approach and ensure its effectiveness. Understanding these principles is essential
to applying the pattern correctly and achieving consistent results.
Principle 1: Iteration Over Perfection
Instead of seeking the perfect solution on the first attempt, the autonomous loop embraces
an incremental approach. Each iteration produces a partial result that is evaluated,
corrected, and improved in the next cycle. This approach is particularly effective
because language models excel at refining existing solutions rather than producing
perfect output from scratch.
The concept is analogous to the agile principle of "fail fast, learn faster": each
loop cycle produces useful information for the next cycle, creating a convergence
process toward the desired solution. The key is to define clear and measurable
success criteria that allow the loop to autonomously determine when the result
is satisfactory.
Principle 2: Failures as Data
In a Ralph Wiggum loop, a failed test or compilation error is not a problem:
it is structured feedback. Every failure contains valuable information
about what needs to be fixed, and Claude Code is particularly skilled at analyzing
error messages and transforming them into corrective actions.
This principle explains why the TDD (Test-Driven Development) pattern pairs
perfectly with the autonomous loop: tests define the success contract and
error messages guide the iterative correction process. A failing test is a
precise signal that indicates exactly what is missing or what is wrong.
Principle 3: Operator Competence Matters
Ralph Wiggum is not a magic button that produces software from nothing. The quality
of the result depends directly on the quality of the instructions provided. A
well-structured PROMPT.md file, with clear objectives, explicit constraints,
and measurable success criteria, produces enormously better results compared to
vague or incomplete instructions.
The human operator remains essential for three aspects: problem definition,
constraint structuring, and final result validation. The autonomous loop
automates execution, but strategic direction remains human.
Principle 4: Persistence Wins
Many software development problems that seem complex are actually solvable
through systematic attempts. A difficult bug that would require hours of manual
debugging can be resolved in a few autonomous loop cycles, because Claude Code can
rapidly explore many different correction strategies, analyze complex stack traces,
and apply fixes systematically.
The 4 Principles Compared
Principle
Traditional Approach
Ralph Wiggum Approach
Iteration
Detailed plan, single execution
Clear objective, multiple iterations
Failures
Errors to avoid, manual debugging
Valuable feedback, self-correction
Competence
Developer writes code
Operator defines objectives and constraints
Persistence
Limited time per attempt
Continuous loop until success
2. Basic Loop Implementation
In its simplest form, the Ralph Wiggum loop is an infinite cycle that continuously
feeds Claude Code with a predefined prompt. The concept is disarmingly simple:
as long as the task is not completed, keep running Claude Code with the same
instructions.
Basic Loop - The Simplest Form
#!/bin/bash
# ralph-loop-basic.sh
# The simplest possible loop
while true; do
cat PROMPT.md | claude --print --dangerously-skip-permissions
echo "--- Iteration completed, restarting ---"
sleep 2
done
This script does three things: reads the contents of the PROMPT.md file,
passes it to Claude Code as input via pipe, waits for completion, and restarts.
The --print flag makes Claude produce formatted output, while
--dangerously-skip-permissions avoids interactive confirmation prompts
that would block the loop.
Warning: Security of the --dangerously-skip-permissions Flag
The --dangerously-skip-permissions flag grants Claude Code permission
to execute any operation without asking for confirmation. This includes writing
files, executing shell commands, and modifying configurations. Use this
flag only in isolated environments (Docker containers, dedicated VMs, test
repositories) and never on production systems or repositories with sensitive data.
PROMPT.md File Structure
The PROMPT.md file is the heart of the autonomous loop. It contains the
instructions that Claude Code receives at each iteration and defines its behavior. An
effective PROMPT.md must be structured, specific, and contain clear completion criteria.
PROMPT.md - Effective Template
# Project Objective
You are developing a REST API for managing a booking system.
The project uses Node.js with Express and TypeScript, and PostgreSQL as the database.
## Current State
Read the `STATUS.md` file to understand what has been completed and what is missing.
After each iteration, update STATUS.md with progress.
## Functional Requirements
1. Full CRUD for entities: User, Booking, Room
2. JWT authentication with refresh token
3. Input validation with Zod
4. Pagination and filtering on all lists
5. Rate limiting on public APIs
## Technical Constraints
- TypeScript strict mode
- Unit tests for each service (coverage > 80%)
- Integration tests for each endpoint
- No unnecessary dependencies
- OpenAPI/Swagger documentation for each endpoint
- Centralized error handling with consistent error codes
## Completion Criteria
The task is COMPLETE when ALL of the following criteria are satisfied:
1. `npm run build` compiles without errors
2. `npm test` passes all tests (0 failures)
3. `npm run lint` produces no warnings or errors
4. Each endpoint has at least 3 integration tests
5. The STATUS.md file indicates "COMPLETED" for all modules
## Workflow Per Iteration
1. Read STATUS.md to understand where you left off
2. Identify the next incomplete task
3. Implement the necessary code
4. Write the corresponding tests
5. Run `npm test` and fix any failures
6. Update STATUS.md with progress
7. If all criteria are satisfied, write "DONE" in STATUS.md
3. Advanced Implementation with Safety Guards
The basic loop works, but in a professional context you need safety mechanisms
to avoid infinite executions, control costs, and ensure the loop behaves
predictably. The advanced implementation adds guard rails that make the
process robust and manageable.
#123;MAX_ITERATIONS:-50} # Maximum number of iterations
MAX_COST=#123;MAX_COST:-"10.00"} # Maximum cost in dollars
SLEEP_BETWEEN=#123;SLEEP_BETWEEN:-5} # Seconds between iterations
PROMPT_FILE=#123;PROMPT_FILE:-"PROMPT.md"} # Instructions file
STATUS_FILE=#123;STATUS_FILE:-"STATUS.md"} # Status file
LOG_DIR=#123;LOG_DIR:-".ralph/logs"} # Log directory
# ================================
# INITIALIZATION
# ================================
ITERATION=0
START_TIME=$(date +%s)
TOTAL_COST=0
mkdir -p "$LOG_DIR"
echo "=== Ralph Wiggum Loop ===" | tee "$LOG_DIR/main.log"
echo "Max iterations: $MAX_ITERATIONS" | tee -a "$LOG_DIR/main.log"
echo "Max cost: \$MAX_COST" | tee -a "$LOG_DIR/main.log"
echo "Start: $(date)" | tee -a "$LOG_DIR/main.log"
# ================================
# GUARD FUNCTIONS
# ================================
check_completion() {
# Check if the STATUS file contains the completion marker
if [ -f "$STATUS_FILE" ]; then
if grep -qi "DONE\|COMPLETATO\|FINISHED" "$STATUS_FILE"; then
return 0 # Completed
fi
fi
return 1 # Not completed
}
check_cost_limit() {
# Verify that the cost does not exceed the limit
if command -v bc &> /dev/null; then
OVER=$(echo "$TOTAL_COST >= $MAX_COST" | bc -l)
if [ "$OVER" = "1" ]; then
return 0 # Limit exceeded
fi
fi
return 1 # Under the limit
}
check_stale_progress() {
# Check if there is progress between iterations
local current_hash=$(md5sum "$STATUS_FILE" 2>/dev/null | cut -d' ' -f1)
local prev_hash=$(cat "$LOG_DIR/.last_hash" 2>/dev/null || echo "")
echo "$current_hash" > "$LOG_DIR/.last_hash"
if [ "$current_hash" = "$prev_hash" ] && [ -n "$prev_hash" ]; then
STALE_COUNT=$((#123;STALE_COUNT:-0} + 1))
if [ "$STALE_COUNT" -ge 3 ]; then
return 0 # Stuck for 3 iterations
fi
else
STALE_COUNT=0
fi
return 1 # Progress ongoing
}
# ================================
# MAIN LOOP
# ================================
while [ "$ITERATION" -lt "$MAX_ITERATIONS" ]; do
ITERATION=$((ITERATION + 1))
ITER_START=$(date +%s)
echo "" | tee -a "$LOG_DIR/main.log"
echo "--- Iteration $ITERATION/$MAX_ITERATIONS ---" | tee -a "$LOG_DIR/main.log"
echo "Timestamp: $(date)" | tee -a "$LOG_DIR/main.log"
# Guard 1: Completion check
if check_completion; then
echo "SUCCESS: Task completed at iteration $ITERATION!" | tee -a "$LOG_DIR/main.log"
break
fi
# Guard 2: Cost check
if check_cost_limit; then
echo "STOP: Cost limit reached (\$TOTAL_COST >= \$MAX_COST)" | tee -a "$LOG_DIR/main.log"
break
fi
# Guard 3: Stagnation check
if check_stale_progress; then
echo "WARNING: No progress for 3 consecutive iterations" | tee -a "$LOG_DIR/main.log"
echo "Attempting approach reset..." | tee -a "$LOG_DIR/main.log"
# Inject strategy change instruction
echo -e "\n\nWARNING: The last 3 iterations produced no progress. Change your approach radically." >> "$PROMPT_FILE.tmp"
cat "$PROMPT_FILE" >> "$PROMPT_FILE.tmp"
PROMPT_TO_USE="$PROMPT_FILE.tmp"
else
PROMPT_TO_USE="$PROMPT_FILE"
fi
# Execute Claude Code
cat "$PROMPT_TO_USE" | claude --print --dangerously-skip-permissions \
2>&1 | tee "$LOG_DIR/iteration-$ITERATION.log"
# Cleanup temporary file
rm -f "$PROMPT_FILE.tmp"
# Calculate iteration time
ITER_END=$(date +%s)
ITER_DURATION=$((ITER_END - ITER_START))
echo "Iteration duration: #123;ITER_DURATION}s" | tee -a "$LOG_DIR/main.log"
# Pause between iterations
sleep "$SLEEP_BETWEEN"
done
# ================================
# FINAL REPORT
# ================================
END_TIME=$(date +%s)
TOTAL_DURATION=$((END_TIME - START_TIME))
echo "" | tee -a "$LOG_DIR/main.log"
echo "=== Final Report ===" | tee -a "$LOG_DIR/main.log"
echo "Iterations completed: $ITERATION" | tee -a "$LOG_DIR/main.log"
echo "Total duration: $((TOTAL_DURATION / 60))m $((TOTAL_DURATION % 60))s" | tee -a "$LOG_DIR/main.log"
echo "End: $(date)" | tee -a "$LOG_DIR/main.log"
# Completion notification
if command -v notify-send &> /dev/null; then
notify-send "Ralph Wiggum Loop" "Completed after $ITERATION iterations"
fi
The --max-iterations Flag
In the most recent versions of Claude Code, the --max-iterations
flag is supported natively, simplifying iteration limit management directly
from the command line without the need for shell wrappers:
Using the native --max-iterations flag
# Loop with a limit of 20 iterations
cat PROMPT.md | claude --print --dangerously-skip-permissions --max-iterations 20
# Combination with other flags
cat PROMPT.md | claude \
--print \
--dangerously-skip-permissions \
--max-iterations 30 \
--model claude-sonnet-4-20250514
4. TDD Patterns in Autonomous Loops
Test-Driven Development (TDD) is the natural companion of the Ralph Wiggum loop.
Tests define the success contract programmatically: when all tests pass, the loop
has reached its goal. This approach eliminates ambiguity from completion criteria
and makes the process completely verifiable and reproducible.
The TDD Workflow in the Loop
The TDD pattern adapted for the autonomous loop follows a precise sequence:
Test definition (human): The operator writes tests that define the expected behavior
First iteration: Claude reads the tests, understands the requirements, and produces the first implementation
Test execution: Tests are run automatically, producing structured feedback
Subsequent iterations: Claude analyzes failures and refines the implementation
Convergence: The process converges when all tests pass
PROMPT.md with TDD Workflow
# Task: Implement the Authentication Module
## Context
You are implementing the authentication module for an Express/TypeScript API.
The tests are already written in `src/auth/__tests__/auth.test.ts`.
## MANDATORY Workflow for each iteration
1. Run `npm test -- --testPathPattern=auth` to see the test status
2. Analyze failed tests: read the error message and the test code
3. Implement or fix the code to pass the NEXT failing test
4. Run the tests again to verify the fix
5. If you introduced regressions, fix those first
6. Update STATUS.md with the count: "Tests passed: X/Y"
## Completion Criteria
The module is COMPLETE when `npm test -- --testPathPattern=auth` produces:
- 0 failed tests
- 0 compilation errors
- Coverage > 80%
When ALL tests pass, write "DONE" in STATUS.md.
## Constraints
- DO NOT modify the test files
- DO NOT use `any` in TypeScript code
- DO NOT ignore errors with empty try/catch
- Every public function must have JSDoc
auth.test.ts - Tests that drive the loop
// src/auth/__tests__/auth.test.ts
import { AuthService } from '../auth.service';
import { UserRepository } from '../../users/user.repository';
import { JwtService } from '../jwt.service';
describe('AuthService', () => {
let authService: AuthService;
let userRepo: jest.Mocked<UserRepository>;
let jwtService: jest.Mocked<JwtService>;
beforeEach(() => {
userRepo = { findByEmail: jest.fn(), create: jest.fn() } as any;
jwtService = { sign: jest.fn(), verify: jest.fn() } as any;
authService = new AuthService(userRepo, jwtService);
});
describe('register', () => {
it('should create a new user with hashed password', async () => {
const result = await authService.register({
email: 'test@example.com',
password: 'StrongP@ss123'
});
expect(result.user.email).toBe('test@example.com');
expect(result.user.password).not.toBe('StrongP@ss123');
});
it('should reject weak passwords', async () => {
await expect(authService.register({
email: 'test@example.com',
password: '123'
})).rejects.toThrow('Password too weak');
});
it('should reject duplicate emails', async () => {
userRepo.findByEmail.mockResolvedValue({ id: '1', email: 'test@example.com' } as any);
await expect(authService.register({
email: 'test@example.com',
password: 'StrongP@ss123'
})).rejects.toThrow('Email already exists');
});
});
describe('login', () => {
it('should return JWT tokens on valid credentials', async () => {
jwtService.sign.mockReturnValue('mock.jwt.token');
userRepo.findByEmail.mockResolvedValue({
id: '1',
email: 'test@example.com',
password: '$2b$10$hashedpassword'
} as any);
const result = await authService.login({
email: 'test@example.com',
password: 'StrongP@ss123'
});
expect(result.accessToken).toBeDefined();
expect(result.refreshToken).toBeDefined();
});
});
});
Progress Indicator in the TDD Loop
A fundamental aspect of the TDD pattern in the autonomous loop is progress tracking.
Each iteration produces a measurable delta: the number of passing tests. This allows
monitoring convergence and identifying stall situations.
tdd-progress-tracker.sh - TDD Progress Monitoring
#!/bin/bash
# Runs tests and tracks progress between iterations
RESULTS=$(npm test -- --json 2>/dev/null || true)
PASSED=$(echo "$RESULTS" | jq '.numPassedTests // 0')
FAILED=$(echo "$RESULTS" | jq '.numFailedTests // 0')
TOTAL=$((PASSED + FAILED))
TIMESTAMP=$(date +%s)
# Save to progress file
echo "{\"timestamp\": $TIMESTAMP, \"passed\": $PASSED, \"failed\": $FAILED, \"total\": $TOTAL}" \
>> .ralph/progress.jsonl
# Calculate delta from previous iteration
PREV_PASSED=$(tail -2 .ralph/progress.jsonl | head -1 | jq '.passed // 0' 2>/dev/null || echo 0)
DELTA=$((PASSED - PREV_PASSED))
echo "Tests: $PASSED/$TOTAL passed (delta: $DELTA)"
# Alert if no progress
if [ "$DELTA" -eq 0 ] && [ "$FAILED" -gt 0 ]; then
echo "WARNING: No new tests passed in this iteration"
fi
5. Defining Effective Completion Criteria
Completion criteria are the contract between the human operator and the autonomous loop.
Poorly defined criteria lead to infinite loops, incomplete results, or resource waste.
Defining effective criteria is a fundamental skill for using the Ralph Wiggum
pattern successfully.
Characteristics of Good Completion Criteria
Characteristic
Good Criterion
Bad Criterion
Measurability
"npm test passes with 0 failures"
"The code works well"
Automatic verifiability
"npm run build exits with code 0"
"The architecture is elegant"
Specificity
"Coverage > 80% on all services"
"Good test coverage"
Completeness
"All 5 endpoints implemented"
"Implement the APIs"
Unambiguity
"Zero ESLint warnings"
"Clean code"
Pattern: Incremental Objectives
For complex tasks, it is effective to structure objectives incrementally,
defining intermediate milestones. This approach helps Claude Code focus on
one sub-objective at a time and provides natural checkpoint points.
STATUS.md - Incremental Tracking
# Project Status
## Milestone 1: Infrastructure Setup [COMPLETED]
- [x] TypeScript project initialization
- [x] ESLint and Prettier configuration
- [x] Jest testing setup
- [x] PostgreSQL database configuration
## Milestone 2: Data Model [IN PROGRESS]
- [x] User schema with validation
- [x] Booking schema with relationships
- [ ] Room schema with availability
- [ ] Migration scripts
## Milestone 3: API Endpoints [TODO]
- [ ] POST /api/users (registration)
- [ ] POST /api/auth/login (authentication)
- [ ] GET /api/rooms (list available)
- [ ] POST /api/bookings (create booking)
- [ ] GET /api/bookings/:id (detail)
- [ ] DELETE /api/bookings/:id (cancellation)
## Milestone 4: Testing and Quality [TODO]
- [ ] Unit tests for all services
- [ ] Integration tests for all endpoints
- [ ] Coverage > 80%
- [ ] Zero lint warnings
## Status: IN PROGRESS - Milestone 2
6. Real Case Studies
The Ralph Wiggum technique has produced remarkable results in real-world contexts.
These case studies demonstrate both the potential and the limitations of the approach,
providing practical lessons applicable to your own projects.
Case Study 1: Y Combinator Hackathon - 6 Repositories in One Night
During a Y Combinator hackathon, a team used the Ralph Wiggum technique to
generate 6 complete repositories overnight. The setup involved
6 parallel Claude Code instances, each with a specific PROMPT.md for a different
microservice of the application.
The team spent the evening defining architecture, interfaces between services, and
integration tests. Then they started the loops and let Claude Code work through
the night. In the morning, 5 of the 6 repositories were functional with passing
tests. The sixth required manual intervention to resolve a database configuration
issue that the loop had not been able to overcome.
Lessons from the Hackathon
Preparation is key: The hours spent defining clear interfaces between services allowed the loops to work independently
Integration tests are the glue: Each service had tests that verified compatibility with the interfaces of others
Not everything works on the first try: 1 out of 6 repositories required manual intervention, but the overall time savings were enormous
Monitoring is necessary: The team periodically checked the logs to identify stuck loops
Case Study 2: $50,000 Contract with $297 in API Costs
A freelance developer used the Ralph Wiggum loop to complete a software development
contract worth $50,000 with Claude API costs of only
$297. The project consisted of migrating a legacy PHP application
to a modern Node.js/TypeScript architecture.
The strategy involved splitting the project into independent modules, each with
its own tests derived from the legacy application behavior. The autonomous loop
processed each module sequentially, using the output of the previous module
as context for the next one.
The result: a project that would have required 2-3 months of full-time work was
completed in 2 weeks, with the developer intervening mainly for code review,
business requirements validation, and manual testing of user flows.
Cost Breakdown
Item
Detail
Modules migrated
12 modules, ~40K lines of PHP code converted
Total iterations
~340 iterations distributed over 2 weeks
Claude API cost
$297 (Sonnet model for the most part)
Developer time
~40 hours (review, testing, refinement)
Contract value
$50,000
Effective ROI
167x on API cost
Case Study 3: CURSED - A Programming Language in 3 Months
The CURSED project is an esoteric programming language created
entirely through Ralph Wiggum autonomous loops distributed over 3 months.
The creator defined the language specification, wrote the tests for the parser,
interpreter, and compiler, and let the autonomous loop implement each component
iteratively.
This case study is particularly interesting because it demonstrates the pattern's
ability to handle highly complex and interconnected projects.
Creating a programming language requires coherent management of grammar, parsing,
semantic analysis, code generation, and runtime, with circular dependencies and
strict correctness constraints.
The project went through several phases: initially the loop produced partial
implementations that failed on the more complex tests, but with each iteration
the quality improved. After about 200 iterations the parser was complete, after
500 the basic interpreter worked, and after over 1000 iterations distributed
across 3 months the language was mature enough to run non-trivial programs.
7. Commands for Loop Management
The community has developed dedicated slash commands to simplify the management
of Ralph Wiggum loops directly from within Claude Code, without having to exit
the session or write manual bash scripts.
Slash Commands for Ralph Wiggum
Command
Description
Parameters
/ralph-loop:ralph-loop
Start a new autonomous loop
--prompt FILE, --max-iter N, --model MODEL
/ralph-loop:cancel-ralph
Stop the running loop
--graceful (waits for current iteration to finish)
/ralph-loop:help
Show documentation and examples
None
Usage Examples for Commands
# Start a loop with explicit configuration
/ralph-loop:ralph-loop --prompt PROMPT.md --max-iter 30
# Start with a specific model to save costs
/ralph-loop:ralph-loop --prompt PROMPT.md --model claude-sonnet-4-20250514 --max-iter 50
# Stop gracefully (finish the current iteration)
/ralph-loop:cancel-ralph --graceful
# Stop immediately
/ralph-loop:cancel-ralph
# Display help and templates
/ralph-loop:help
8. When to Use and When NOT to Use Ralph Wiggum
The Ralph Wiggum pattern is powerful but not universal. Understanding the appropriate
contexts for its use is as important as mastering its implementation.
Using the autonomous loop in the wrong context can lead to resource waste,
low-quality results, or worse, damage to the codebase.
Existing tests as guard rails, measurable progress
UI/UX design
No
Requires subjective aesthetic judgment that cannot be automated
Architectural decisions
No
Requires strategic vision and non-measurable trade-offs
Code with uncontrollable external dependencies
No
External APIs can fail, creating infinite loops
Exploratory prototyping
Maybe
Useful if success criteria are definable, otherwise no
Bug fix on a single issue
Maybe
If a test reproducing the bug exists, yes. Otherwise, interactive is better
Signs That the Loop Is Not Working
Oscillation: The number of passing tests oscillates between iterations without a positive trend
Stagnation: No progress for 3+ consecutive iterations
Regression: Previously green tests turn red
Complexity explosion: Claude adds increasingly complex code instead of simplifying
Error loop: The same error appears repeatedly with different fixes that don't resolve it
When to Intervene Manually
If you observe one of the above signs for more than 5 consecutive iterations, it is time
to stop the loop, analyze the situation, and intervene. The most
effective actions are: rewriting the PROMPT.md with more specific instructions,
adding hints about the solution path, simplifying the problem by splitting it
into sub-tasks, or manually resolving the blocker and restarting the loop.
9. Cost Management and Optimization
Autonomous loops can consume significant API resources if not managed carefully.
Cost management is a critical aspect that must be planned from the start and
monitored during execution.
Cost Optimization Strategies
Model selection: Use Claude Sonnet for routine iterations and Claude Opus only for tasks requiring complex reasoning. Sonnet costs about 20% compared to Opus.
Minimal context: Reduce the PROMPT.md to the minimum necessary. Every input token is counted at each iteration.
Budget cap: Always set a maximum cost limit in the loop script
Incrementality: Split large projects into sub-tasks with separate loops
Local cache: Save intermediate results to avoid recalculations in case of restart
Cost Estimates by Scenario
Scenario
Typical Iterations
Estimated Cost (Sonnet)
Estimated Cost (Opus)
Simple CRUD API (5 endpoints)
10-20
$1-3
$5-15
Module with 20+ tests
20-40
$3-8
$15-40
Framework migration
50-100
$10-25
$50-125
Complete project (hackathon)
100-300
$25-75
$125-375
10. Risk Management and Monitoring
Running code autonomously carries inherent risks that must be managed with
appropriate protocols. A structured approach to risk management allows you to
leverage the benefits of the autonomous loop while minimizing the possibility
of incidents.
Risk Mitigation
Risk Matrix and Countermeasures
Risk
Probability
Impact
Countermeasure
Infinite loop
Medium
High (costs)
Max iterations + cost cap + stale detection
Codebase corruption
Low
High
Git commit checkpoints, dedicated branch
Dangerous command execution
Low
Critical
Docker isolation, read-only filesystem for critical folders
Low-quality code
Medium
Medium
Lint + type check as completion criteria
Unexpected costs
Medium
Medium
Budget cap with alerts at 50% and 80%
Secure Setup with Docker
The recommended practice for autonomous loops on non-critical projects is execution
in an isolated Docker container. This ensures that any dangerous commands cannot
damage the host system.
Dockerfile for Secure Loop
FROM node:20-slim
# Install Claude Code
RUN npm install -g @anthropic-ai/claude-code
# Install common development dependencies
RUN apt-get update && apt-get install -y \
git jq curl \
&& rm -rf /var/lib/apt/lists/*
# Create non-root user
RUN useradd -m developer
USER developer
WORKDIR /home/developer/project
# Copy the project
COPY --chown=developer:developer . .
# Install project dependencies
RUN npm install
# Loop startup script
COPY ralph-loop-advanced.sh /home/developer/ralph-loop.sh
# Resource limits
# --memory=4g --cpus=2 (to be specified at docker run)
CMD ["bash", "/home/developer/ralph-loop.sh"]
The Ralph Wiggum technique represents a paradigm shift in how we interact
with AI assistants for software development. It is no longer about asking
for help on a single problem at a time, but about delegating entire
development segments to an autonomous agent that iterates until
objectives are achieved.
The case studies demonstrate that the potential is real: from generating 6
repositories in one night for a hackathon, to completing contracts worth tens
of thousands of dollars with minimal API costs, to creating an entire
programming language. The common denominator of success is the quality of
preparation: clear objectives, well-written tests, and measurable completion
criteria.
Key Takeaways
4 guiding principles: Iteration, failures as data, operator competence, persistence
TDD is the natural partner: Tests define the success contract in an automatically verifiable way
Safety guards are mandatory: Max iterations, cost cap, and stale detection prevent problems
PROMPT.md is the heart: Result quality depends directly on instruction quality
Not everything is automatable: Design, architecture, and strategic decisions require human judgment
Docker for security: Isolating the loop in a container protects the host system
Active monitoring: Periodically check progress and intervene when necessary
In the next article we will explore the BMAD Method: a structured
methodology for AI-driven agile development that uses document sharding,
specialized agents, and guided workflows to manage complex projects in a
systematic and scalable way.
