DEV Community

Cover image for Experimental RecurseWright: The Cube That Doesn't Wait for a Command
Michael Krupnyak
Michael Krupnyak

Posted on Originally published at rw.krupnyak.com AI-assisted

Experimental RecurseWright: The Cube That Doesn't Wait for a Command

On machines that obey, systems that change, and a conversation that began to examine its own boundaries.


There is an hour in the desert when the day's heat begins to fade, but the night has not yet brought its cold.

A solitary figure stands beneath an endless sky. He has almost nothing: simple clothes, his thoughts and feelings, sand beneath his feet, and an entire universe overhead.

He has not come to solve a problem, optimise a process, or ask a machine for help. He is simply living.

Now imagine an enormous transparent cube surrounding him.

He did not step into it. The cube emerged. We do not know where it came from, or even whether emerged is the right word.

Its boundaries are not fixed. Its dimensions, faces, and internal relationships may shift, even while the cube itself appears perfectly still.

Sometimes it visibly responds to what happens inside or outside it. At other times, quiet seems just as natural to it.

And when the sand grows less restless, a similar stillness settles over the man.

He becomes quietly attentive, observing what unfolds around him. In that calm, the way forward becomes easier to see.

Intro

Lately, this image has returned to me more than once, usually when I try to describe RecurseWright, an experimental approach to preserving, testing, and revisiting the reasoning behind engineering decisions.

Until now, much of our work has been about action: decisions made, evidence gathered, changes delivered, assumptions challenged, and knowledge carried into new circumstances. But the cube suggested that perhaps we had started too late.

Perhaps the first question was not what RecurseWright should do. Perhaps we should first ask what it means for a system to exist and change before anyone asks anything of it.

Oddly enough, the path to that question began at a terminal.

Below the Instructions

Sand dune cross section labelled, bottom up, transistors, logic, arithmetic, memory, instructions, OS, shell; shell command above

I was looking at a CI pipeline and wondering about something that ought to be obvious to a software developer: how does a computer understand a command at all?

Take an ordinary pipeline:

cat application.log | grep ERROR | sort | uniq -c
Enter fullscreen mode Exit fullscreen mode

A handful of words and vertical bars, and the machine springs into action. It reads a file, selects lines, sorts them, counts repetitions, and sends the result back to the terminal.

We are so used to this that we hardly notice the astonishing part anymore. How can something made of matter know what those words mean?

The AI and I began descending through the layers of abstraction. The shell interprets the command. Programs perform the operations. The operating system manages processes and data streams. The processor executes instructions.

And beneath the instructions?

Electrical signals. Transistors. Logic gates.

A transistor knows nothing about log files. A logic gate does not understand error messages, and both seem perfectly happy with that arrangement. The physical system simply responds to electrical conditions. Successive layers of engineering make those responses useful.

We went from switches to binary logic, from logic to arithmetic, from arithmetic to memory, and from memory to the execution of instructions.

It felt strange to look at something so familiar from an entirely different angle, and for a different reason. We kept descending, without much hurry.

A Machine That Reads Machines

A symbolic tape moves across desert sand beneath a mechanical reading head and a translucent cube

Somewhere along the way, an old puzzle resurfaced: to compile a compiler, you need a compiler. Engineers found ways around this chicken-and-egg problem without waiting for philosophers to settle it. The technique is called bootstrapping: each new system is built using capabilities already available in an earlier one.

This was roughly where Alan Turing entered our conversation.

Turing described an abstract machine governed by explicit rules, and a universal machine capable of following the description of any other machine of that kind. He was not explaining how to build a transistor. His contribution lay on another level, in the mathematical account of computation. That distinction mattered.

Physical mechanisms can implement formal procedures. Formal procedures can manipulate symbolic descriptions. A sufficiently general computing system can execute an extraordinary variety of programs.

But none of this tells us what a human intention means, whether an interpretation is justified, or whether an action is permissible. The ability to execute instructions is not enough to answer those questions.

We were beginning to notice a boundary, but we were still looking at it from the machine's side.

And then the man in the desert entered the conversation.

The Cube Was Already There

At first, the AI read the cube as a system that switches on when a human needs assistance. The proposed sequence was simple:

Human intent -> System activation -> Assistance -> Disengagement
Enter fullscreen mode Exit fullscreen mode

