[{"content":"Source: Ralph Wiggum as a “Software Engineer” — Geoffrey Huntley, 2025\nSummary Ralph is not a tool but a technique: an infinite loop that feeds a prompt into an AI coding agent (while :; do cat PROMPT.md | claude-code ; done). Huntley uses it to build CURSED, a new programming language with zero prior training data, and argues that Ralph is effective enough to displace a large majority of software engineers for greenfield projects, though he personally would not use it in an existing codebase. The approach requires faith in eventual consistency: each failure is a tuning opportunity, and each defect is addressed by refining the prompt. There is no perfect prompt; prompts evolve through continuous observation and adjustment specific to each project.\nThe technique rests on several core principles. Architecture must be monolithic, a single process in one repo, because non-determinism in multi-agent communication creates chaos. Each loop iteration should tackle exactly one task, letting the agent decide what matters most. The context window must be loaded deterministically with the same project plans and specs every time. And the agent must be instructed to search the codebase before assuming something hasn\u0026rsquo;t been implemented, because ripgrep-based code search can lead the agent to incorrectly conclude that code does not exist. Huntley calls this non-determinism Ralph\u0026rsquo;s \u0026ldquo;Achilles\u0026rsquo; heel.\u0026rdquo; Backpressure for correctness comes from the language\u0026rsquo;s type system and static analyzers, not from the generation step itself.\nIn practice, Ralph requires a detailed, prioritized TODO list that gets deleted and regenerated when the agent goes off track. The agent can update its own documentation when it discovers improvements and log bugs for future resolution. When the codebase breaks beyond repair, options range from git reset --hard to crafting rescue prompts. Huntley expects roughly 90% completion on greenfield projects, and an engineer he taught the technique to delivered a $50,000 contract for $297 in API costs. He is clear that senior engineering expertise is still essential for guiding the process. Anyone claiming engineers are no longer needed is, in his view, wrong.\nQuotes \u0026ldquo;Each time Ralph does something bad, Ralph gets tuned — like a guitar.\u0026rdquo;\n\u0026ldquo;You need to ask Ralph to do one thing per loop. Only one thing.\u0026rdquo;\n\u0026ldquo;Any problem created by AI can be resolved through a different series of prompts.\u0026rdquo;\n\u0026ldquo;There is no such thing as a perfect prompt.\u0026rdquo;\n\u0026ldquo;Anyone claiming that engineers are no longer required and a tool can do 100% of the work without an engineer is peddling horseshit.\u0026rdquo;\nNotes Huntley published Ralph in July 2025, about four months before Anthropic\u0026rsquo;s Effective Harnesses for Long-Running Agents. The core idea is the same: run an agent in a loop so each iteration gets a fresh context window instead of rotting in an old one. I wonder if Ralph inspired Anthropic\u0026rsquo;s approach or if they arrived at the loop independently. Either way, it seems like an obvious response once you hit context limits enough times.\nRalph is minimal on purpose: a bash loop, one prompt, and faith that things will converge. Anthropic adds more structure: an immutable feature list, a progress file, git history for context recovery, and a startup routine that rebuilds state before each session. Huntley says he wouldn\u0026rsquo;t use Ralph on anything but greenfield projects. Does Anthropic\u0026rsquo;s extra structure move the loop closer to working in existing codebases? Parts of it help: the feature list keeps the agent from wandering, and the progress file gives it a reliable starting point. But a large legacy codebase needs more than that. The agent has to understand architecture it didn\u0026rsquo;t build, follow conventions it didn\u0026rsquo;t choose, and avoid breaking things it doesn\u0026rsquo;t fully grasp. What would actually make a looped agent repeatable and safe in that kind of environment?\n","permalink":"https://www.christopherplain.com/posts/2026-03-25-ralph-wiggum-as-a-software-engineer/","summary":"Geoffrey Huntley describes Ralph, a technique that runs AI coding agents in an infinite loop with continuous prompt tuning to build greenfield software projects.","title":"Ralph Wiggum as a “Software Engineer”"},{"content":"Source: You Don\u0026rsquo;t Need SaaS. The $0.10 System That Replaced My AI Workflow (45 Min No-Code Build) — Nate Jones, 2026\nSummary AI tools today each maintain their own isolated memory. Claude cannot access context from ChatGPT; a phone app doesn\u0026rsquo;t share context with a coding agent. Jones argues this is not incidental but a deliberate lock-in strategy, betting that if they trap your context, you\u0026rsquo;ll stay. Traditional note-taking apps like Notion or Apple Notes are no substitute because they were designed for human browsing, not programmatic retrieval by agents. The internet is forking into a human web and an agent web, and memory architecture needs to serve both.\nThe proposed solution is what Jones calls the \u0026ldquo;Open Brain\u0026rdquo;: a Postgres database (hosted on Supabase) where every captured thought is stored alongside a vector embedding. An MCP server sits in front of the database, exposing semantic search, recent entries, and usage stats to any MCP-compatible AI client. When an agent queries the system, it retrieves entries by meaning rather than keyword match. The architecture is tool-agnostic: switching from Claude to ChatGPT or any future client requires no migration. Capture can happen from Slack, a chat app, or any MCP-compatible tool; the round trip from input to embedded, classified, searchable entry takes under ten seconds.\nThe core argument is about compounding returns. Someone who starts every AI conversation from scratch gets the same value on day one and day five hundred. Someone whose agents can query months of accumulated context, including decisions, preferences, project history, key people, gets meaningfully better results over time. Jones estimates the running cost at roughly ten to thirty cents per month using free tiers of Supabase and Slack, making the barrier primarily one of habit, not expense.\nQuotes \u0026ldquo;Claude\u0026rsquo;s memory doesn\u0026rsquo;t know what you told ChatGPT. ChatGPT\u0026rsquo;s memory doesn\u0026rsquo;t follow you into Cursor. Your phone app doesn\u0026rsquo;t share context with your coding agent. Every platform has built a walled garden of memory and none of them talk to each other.\u0026rdquo;\n\u0026ldquo;Your Notion workspace, for example, is built for human eyes. It\u0026rsquo;s built for pages, for databases, for views, for toggles, for cover images. It\u0026rsquo;s beautiful for you. It\u0026rsquo;s useless for an AI agent that needs to search by meaning, not by folder structure.\u0026rdquo;\n\u0026ldquo;The best prompt in the world cannot compensate for an AI that does not know what you\u0026rsquo;ve been working on, what you\u0026rsquo;ve already tried, what your constraints are, who the key people in your life are, or what you decided last Tuesday.\u0026rdquo;\n\u0026ldquo;The gap between \u0026lsquo;I use AI sometimes\u0026rsquo; and \u0026lsquo;AI is embedded in how I think and work\u0026rsquo; is the career gap of this decade. And it comes down to memory and context infrastructure.\u0026rdquo;\nNotes Jones doesn\u0026rsquo;t address discoverability. Memory is only useful if the right context surfaces when you need it. Flat files make this easy. You can scan folders, search by name, and browse directly. A database with embeddings requires you to ask the right question to get the right context back. Semantic search is powerful but will it have the same discoverability as markdown files? I need to think further about how this can be tested.\n","permalink":"https://www.christopherplain.com/posts/2026-03-25-you-dont-need-saas/","summary":"Why AI tools\u0026rsquo; siloed memory creates lock-in, and how a Postgres database with vector embeddings exposed via MCP can give every agent persistent, semantic access to your accumulated knowledge.","title":"You Don't Need SaaS. The $0.10 System That Replaced My AI Workflow (45 Min No-Code Build)"},{"content":"Source: Effective Harnesses for Long-Running Agents — Justin Young, 2025\nSummary Long-running AI agents start every session with a blank slate. Without scaffolding, they fail in two ways: they try to do too much at once, run out of context, and leave things half-built; or they see existing progress and prematurely declare the work done. Both problems come down to the agent having no way to know what\u0026rsquo;s been done and what\u0026rsquo;s left.\nYoung proposes a two-agent setup using the Claude Agent SDK. An initializer agent runs once to set up the environment. It creates a startup script, a progress log, an initial git commit, and a structured JSON feature list with 200+ entries, each marked passes: false. A coding agent handles all later sessions. The feature list is the key mechanism: it prevents the agent from trying to do everything at once and stops it from declaring victory while incomplete features remain. The agent can only flip passes to true. It cannot modify feature descriptions or test steps.\nEach session, the coding agent reads git logs and the progress file to rebuild context, picks the highest-priority incomplete feature, starts the dev server, and runs baseline tests before doing any new work. It works one feature at a time, commits with descriptive messages, and updates the progress file before ending. A major reliability gain came from having the agent use Puppeteer to test features in a real browser rather than just trusting the code it wrote, though some things like browser-native alert modals remain invisible to it.\nQuotes \u0026ldquo;Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.\u0026rdquo;\n\u0026ldquo;The key insight here was finding a way for agents to quickly understand the state of work when starting with a fresh context window, which is accomplished with the claude-progress.txt file alongside the git history.\u0026rdquo;\n\u0026ldquo;Providing Claude with these kinds of testing tools dramatically improved performance, as the agent was able to identify and fix bugs that weren\u0026rsquo;t obvious from the code alone.\u0026rdquo;\nNotes The practical question is how repeatable this is. Could the harness components (the feature list, progress file, startup routine, and session prompts) be generated consistently across different projects, or does each one need a custom setup? The approach is compelling, but its adoption at scale depends on how much of the scaffolding can be made generic and easy to generate.\n","permalink":"https://www.christopherplain.com/posts/2026-03-20-effective-harnesses-for-long-running-agents/","summary":"How to help AI agents maintain progress across multiple sessions using persistent state artifacts like progress files, feature lists, and structured startup routines.","title":"Effective Harnesses for Long-Running Agents"}]