Nice! It's a totally different world with AI tools. Seems like a good strategy to get previously non-technical folks in on it, especially for front end apps.
Yes, but did you try it? I think Codebuff is by far the easiest to use and may also be more effective in your large codebase than any other comparable tool (i.e. like Cursor composer, Aider, Cline. Not sure about Qodo) because it is better at finding the appropriate files.
Re: style guide. We encourage you to write up `knowledge.md` files which are included in every prompt. You can specify styles or other guidelines to follow in your codebase. One motivating example is we wrote in instructions of how to add an endpoint (edit these three files), and that made it do the right thing when asked to create an endpoint.
Sure! I git cloned some open source projects, and wrote a script (with Codebuff) to pick commits and individual diffs of files. For each of those, I had Claude write a sketch of what changed from the old file to the new.
This is all the data I need: the old file, the sketch of how Claude would update it, and the ground truth diff that should be produced. I compiled this into the ideal conversation where the assistant responds with the perfect patch, and that became the training set. I think I had on the order of ~300 of these conversations for the first run, and it worked pretty well.
I came up with more improvements too, like replacing all the variant placeholder comments like "// ... existing code ..." or "# ... (keep the rest of the function)" with one [[*REPLACE_WITH_EXISITNG_CODE*]] symbol, and that made it more accurate
Thanks for your reply! I started Codebuff without being aware of Aider. I actually have not yet tried Aider (though I plan to try it soon!).
It's totally true that a lot of the development of Codebuff is merely me (and Brandon) working through a lot of the problems that Aider already solved! That makes sense.
Partly, my thesis is that if you start after Sonnet 3.5 is out, that you design things differently. For example, I started without manual file selection and worked to make it more like an agent that has native access to your environment.
Needless to say, I'm a fan of the work Paul has done on Aider, and I've appreciated the benchmarks and guides he's created and shared publicly. And Cline is also an amazing project which I want to try out soon as well!
With respect to privacy, we have pledged not to store your codebase, and mainly store logs that we use to debug the application. When seeing users use Codebuff, I mean I literally watched them use it, as we've done many in-person user tests, plus the Manifold Team has been using Codebuff for a while.
We also intend to release a Privacy Mode, like Cursor has, where we will not store anything at all, not even the logs of your interactions!
It makes sense to be a bit skeptical of Codebuff, since we are so new, but I intend to not let our users down!
Sweet. Personally, I use both Cursor and Codebuff.
I open the terminal panel at the bottom of the Cursor window, start up `codebuff`, and voila, I have an upgraded version of Cursor Compose!
Depending on what exactly I'm implementing I rely more on codebuff or do more manual coding in Cursor. For manual coding, I mostly just use the tab autocomplete. That's their best feature IMO.
But codebuff is very useful for starting features out if I brain dump what I want and then go fix it up. Or, writing tests or scripts. Or refactoring. Or integrating a new api.
As codebuff has gotten better, I've found it useful in more cases. If I'm implementing a lot of web UI, I can nearly stop looking at the code altogether and just keep prompting it until it works.
Hopefully that gives you some idea of how you could use codebuff in your day-to-day development.
Codebuff is a bit simpler and requires less input from the user since you just chat and it does multi-file edits/runs commands. It's also more powerful since it pulls more files as context.
I think you just need to try it to see the difference. You can feel how much easier it is haha.
We don't store your codebase, and have a similar policy to Cursor, in that our server is mostly a thin wrapper that forwards requests to LLM providers.
The PearAI debacle is another story, but mostly they copied the open source project Continue.dev without giving proper attribution.
I think it would handle the giant file, but it would definitely pull the whole thing into context.
We are doing some tricks so it should be able to edit the file without rewriting it, but occasionally that fails and we fallback to rewriting it all, which may time out on such a file.
One is that I think it is simpler for the end user to not have to add their own keys. It allows them to start for free and is less friction overall.
Another reason is that it allows us to use whichever models we think are best. Right now we just use Anthropic and OpenAI, but we are in talks with another startup to use their rewriting model. Previously, we have used our own fine-tuned model for one step, and that would be hard to do with just API keys.
The last reason that might be unpopular is that keeping it closed source and not allowing you to bring your keys means we can charge more money. Charging money for your product is good because then we can invest more energy and effort to make it even better. This is actually beneficial to you, the end user, because we can invest in making the product good. Capitalism works, cheers.
Per your last question, I do advise you use git so that you can always revert to return to your old file state! Codebuff does have a native "undo" command as well.
I wrote a custom `applyPatch` function that tries to use the line numbers, but falls back to searching for the context lines to line up the +/- patched lines.
It actually got line number not too wrong, and so they might have been helpful. (I included the line numbers for the original file in context).
Ultimately though, this approach was still error prone enough that we recently switched away.
It sounds minor that it finds files for you, but if you try it out, you'll see that it's a giant leap in UX and the extra files help it generate better code because it has more examples from your codebase.
That's surprising to me, usually it works quite well at this. Did you start codebuff in the root of your project so that it can get context on your codebase?