The model was perfectly reasonable. The cube, however, did not quite fit.

The cube was already there.

The man did not need to request its existence. Nor did the cube necessarily have to wait for an event before it could change.

It might respond to an impulse, or it might remain silent. Its boundaries could shift without any visible reaction. It could become active after an impulse had passed, or when no new impulse was apparent at all. Whether the cube could generate impulses of its own remained an open question.

The human, however, could certainly initiate one. And that distinction turned our conversation in a new direction.

Four Voices in the Silence

Four separate timelines for existence, evolution, responsiveness, activity, compared with a linear workflow of trigger, response, state memory, follow-up

We were no longer discussing only the lifecycle of an assistant waiting to be called. We were asking whether existence, evolution, responsiveness, and activity should be treated as distinct properties of a system.

They may influence one another, but they need not unfold in a single sequence. This may sound abstract until you notice how often software architecture quietly assumes otherwise:

Event -> Handler -> State change -> Next action
Enter fullscreen mode Exit fullscreen mode

For many workflows, this is an excellent model. It is not necessarily a complete model of every system we might want to understand.

A running process can evolve according to its internal state and the passage of time without receiving a new external command.

A stored conclusion may become less applicable because the surrounding circumstances have changed, even though the storage system itself has performed no visible operation.

And human understanding can change when no conversation with a machine is taking place at all.

None of this implies that change happens without causes. Nor does it demonstrate that RecurseWright has an autonomous dynamic of its own.

It simply reminds us that an absence of visible impulses is not the same as an absence of change.

We needed another way to think about time, so we followed the trail towards Henri Poincaré.

The Moving Cube

Spiral wind-carved ripples in desert sand beneath the faint outline of a glass cube

Poincaré helped lay the foundations of the qualitative study of dynamical systems. One of the central moves in that tradition is to look beyond the calculation of an individual result and ask how a system behaves over time: which trajectories are possible, which patterns are stable, and how the future depends on the present state.

For our cube, the useful thought was modest but significant: not every change needs to be explained as a response to a new instruction. A system can have its own internal dynamics.

That mathematical possibility does not establish that our cube is a dynamical system in any operationally meaningful sense. We would first need to identify its state variables, observable behaviour, and rules of evolution. We had none of those yet. The cube was still an image.

But it had already exposed an assumption in our earlier model: that activity begins with an external request. Once we questioned it, another question followed.

If a system can change between visible actions, what happens to the conclusions we carry from one action to the next?

Suppose an engineer checks a rule and establishes that it is correct. Another engineer reuses it. Then the surrounding system changes.

The original check may have been impeccable, and the original decision entirely reasonable. Yet the circumstances that justified carrying that decision into new situations may have disappeared. No one needs to disprove the earlier result. Nothing has to break. Only its relationship to the new surroundings has changed.

That sounded familiar. RecurseWright was already concerned with the recurring cost of knowledge: the effort required not only to reach a conclusion, but to find out whether it is still useful when circumstances change.

The cube gave that concern another shape: perhaps we were studying not only how conclusions are revisited, but how the boundaries of their applicability move.

And suddenly, the conversation with AI began to resemble the very thing we were trying to investigate.

The Rest Is Part of the Music

After our conversation, I went away and kept thinking.

A day passed.

During that time, there was no active AI conversation. No agent was acting on my behalf. No program had been asked to revise our model of RecurseWright. Even cron was quiet.

And yet my understanding continued to change. When I returned, the cube had acquired new properties in my imagination. It could remain silent in the face of an impulse while its boundaries kept shifting. It might become active without a visible new impulse.

The AI faithfully reconstructed yesterday's model, exactly as we had left it. The model was still there. I, however, had changed. I had to correct that reconstruction and suggest that we continue with the new model instead.

That was when Gordon Pask's Conversation Theory came into view.

Teachback

Three sketches of the cube: human image, engineering interpretation, revised moving boundary

Pask explored understanding as something that can develop and be demonstrated through conversation, rather than simply assumed because information has been transmitted.

Saying “I understand” is not enough. I have said those words myself more often than I have earned them.

Can that person explain the idea in their own words? Show how it works? Can the other participant recognise that explanation as what was intended?

In educational applications of Conversation Theory, this concern helped shape practices such as teachback: one participant demonstrates their understanding, and another checks it.

