Inspiration
AI coding agents are incredibly useful, but they often make the same mistakes repeatedly. You correct one problem today, continue working, and then find yourself correcting essentially the same problem again a few days later.
The frustrating part is that these corrections usually disappear into individual conversations. There is no simple way to see which mistakes keep recurring, how often they happen, or which instructions would have the biggest impact if they were permanently added to the agent's rules.
That inspired Repeat Offender.
The idea was simple: treat recurring AI mistakes like a "rap sheet." Instead of repeatedly correcting the same behaviour, record it, detect when it happens again, count it, and eventually turn those repeated corrections into permanent instructions for the coding agent.
The goal was to create a feedback loop:
AI makes a mistake → developer corrects it → Repeat Offender remembers it → repeated mistakes become rules → the AI is less likely to make them again.
What it does
Repeat Offender is a local-first logbook for tracking mistakes made by AI coding agents.
A developer records two things:
- What the AI agent did wrong
- What it should have done instead
When a new correction is submitted, Repeat Offender compares it with previous corrections.
If the new entry appears to describe a mistake that has already been recorded — even when it is written differently — the application treats it as another occurrence of the same offence instead of creating a duplicate entry.
The offence count increases and the developer can immediately see which mistakes are happening most often.
For example, instead of having six different notes describing essentially the same behaviour, the interface might show:
You've corrected this 7 times now.
Repeat Offender then ranks these recurring problems by frequency.
The worst repeat offenders appear first, so the rules that could save the most developer time receive the highest priority.
The app also supports searching and filtering offences, importing and exporting the logbook as JSON, example data, light/dark themes, and local browser persistence.
Everything stays on the user's machine.
How we built it
We deliberately kept Repeat Offender lightweight and local-first.
The application is built with HTML, CSS and vanilla JavaScript. There is no frontend framework, no bundler, no backend server, no external API, and no runtime dependency.
The project consists of one main interface and a small set of focused JavaScript modules:
src/matching.jshandles recurrence detection.src/offences.jscreates, ranks and filters offences.src/exporting.jsgenerates agent rules files and JSON backups.src/storage.jshandles browser local storage.src/examples.jsprovides the example logbook.src/app.jsconnects the logic to the browser interface.
The core matching system does not send corrections to an AI model. Instead, it uses deterministic text processing.
Each correction is normalised by lowercasing the text, removing punctuation and filtering less meaningful words. The remaining words are compared using weighted overlap, with more importance given to the description of what the agent did wrong.
This gives Repeat Offender a lightweight similarity score that can determine whether a correction is probably a recurrence of an existing offence.
A major design principle was keeping the important logic as pure functions so that it could be tested independently from the browser.
The project currently includes 40 automated tests using Node's built-in test runner:
node --test tests/*.test.js
There is no installation step required for the application itself.
The project was also planned before implementation using the Devpost Learn Skill Pack, with separate scope, product requirements, technical specification and build-checklist documents.
Challenges we ran into
The hardest part was determining when two differently worded corrections should count as the same mistake.
A similarity system that is too strict creates duplicate offences. A system that is too loose incorrectly combines unrelated mistakes.
Our original technical specification estimated a matching threshold of 0.45, but rather than trusting that assumption, we created test fixtures first.
We created examples that must match and examples that must remain separate, then measured their similarity scores.
The results showed that valid rewordings scored approximately 0.329–0.563, while unrelated examples scored only around 0.000–0.025.
That proved the original threshold would have missed legitimate repeated mistakes.
We therefore changed the threshold to 0.28.
This became one of the most useful lessons from the project: when a value cannot be justified theoretically, build evidence around it instead of guessing.
Another challenge was balancing simplicity with usefulness. Using a language model for semantic matching could potentially detect more sophisticated rewordings, but it would introduce API keys, latency, cost, privacy considerations and network dependency.
For this version, we intentionally chose an offline and testable approach.
We also had to account for false matches. If Repeat Offender incorrectly groups two corrections, the interface provides a Split out action so the user can separate them again.
Accomplishments that we're proud of
We are especially proud that Repeat Offender turns a very small interaction — recording a correction — into something that can improve future AI-assisted development.
The application completes the entire feedback loop rather than simply storing notes.
We are also proud that:
- The application works completely offline.
- No account, API key or external service is required.
- There is no
npm installor build step required to run the app. - The core functionality is covered by 40 automated tests.
- Reworded mistakes can be recognised as repeat offences.
- Logbooks can be backed up and restored using JSON.
- Importing another logbook runs recurrence detection instead of blindly creating duplicates.
- Rules can be exported directly to formats used by popular AI coding agents.
- The full application remains small enough to understand and inspect.
- The demo itself is reproducible using an automated recording script instead of relying on a one-time screen recording.
We also planned the project before writing the implementation, which helped us keep the scope focused on one central idea: make repeated AI mistakes visible and actionable.
What we learned
The biggest lesson was that improving AI-assisted coding is not always about using a larger or more sophisticated AI model.
Sometimes the missing piece is simply memory and feedback.
AI agents can be very capable, but if corrections disappear at the end of every conversation, developers are forced to repeat themselves.
By recording those corrections and measuring recurrence, we can turn individual frustrations into structured evidence.
We also learned the importance of testing assumptions early.
The similarity threshold looked like a small implementation detail, but it was actually central to the entire product. Writing the fixtures before building the UI exposed an incorrect assumption before it became embedded throughout the application.
Another lesson was that local-first architecture can be a feature rather than a limitation. Keeping everything in the browser made the application fast, private, inexpensive and easy to run.
Finally, we learned that a useful AI tool does not necessarily need another AI API call. For this problem, a simple deterministic algorithm created a solution that is explainable, measurable and testable.
What's next for Repeat Offender
The next step is to make Repeat Offender smarter while preserving its local-first philosophy.
We would like to explore stronger semantic matching so that the application can recognise repeated mistakes even when two corrections use completely different vocabulary.
We also want to explore:
- Browser extensions and IDE integrations
- Direct integration with coding agents
- Project-specific and global rule sets
- Full occurrence history for each offence
- Better analytics showing how recurring mistakes change over time
- Automatic suggestions for combining similar offences
- Team logbooks for shared coding standards
- Git-based rule-file synchronisation
- One-click updating of existing
CLAUDE.md,AGENTS.mdor.cursorrulesfiles
The longer-term vision is for Repeat Offender to become a lightweight learning layer between developers and AI coding agents.
Instead of developers repeatedly adapting to the same AI mistakes, the system should help the AI adapt to the developer.
Log in or sign up for Devpost to join the conversation.