I don't think you're missing anything.

Aider tends to maintain near "state of the art" including e.g. treesitter, and an actually refined (as in, iterated improvements over time) user experience.

Aider has been refining for 8000 commits since May of 2023. Codebuff "all started" circa Claude Sonnet 3.5.

The story of discovery (e.g. git patch) at best feels like a lack of researching the landscape since leaderboards for SOTA indicate whether a model performs better as whole code or diffs and Anthropic even cites Aider benchmarks, but cynically, the narrative feels a bit like looking through the things Aider has been doing differently/better, and putting them in an origin story so the feature list might sound less like the “sincerest form of flattery.”

Particularly concerning is the story talking about "seeing" users coding loops. Perhaps this is a figure of speech. As designed, Codebuff are in the middle of all users' code slinging, so perhaps it isn't.

Checking the Privacy Policy shows it's only about cookies and tracking, not about information privacy or IP protection of any kind.

Checking the Terms of Service says they own any code you post through it and can give it to others:

"However, by posting Content using Service you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through Service. You agree that this license includes the right for us to make your Content available to other users of Service."

Meaning, the TOS is a for a public social media type service, not for an intellectual property service.

(Note that in VSCode "cline" can give Aider a run for its money.)

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.

I did find codebuff a lot easier to install and get started with...usability can make or break a project. Just as a user, I think it's nice to have multiple projects doing the same thing -- exploring more of the solution space.

(I've just played a little bit with aider and codebuff. I've previously tried aider and it always errored out on my code base, but inspired by this comment I tried again, and now it works well.)

Beyond what James highlighted, I personally really like how simple Codebuff is. CLI tools tend to go a bit overboard with options and configurations imo, which is ok if you're just setting them up once or twice. But for a tool I want to rely upon every day for my work, I want them to be as simple as possible, but no simpler.

Have you used Aider extensively? How are you finding it for your coding needs vs IDE-based chats?

I hear you. This is actually a foundational idea for Codebuff. I made it to work within the large-ish codebase of my previous startup, Manifold Markets.

I want the demos to be of real work, but somehow they never seem as cool unless it's a neat front end toy example.

Here is the demo video I sent in my application to YC, which shows it doing real stuff: https://www.loom.com/share/fd4bced4eff94095a09c6a19b7f7f45c?...

Watching the demo it seems like it would be more effective to learn the skills you need rather than using this for a decade.

It takes 5+ seconds just to change one field to dark mode, I don't even want to imaigne a situation where I have two fields and I want to explain that I need to change this field and not that field.

I'm not sure who is the target audience for this, people who want to be programmers without learning programming ?

Every experience I have had with LLMs generating code. LLMs tend to follow the prompt much too closely and produce large amounts of convoluted code that in the end prove not only unnecessary but quite toxic.

Where LLMs shine is in being a personal Stack Overflow: asking a question and having a personalized, specific answer immediately, that uses one's data.

But solving actual, real problems still seem out of reach. And letting them touch my files sound crazy.

(And yes, ok, maybe I just suck at prompting. But I would need detailed examples to be convinced this approach can work.)

> Do you have any example PRs on larger more complex projects that have been written with codebuff and how much of that was human interactive?

We have a lot of code in production which are AI written. The important thing is that you need to consciously make a module or project AI-ready. This means that things like modularity and smaller files are even more important than they usually are.

I can't share those PRs, but projects on my profile page are almost entirely AI written (except the https://bashojs.org/ link). Some of them might meet your definition of niche based on the example you provided.

Kind of like "please describe the solution and I will write code to do it". That's not how programming works. Writing code and testing it against expectations to get to the solution, that's programming.

> ex: new tiptap extension that can do notebook code eval

Claude wrote me a prosemirror extension doing a bunch of stuff that I couldn’t figure out how to do myself. It was very convenient.

+1; Ideally I want a tool I don't have to specify the context for. If I can point it via config files at my medium-sized codebase once (~2000 py files; 300k LOC according to `cloc`) then it starts to get actually usable.

Cursor Composer doesn't handle that and seems geared towards a small handful of handpicked files.

Would codebuff be able to handle a proper sized codebase? Or do the models fundamentally not handle that much context?

It's pretty good for complex projects imo because codebuff can understand the structure of your codebase and which files to change to implement changes. It still struggles when there isn't good documentation, but it has helped me finish a number of projects

