Comments URL: https://news.ycombinator.com/item?id=45271779

Points: 1

# Comments: 0

maybe what we're asking for is that terminal commands keep in mind that agents are now the primary users of them, and have a feeling that new packages or commands could get wider adoption if they are better understood by a coding agent

- similar to SEO for LLMs growing in adoption - documentation sites offering .md file raw for LLMs to ingest easily

These things will make it so that your packages or libs adopted faster

Comments URL: https://news.ycombinator.com/item?id=45098888

Points: 3

# Comments: 3

Howdy - I’m Kevin, co-founder of Firebender, and we built the first background coding agent in android studio / Jetbrains!

Why not just use Cursor background agents or OpenAI Codex?

Both of these require setting up a cloud container and cloning your existing developer environment, and maintaining it. Then when you want to iterate on changes as AI inevitably makes a mistake, you either throw away the work, or have to pull down the branch and clean it up. This feels really clunky. With Firebender, background agents run locally in a lightweight git worktree/IDE tab. This means when the agent is done, you can easily clean up the changes and run code with a few clicks.

Under the hood, the agent behaves similarly to claude code (didn’t want to reinvent the wheel), but also leverages all of the hooks into IntelliJ sdk like go-to-definition, find usages, auto-imports for accuracy, and it gives a cleaner visual UI for reviewing changes and merging them. You can use any frontier model like gpt-5/sonnet-4 as the base.

We’ve had to do quite a bit of reverse engineering of the IntelliJ codebase to cleanly set up and manage the isolated environment, and I think you’ll appreciate the simple UX of hitting cmd+enter to run a background agent anywhere.

get started docs: https://docs.firebender.com/get-started/background-agents

download the plugin: https://firebender.com

Would love to get your feedback to help us improve the tool for you! Thanks!

Comments URL: https://news.ycombinator.com/item?id=45029120

Points: 9

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=44892136

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=44891420

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44517508

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44517475

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44517456

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43628781

Points: 3

# Comments: 0

Also, if you ever want to revisit a video, just use chromes history, but you'll find also this rarely happens if ever.

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).

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.