The feedback loop
inline gets quieter and sharper the more your team uses it. It watches how you respond to its findings — resolve a thread, react with a 👎, change the flagged code, or merge without touching it — and turns those signals into outcomes, an acceptance rate, and proposed suppression rules. Reading these signals is deterministic and free: no model runs to read reactions.
# The signals
Three signals, all read straight from GitHub:
- Thread state — was the review conversation resolved or left open?
- Reactions — 👍 / ❤️ / 🎉 on a finding’s comment count as up; 👎 / 😕 count as down. Bot reactions are ignored.
- Code change — did a later push touch the exact lines the finding flagged?
# Live, during the PR
On each incremental review, prior open findings whose lines the new push touched are marked addressed — they stop counting against the merge gate, because changing the code is evidence the point landed. If a later review re-confirms the same issue, it’s reopened.
# On PR close: the harvest
When a PR closes, inline runs a feedback pass. It syncs thread resolutions, computes one diff per distinct reviewed commit, and resolves each finding to a single outcome:
| Outcome | Condition |
|---|---|
| Rejected | 👎 present and ≥ the 👍 count. |
| Fixed | The flagged code changed — the fix is the proof. |
| Accepted | 👍 present, no code change. |
| Dismissed | Thread resolved, no code change. |
| Ignored | PR merged, finding untouched and unresolved. |
| None | Closed unmerged, no signals. |
Line matching uses a small fuzz against the base-side line map; file-level findings match on any change to their file. These outcomes power the acceptance-rate metric on the dashboard.
# Dismissal patterns → proposed learnings
The loop’s most useful output: when the same finding pattern is dismissed or rejected across at least 3 distinct PRs within 90 days, inline drafts a suppression rule.
- Findings are grouped by category and a normalized title — the same normalization the dedup fingerprint uses, so a proposed rule covers exactly the findings that share an identity.
- A single cheap model call drafts the rule, stored as a proposed, inactive learning with the evidence attached.
- One proposal per pattern, ever.
Crucially, inline never silences a class of finding on its own. A proposed learning sits inactive until an admin approves it in the portal (which activates it) or deletes it. inline surfaces the pattern; a human decides.
This is the whole philosophy in one mechanism: the agent notices what you keep rejecting and offers to stop — but you stay in control of what it stops saying.
# Tuning
The thresholds (3 distinct dismissals, a 90-day window) are built in. What you control is what happens next: review proposed learnings under Learnings in the portal and approve the ones that match your team’s taste.