Three months ago, I wrote an article about what I had been thinking while living with Ralph Loop.

Over the next three months, the capabilities of AI models used for coding improved tremendously. Until then, I had often reset context because I feared context anxiety. I had also put a great deal of effort into designing a harness that would keep the context from growing too large. Recently, instead of fearing context anxiety, I have even started to think about how to give the model more context.

I think this change came from growing trust in models and growing distrust in myself. Fable 5 often makes more elegant proposals than I can, and that elegance does not seem to weaken as context grows. Meanwhile, the speed of implementation and the documents piling up have made me start to give up on understanding the system as a whole. Watching an agent finish in a short time what I could not complete in a full day has only increased my trust—or dependence—on the model’s judgment and the agent’s ability to carry out the work.

These changes shifted my attention in software development: from saving limited context to building reliable context, from generating code to adjusting how implementation proceeds, and from reading generated artifacts to observing the behavior they produce and judging whether it is right.

Taking the Ralph Loop I used three months ago as a starting point, this article looks back at how my harness moved beyond Ralph Loop by August 2026. It also records how this change made me question whether source code really is the central representation of a system.

Ralph Loop Dissolved into My Current Harness

Ralph Loop is known as a technique that runs an agent inside a while loop in a shell script. But as I used Ralph Loop for development, I began to think that its value for me was not the while loop itself. The value was in separating conversation from implementation and persisting context. I also wrote about this in my previous article.

As I took that idea further, the while loop disappeared from my harness. In its place, a one-shot run appeared. It implements a coherent group of tasks as a working set, passes through a gate, and integrates the result into the working environment. ralph.sh became one of the engines that executes these runs. Around it, I added other mechanisms: organization by the Orchestrator, environment isolation, working-set selection, task ownership, and integration into the working environment.

The current harness is available in the ralph-loop-starter. The repository keeps its original name for historical reasons.

As these changes built up, it became hard to tell which parts were specific to Ralph Loop. My current harness still inherits several of its genes: fresh context for each run, externalized context, and the separation of conversation from implementation. But the mechanisms around those ideas have changed, and the outline of Ralph Loop has dissolved into the general practices I now use when developing with agents. I no longer find it useful to describe my harness as Ralph Loop. For me, Ralph Loop was the route I took to reach it.

Context Anxiety Has Eased

Ralph Loop divides a goal into small tasks and gives each task fresh context. As context windows grew and models became better at using them, this allocation began to feel too conservative. I kept fresh context for each run, but changed its unit from one task to a working set: a coherent group of tasks that can be implemented together. The implementation agent can compose the working set itself, or the Orchestrator can assign one.

This is not a change in principle. It is only a change in degree. Context is still finite. I still want to give an implementation agent enough room to complete one piece of work in a consistent way, so I continue to give each run fresh context.

So far, I have never seen an implementation agent fail to complete an implementation, or produce an obviously wrong one, because its working set was too large. Instead, I feel frustrated when a working set is too small and the work takes too long. So I have started to think that tasks with sequential dependencies could be grouped together to reduce waiting time.

Conversation No Longer Waits for Implementation

In the Ralph Loop I used three months ago, an agent selected one task from PRD.md, implemented it, recorded its completion in PRD.md, and repeated this process in sequence. Now that one-shot runs can execute asynchronously, a human can continue discussing the system with a conversation agent and refine their understanding while an implementation agent is working. The results of those discussions can also be written into the PRD and SPEC immediately.

Independent Work Proceeds in Parallel

In addition to becoming asynchronous, the harness can execute several runs in parallel. Parallel execution can cause conflicts in three places: working directories, task ownership, and the integration branch. Worktrees separate the working directories. A claim on a task with a stable ID establishes task ownership. An integration lock makes sure that only one run integrates into the integration branch at a time. My current harness controls these three places separately. Safe parallel execution is not possible if any one of them is missing.

This is more than a simple increase in implementation speed. Together with asynchronous runs, it means that I can keep adding independent tasks as they become clear and start runs for them without waiting for work already in progress to finish.

Beyond Source Code

For most of my career as a software engineer, I treated source code as the most authoritative account of a system. I still believe that, at least in part. And yet, to be honest, I now understand almost nothing about the codebase.

Since I began leaving implementation to AI, I no longer know how its methods and classes are organized, or whether I have a comprehensive understanding of its error handling. Even the libraries it uses are only vaguely familiar to me. The SPEC is mostly there for AI, not for me, and I do not read unit tests at all. By the standards I used to have as an engineer, I would have said that I did not understand the system at all.

Even so, I can still keep the work moving. In practice, I form a hypothesis about the behavior I want and discuss it with agents. I then write it down, ask an agent to implement it, and judge the result against what I expected.

I do not know whether this means that I understand the system in a different way, or whether I have simply found a way to work without understanding it. That tension has made me wonder whether source code really is the central representation of a system.

Source code is still central to a system. But it may not be the place where all the information that shapes the system should live. I have begun to imagine that a system could instead have a central structure for this information, including its intent, constraints, and the reasons behind them.

Building and maintaining such a structure would be difficult. But AI could make it practical by serving as the interface for creating, updating, and reading it. It could then use the structure to generate human-readable documentation, a task ledger, agent context, and even source code.

Closing

Only three months. I did not expect my view of software development to change this much in that time. Three months ago, I wrote that improving the harness itself had become a software engineer’s job. Now services and agents are starting to take over even the work of building the harness.

Even so, context engineering will remain an important concern. The mechanisms for finding relevant context may mature, but deciding what information to give an agent will remain an open question.

This is only what I think as of August 2026. Many things in this article contradict what I wrote with confidence three months ago. The same may happen again three months from now. I am still surprised that I have come to think that source code might be merely one representation of a system. What a time to be alive!