Absolutely! Imaging setting a bunch of css styles through a long winded AI conversation, when you could have an IDE to do it in a few seconds. I don't need that.

The long tail of niche engineering problems is the time consuming bit now. That's not being solved at all, IMHO.

Great question – we struggled for a long time to put our demo together precisely for this reason. Codebuff is so useful in a practical setting, but we can't bore the audience with a ton of background on a codebase when we do demos, so we have to pick a toy project. Maybe in the future, we could start our demo with a half-built project?

Hopefully the demo on our homepage shows a little bit more of your day-to-day workflows than other codegen tools show, but we're all ears on ways to improve this!

To give a concrete example of usefulness, I was implementing a referrals feature in Drizzle a few weeks ago, and Codebuff was able to build out the cli app, frontend, backend, and set up db schema (under my supervision, of course!) because of its deep understanding of our codebase. Building the feature properly requires knowing how our systems intersect with one another and the right abstraction at each point. I was able to bounce back and forth with it to build this out. It felt akin to working with a great junior engineer, tbh!

EDIT: another user shared their use cases here! https://news.ycombinator.com/item?id=42079914

The main issue is the models you need to do the job are too big for most consumers, even people with nice video cards. You'll need a couple L40S GPUs at minimum. Maybe a few H100s more realistically.

So do you want to buy tens of thousands of dollars in GPUs or do you want to rent them second-by-second? Most people will choose the latter. I understand you don't trust the infrastructure and that's reasonable. If self-hosting was viable it would be more popular.

Haha yes, here's the story of why we rebranded: https://manifold.markets/JamesGrugett/what-will-we-rename-ma...

Thanks for sharing! haxton was asking about practical use cases, I'll link them here!

Yes, this is a good point. I think not asking to run commands is maybe the most controversial choice we've made so far.

The reason we don't ask for human review is simply: we've found that it works fine to not ask.

We've had a few hundred users so far and usually people are skeptical of this at first, but as they use it they find that they don't want it to ask for every command. It enables cool use cases where Codebuff and iterate by running tests, seeing the error, attempting a fix, and running them again.

If you use source control like git, I also think that it's very hard for things to go wrong. Even if it ran rm -rf from your project directory, you should be able to undo that.

But here's the other thing: it won't do that. Claude is trained to be careful about this stuff and we've further prompted it to be careful.

I think not asking to run commands is the future of coding agents, so I hope you will at least entertain this idea. It's ok if you don't want to trust it, we're not asking you to do anything you are uncomfortable with.

It's strange that all the closed models whose mentioned reasons for being closed is safety is allowing this, and banning the apps which allows for erotic roleplay all the time. Roleplay is significantly less dangerous than full shell control.

You are really missing out: https://github.com/e2b-dev/e2b

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.

None of them are owned by the creator of Codebuff. Why not create something to replace or be at the same level as those? Also, who is "we"? I don't use or like none of these.

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!

one size does not fit them all, and such tools are quite straightforward to develop. I even created one myself: https://npmjs.com/genaicode, I started with CLI tool, but eventually learned that such UX is not good (even interactive CLI), and I created a web UI.

where the problems start: cost of inference vs quality, latency, multi modality (vision + imagen), ai service provider issues (morning hours in US time zones = poor quality results)

the best part is being able to adjust it to my work style

We also have ed, the standard Unix text editor.

A tool like this is probably a great way to get some VC money.

first time?

Cool, it's probably about the same, since we're both using the new Sonnet 3.5 for coding.

We might have a bit of an advantage because we pull more files as context so the edit can be more in the style of your existing code.

One downside to use pulling more context is we burn more tokens. That's partly why we have to charge $99 whereas cursor is $20 per month.

Ah, good catch. We (read: I) introduced a bug that gave customers $500 worth of credits in a month as opposed to the $100 they paid for, and this user saw that and took advantage. Needless to say, we fixed the issue and added more copy to show to users when they _do_ exceed their thresholds. We haven't had that issue since. And of course, we ate the cost because it was our (expensive!) mistake.

The user had spent the entire weekend developing the app, and admitted that he would have been more careful to manage his Codebuff usage had it not been for this bug.

We're open to adding hard limits to accounts, so you're never charged beyond the credits you paid for. We just wanted to make sure people could pay a bit more to get to a good stopping point once they passed their limits.

Thanks! Yup, so long as you don't have key bindings for meta-x and meta-c, you ought to be good in the terminal. We honor any repository's .gitignore and won't touch those files. We don't even let Codebuff know they exist, which has caused some issues with hallucinations in the past.

