Giving AI agents ways of verifying their work on their own,
like automated tests or browser access, is very
useful. You can kind of take that to the
extreme by building a loop where you
essentially don't interact with Claude code at all
anymore, and that pattern is also known
as the Rolf loop. It's named after
Ralf Wiggum, the character from The Simpsons, for its
naive persistence. The ultimate idea behind that Rolf loop
is pretty simple. You create a shell script, and you find
this updated starting project, including the shell script attached,
you wanna try it. And that shell script, in the end, sets
up a loop, a loop that goes through a maximum amount of
iterations specified by you, and that maximum amount of
iterations is simply an input that's expected to ensure
that the loop doesn't keep on running forever, but that it has some
exit condition. But whilst the loop is running,
Claude code is invoked over and over
again, with all permissions allowed, and therefore, you
should configure it to run in sandbox mode.
More on that in a second. And we're not running Claude code
in the interactive mode in which we used it throughout the course,
instead with the -p flag, we can pass in a prompt
directly. And the prompt we do pass in is this one here, where we
point at some files, which I'll show you in a second,
ask Claude code to pick a task from a list of
tasks where passes is set to false, and you'll
see that list in a second, and where we then want it to tackle that
task and also verify its changes by
running tests and by also visiting the
website by using the Playwright MCP, so by testing
those changes in the browser, as you saw over the last
lectures. Now, that list of tasks is simply a JSON
document with a bunch of tasks, and the format is totally up to you.
This will be handled by an AI, so there is no fixed format.
This is just one convention you often see, that you have a
description of the task, some steps that make up the task, and a
passes flag, which initially is set to false for all
tasks. And the idea is that the agent changes it to true
task by task once it worked through the tasks.
The idea is also that the agent doesn't have to go in
chooses on its own the next task it should
tackle. Now, this task list in my case here was derived
from this spec document, which I created early on in this
course, and I used AI for deriving this list of
tasks here. And you can, of course, define any tasks you want and be
as granular as you want. You should try to not be too
granular or too general, though. The tasks
should typically be focusing on one main problem
each. But then the idea is really just that you
keep Claude code running on its own, task by task,
and that it verifies its work on its own with tests, with browser
access, and you as a human don't do anything.
You keep Claude working and you come back once it's done to
verify the overall result. That's the idea.
Now, important, you have to grant Claude code
broad permissions, because otherwise it would need your
example, edit a file or to send an HTTP request, and the
idea is that it can go on its own. So since that's the case, you
must make sure that you get this sandbox mode
enabled. You could also try running Docker
Sandbox here, run Claude with Docker Sandbox,
earlier, but I consistently ran into various
there when it, for example, came to Claude code trying to use the
browser, which is why I'm using this built-in
instead. This is a very important setting for this
loop. You don't wanna grant it broad permissions
It could delete your hard drive. Just as before,
you also still use other features like agents or
skills or a Claude MD file with
instructions because you're still using Claude code, just in
that autopilot mode. Well, and then the idea simply is that you
invoke this Rolf shell script here, and you give it a
maximum number of iterations, like 10 or whatever, and then it
starts. It takes a look at this prd.json file,
task, and goes to work. And it'll report back whenever
it finished a task, and it will progress through
task, and let you know once it's done overall,
max number of iterations expired here, of course.
If you wanna see what it's doing, you can always, by the way,
run a new Claude session in a separate terminal window.
Obviously, you must keep this one here open
claude -c to continue the last session that was started, which
should be the session started by the Rolf loop, and then you can see
what it's doing. So here, for example, it's writing a database initialization
script now. Now, this is not live updating though.
You'll have to run it again to see the latest state, and you could also
interfere here, but that, of course, is not really the idea of
the Rolf loop. Now, I did actually let
Rolf work on that same project we built manually throughout the
course, or manually with AI, I guess, and the
result looks different from what we built in this course.
But I have a working application where I
can sign up and log in and create
notes,
which supports rich text editing, public
sharing, saving, viewing, viewing
publicly-shared notes.And also
deleting, including this confirmation dialogue.
And all that was built automatically by that Rolf loop,
I did not interfere at any time. In that project I shared
with you, here it, for example, finished the first task now.
So, the question therefore is should you only use the Rolf
loop from now on? And I'd say it depends.
It can definitely yield good results, like the application I built you.
It's not a super complex app, of course, but it works and
it works because Cloud code was able to test the
changes on its own with the playwright MCP, with automated
tests, and that feedback loop is important.
So especially for prototyping or building utility software or
internal tools, it can be amazing.
You can just offload work to it and then work on something else.
Obviously, you'll need to plan ahead though,
document. You need to derive those tasks, you should take a look
at them and not just blindly trust what AI generated here for
you. So it does have some upfront cost or some
upfront effort, but it can then, of course, do its job and
you can work on something else. It can, however, potentially
cost a lot of tokens because since the AI does
work on its own and since it does need to verify everything by running tests,
by generating all these browser usage commands, which all cost a
lot of tokens, you do spend a lot of tokens, and that
aware of. So you can burn through your tokens in
Cloud code subscription quite quickly.
And there's a trade-off, of course.
When using this autonomous loop, you have less
control. You only see what it's doing when you
check in from time to time or when you run the application from time to
time. Whilst it's working, you have no insight into what's
happening. You don't use plan mode and see what it plans to
do, you don't have that live stream of what it's
doing. And of course, if you come back and decide that something doesn't work
or look the way you want it to look, well then a lot of tokens were
spent for nothing. But of course, on the other hand,
other work and you can of course work on multiple projects in parallel by
having multiple such loops running in parallel.
It's also worth noting though that AI code quality will
vary. A working application is not the same as a
production-ready application. The code generated can have bugs,
including serious performance or security bugs.
You always must verify and review that code
before you push it to production, especially if it's public
and/or you're charging money for it.
Don't blindly trust it. Don't fall into the vibe coding
trap. And AI can also get stuck. I had it more
than once that the Rolf loop would simply get stuck and
I had to restart it manually or I had to help
it get unstuck in other ways by installing an extra
dependency. That might not happen for you, that might not happen with
future versions of Cloud code. It definitely did happen from time to
time for me though, and therefore the Rolf loop can
be useful. It does not replace you as a
developer evaluating the results though and steering the AI
into the right direction. You must create a good
plan. You must derive good tasks. You must
have a solid project setup where tests are enabled,
where you give the AI just the right skills and so on.
So there is some upfront work involved which you have to go
through in order to get good results.
But then, the Rolf loop can be useful, especially as mentioned
in my case for prototyping or simple products.