jahooma

Current AI's could never have such deep thoughts haha

I wrote every word! Though I did have some suggestions from Opus haha

Hi, just wrote up some reflections & strategy on this moment as a codegen startup founder.

Let me know if you have any questions!

Yup, it's just what we wanted for our coding agent. Codebuff can enter a "Deep thinking" mode and we can tell it to burn a lot of tokens hahaha.

I would try this if it had Android support! Is that planned?

Also curious which integrations people use the most. If it's email, why not just build an email app?

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.

I'm just saying what users of Codebuff have said about us compared to competitors.

You should try Codebuff and see for yourself how it reads files! It's not simply a tool call. We put a lot of work into it.

Here's my application: https://manicode.notion.site/Manicode-YC-application-c52f592...

I listed: Cursor, Devin, Codium, Augment, Greptile, Lovable.dev, Aider.chat, mentat.ai, devlo.ai, etc

So I did mention Aider. I was definitely aware that it existed, I just hadn't used it.

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

https://i.giphy.com/media/v1.Y2lkPTc5MGI3NjExbDExYmM5Y3N0eHJ...

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.

Thank you for the very kind comment!

Good question! There's a couple reasons.

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?

Ah yeah, that's what I mean! I thought RAG is synonymous with this vector search approach.

Either way, we do the search step a little different and it works well.

Yup, there's a tradeoff in $$$, but for a lot of people it should be worth it, since Codebuff can find more relevant files with example code that will make the output higher quality.

I have heard good things about Cline! I'm curious to learn more. I need to try it out myself.

I see Codebuff as a premium version of Cline, assuming that we are in fact more expensive. We do a lot of work to find more relevant files to include in context.

That's a really great point. Since we manage the context, we should clear the old files if it's been > 5 minutes. Thanks for the idea!

Codebuff is the easiest to use of all these, because you just chat, and it finds all the right files to edit. There's no clicking and you don't have to confirm edits.

It is also a true agent. It can run terminal commands to aid the request. For one request it could: 1. Write a unit test 2. Run the test 3. Edit code to fix the error 4. Run it again and see it pass

If you try out Codebuff, I think you'll see why it's unique!

Amazing, good to hear! What were the minor glitches you encountered? Would love to fix them up.

Ah, but in Cursor you (mostly) have to manually choose files to edit and then approve all the changes.

With Codebuff, you just chat from the terminal. After trying it, I think you might not want to go back to Cursor haha.

I think managing context is the most important aspect of today's coding agents. We pick only files we think would be relevant to the user request and add those. We generally pull more files than Cursor, which I think is an advantage.

However, we also try to leverage prompt-caching as much as possible to lower costs and improve latency.

So we basically only add files over time. Once context gets too large, it will purge them all and start again.

We might! You could also set up your project within a docker container pretty simply (Codebuff would be great at setting that up :P).

We always reset the directory back to the project directory on each command, so that helps.

But we're open to adding more restrictions so that it can't for example run `cd /usr && rm -rf .`