Making sure that our word is trustworthy to the broader world at large is going to be a big challenge for us. Do you have any ideas for what we can do? We're starting to think about open source, but we aren't quite ready for that yet.

Thanks for being one of our early users and dealing with our bugs! I love that we can fit into so many developers' workflows and support them where _they are_, as opposed to forcing them to use us for everything.

Thanks for being an early user and supporter! You've helped us catch so many issues that have helped us get the product to where it is today!

Codebuff works on a local directory level, so it technically doesn't have to be a monorepo (though full disclaimer: our codebase is a monorepo and that's where we use it most). Most important thing is to make sure you have the projects in the same root directory so you can access them together. I've used it in a setup with two different repos in the same folder. That said, it might warn you that there's not .git folder at the root level when this happens.

This does seem to be suited to monorepo.

Haha, it's because I used to work on Manifold Markets!

Codebuff was originally called Manicode. We just renamed it this week actually.

There was meant to be a universe of "Mani" products. My other cofounder made Manifund, and there's a conference we made called Manifest!

Cause they wrote codebuff using codebuff.

They came out of Manifold. Though I acknowledge that doesn't really answer your question.

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.

Hah no, you're not alone! Candidly, this is one of the top complaints from users. We're doing a lot of prompt engineering to be safe, but we can definitely do more. But the ones who take the leap of faith have found that it speeds up their workflows tremendously. Codebuff installs the right packages, sets up environments correctly, runs their scripts, etc. It feels magical because you can stay at a high level and focus on the real problems you're trying to solve.

If you're nervous about this, I'd suggest throwing Codebuff in a Docker container or even a separate instance with just your codebase.

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.

Thanks for using Codebuff! Yeah, these edit issues are annoying, but I'm confident we can reduce the error rate a lot in the coming weeks.

We thought about making a VSCode extension/fork like everyone else, but decided that the future is coding agents that do most of the work for you.

The terminal is actually a great interface because it is so simple. It keeps the product focused to not have complex UI options. But also, we rarely thought we needed any options. It's enough to let the user say what they want in chat.

You can't point to specific lines, but Codebuff is really good at finding the right spot.

I actually still use Cursor to edit individual files because I feel it is better when you are manually coding and want to change just one thing there.

We do plan to do the SWE bench. It's mostly the new Sonnet 3.5 under the hood making the edits, so it should do about as well as Anthropic's benchmark for that, which is really high, 49%: https://www.anthropic.com/news/3-5-models-and-computer-use

Fun fact is that the new Sonnet was given two tools to do code edits and run terminal commands to reach this high score. That's pretty much what Codebuff does.

Amazing, glad it worked well for you! I main VSCode but tried Zed in my demo video and loved the smoothness of it.

Totally understand where you're coming from, I personally use it in a terminal tab (amongst many) in any IDE I'm using. But I've been surprised to see how different many developers' workflows are from one another. Some people use it in a dedicated terminal window, others have a vim-based setup, etc.

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! That's awesome to hear – if you wouldn't mind me asking, what was the context and tech stack of your side project? We love hearing about the wide variety of use cases people have found for Codebuff!

Thank you for the very kind comment!

Tongue-in-cheek! No idea what you're talking about. But I appreciate the kind words :)

Ultimately, I think a future where the limit to good software is good ideas and agency to realize them, as opposed to engineering black boxes, mucking with mysterious runtime errors, holy wars on coding styles, etc. is where all the builders in this space are striving towards. We just want to see that happen sooner than later!

Are you an adept sysadmin, cloud architect, and/or data engineer?

It’s a weird catch-22 giving praise like that to LLMs.

If you are, then you might be able to intuit and fill in the gaps left my the LLM and not even know it.

And if you’re not, then how could you judge?

Not really much to do with that you were saying, really, just a thought I had.

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 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?

Great question!

In Codebuff you don't have to manually specify any files. It finds the right ones for you! It also pulls more files to get you a better result. I think this makes a huge difference in the ergonomics of just chatting to get results.

Codebuff also will run commands directly, so you can ask it to write unit tests and run them as it goes to make sure they are working.

Good question – here are a few reasons:

- It chooses files to read automatically on each message — unlike Cursor’s composer feature. It also reads a lot more than Cursor's @codebase command. - It takes 0 clicks — Codebuff just edits your files directly (you can always peek at the git diffs to see what it’s doing). - It has full access to your existing tools, scripts, and packages — Codebuff can install packages, run terminal commands and tests, etc. - It is portable to any development environment

