Hire engineers to audit your code

A report you can act on and hand to your board: an overall score, findings grouped by quality, security, architecture, tests and documentation, each with the file it lives in and an estimate of what leaving it alone costs. Then a call where we walk you through the three things worth fixing first. We do not deliver a list of three hundred lint warnings and call it an audit.

Long enough to have tried selling it as software. We ran code review as a product — knowmycode.ai — until May 2025, then folded it back into a service, because a scored report with nobody to argue about it is worth less than it costs. The tool survived the product: between September 2025 and January 2026 it was scheduled 156 times against client repositories, 30 of those runs produced a report with findings in it, and across the 29 codebases behind them the first read averaged 4.2 out of 10. The other 126 runs returned a default report and no files read, which is a permissions problem rather than an audit, and our diligence page sets out the whole sample. Before the tool existed we did this by hand, with people assigned to it, which is why the reports read like an engineer wrote them rather than a linter.

Both a tool and a person. We run our own audit bot across a repository first — it runs against repositories on GitHub and Bitbucket, ours and our clients', and it scores every run out of ten across code quality, security, architecture, testing, documentation, DevOps, dependencies, error handling, performance and technical debt. Then an engineer who maintains production systems reads what the bot flagged plus the parts it cannot judge: whether the architecture matches what the business is about to ask of it. The bot finds the symptoms, the engineer works out which ones matter.

We have the comparison rather than a claim, and the method behind it is on our AI transformation page. Across our own client work, products where automated review has run since the first commit merge a pull request at a median of under an hour; a product of the same age reviewed entirely by hand sits at twenty hours. That is 4,068 merged pull requests over eighteen months, and the gap holds every month. The quick ones also carry larger pull requests and more review comments, which is the part that matters: the review is not being skipped, it is arriving while the author still remembers the change. What none of it shows is developers producing more — commits per person are flat. What changed is how long work waits.

A week for a typical codebase, two if it is large or split across many services. We need read access to the repository, and half an hour with someone who can explain what the product is supposed to do — an audit without that context grades style instead of risk.

Yes, and it happens. The more common outcome is a middling score with two or three genuine risks, because that is what working software looks like once it has shipped for a few years. A first audit rarely comes back above seven out of ten: three of the 29 client codebases we have scored cleared it, and our own 57 repositories average 6.0 on the same scale. We publish ours rather than a nine, which is how we know what a realistic number looks like.

We can, and we will say so plainly rather than pretending the audit is neutral advice. It is also a legitimate outcome to take the report to your own team, or to another vendor. If you would rather we had no stake in the answer at all, say so before we start and we will price the audit as the only deliverable.