Skip to content

Latest commit

 

History

History
134 lines (88 loc) · 4.32 KB

File metadata and controls

134 lines (88 loc) · 4.32 KB

Ralph Wiggum Philosophy

Core Principles

1. Autonomous by Default

Ralph is designed to run without human intervention. Every design decision prioritizes autonomous operation:

  • Self-correcting: When validation fails, the agent fixes issues automatically
  • Self-documenting: The agent maintains prd.json and AGENTS.md
  • Self-organizing: Tasks are prioritized and tracked without manual curation

2. Safety Through Isolation

"It's not if it gets popped, it's when."

Running autonomous agents with full system access is inherently risky. Ralph mitigates this through:

  • Docker sandboxing: Default recommendation for autonomous runs
  • Resource limits: CPU and memory constraints prevent runaway processes
  • Git boundaries: All changes go through commits, nothing is invisible
  • Network isolation: Optional network_mode: none for maximum security

3. Specification-Driven Development

Ralph doesn't guess what to build. It reads specifications and implements exactly what's documented:

  • Specs define the "what" and acceptance criteria
  • AGENTS.md defines the "how" (commands, patterns)
  • prd.json tracks progress and priorities

This creates a clear contract between humans (who write specs) and agents (who implement them).

4. Iterative Progress

Complex systems aren't built in one pass. Ralph's loop design embraces iteration:

  • Each loop picks ONE task, implements it, validates, commits
  • Small, atomic commits are easier to review and revert
  • Continuous progress is more valuable than perfect plans

5. Transparency Through Git

Every change Ralph makes is a git commit. This provides:

  • Complete audit trail of agent actions
  • Easy rollback if something goes wrong
  • Integration with existing code review workflows
  • No "magic" - everything is visible

Design Decisions

Why Shell Scripts Over npm/pip?

  1. Universal: Bash works on any Unix system without runtime dependencies
  2. Simple: No version management, dependency hell, or package conflicts
  3. Transparent: Read the scripts to understand exactly what happens
  4. Updatable: git pull to update, no npm/pip update complexities

Why Separate CLI Adapters?

Different CLIs have different:

  • Flag syntax
  • Authentication methods
  • Model specifications
  • Output formats

Adapters abstract these differences while keeping the core loop logic clean.

Why Project-Local Ralph Files?

Prompts and configuration live in the project, not globally, because:

  1. Tuning: Prompts should be optimized per-project
  2. Versioning: Track prompt changes in git with the code
  3. Sharing: Team members get the same prompts
  4. Reproducibility: Same prompts = same behavior

Why Interactive Initialization?

ralph init asks questions rather than requiring users to edit config files:

  1. Lower barrier: Start working immediately
  2. Fewer errors: No typos in configuration keys
  3. Discoverability: Users learn available options
  4. Sensible defaults: Most users accept the defaults

Anti-Patterns

Don't: Run Without Understanding

Ralph is powerful but not magical. Understand:

  • What the prompts tell the agent to do
  • What validation commands catch (and don't catch)
  • What the agent has access to

Don't: Skip Spec Writing

"Just implement it" leads to:

  • Incomplete features
  • Scope creep
  • Misaligned expectations

Write specs first. The time invested pays off.

Don't: Ignore the Plan

prd.json is the contract. If you:

  • Want different priorities → Edit the plan
  • Want to skip something → Remove it from the plan
  • See wrong estimates → Update the plan

The agent follows the plan. Shape the plan to shape the output.

Don't: Fear Iteration

Ralph isn't meant to "get it right the first time." Expect:

  • Multiple passes to complete features
  • Learning captured in AGENTS.md
  • Plan refinement as implementation reveals complexity

This is normal. Embrace the loop.

Future Directions

Ralph's design leaves room for:

  1. Multi-agent coordination: Multiple Ralphs working on different features
  2. Human checkpoints: Pause loops for review at key milestones
  3. Metrics and observability: Track agent efficiency over time
  4. Custom validation hooks: Project-specific quality gates
  5. Cost tracking: Monitor API usage across iterations

These aren't implemented yet, but the architecture supports them.