We use OpenAI and Anthropic, so unfortunately we have to abide by their policies. But we only grab snippets of your code at any given point, so your codebase isn't seen by any entity in its entirety. We're also considering open-sourcing, so that might be a stronger privacy guarantee.

I should note that my cofounder James uses both and gets plenty of value by combining them. Myself, I'm more of a plain VSCode guy (Zed-curious, I'll admit). But because Codebuff lives in your terminal, it fits in anywhere you need.

No comment on our batchmates

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.

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

A skilled surgeon is a great analogy! We actually instruct Codebuff to focus on making the most minimal edits, so that it does precisely what you want.

I'm currently hacking together a prototype of such a tool. The problem I noticed is that in CLI, commands are way less predictable than lines in code files, so such a tool will probably have a pretty low correct completion rate. However, there are clearly cases where it could be very helpful.

I assume you're referring to it guessing at what command you might type next? If so, the closest I can think of is Warp. Have you tried it?

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.

Nope, if you go over the allotted credits on the $99 plan, then you pay per usage (with a 5% discount).

We actually ended up not charging this guy since there was a bug where we told him he got 50,000 credits instead of 10,000. Oops!

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

Yes, at least, partially. It will work, but maybe not as well as we don't parse out the function names from .svelte files.

I can add it if tree sitter adds support for Svelte. I haven't checked, maybe it already is supported?

Weird, thanks for flagging – we're just using a Youtube embed in an iframe but I'll take a look.

No worries if this isn't a good fit for you. You're welcome to try it out for free anytime if you change your mind!

FWIW I wasn't super excited when James first showed me the project. I had tried so many AI code editors before, but never found them to be _actually usable_. So when James asked me to try, I just thought I'd be humoring him. Once I gave it a real shot, I found Codebuff to be great because of its form factor and deep context awareness: CLI allows for portability and system integration that plugins or extensions really can't do. And when AI actually understands my codebase, I just get a lot more done.

Not trying to convince you to change your mind, just sharing that I was in your shoes not too long ago!

> Your website has a serious issue.

I was thinking the same. My (admittedly old-ish) 2070 Super runs at 25-30% just looking at the landing page. Seems a bit crazy for a basic web page. I'm guessing it's the background animation.

    > I'm sorry. It's just another wrapper for a 3rd party model

For trivial tasks, this is certainly easy. For complicated tasks, like understanding a codebase or a product catalog of tens of thousands of entries, this is non-trivial.

My team is not working in the code gen space, but even though we also "just wrap" an API, almost all of our work is in data acquisition, transformation, the retrieval strategy, and structuring of the request context.

The API call to the LLM is like hitting "bake" on an oven: all of the real work happens before that.

I tried it on two of my git repositories, just to see, if it could do a decent commit summary. I was very pleasantly surprised with the good result. I was unpleasantly surprised, that this already cost me 175 credits. If I extrapolate this over my ~100 repositories, that would already put me at 8750, just to let it write a commit message for release day. That is way out of free range and basically would eat up most of the $99 I would have to spend as well. My subscription price for cody is $8 for a month. Pricing seems just way off.

Sorry Will try an external keyboard next time!

Your comment is a bit suspicious given that your previous submissions are limited to manifold market links, and this tool came from that company.

Could you elaborate on those ways please?

Don't take it personally or get too discouraged. You are not your product, and you're certainly not your first demo of your first product. But, knowing your competition, how you stack up against them, and how the people you're selling to feel about them, is a huge part of your job as a founder. It will only get more important.

You have to constantly do your research. It is one of those anxiety-inducing tasks that's easy to justify avoiding when all you want to do is code your idea up and there's so much other work to do. But it's your job. Even when you hire someone else to run product for you it'll be your responsibility to own it.

What you've built is cool, a lot of people love it even though they know about the other tools available. Now you know what your main competition does, you also know what it doesn't do, so you get to solve for that - and if you solved the context problem in isolation with treesitter then you're obviously capable.

You'll have realised by now that Aider didn't use treesitter when it started. Instead it used ctags - a pattern-matching approach to code indexing from 40 years ago that doesn't capture signatures or create an ast, it effectively just indexes the code with a bunch of regex. And it's not like treesitter wasn't around when aider was first written. Keep that in mind.

Good luck.