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

An AI editing session is like an AI chat with rigid structure that allows some usability enhancements.

The main difference is about steps. In a classical AI chat, you would ask a model to edit code, then ask for amendments, then ask some more, etc. Each subsequent message would add up to the context window, geometrically increasing the token usage. CodeVROOM sessions can be stepped back and forth. If you don’t like the model reply, you can step back, slightly tweak your last message, and re-run it. Or switch to a smarter-but-slower model, and let it redo the same step. Or ask the faster model 5 times and pick the best reply. You can also be linear like with the regular chats, but you don’t have to.

The second difference is special out-of-band steps. CodeVROOM can ask the model to take brief editing instructions and expand them into something less ambiguous. It can also take the code with instructions, and ask which additional code is needed to complete them. These steps run in separate temporary conversations and do not pollute the main context window.

In most of the cases, the special steps run completely under the hood, without needing any special steps from the user. But if you are not happy with what the model produced, you can always step back and edit how it understood your request, and what code it deemed relevant.

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.