Launched this week
heal.dev
Find bugs and vulnerabilities code review misses
828 followers
Find bugs and vulnerabilities code review misses
828 followers
Code review catches what’s wrong in a diff. Heal catches what breaks when the app runs. Heal learns how to run your application, builds a production-like sandbox with external services stubbed, then hunts for bugs, performance regressions, and runtime vulnerabilities users would hit. It reproduces every defect before reporting it, so you get real bugs to fix, not a backlog of AI-generated suspicions.
Free Options
Launch Team / Built With
Dropbox SignSimple, secure eSignatures for the way your team works.
Promoted
Reproducing every defect before reporting it is the right bar, most review bots drown you in maybes. How do you handle apps where the bug only shows up with real third party responses, like a payment or email provider returning something odd that your stubs don't model?
@thamibenjelloun That's a great question. The agent adds the best stubs it can (it can take docs as an input), but if you need to add more knowledge about something that happened and isn't in the mocks, you can tell the agent (eg. with our MCP server) to add it.
We had this use case on a side project with Maptiler and Strava integrations, logged the errors in @BetterStack with their MCP server, and asked the agent to enrich the mocks with them.
@thamibenjelloun also the agent starts to ask you to review the local sandbox it'll build, such that you can explicitly tell it if you want to use a real third-party / provider with staging/dev access.
How much configuration does it take for Heal to learn how to run an app? For projects with non-trivial local setups (multiple services, env specific config), that first step seems like the real test.
@mehdi_hamri Hey! A couple of metrics on that: small codebase (one frontend app, a backend app and a single database) up to 20min. For a large codebase with multiple frontends, backends and a lot of storage and external dependencies, the agent takes the time it needs (we've seen 3 hours for an enormous codebase). But, the agent is train to stop and ask the user for more informations when it's blocked or judges it can speed up the build with the user insights.
honestly what stops auto merge isnt whether the code works, its whether the change is what we actually wanted. a sandbox can prove nothing breaks but it cant tell me the feature is wrong for users. id maybe auto merge dep bumps and small fixes when heal reproduces nothing. curious if you let teams set that threshold per repo
@hitensethiya Great point. Very small fixes or merge dep bumps are probably not the best candidate for a heal run: where we shine is testing new areas, a bit like when you go run exploratory testing on something new.
That said, you can run heal on whatever diff you want, and ultimately one way to adopt is to start on the smaller changes! Would love to have you give it a go!
The "what code review misses" angle is honest, nobody reads the fifth PR of the day properly. Does it run on every PR or does that get noisy fast?
@jean_bonnenfant_tinct you need to trigger manually the agent or schedule runs on our SaaS. It doesn't make sense to trigger the agent on a single PR as we are using an internal concept of "feature" describing a user or client (machine). We release this week a beta feature to auto trigger the agent on a chunk of PR (the agent checking all PR to build a coherent chunk for a run). Hope this make sense for you!
Reproducing a defect before reporting it sets a useful bar. I would like to see the smallest failing case alongside each finding.
@oleksii_sekundant spot on! What heal does is give a script/test that allows to reproduce the issue and validate it's fixed. Both useful for repro, and having a feedback loop to verify the work of the coding agent you ask for a fix.