Ideas for the next version of Codev (codename 'Bauhaus') and beyond?

[waleedkadous]

Hey folks,

Here are my initial ideas for the next version of Codev. Do let me know your thoughts!

Bauhaus

codev CLI command

I think we might need a separate command for codev itself, distinct from agent-farm. Agent farm is pretty tightly locked to the directory it's running in (E.g. if I spawn a builder I read the builder.md file from the current codev/ dir). And there's already codev-doctor. I am thinking npx @cluesmith/codev install to install the codev tools.

Stateful consultation

My favorite command in agent-farm is send. af send architect "OK, I'm ready for you to review the PR" literally sends a message using tmux send-keys to the architect terminal.

What if we can use that power for now for gemini and codex? Right now, gemini and codex are stateless: we run them using the consult command line tool, that finishes and the next time we do that again.

What if instead we had gemini and codex each running in their own terminal and the way we do consults is by sending strings to the terminal and gathering the result? That would probably be considerably faster since they'll have launched and have the context already loaded.

Window management?

I am not sure about this one. Right now we have a very rigid window management system: Architect always on the right takes haf the screen, builders, annotators, shells on the left. I kind of like it but others might not.

Longer term

Solid foundation?

Right now, the system feels like it's made of rubber bands and duct tape: we glued together ttyd, tmux, our own custom html generation, git, gh, gemini, codex etc to form a useful tool. It's a bit hacky to have things like: each terminal gets its own port. On the other hand it's extremely flexible. Thoughts?

Sandboxing

Currently the agents run in --dangerously-skip-permissions and --yolo etc mode to allow them to move autonomously.