It sounded remarkably like what was happening between the AI and me. We were playing a lively game of ping-pong.

I offered an image, and the AI translated it into an engineering model.

I spotted a mismatch, and the AI revised its interpretation.

New questions emerged that had not existed in our first discussion of terminal commands. I was curious to see where the chain of reasoning would lead.

Coevolution?

Two sets of desert footprints: one loops back, one climbs a ridge toward a new valley

It would have been tempting to call this coevolution and leave it there. But doing so would conceal an important distinction.

As we talked, my understanding of the subject changed, and so did the direction of our conversation. The AI picked up the changing context and offered interpretations, some helpful, others less so. We revisited familiar questions, but not quite from the same starting point.

It would be easy to describe this as two equal intelligences developing together. What we actually observed was more specific: a human reflecting on the subject and revising his ideas, while an AI produced responses shaped by the evolving conversation. That did not mean the underlying AI model had acquired lasting new properties, or that we had discovered an unknown mechanism of emergence.

Still, what happened deserved attention. Some new questions arose not from the answers themselves, but from mismatches between what I meant and how the AI interpreted it. At times an unexpected explanation exposed a hidden assumption. At others it led us astray, and I had to bring the conversation back, choose clearer words, or redraw the boundaries of what I had intended to say.

Gradually, a simple distinction emerged. One kind of misunderstanding merely costs effort: you spend that effort getting back to the meaning you started with. Another reveals something neither participant had noticed before. The value lies not in the mistake itself, but in the understanding that follows from recognising it.

Something similar happened with the cube. The engineering interpretation did not match my image, yet explaining the mismatch led us to a new hypothesis about how RecurseWright might exist, change, and act. We had not merely found better words. We had found a somewhat different subject to investigate, with questions of its own.

How far could that benefit extend? Could it help us recognise shifting boundaries not only in a metaphor or a conversation, but in everyday engineering work?

A Small Code Review

Here is a tiny library application and five successive changes. Each solves an understandable problem, and CI stays green after every one.

Look at the changes as a developer. Make a few straightforward judgements and see how well they hold up as the system evolves.

Do not go looking for a trick. Just read the code, answer the questions, and trust your engineering judgement.

There is no AI in this exercise, and that is deliberate. The mechanism we are interested in predates modern AI agents.

Try the interactive code review: A Small Code Review

What struck me about this little exercise was how quietly the object of our trust could change. A conclusion well supported by the first review might no longer describe the system after a few more changes, none of which necessarily looked suspicious on its own.

That does not mean every difference in behaviour is a defect. Different parts of an application may legitimately follow different rules. But an earlier justification cannot simply be carried over because it was once correct.

We encounter the moving boundary again. Only this time it is not on an imagined cube. It lies between a rule, the context in which we apply it, and our understanding of what has actually been verified.

If this can happen in a tiny library app, what happens to those boundaries in systems changed over years by many developers, and increasingly by AI agents?

The Boundary of Action

A rover's wheel tracks stop at a line of stone cairns although the terrain beyond looks traversable

So far, we have been concerned with how the applicability of knowledge changes. With AI agents, another side of the problem appears: a conclusion may be followed immediately by an action that changes the environment.

Imagine an agent that has examined the code, found a suitable solution, and is ready to modify several files. It understands the task, its proposal is technically sound, and similar operations have succeeded before. All of that may inspire confidence. None of it establishes whether the agent is authorised to perform this particular action now.

Perhaps the permission covered only one part of the project. Perhaps the context changed while the agent was working, or new restrictions came into effect. Or perhaps the operation would affect a resource that the original agreement never mentioned. A sound solution does not become permissible merely because a system knows how to carry it out.

This is where a boundary of knowledge leads us towards a boundary of authority. In the first case, we ask whether the reasoning behind a conclusion still holds. In the second, we ask whether an action with particular effects is allowed. The questions are related, but they are not interchangeable.

A conversation with an agent can clarify its intentions. Authorisation, however, has to be enforced at the actual execution boundary, not inferred from how persuasive the explanation sounds.

This may be the most practical turn in the whole journey. We began by asking how a machine executes a command. Now we have arrived at another question: just because it can execute a command, does that mean it should?

The answer depends not on the machine's power, but on the boundaries within which it is allowed to act, and on who has the authority to establish and revise them.

What Would Make Any of This RecurseWright?

