Show HN: Firebender, a simple coding agent for Android Engineers (docs.firebender.com)
The agent can edit multiple files, run gradle tasks like tests, and use the output to improve its changes. At the end, it reports a git diff of all changes that can be accepted or rejected.
Under the hood, the agent relies on Claude 3.7 sonnet and a fast code apply model to speed up edits. We built tools to give deeper access throughout the IDE like IntelliJ’s graph representation of kotlin/java code, “everywhere search” for classes, and have more integrations planned. The goal is for the agent to have access to all the IDE goodies that we engineers take for granted, to improve the agent's responses and ability to gather correct context. In order to improve the agent, there are internal evals like “tasks” and simulate the IDE which serves as a gym for the agent. This is heavily inspired by SWE-bench. Whenever tools, prompts, subagents, or models are changed, this gym helps find regressions quickly.
Building the UI was surprisingly hard. I had the great pleasure of becoming proficient in Java Swing (released in ‘96 by Netscape) to get this done right. Things like markdown streaming, or streaming git diffs are prone to layout flickering where Swing tries to recalculate where elements should go. We had to write our own markdown parsing and rendering engine that repaints Swing components only when changed portions of the markdown nodes. The UI tends to focus on simplifying reviewing AI changes, something I have a feeling we’ll be doing much more in the coming years.
If you’re an Android engineer, please let me know if you run into any bugs or want anything improved in the plugin!
18 comments
[ 2.8 ms ] story [ 49.4 ms ] threadabout: https://firebender.com/about
terms: https://firebender.com/tos
privacy: https://firebender.com/privacy
Also, the developers are super active in their Discord and are fast to fix bugs. Love this project.
same is true for intellij and kotlin/java support
> Some features may use a custom model like Apply, Autocomplete, Agent, so these proxy settings won’t be relevant, and your code will be sent to Firebender servers for processing.
Which suggests that there's always some cloud component? How usable is the plugin with fully local setup?
right now requests go directly to your proxy from the plugin if you have it configured (i.e. if you set up a clean VPC/VPN network environment with no outbound requests besides anthropic): both chat, cmdk, and agent will work. We are still working on the DevX for this, but need someone to work closely on this. Enterprise is also pushing us to make this more friendly.
But there are massive downsides, we use some custom models and hosting infrastructure to speed things up. For example, code edits will take much longer.
For fully local LLMs, we just need to setup a unified API client, but there aren't any good kotlin ones and I'm scrambling to write this from scratch. It is very annoying how there are different nuances in the anthropic/openai/etc. and all the "Open source" gateways are cloud hosted. I don't think people will want to "host" a gateway locally, the best experience is to just to put your keys/base url in settings which could be localhost:3000.
I can solidify this option with stronger guarantees.
Separately, we're working on Soc II at the moment and should have type 1 soon, and type 2 pending the observation period.
I know trusting my word is difficult bc I'm a random person on the internet, but we do NOT store you code data or use your code data to improve our product in any way (like training models).