A bug to a PR

Users report password reset emails aren’t arriving. It’s affecting customers. You need to find the bug and fix it.

​

The old version

Read the password reset code. Auth module, email service, queue system. Trace the flow: reset requested, token generated, email queued, email sent. Find the issue: the email template has a broken link because the base URL changed during the migration last week. Fix the template. Write a test. Open a PR. Wait for review. Two to four hours.

​

With Fluso

You ask:

“Users report password reset emails aren’t arriving. Find the bug in our auth module.”

Fluso reads the auth code, the email service, and the templates, then replies: “Found it. The password reset email template in templates/reset-password.html line 12 uses https://old-domain.com/reset?token=.... The base URL changed when we migrated to the new domain last week. The links in the emails are broken.” You ask:

“Fix it and create a PR.”

Fluso updates the template, writes a test that validates the link format, and opens the PR. “Done. PR #156 — fixed the reset link domain, added a test that validates the link format. Ready for review.” You read the diff. Run the test locally. Approve the PR. Fifteen minutes from “we have a bug” to “the bug is fixed.”

​

Variations

When you want to reproduce first:

“Users report login errors with the new SSO flow. Reproduce it locally and find the bug.”

Fluso writes a test that reproduces the issue, then traces the code from the failing test backwards. When there are multiple suspects:

“Production hotfix — 5xx errors spiking on /api/orders. Could be the new payment provider integration or the rate limiter we deployed yesterday. Find the cause.”

Fluso reads recent commits, checks both code paths, isolates the issue. When you only want diagnosis, not a fix:

“Analyse why our test suite is flaky in CI but passes locally. Don’t fix anything yet — just diagnose.”

Useful when you want a root-cause report before deciding what to do about it.

​

What this is good at, and what it isn’t

Bugs that live inside a single repository, where Fluso can read the code and follow the logic, are where it shines. Reproducible bugs are easier than intermittent ones. Fixes that follow existing conventions are easier than redesigns. Routine PRs — with tests, with proper docs, ready for review — are exactly the kind of work this is good for. Less good fits: distributed bugs that span multiple services and require runtime introspection. Architectural redesigns where the question is “what’s the right approach” not “where’s the bug”. Performance pathology that needs profiler output you have to gather.

​

Tips

Name the symptom, not your guess at the cause. “Password reset emails aren’t arriving” is more useful than “the email template is broken”. Let Fluso diagnose; if you tell it the answer up front, you bias the search. Always read the diff. Fluso writes good code, but you’re still the engineer of record. Reading the diff and running the tests locally is non-negotiable before merge. Drop a context.md in the repo describing your stack, conventions, and do-not-touch zones. Fluso reads and follows. The first PR after you add it will make the value obvious.

​

Related