CodeVROOM is designed to do fast small edits to large projects with minimal prompting. It achieves this by combining the best of AI chats and AI agents into the concept of AI Editing Sessions. This page explains them in detail.

Overview

A session is a step-by-step process of doing a specific code edit with AI. It starts with a symbol (like a function/class) and brief instructions what AI should do.

Many simple sessions consist of just 1 step: you ask AI to change something, and it does it right away. More complex sessions can include different type of steps:

• Asking AI what other symbols are relevant to the request, and pulling them into the session
• Asking AI to expand brief instructions into longer form that can you can edit
• Manually adding more symbols to the context window
• Doing the actual edit
• Doing the follow-up edits

Sessions can be stepped back. E.g. if you don’t like the initial edit, you can go back and ask the AI to look at more symbols before trying it again. Or you can switch to a smarter model. Or amend your instructions, or let AI expand them. You can also retry the same step several times, pick the best option, and ask for follow-up edits based on it.

Sessions allow trying different options very quickly without tainting the context window with unsuccessful edits, and reduce the token usage, since only the relevant steps get included in the follow-up contexts.

Expanding Instructions

AI is surprisingly good at understanding very brief instructions, but not always. Let’s assume you want to add a method for calculating distance between 2 vectors to a class like this:

internal class MyVector
{
    public double X, Y;
}

Your prompt could be “add a Distance() method calculating the distance between two vectors”. Or you could just say “Distance()” and ask the model to expand it:In this example, the model first thought about calculating the distance between (0,0) and (X,Y), but suggested the correct variant as the second option.

With editing sessions, you can always start with the most brief prompt possible and see what the model does. If it doesn’t produce what you wanted, simply step back and refine your prompt, or switch into the planning mode and pick another alternative.

Pulling Context

Let’s look at a class representing a directory entry:

class ListEntry
{
    public EntryKind Kind { get; set; }
    public string Name { get; set; }
    public WrappedTimestamp Timestamp { get; set; }
}

You want to implement sorting: first show directories, then files. Otherwise, do a case-insensitive comparison.

You can do it with a rather brief prompt:

IComparable:
* folders first
* otherwise by insensitive name

The problem is, unless you include the definition of EntryKind, the model will hallucinate what it could be, and it won’t always match reality. On the other hand, preemptively including every single type referenced from ListEntry (like WrappedTimestamp) may not be very practical. So, CodeVROOM can ask the model what it deems relevant to this particular request, and pull it into the context window:Note that it is normally done automatically at the beginning of each session. You would only need to use the planning GUI if the model didn’t get it right from the first time:BTW, if you don’t like the models producing somewhat bulky and redundant code, it’s usually rather easy to tweak them. In this case, the “isDir != otherIsDir” prompt was sufficient to have the model introduce the temporary variables and eliminate the duplicate comparisons: And remember, if you don’t like the result, you can always step back, switch to another model, or just redo the same step multiple times, and pick the best one.