What is the difference between a new bug and a regression?
A new bug is a defect in behavior a change adds, while a regression is a defect the change causes in behavior that already worked. Both start in the change. A pre-existing bug, also called an existing bug, is a third kind. It was in the code before the change, even when the change exposed it.
The check that separates them is a run of the same steps on the code before the change. For a regression, the steps pass there and fail after the change. For a pre-existing bug, they fail the same way on both versions. A new bug has nothing to compare, because its behavior did not exist before.
All three are defects, the flaws in code that people call bugs. Sorting a failure this way is an early step in debugging, because it tells the team whether to look in the change or in older code.
What is a new bug?
A new bug is a defect in behavior that the change itself adds, e.g. a new address form that drops the apartment line. "New" refers to the change that added the behavior, not to when someone found the bug.
Checks written for the new behavior catch it, e.g. tests written from the request. Regression testing cannot, because it reruns checks for behavior that existed before. A new bug belongs to the change, so its fix usually lands in the same branch before the merge.
What is a regression?
A regression, also called a regression bug or software regression, is a defect where behavior that worked before a change fails after it. The change causes it, even when the failure shows up in code the change did not touch, e.g. a cart that empties after an edit to the address form. A test that fails because the request changed that behavior on purpose marks an intended change, not a regression.
The International Software Testing Qualifications Board (ISTQB) defines regression testing as testing that detects whether a change introduced or uncovered defects in unchanged parts of the software. A defect the change introduced is a regression. A defect it uncovered was already there, so a failing regression test can also point to a pre-existing bug.
Because an earlier version worked, git bisect can find the commit where a regression started. Golden file testing and differential testing catch regressions by comparing the output of the changed code with the output of the old version.
Teams often treat a regression as a release blocker, because shipping it leaves the software worse than the version customers have. A team can still choose to ship a known regression and record that decision.
What is a pre-existing bug?
A pre-existing bug is a defect that was in the code before the change under review. The change did not create it, but the change may be what exposed it, e.g. an added test that reaches an old code path for the first time. New behavior can expose an old defect too, e.g. a form that sends an old function an unusual input. The same call fails on the old code, so the bug is pre-existing. Still, the form cannot merge until someone fixes the function.
To show that a bug was already there, a developer runs its reproduction steps on the commit the change started from, with the same data and settings. If they fail the same way, the bug predates the change. The same run on old code is the first step to verify a bug fix and the first half of a fail-before, pass-after check.
If an older version once worked, the bug is an older regression that bisect can date. Otherwise bisect has no good commit, which Git's manual describes as one "known to be before the bug was introduced."
When should a team tell them apart?
Here is an illustrative example. Acme Co. sells furniture online. A developer asks a coding agent to "Let customers edit their delivery address during checkout." On the agent's branch, 3 checkout tests fail, and the agent's summary lists the cart failure as pre-existing. The developer runs the checkout tests on the commit the branch started from, in a second working tree:
base=$(git merge-base origin/main HEAD)
git worktree add --detach ../acme-base "$base"
cd ../acme-base && npm ci
npx playwright test tests/checkout --retries=0
The two runs sort the failures:
- New bug. The address test is not on the old commit, because the form did not exist. On the branch, the form drops the "Apt 4" line.
- Regression. The cart test passes on the old commit and fails on the branch. The address saved, but the cart emptied.
- Pre-existing bug. An older discount test fails on both commits with the same total, $240.00 instead of $220.00.
The sort belongs before the merge, because each label changes who fixes the failure and whether it blocks the merge. The agent's summary was wrong about the cart. The agent fixes the address form and the cart in the branch, because the change caused both, and the cart regression blocks the merge. The discount bug goes to the discount team as a separate report, because merging leaves it no worse.
This example is simplified. A real project would rerun each failing test on both commits, because a flaky test can pass on one and fail on the other.
What changes when a coding agent writes the code?
A coding agent often runs the tests while it works and reports the failures. Its summary can label a failure as pre-existing or unrelated to the change without running that test on the old commit. That label is a claim, not evidence. If some tests failed before the agent started, its own regressions can hide among the old failures.
An agent that meets a pre-existing bug can also fix it inside the current task, which widens the diff and mixes unrelated work into one review. Such edits are one way agents break working features. In a fix loop, a failure that an earlier round removed can come back, which is a regression inside the agent's own session.
A practical adjustment is to run the tests before the agent starts and save the result as a baseline. A failure then counts as pre-existing only when the baseline shows the same test failing with the same error. Sorting a failed continuous integration (CI) run the same way is part of CI failure triage.
How do new bugs, regressions, and pre-existing bugs compare?
The three kinds of bug differ on these points:
| Point | New bug | Regression | Pre-existing bug |
|---|---|---|---|
| When the defect started | In the change | In the change | Before the change |
| Behavior that fails | Behavior the change adds | Behavior that worked before | Behavior that failed before too |
| Same steps on the old code | Cannot run without the new behavior | Pass | Fail the same way |
| Can git bisect date it? | No, the behavior never worked | Yes | Only if an older version worked |
| Usual owner | The author of the change | The author of the change | The owner of that code |
| Blocks the merge? | Usually | Usually | Not by itself |
| Removed by a revert? | Yes, with the feature | Yes | No |
How do you compare behavior before and after a change?
Run the same steps on the code before the change and on the code after it, with the same data and settings. If the change edited a test, the two runs no longer check the same steps, so read that edit first. Keep the failing steps to run again after the fix.
What passed before needs to remain true, unless someone explicitly decides otherwise. After your agent makes the change, RunStory repeats the failing workflow to check that the problem is resolved. It is in private alpha for CLIs and web apps, and your team keeps the final release decision.
FAQs
How do you tell whether a bug was already there?
To tell whether a bug was already there, run its reproduction steps on the code before the change. If the steps fail the same way there, the bug predates the change. If they pass there every time, the change introduced it.
Can git bisect find when a pre-existing bug started?
Git bisect can find when a pre-existing bug started only if some older commit shows the correct behavior, because the search needs one good commit and one bad one. If the bug has been there since the code was written, no good commit exists.
Who should fix a pre-existing bug found during a change?
A pre-existing bug found during a change usually goes to the team that owns that code, as a separate report and a separate fix. The change waits for that fix only when the added behavior cannot work without it.
Should a regression block a release?
A regression usually blocks a release when it breaks behavior customers rely on, because the release would leave the software worse than the version they have. Shipping a known regression is a choice a team can make, as long as someone records it.