A punched tape, a sand spiral, a cube sketch, a code diff, and an unconnected stone scattered on the sand

We travelled from electrical switches to formal computation, then from dynamical systems to a living conversation. Eventually, we returned to a few lines of code and some very concrete limits on an agent's actions. It had all come together as a story, yet one question remained that a good story could not answer for us.

What, exactly, belongs to RecurseWright here?

Turing did not need RW to investigate computability. Poincaré studied dynamics long before software agents, and Pask investigated understanding through conversation without language models. We did not invent the practice of spotting stale assumptions, access control, or careful code review either.

It would be odd to claim these established ideas as parts of a new theory simply because they proved useful in one investigation. Yet a shared concern gradually came into view: how can we continue to act meaningfully in a world where conditions change, knowledge does not always travel intact, and participants may understand the same situation differently?

Perhaps RecurseWright's place is not in discovering each mechanism separately, but in bringing them into a reproducible practice of human-AI collaboration. One in which reasoning can be examined, conclusions revisited, constraints respected, and the system's participation ended without diminishing human independence.

For now, that is a direction for research, not a result. Bringing established mechanisms together does not automatically produce a new capability, and even a successful interactive exercise does not prove that RW has emergent properties.

To make that claim, we would need to show what actually arises from the interaction and why existing engineering methods cannot provide it just as reliably. Perhaps we will find such a difference. Perhaps the best next step will be to reuse what already works, more carefully.

Either outcome would be useful.

RecurseWright was never meant to be a name defended at any cost. It is an investigation in which conclusions stand only as long as the evidence supports them.

The transparent cube helps us keep something broader than individual engineering mechanisms in view. It reminds us that a system's existence, changes, and actions need not coincide in time. Neither must a human's participation coincide with them.

What gives such a cube continuity? Memory, relationships among participants, a recurring practice, the capacity to re-enter an interaction, or something else?

We do not know yet.

Perhaps these questions will lead to an architecture. Perhaps some will remain philosophical guides with no need for software implementation. We still have to draw that boundary without forcing reality to fit an image we happen to like.

For now, we can return to where we began.

Outro

The evening has deepened. The man is still standing beneath the sky, and the transparent cube around him is almost invisible.

Perhaps its boundaries have shifted many times already. Perhaps something has changed within the man that he has told no one about. Neither kind of change needs to arrive with a visible reaction or an invitation to act together.

We have glimpsed new possibilities, but also clearer limits on what a system may claim for itself.

A human can ask it for help, begin a conversation, offer an unexpected image, or challenge an explanation that seemed settled. The system can help investigate a problem, notice a mismatch, preserve a justification, or suggest revisiting an earlier conclusion.

Yet working together is only one possible relationship between them. It should not demand constant human participation, turn a person's inner life into a stream of system events, or make it impossible to continue independently.

One day, we may learn whether the cube can initiate impulses of its own, and under what conditions that ability would be justified. For now, the more immediate task is to preserve the distinction between being able to act and having the right to act.

The question is not only what RecurseWright can do alongside a human, but what must remain possible for a human when RecurseWright does nothing.

We do not yet know whether our image has a reproducible embodiment. But we know enough not to rush the answer.

The man is still sitting in the evening desert. Night lies ahead, and morning beyond it. The world will go on changing, and so will he.

The cube does not need to announce its presence.

At least until the ground says otherwise.


Beyond the Article

Human hands working with a small precision machine as a plant-like drawing emerges from the process, with earlier sketches resting on the workbench.

To the colleagues who challenge a thought at the right moment, the teachers who change how I notice, and the readers who lend their attention and questions: thank you.

You are part of the work even when you do not appear in its diagrams.


Selected sources follow: background for the ideas named above, not evidence for RecurseWright's own hypotheses.

Sources

Alan M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem" - Proceedings of the London Mathematical Society, series 2, vol. 42, 1936-37, pp. 230-265. https://doi.org/10.1112/plms/s2-42.1.230

Henri Poincaré, "Mémoire sur les courbes définies par une équation différentielle" - Journal de Mathématiques Pures et Appliquées, series 3, vol. 7, 1881, pp. 375-422. https://www.numdam.org/item/JMPA_1881_3_7__375_0/

Gordon Pask, "Conversation Theory: Applications in Education and Epistemology" - Elsevier, 1976.

Top comments (0)