When your team codes with AI
Find the code that only looks finished.
Code now arrives faster than a team has time to review it. Coding assistants and agents produce it in volume, and developers who are short of time write it in a hurry. Much of that code compiles, passes the tests and looks finished, so the problems in it are easy to miss, such as a test that checks nothing or a second copy of code that already existed.
Watchdog surveys the whole product on the team's schedule and finds these problems in the code itself, whoever or whatever wrote it. Each survey shows whether the share of code that needs work grows as the team speeds up, and whether the fixes worked. The team's own coding agent can work through what Watchdog finds, starting with the fix that raises the score most for the least work. Watchdog is where a team begins, and it works alongside the tools the team already runs.
Sign in with GitHub, GitLab, Bitbucket or Azure DevOps · no card · the first survey of every repository you connect is free.
Behind code that compiles
What Watchdog finds that a quick review misses.
Each problem below reads well in a quick review, so it gets merged. Watchdog finds it because it looks at how the code is built and how it fits into the whole product, in every file and at every survey.
Code that looks finished but does nothing
A function called CalculateTax that always returns 0 compiles and can pass its tests, yet no order is ever charged tax. Watchdog finds functions like it by how they are built: functions that only say they haven't been written yet, functions that ignore their inputs and always return the same value, and placeholder text left in the finished product. It also finds errors that are caught and then ignored, so a failed payment leaves no message and no log entry. The checks for unfinished code read C#, Dart, F#, Java, JavaScript, Ruby, Scala and TypeScript so far. The check for errors that disappear reads C#, Dart, Erlang, Go, Java, Kotlin, PHP, Python, Ruby, Scala and Swift.
Tests that check nothing
Tests are quick to produce in large numbers, and a test can run the code without checking the result. A test that runs the checkout but never checks the total passes whether the total is right or wrong, and the code still counts as tested. Watchdog finds tests that check no result, and tests that are switched off but still make the test suite look bigger than it is. This check reads several languages.
A second copy of code that already exists
When a change adds a copy of code that already exists elsewhere, a bug fixed in one copy stays in the other, and every later change has to be made twice. Watchdog finds blocks of code that are identical or nearly identical, and scores them by how much of the product they make up.
Changes that fit where they were made, but not in the product
A change can look right on its own and still be wrong for the product as a whole. Watchdog reads how the parts of the product depend on each other and whether the boundaries in the design are kept, so a change that reaches across a boundary shows up even when it looked fine in review. It also finds code that nothing uses, such as a function or a file left behind by an earlier change.
Each of these checks, and the languages it reads, is explained in full on What we measure. Where a check can't read your code, the report says so and that check isn't scored.
Once the problems are found
Your team's coding agent can work through the fixes, and Watchdog tells it what to fix first.
A survey of a product that changes fast can find many problems at once, and a team that is already short of time cannot sort them all by hand. The order matters, because some fixes raise the score a lot for little work, while others take days and change little.
Watchdog sorts the problems into one list, with the fix that raises the score most for the least work at the top. The team's own coding agent can read that list directly and work through it in the team's own code, or a developer can work through it by hand. The next survey shows whether each fix worked.
A ranked list your agent can start on straight away
Each item on the list is one area of the code with its open problems, what fixing them is expected to add to the score, and how to fix them. A problem names its file and line where it has one. A problem in the design as a whole, such as how the parts depend on each other, names the part of the product instead. Watchdog puts every language in the repository on the same list, so a problem in TypeScript and a problem in C# are weighed against each other. The expected gain is an estimate until the next survey measures it. Coding agents read the list through the standard way they connect to tools (MCP), for example Claude Code, GitHub Copilot, Cursor or opencode.
Several agents can work at once without doing the same fix twice
An agent marks a problem as its own while it works on it, so a second agent does not start on the same one. The mark lasts a short time, and an agent that stops can hand the problem back to the list. A team can therefore run several agents on one repository at the same time.
Watchdog never changes your code
Watchdog surveys a temporary copy of the code and has no way to write to the repository. It makes no commits, no branches and no pull requests (changes proposed for merging). That is deliberate, because a tool that changed the code it grades could no longer grade it neutrally. Every change is made by your team or its agent, the team decides what to merge, and the change stays in the team's own history.
When a problem looks wrong, your team decides
The agent may find that a problem it is working on looks wrong. Your team then looks at it and decides what to do. The team can leave it, or the agent or a developer can send it to Watchdog with the reason, so the check that found it can be corrected. How that works is set out in the guide From finding to fix.
The agent list is included in every plan, the free one too, and keys for coding agents never count as accounts. A check-up survey straight after a fix is switched on per repository by its owner and counts toward the plan's monthly allowance. How to connect an agent is set out in the guide From finding to fix.
As the team speeds up
See whether speed is costing quality, and whether the fixes worked.
Whether the code that needs work is growing
Every survey gives each file a score from 0 to 10 by what it found in it, and sorts the files into three groups: files that are well organised, tested and worth protecting, files in the ordinary middle, and files with copied code, leftover code that nothing uses or unfinished placeholders. Each survey adds a new column to that split, so the team sees within a sprint whether the share of files that need work grows as more code arrives.
Whether a fix really worked
A developer or a coding agent can mark a finding as fixed when the problem is still there. Watchdog treats every reported fix as unconfirmed until the next survey checks it: if the problem is gone, the finding closes, and if it is still there, the finding opens again. Reformatting the code doesn't make a finding disappear, because Watchdog does not go by the line number a finding sits on. A closed finding shows that this one problem is gone; it doesn't show that the whole change was right.
Try it on a repository where the assistants have been busy.
Sign in with GitHub, GitLab, Bitbucket or Azure DevOps · no card · TypeScript, C#, Java, Python, Kotlin and more · the first full report on every repository is €0.
Next: From code host to your first baseline · From finding to fix, by hand or by agent, or browse all the guides.
Leading an engineering team? See Watchdog for engineering teams.
Already run other tools on your code? See Where Watchdog fits with your tools.