Docs
Introduction

Introduction

Learn what can Fume do for your team.

Fume is an AI agent that has access to an isolated development environment in which it can run applications, write code and use the browser. It's specialized in reviewing and testing all of the edge cases that your engineers might have missed. Here are two examples that demonstrate how Fume works on real open-source PRs:

Example 1: Cal.com PR #18231

This pull request is a usual refactor pull request. It's a good example of how Fume can make sure nothing breaks in your application as you refactor pieces. Shortly after the pull request is created, Fume will let you know that it's reviewing this PR and give you a link where you can track its progress.

Then, stylistic comments are going to be sent to the PR one by one if any. It may take up to few hours for Fume to complete the full review as it's actually using it's computer to test your code changees; however you may expect to receive the stylistic comments in a matter of minutes.

You can easily customize what Fume should look out for by editing the .fumeconfig file. More on that here: Customizing Fume - TODO.

For every stylistic commment, you will see 3 things:

  1. The comment body itself (very short 1-2 sentences max.)
  2. Suggested Changes (optional)
  3. Feedback reactions

For some comments, Fume will also suggest a fix. These can be multi-line or even multi-file! If you decide that changes seem good, you can commit them with one click. This is especially useful for small nitpicks that are good practice but you wouldn't spend time fixing them yourself.

You can also flag the comment you like or dislike using the 👍 and 👎 reactions. Fume will learn from your feedback over time.

Once Fume is done with the stylistic review, it will move on with actually testing the changes made in all of the edge cases. This can happen in various ways, here are some of the most common methods Fume use to test your changes:

  • Automated tests (if your codebase already uses them)
  • Ad-hoc test scripts
  • Browser testing (mostly for UI/UX changes)
  • Sending HTTP requests (API testing)

Fume chooses the best way to test the changes. In this example, Cal.com already employs automated unit testing - in fact the PR author added a few himself. Fume runs these tests as a sanity check and add a few of its own to test uncovered edge cases. At the end, it reports the results in a final comment:

Example 2: Cal.com PR #17291

This is UI fix from the Cal.com repository but this time, we intentionally introduced a bug in the code. Fume started the app locally and used it's browser to test the user flow that has been edited. In the final report, a screen recording showing how Fume tested the user flow is also attached.

Now you have a good grasp of what Fume can do for your team. You can move on with setting it up!