Ralph Wiggum: Loop AI による自律開発
複雑なソフトウェア開発目標を説明できると想像してください。Enter キーを押してください。 そして数時間後に戻ってくると、作業が完了していることがわかります。コードが書かれ、テストが合格し、 ドキュメントを更新しました。これはSFではなく、 ラルフ・ウィガムのテクニック、クロード コードをアシスタントから変換するアプローチ インタラクティブな 反復的な自律開発者.
「ラルフ・ウィガム」という名前は、粘り強さで知られるシンプソンズのキャラクターに由来しています。 素朴だが驚くほど効果的。基礎となる哲学は似ています: 反復 問題に精力的に取り組み、失敗をフィードバックとして利用して改善する そして目標が達成されるまで継続します。この記事では、 基本原理からユースケースまで、この革新的な技術を詳しく説明します 驚異的な成果を上げた実在の人物。
何を学ぶか
- ラルフ ウィガム自律ループの哲学と原則を理解する
- 基本ループと安全ガードを備えた高度なバージョンを実装する
- 自律ループ用の効果的な PROMPT.md ファイルの構造化
- 反復ループ内に TDD パターンを適用する
- コスト、リスク、長期実行中のモニタリングを管理
- 実際のケーススタディを分析する: ハッカソン、契約、創造的なプロジェクト
- ループ管理専用のスラッシュ コマンドを理解する
- ラルフ ウィガム パターンをいつ使用するか、いつ回避するかを決定する
シリーズ概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | テクニカルパートナーとしてのクロード | セットアップと最初のステップ |
| 2 | プロジェクトのコンテキストとセットアップ | CLAUDE.mdと設定 |
| 3 | コンセプトと要件 | MVP とユーザーペルソナ |
| 4 | バックエンドとフロントエンドのアーキテクチャ | Spring Boot と Angular |
| 5 | コードの構造 | 組織と規約 |
| 6 | 高度なエンジニアリングプロンプト | 高度なテクニック |
| 7 | テストと品質 | 戦略とテストの生成 |
| 8 | 専門的な文書 | README、API、ADR |
| 9 | デプロイとDevOps | Docker、CI/CD、モニタリング |
| 10 | 進化と維持 | リファクタリングとスケーラビリティ |
| 11 | 実際のプロジェクトの統合 | クロード・コードの運用中 |
| 12 | 高度な CLI とコマンド | コマンドラインの習得 |
| 13 | カスタムスラッシュコマンドとスキル | クロードコードの拡張 |
| 14 | サブエージェントと委任 | 専門エージェントを調整する |
| 15 | フック: イベント駆動型オートメーション | イベントベースの自動化 |
| 16 | Ralph Wiggum: 自律型 AI ループ (ここにいます) | 反復的な自律開発 |
| 17 | BMAD 手法: アジャイル AI 開発 | アジャイルな AI 主導の方法論 |
| 18 | マルチエージェントオーケストレーション | エージェントのチームを調整する |
| 19 | コラボレーションとコワーキング AI | クロードと協力して |
| 20 | セキュリティと権限 | ワークフローを保護する |
| 21 | 監視と最適化 | 指標とパフォーマンス |
1. 自律ループの哲学
ラルフ ウィガムのテクニックは 4 つの基本的な定義原則に基づいています。 アプローチを確立し、その有効性を保証します。これらの原則を理解することが不可欠です パターンを正しく適用し、一貫した結果を得ることができます。
原則 1: 完璧よりも反復
最初の試行で完璧なソリューションを探すのではなく、自律ループは次のことを採用します。 段階的なアプローチ。各反復で部分的な結果が生成されます。 次のサイクルで評価、修正、改善されます。このアプローチは特に、 言語モデルは既存のソリューションを改良することに優れているため、効果的です ゼロから完璧な出力を作成するのではなく、
この概念は、「速く失敗し、より速く学習する」というアジャイルの原則に似ています: すべてのサイクル ループの部分では次のループに役立つ情報が生成され、プロセスが作成されます。 望ましい解決策に向けて収束します。重要なのは基準を定義することです ループ自体が決定できるようにする明確で測定可能な成功 結果が満足のいくものになったとき。
原則 2: データとしての失敗
Ralph Wiggum ループでは、テストの失敗やコンパイル エラーは問題になりません。 私は 構造化されたフィードバック。すべての失敗には貴重な情報が含まれています 何を修正する必要があるかについて、Claude Code は特に分析に優れています。 エラーメッセージを表示し、それらを修正措置に変換します。
この原則は、TDD (テスト駆動開発) パターンが採用される理由を説明します。 自律ループと完全に連携: テストによって成功したコントラクトが定義され、 エラー メッセージは、反復的な修正プロセスを推進します。失敗するテスト そして、何が欠けているか、何が間違っているかを正確に示す正確な信号。
原則 3: オペレーターの能力が重要
ラルフ ウィガムは、何もないところからソフトウェアを生み出す魔法のボタンではありません。品質
結果の程度は、提供された指示の品質に直接依存します。あ
ファイル PROMPT.md よく構造化されており、明確な目的と明示的な制約がある
測定可能な成功基準により、他のものと比べてはるかに優れた結果が得られます。
曖昧または不完全な指示。
人間のオペレーターは、問題の定義、 制約の構造化と結果の最終的な検証。自律ループ 実行は自動化されますが、戦略的な方向性は人間のままです。
原則 4: 継続が勝利する
複雑に見えるソフトウェア開発の問題の多くは、実際には解決可能です 体系的な試みを通じて。何時間ものデバッグを必要とする難しいバグ クロードコードは次のことができるため、マニュアルは数サイクルの自律ループで解決できます。 さまざまな修正戦略を迅速に検討し、スタック トレースを分析します 複雑な修正を体系的に適用します。
4 つの原則の比較
| 原理 | 従来のアプローチ | ラルフ・ウィガムのアプローチ |
|---|---|---|
| 反復 | 詳細な計画、単一の実行 | 明確な目標、複数回の反復 |
| 失敗 | 回避すべきエラー、手動デバッグ | 貴重なフィードバック、自己修正 |
| 能力 | 開発者がコードを書く | オペレータは目的と制約を定義します |
| 持続性 | 試行ごとの制限時間 | 成功するまで継続ループ |
2. 基本的なループの実装
最も単純な形では、ラルフ ウィガム ループは次のような無限ループです。 事前定義されたプロンプトを使用して継続的に Claude Code を実行します。コンセプトは武装解除です シンプル: タスクが完了するまで、次のコマンドを使用してクロード コードを実行し続けます。 同じ指示。
#!/bin/bash
# ralph-loop-basic.sh
# Il loop più semplice possibile
while true; do
cat PROMPT.md | claude --print --dangerously-skip-permissions
echo "--- Iterazione completata, ripartenza ---"
sleep 2
done
このスクリプトは次の 3 つのことを行います。 ファイルの内容を読み取ります。 PROMPT.md、それ
パイプ経由で入力として Claude Code に渡し、完了を待って再び開始します。
旗 --print Claude はフォーマットされた出力を生成しますが、
--dangerously-skip-permissions 対話型の確認プロンプトを避ける
ループをブロックしてしまいます。
警告: --dangerously-skip-permissions フラグのセキュリティ
Il flag --dangerously-skip-permissions クロード・コードのアクセス許可を付与します
確認を求めずに操作を実行すること。これには書き込みも含まれます
ファイル、シェルコマンドの実行、構成の変更。 使用する
このフラグは隔離された環境でのみ使用されます (Docker コンテナ、専用 VM、リポジトリ
テスト中）、機密データを含む運用システムやリポジトリでは決して使用しないでください。
PROMPT.md ファイル構造
ファイル PROMPT.md それは自律ループの中心です。説明書が入っています
クロード コードは反復ごとにそれを受け取り、その動作を定義します。あ
有効な PROMPT.md は構造化され、具体的であり、基準が含まれている必要があります。
クリア完成。
# Obiettivo del Progetto
Stai sviluppando un'API REST per la gestione di un sistema di prenotazioni.
Il progetto usa Node.js con Express e TypeScript, e PostgreSQL come database.
## Stato Corrente
Leggi il file `STATUS.md` per capire cosa è stato completato e cosa manca.
Dopo ogni iterazione, aggiorna STATUS.md con i progressi.
## Requisiti Funzionali
1. CRUD completo per le entità: User, Booking, Room
2. Autenticazione JWT con refresh token
3. Validazione input con Zod
4. Pagination e filtering su tutte le liste
5. Rate limiting sulle API pubbliche
## Vincoli Tecnici
- TypeScript strict mode
- Test unitari per ogni service (copertura > 80%)
- Test di integrazione per ogni endpoint
- Nessuna dipendenza non necessaria
- Documentazione OpenAPI/Swagger per ogni endpoint
- Error handling centralizzato con codici errore consistenti
## Criteri di Completamento
Il task è COMPLETO quando TUTTI i seguenti criteri sono soddisfatti:
1. `npm run build` compila senza errori
2. `npm test` passa tutti i test (0 fallimenti)
3. `npm run lint` non produce warning o errori
4. Ogni endpoint ha almeno 3 test di integrazione
5. Il file STATUS.md indica "COMPLETATO" per tutti i moduli
## Workflow per Iterazione
1. Leggi STATUS.md per capire dove sei rimasto
2. Identifica il prossimo task incompleto
3. Implementa il codice necessario
4. Scrivi i test corrispondenti
5. Esegui `npm test` e correggi eventuali fallimenti
6. Aggiorna STATUS.md con i progressi
7. Se tutti i criteri sono soddisfatti, scrivi "DONE" in STATUS.md3. 安全ガードによる高度な実装
基本的なループは機能しますが、専門的なコンテキストではメカニズムが必要です 際限のない実行を回避し、コストを管理し、 ループは予測どおりに動作します。高度な実装の追加 プロセスを堅牢かつ管理しやすくするガード レール。
#!/bin/bash
set -euo pipefail
# ================================
# CONFIGURAZIONE
# ================================
MAX_ITERATIONS=${MAX_ITERATIONS:-50} # Numero massimo di iterazioni
MAX_COST=${MAX_COST:-"10.00"} # Costo massimo in dollari
SLEEP_BETWEEN=${SLEEP_BETWEEN:-5} # Secondi tra iterazioni
PROMPT_FILE=${PROMPT_FILE:-"PROMPT.md"} # File con le istruzioni
STATUS_FILE=${STATUS_FILE:-"STATUS.md"} # File di stato
LOG_DIR=${LOG_DIR:-".ralph/logs"} # Directory log
# ================================
# INIZIALIZZAZIONE
# ================================
ITERATION=0
START_TIME=$(date +%s)
TOTAL_COST=0
mkdir -p "$LOG_DIR"
echo "=== Ralph Wiggum Loop ===" | tee "$LOG_DIR/main.log"
echo "Max iterazioni: $MAX_ITERATIONS" | tee -a "$LOG_DIR/main.log"
echo "Max costo: \$MAX_COST" | tee -a "$LOG_DIR/main.log"
echo "Avvio: $(date)" | tee -a "$LOG_DIR/main.log"
# ================================
# FUNZIONI DI GUARD
# ================================
check_completion() {
# Controlla se il file STATUS contiene il marker di completamento
if [ -f "$STATUS_FILE" ]; then
if grep -qi "DONE\|COMPLETATO\|FINISHED" "$STATUS_FILE"; then
return 0 # Completato
fi
fi
return 1 # Non completato
}
check_cost_limit() {
# Verifica che il costo non superi il limite
if command -v bc &> /dev/null; then
OVER=$(echo "$TOTAL_COST >= $MAX_COST" | bc -l)
if [ "$OVER" = "1" ]; then
return 0 # Limite superato
fi
fi
return 1 # Sotto il limite
}
check_stale_progress() {
# Controlla se ci sono progressi tra un'iterazione e l'altra
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=$((${STALE_COUNT:-0} + 1))
if [ "$STALE_COUNT" -ge 3 ]; then
return 0 # Bloccato da 3 iterazioni
fi
else
STALE_COUNT=0
fi
return 1 # Progressi in corso
}
# ================================
# LOOP PRINCIPALE
# ================================
while [ "$ITERATION" -lt "$MAX_ITERATIONS" ]; do
ITERATION=$((ITERATION + 1))
ITER_START=$(date +%s)
echo "" | tee -a "$LOG_DIR/main.log"
echo "--- Iterazione $ITERATION/$MAX_ITERATIONS ---" | tee -a "$LOG_DIR/main.log"
echo "Timestamp: $(date)" | tee -a "$LOG_DIR/main.log"
# Guard 1: Controllo completamento
if check_completion; then
echo "SUCCESSO: Task completato all'iterazione $ITERATION!" | tee -a "$LOG_DIR/main.log"
break
fi
# Guard 2: Controllo costo
if check_cost_limit; then
echo "STOP: Limite costo raggiunto (\$TOTAL_COST >= \$MAX_COST)" | tee -a "$LOG_DIR/main.log"
break
fi
# Guard 3: Controllo stagnazione
if check_stale_progress; then
echo "WARNING: Nessun progresso per 3 iterazioni consecutive" | tee -a "$LOG_DIR/main.log"
echo "Tentativo di reset approccio..." | tee -a "$LOG_DIR/main.log"
# Inietta istruzione di cambio strategia
echo -e "\n\nATTENZIONE: Le ultime 3 iterazioni non hanno prodotto progressi. Cambia approccio radicalmente." >> "$PROMPT_FILE.tmp"
cat "$PROMPT_FILE" >> "$PROMPT_FILE.tmp"
PROMPT_TO_USE="$PROMPT_FILE.tmp"
else
PROMPT_TO_USE="$PROMPT_FILE"
fi
# Esecuzione Claude Code
cat "$PROMPT_TO_USE" | claude --print --dangerously-skip-permissions \
2>&1 | tee "$LOG_DIR/iteration-$ITERATION.log"
# Cleanup file temporaneo
rm -f "$PROMPT_FILE.tmp"
# Calcola tempo iterazione
ITER_END=$(date +%s)
ITER_DURATION=$((ITER_END - ITER_START))
echo "Durata iterazione: ${ITER_DURATION}s" | tee -a "$LOG_DIR/main.log"
# Pausa tra iterazioni
sleep "$SLEEP_BETWEEN"
done
# ================================
# REPORT FINALE
# ================================
END_TIME=$(date +%s)
TOTAL_DURATION=$((END_TIME - START_TIME))
echo "" | tee -a "$LOG_DIR/main.log"
echo "=== Report Finale ===" | tee -a "$LOG_DIR/main.log"
echo "Iterazioni completate: $ITERATION" | tee -a "$LOG_DIR/main.log"
echo "Durata totale: $((TOTAL_DURATION / 60))m $((TOTAL_DURATION % 60))s" | tee -a "$LOG_DIR/main.log"
echo "Fine: $(date)" | tee -a "$LOG_DIR/main.log"
# Notifica completamento
if command -v notify-send &> /dev/null; then
notify-send "Ralph Wiggum Loop" "Completato dopo $ITERATION iterazioni"
fi--max-iterations フラグ
クロード コードのより新しいバージョンでは、フラグ --max-iterations
ネイティブにサポートされているため、反復制限の管理が容易になります。
シェル ラッパーを必要とせずにコマンド ラインから直接実行します。
# Loop con limite di 20 iterazioni
cat PROMPT.md | claude --print --dangerously-skip-permissions --max-iterations 20
# Combinazione con altri flag
cat PROMPT.md | claude \
--print \
--dangerously-skip-permissions \
--max-iterations 30 \
--model claude-sonnet-4-202505144. 自律ループの TDD パターン
テスト駆動開発 (TDD) は、Ralph Wiggum ループの自然な仲間です。 テストは成功した契約をプログラム的に定義します。 テストに合格すると、ループは目的を達成します。このアプローチにより、 完了基準の曖昧さを排除し、プロセスを完全に完了します。 検証可能で再現可能です。
ループ内の TDD ワークフロー
自律ループに適応された TDD パターンは、正確なシーケンスに従います。
- テスト定義 (人間): オペレーターは、予想される動作を定義するテストを作成します。
- 最初の反復: クロードはテストを読み、要件を理解し、最初の実装を作成します。
- テストの実行: テストは自動的に実行され、構造化されたフィードバックが生成されます
- 後続の反復: クロードは失敗を分析し、実装を改良します
- 収束： すべてのテストに合格するとプロセスは収束します
# Task: Implementare il Modulo di Autenticazione
## Contesto
Stai implementando il modulo di autenticazione per un'API Express/TypeScript.
I test sono già scritti in `src/auth/__tests__/auth.test.ts`.
## Workflow OBBLIGATORIO per ogni iterazione
1. Esegui `npm test -- --testPathPattern=auth` per vedere lo stato dei test
2. Analizza i test falliti: leggi il messaggio di errore e il codice del test
3. Implementa o correggi il codice per far passare il PROSSIMO test fallito
4. Esegui di nuovo i test per verificare il fix
5. Se hai introdotto regressioni, correggi prima quelle
6. Aggiorna STATUS.md con il conteggio: "Test passati: X/Y"
## Criteri di Completamento
Il modulo è COMPLETO quando `npm test -- --testPathPattern=auth` produce:
- 0 test falliti
- 0 errori di compilazione
- Coverage > 80%
Quando TUTTI i test passano, scrivi "DONE" in STATUS.md.
## Vincoli
- NON modificare i file di test
- NON usare `any` nel codice TypeScript
- NON ignorare errori con try/catch vuoti
- Ogni funzione pubblica deve avere JSDoc// 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();
});
});
});TDD ループの進行状況インジケーター
自律ループにおける TDD パターンの重要な側面は、トラッキングです。 進歩の。各反復では、測定可能なデルタ、つまり次の数が生成されます。 合格したテスト。これにより、収束を監視し、識別することができます。 行き詰まりの状況。
#!/bin/bash
# Esegue i test e traccia il progresso tra iterazioni
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)
# Salva nel file di progresso
echo "{\"timestamp\": $TIMESTAMP, \"passed\": $PASSED, \"failed\": $FAILED, \"total\": $TOTAL}" \
>> .ralph/progress.jsonl
# Calcola delta rispetto all'iterazione precedente
PREV_PASSED=$(tail -2 .ralph/progress.jsonl | head -1 | jq '.passed // 0' 2>/dev/null || echo 0)
DELTA=$((PASSED - PREV_PASSED))
echo "Test: $PASSED/$TOTAL passati (delta: $DELTA)"
# Alert se nessun progresso
if [ "$DELTA" -eq 0 ] && [ "$FAILED" -gt 0 ]; then
echo "WARNING: Nessun nuovo test passato in questa iterazione"
fi5. 効果的な完了基準を定義する
完了基準は、人間のオペレーターと自律ループの間の契約です。 基準が適切に定義されていないと、無限ループ、不完全な結果、またはリソースの無駄が発生します。 効果的な基準の定義は、 ラルフ・ウィガムパターンが成功しました。
良好な完了基準の特徴
| 特性 | 良い基準 | 悪い基準 |
|---|---|---|
| 測定可能性 | 「npm テストは失敗なしで合格しました」 | 「コードは正常に動作します」 |
| 自動検証可能性 | 「npm run build がコード 0 で終了します」 | 「建築はエレガントです」 |
| 特異性 | 「すべてのサービスで > 80% をカバー」 | 「テスト範囲が広い」 |
| 完全 | 「5 つのエンドポイントすべてが実装されました」 | 「APIの実装」 |
| 曖昧さはない | 「ゼロ警告 ESLint」 | 「クリーンなコード」 |
パターン: 段階的な目標
複雑なタスクの場合は、段階的に目標を構造化することが効果的です。 中間マイルストーンを定義します。このアプローチは、Claude Code が集中するのに役立ちます 一度に 1 つのサブ目標を達成し、自然なチェックポイント ポイントを提供します。
# Status del Progetto
## Milestone 1: Setup Infrastruttura [COMPLETATO]
- [x] Inizializzazione progetto TypeScript
- [x] Configurazione ESLint e Prettier
- [x] Setup Jest per testing
- [x] Configurazione database PostgreSQL
## Milestone 2: Modello Dati [IN CORSO]
- [x] Schema User con validazione
- [x] Schema Booking con relazioni
- [ ] Schema Room con disponibilità
- [ ] Migration scripts
## Milestone 3: API Endpoints [DA FARE]
- [ ] POST /api/users (registrazione)
- [ ] POST /api/auth/login (autenticazione)
- [ ] GET /api/rooms (lista disponibili)
- [ ] POST /api/bookings (crea prenotazione)
- [ ] GET /api/bookings/:id (dettaglio)
- [ ] DELETE /api/bookings/:id (cancellazione)
## Milestone 4: Testing e qualità [DA FARE]
- [ ] Test unitari per tutti i service
- [ ] Test integrazione per tutti gli endpoint
- [ ] Coverage > 80%
- [ ] Zero warning lint
## Stato: IN CORSO - Milestone 26. 実際のケーススタディ
ラルフ ウィガム手法は、現実世界の設定で顕著な結果を生み出しています。 これらのケーススタディは、アプローチの可能性と限界の両方を示しています。 あなた自身のプロジェクトに適用できる実践的なレッスンを提供します。
ケーススタディ 1: Y Combinator ハッカソン - 一晩で 6 つのリポジトリ
Y Combinator ハカソン中に、チームはラルフ ウィガムのテクニックを使用しました 生成する 一晩で 6 つのフルリポジトリ。セットアップが含まれています クロード コードの 6 つのインスタンスを並行して実行し、それぞれに固有の PROMPT.md を持ちます。 アプリケーションの異なるマイクロサービス。
チームは夜をかけて、アーキテクチャ、サービス間のインターフェイス、および 統合テスト。それから彼はループを開始し、Claude Code を機能させました。 一晩中。朝までに、6 つのリポジトリのうち 5 つが稼働し、テストが実行されました。 彼らは通り過ぎた。 6 番目は、問題を解決するために手動介入が必要でした ループが克服できなかったデータベース構成。
ハッカソンから得た教訓
- 準備が重要です: サービス間の明確なインターフェイスの定義に何時間も費やしたことで、ループが独立して動作できるようになりました
- 統合テストは接着剤です。 各サービスには、相互のインターフェイスとの互換性をチェックするテストがありました。
- 最初の試行ですべてが機能するわけではありません。 6 件中 1 件のリポジトリでは手動介入が必要でしたが、全体的な時間の節約は大幅に短縮されました
- 監視が必要な場合: チームは定期的にログをチェックして、スタックしたループを特定しました。
ケーススタディ 2: API コスト 297 ドルの 50,000 ドルの契約
フリーランスの開発者が Ralph Wiggum ループを使用して、 ソフトウェア開発契約額 50,000ドル 費用がかかる 太陽のAPIクロード $297。プロジェクトは移行で構成されていました 従来の PHP アプリケーションから最新の Node.js/TypeScript アーキテクチャへ。
この戦略には、プロジェクトを独立したモジュールに分割することが含まれていました。 従来のアプリケーションの動作から派生した独自のテストを使用します。自律ループ 前のモジュールの出力を使用して、各モジュールを順番に処理しました 次のコンテキストとして。
その結果、フルタイムで 2 ～ 3 か月の作業が必要となるプロジェクトが完成しました。 開発者が中心となって2週間で完成 コードレビュー、ビジネス要件の検証、手動テスト用 ユーザーフローの。
コストの内訳
| Voce | 詳細 |
|---|---|
| 移行されたモジュール | 12 モジュール、約 40,000 行の PHP コードを変換 |
| 総反復数 | 2 週間にわたって最大 340 回の反復 |
| コスト API クロード | 297 ドル (ほとんどのソネット モデル) |
| 開発者の時間 | 約 40 時間 (レビュー、テスト、改良) |
| 契約金額 | 50,000ドル |
| 効果的なROI | API コストが 167 倍 |
ケーススタディ 3: CURSED - 3 か月でプログラミング言語を習得
プロジェクト 呪われた それは難解なプログラミング言語です 3 か月にわたってラルフ ウィガムの自己完結型ループを通じて完全に作成されました。 作成者は言語仕様を定義し、パーサーのテストを作成し、 インタプリタとコンパイラの自己完結型ループの実装は残ります。 各コンポーネントを繰り返し実行します。
このケーススタディは、次の能力を実証しているため、特に興味深いです。 プロジェクト管理のパターン 非常に複雑で相互接続されている。 プログラミング言語を作成するには、一貫した管理が必要です。 文法、解析、意味分析、コード生成とランタイム、 循環依存関係と厳格な正確さの制約。
プロジェクトはいくつかのフェーズを経ました。最初はループによって実装が生成されました。 より複雑なテストでは失敗した部分的ですが、反復するたびに品質が向上しました 改善していました。約 200 回の反復後にパーサーが完成し、500 回後にインタープリターが完成しました。 ベースは機能し、1000 回以上の反復を経て 3 か月にわたって言語が普及しました。 重要なプログラムを実行できるほど十分に成熟していました。
7. ループ管理用コマンド
コミュニティは管理を簡素化するための専用のスラッシュ コマンドを開発しました。 Ralph Wiggum は、Claude コード内から直接ループします。 セッションからログアウトするか、手動の bash スクリプトを作成します。
ラルフ・ウィガムのスラッシュコマンド
| 指示 | 説明 | パラメータ |
|---|---|---|
/ralph-loop:ralph-loop |
新しい自己完結型ループを開始する | --prompt FILE, --max-iter N, --model MODEL |
/ralph-loop:cancel-ralph |
実行中のループを停止します | --graceful (現在の反復が終了するまで待ちます) |
/ralph-loop:help |
ドキュメントと例を表示する | 誰でもない |
# Avvia un loop con configurazione esplicita
/ralph-loop:ralph-loop --prompt PROMPT.md --max-iter 30
# Avvia con modello specifico per risparmiare costi
/ralph-loop:ralph-loop --prompt PROMPT.md --model claude-sonnet-4-20250514 --max-iter 50
# Interrompi gentilmente (finisci l'iterazione corrente)
/ralph-loop:cancel-ralph --graceful
# Interrompi immediatamente
/ralph-loop:cancel-ralph
# Visualizza aiuto e template
/ralph-loop:help8. ラルフ・ウィガムを使用する場合と使用しない場合
ラルフ ウィガム パターンは強力ですが、普遍的ではありません。コンテキストを理解する その使用に適切であることは、その実装を習得することと同じくらい重要です。 自律ループを間違ったコンテキストで使用すると、リソースが無駄になる可能性があります。 結果の品質が低下したり、さらに悪いことにコードベースが損傷したりする可能性があります。
意思決定マトリックス: ラルフ ウィガム イエスかノーか?
| シナリオ | 適していますか？ | モチベーション |
|---|---|---|
| 明確な仕様によるAPIの実装 | Si | 明確に定義された要件、検証可能なテスト、予測可能な収束 |
| フレームワーク間のコードの移行 | Si | 反復パターン、等価性テスト、並列化可能なタスク |
| 既存のコードからのテストの生成 | Si | 明確な目的（範囲）、即時フィードバック |
| 回帰テストによるリファクタリング | Si | ガードレールとしての既存のテスト、測定可能な進歩 |
| UI/UXデザイン | No | 自動化できない主観的な美的判断が必要です |
| アーキテクチャ上の決定 | No | 戦略的なビジョンと測定不可能なトレードオフが必要です |
| チェックできない外部依存関係を含むコード | No | 外部 API が失敗し、無限ループが発生する可能性がある |
| 探索的なプロトタイピング | 多分 | 成功基準が定義可能な場合は便利ですが、それ以外の場合は役に立ちません |
| 単一の問題のバグ修正 | 多分 | バグを再現するテストがある場合は、はい。それ以外の場合は、よりインタラクティブに |
ループが機能していない兆候
- 発振： 合格したテストの数は反復間で変動し、肯定的な傾向はありません
- 停滞： 3回以上連続して繰り返しても進歩なし
- 回帰: 以前は緑だったテストが赤に変わります
- 複雑さの爆発: クロードは単純化する代わりに、ますます複雑なコードを追加します。
- エラーループ: 同じエラーが繰り返し表示され、別の修正を行っても解決されません
手動で介入する場合
上記のシグナルのいずれかを 5 回以上連続して観察した場合は、そのタイミングです。 の ループを断ち切り、状況を分析して介入する。 最も効果的なアクションは、より具体的な指示で PROMPT.md を書き換えることです。 解決策に関するヒントを追加し、問題を細分化して単純化します。 サブタスクで実行するか、ハングを手動で解決してループを再開します。
9. コスト管理と最適化
自己完結型ループは、次の方法で管理しない場合、大量の API リソースを消費する可能性があります。 気をつけてください。コスト管理は計画が必要な重要な側面です 最初から実行され、実行中に監視されます。
コスト最適化戦略
- モデルの選択: Claude Sonnet は日常的な反復に使用し、Claude Opus は複雑な推論が必要なタスクにのみ使用します。 Sonnet は Opus と比較して約 20% のコストがかかります。
- 最小限のコンテキスト: PROMPT.md を必要最小限に減らします。各入力トークンは反復ごとにカウントされます。
- 予算の上限: ループ スクリプトで常に最大コスト制限を設定します。
- 漸進性: 大規模なプロジェクトを個別のループを使用してサブタスクに分割する
- ローカルキャッシュ: 再起動時の再計算を避けるために中間結果を保存します。
シナリオのコスト見積もり
| シナリオ | 典型的な反復 | 推定コスト (ソネット) | 推定コスト (オーパス) |
|---|---|---|---|
| シンプルな CRUD API (5 エンドポイント) | 10-20 | 1～3ドル | 5～15ドル |
| 20以上のテストを含むモジュール | 20-40 | 3ドルから8ドル | 15～40ドル |
| フレームワークの移行 | 50-100 | 10～25ドル | 50～125ドル |
| プロジェクトの完了 (ハッカソン) | 100-300 | 25～75ドル | $125-375 |
10. リスク管理とモニタリング
自分でコードを実行するには、管理が必要な固有のリスクが伴います 適切なプロトコルを使用して。リスク管理への構造化されたアプローチにより、 事故の可能性を最小限に抑えながら、自律ループの利点を活用します。
リスクの軽減
リスクマトリックスとその対策
| リスク | チャンス | インパクト | 対策 |
|---|---|---|---|
| 無限ループ | 平均 | 高い（費用がかかる） | 最大反復回数 + コスト上限 + 古い検出 |
| コードベースの破損 | 低い | 高い | Git コミット チェックポイント、専用ブランチ |
| 危険なコマンドの実行 | 低い | 評論家 | Docker 分離、重要なフォルダーの読み取り専用ファイルシステム |
| 低品質のコード | 平均 | 中くらい | 完了基準としての lint + 型チェック |
| 予期せぬコスト | 平均 | 中くらい | 50% および 80% でアラートが発生する予算上限 |
Docker を使用した安全なセットアップ
重要ではないプロジェクトと実行における自律ループの推奨プラクティス 分離された Docker コンテナ内。これにより、危険なコマンドが実行されなくなります。 ホスト システムに損傷を与えることはできません。
FROM node:20-slim
# Installa Claude Code
RUN npm install -g @anthropic-ai/claude-code
# Installa dipendenze di sviluppo comuni
RUN apt-get update && apt-get install -y \
git jq curl \
&& rm -rf /var/lib/apt/lists/*
# Crea utente non-root
RUN useradd -m developer
USER developer
WORKDIR /home/developer/project
# Copia il progetto
COPY --chown=developer:developer . .
# Installa dipendenze del progetto
RUN npm install
# Script di avvio del loop
COPY ralph-loop-advanced.sh /home/developer/ralph-loop.sh
# Limiti di risorse
# --memory=4g --cpus=2 (da specificare al docker run)
CMD ["bash", "/home/developer/ralph-loop.sh"]# Avvia il loop con limiti di risorse
docker run \
--memory=4g \
--cpus=2 \
--env ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
--env MAX_ITERATIONS=50 \
--env MAX_COST=20.00 \
-v $(pwd)/output:/home/developer/project/output \
ralph-wiggum-loop
# Monitora i log in tempo reale
docker logs -f $(docker ps -q --filter ancestor=ralph-wiggum-loop)
# Ferma il loop
docker stop $(docker ps -q --filter ancestor=ralph-wiggum-loop)結論
ラルフ ウィガムのテクニックは、どのような方法でパラダイム シフトを起こしたかを表しています。 ソフトウェア開発のために AI アシスタントと対話します。それはもう関係ない 一度に 1 つの問題について助けを求めることはできますが、 代表者 開発の全セグメント まで反復する自律エージェントへ 目標の達成。
ケーススタディは、可能性が本物であることを示しています: 第 6 世代以降 との契約が完了したら、ハッカソンのために一晩でリポジトリを作成します。 最小限の API コストで数万ドル、 プログラミング言語全体。成功の共通点 それは準備の質です。明確な目標、よく書かれたテスト、 測定可能な完了基準。
重要なポイント
- 4 つの基本原則: 反復、データとしての失敗、オペレーターの能力、永続性
- TDD と自然なパートナー: テストは自動的に検証可能な方法で成功した契約を定義します
- 安全防護具は必須です: 最大反復、コスト上限、および古い検出により問題を防止します
- PROMPT.md は心臓部です。 結果の品質は指示の品質に直接依存します
- すべてを自動化できるわけではありません。 設計、アーキテクチャ、戦略的決定には人間の判断が必要
- セキュリティのための Docker: コンテナ内のループを分離するとホスト システムが保護されます
- アクティブな監視: 定期的に進捗状況を確認し、必要に応じて介入する
次の記事では、 BMAD法: 方法論 ドキュメントシャーディングを使用したアジャイルな AI 主導開発のために構造化されており、 複雑なプロジェクトを適切な方法で管理するための専門エージェントとガイド付きワークフロー 体系的かつスケーラブル。