Launch HN: Bullet (YC S26) – A Faster Coding Agent
Hi HN! We’re Adi and Alex, founders of Bullet, a faster coding agent. Bullet started in a senior year dorm. We were fresh out of working at AppLovin and Citadel, and naturally thought we were on a sure path to startup success. We were going to use our skills optimizing stock pricing calculation speeds and agent document context to take over the world. So, Bullet started as an AI hedge fund, a browser-use agent, synthetic financial data (oof), a mobile IDE, and a bunch of other things. We wanted to build something people wanted, but it seemed like everything we built was just terrible, useless, or both. So, we decided to do something completely different, something completely out of the blue, something that no one had ever done before. Solve a problem we actually had. Over the course of six pivots, we suffered. Throughout all of our adventures, one final boss kept getting in our way. Claude Code and his little brother Codex. We were spending hours waiting for coding agents like Claude Code and Codex, and got so frustrated to the point that I downloaded the Claude Code whip. We had spent months of time waiting for six codebases-worth of useless coding agent work. Lightbulb moment. There’s nothing more noble than destroying the institutions! Let’s take on Claude Code and Codex, we can do it! Piece of cake! And so, Bullet started off as a side project. We used the Claude Code to improve the Claude Code: 1. Model routing. Do you regret giving a task to Fable when it could have literally been done by Sonnet? 2. Targeted code + context search. We think embedding the whole repo is dumb. We also think sticking the whole context (or compressed context) in chat is dumb. So we do faster and better greps over both. 3. Aggressive context hygiene. Tool output is bounded, stale screenshots disappear, we don’t re-read files…the garbage never floods the model. 4. Efficient turns. Batch independent investigation, make one surgical edit, then perform one focused verification. Internal measurement showed 16% fewer round trips and 27% lower cost. 5. The Flash. We prayed to Barry Allen for speed. And thank the Flash, he gave us speed! On SWE-bench Verified, Bullet resolved 479/500 (95.8%) in one attempt, averaging 119s per task, 35–67% faster than mini-SWE-agent + Fable/Sol depending on task. Full results and methodology here (https://www.codewithbullet.com/blog/benchmark-results.html) Eventually we started using it every day and never went back. Listed above were just some of the things about Claude Code that frustrated us the most, but we are constantly optimizing every day (look at that, maybe we did learn something from our jobs). In our development, the biggest insight was that model speed matters less than reducing round trips. Independent searches, reads, and commands should happen in parallel, while dependent editing and verification stay sequential. One surprising obstacle was code search, small issues like regex-dialect mismatches caused silent misses and sent agents down completely wrong paths, so we built targeted search with fallbacks and bounded context. The most interesting use case so far has been long iterative work (like benchmarks, data pipelines, and evaluation loops), where each step depends on the last and running multiple agents can’t help as much. Here’s the video demo (https://www.youtube.com/watch?v=rWVmG5fRKgE) We hope that you guys try out Bullet if you are suffering with speed as much as we were, and we hope it brings you joy, rainbows, and faster responses. And if it’s terrible, let us know it’s terrible (we’re masochists btw)! We'll be in the comments all day, you can also contact us at bullet@davidhf.com. You can try it at https://codewithbullet.com. P.S: we hid a code on the website, see if you can unlock the secret page at the footer, all built with Bullet
Comments
5 preview comments · loading full threadLog in to h4cker, then connect Hacker News to publish comments.
This is a promising direction! Unfortunately, I think the benchmark result here is essentially meaningless. I recently discovered this same lesson the hard way. I was trying to get a multi-agent system I was building to improve upon GPQA Diamond scores (system here: http://pellmell.ai). No matter how hard I tried, I could not get any lift. When Fable 5 dropped, it also did not improve upon Opus, and I realized my mistake. The benchmark was saturated! Now, looking at the result here, I see a similar pattern. Fable is not better than Opus, and the score is ~95%. Notably, this post omits which subagent is being used. Why? An intellectually honest way to tell if this thing really works would be to run that agent and report its score and cost as well. Going back to my GPQA Diamond lesson, you can see here how a saturated leaderboard behaves https://artificialanalysis.ai/evaluations/gpqa-diamond. Fable gets 92.6% for $0.22 per task while several models score higher for $0.01. I could easily publish a router that “enhances Fable on GPQA Diamond” showing improved score for lower cost, just by implementing a router that picks the model at random!
So I hit download, and I got a .deb file. Installing a .deb requires root. Okay, a coding agent that wants root access. I know almost no one is good at supply chain security unless it is their core business, 2500 companies hacked this week for using LiteLLM, etc. So I look around for source code links and come up empty. So, I am supposed to just give a random binary on a website that may or may not be malware depending on what NPM dependencies are in play, and give it root access, and trust whatever unknown CI/CD system that builds it to be able to execute any commands on my system with root privileges, and I am not even allowed to review the code? That is an amount of trust I would not even extend to family, and you are asking for it from every single user. So I asked a local LLM to decompile it for me, the 198 dependencies, and license compliance. From here I could have it write an extensive test suite, delete the code, have LLM re-write the code to pass all the tests, then open source the result myself. I am probably not actually going to do this, but anyone could. Proprietary software is no longer a moat, and for something like this it just makes your software very hard to trust. Clean room code laundering is so easy now you might as well open source it yourself.
I think this adds no value. I would stick to OpenCode. Things I would value: high-fidelity visualization (bonus points for Figma-like visual edits), good tool use (don't force me to tell the model), token efficiency, resource efficiency. Things that are not problems: * Routing: OpenCode predefines subagents that you can set to appropriate models. * Search: there are AST and embedding-based search MCPs. I use https://github.com/DeusData/codebase-memory-mcp
35% faster than swe-mini-agent, nice. You say this is due to somehow parallelizing operations? I'm using a custom harness based on swe-mini-agent (actually its little brother, their tutorial [0]) and found it way faster than codex (for small tasks) despite being "just bash" in a while loop. The main difference is that I do the opposite of what you said, i.e. I do dump the context in the prompt. You don't need to grep for what's right in front of you :) But my repos are small (often smaller than Claude's system prompt!), and I have a script that dumps an "outline" (e.g. function headers and top level vars). I had an even smaller harness for surgical edits but it was a bit too fiddly and I missed the "let it poke around and figure stuff out" mode of full agentic ones. What I do miss from that old one though is that it could edit several files simultaneously, in one LLM call. Maybe someday I'll add that back :) That being said, within a few months everyone who cares about speed will be on Cerebras etc., which will make even the slow harnesses way faster than mine and yours! (I've tested them already and it's insane how fast it is...) [0] https://minimal-agent.com/
Since I can't get this thing not to annotate its commits with itself as an author, I can't use it. That should be an option, not forced.