Debugger

Overview

Members

debug

First, we add some context to the project’s current_task telling it it’s entering a debugging step, and opens a new conversation branch.

The prompt (debug.prompt) it’s using does some clever templating to make it fairly generic — if it’s debugging a problem or a specific command. It gets passed a function definition with a JSON schema similar to the output of implement_task, where it produces a series of steps where either a command is run, a file is modified, or the user is asked to intervene.

We then enter a while: True loop where we run our new steps against execute_task.

Reaching project members

I’ve been in DI land for so long, I’ve forgotten the simplicity of dropping a container object reference into the child of said container. To get from the debugger to the developer to run execute_task for example, it runs self.agent.project.developer.execute_task.

Simple and effective for the application’s scope. Feels cozy somehow.

There’s a case it checks where if the result of execute_task includes an entry for step_index, which I assume indicates the failed step. It then takes the completed steps, next steps, and reprompts it to regenerate the list of steps altogether and begins the loop again.

Change in prompts

Interesting to note here it doesn’t reuse the original debugging prompt, but the prompt implement_task uses to initially break down the task.

If successful, we update our message in the conversation and return.