The code works. That is not the same as correct.
Generating code stopped being the expensive part. Knowing whether it survives real users did not. A fixed-scope review of the path that carries the most risk, delivered as a written report you own, with the criteria your team needs to judge the next batch itself.
Talk to an engineerWhen teams call us
- A feature was built in two days and has been failing intermittently for two months, and nobody can say which part.
- The tests pass, the review was approved, and the feature still failed for every real user.
- The codebase grew faster than anyone’s understanding of it, and a small change now touches things nobody expected.
- A prototype went to production without anyone deciding that it should.
- There is a lot of code and very little agreement about which parts can be trusted.
- Everything works on the machine of the person who generated it, and the failures start at the edges: another format, another version, another timezone.
What we do
Read what was actually generated
Not a linter pass. We follow the critical paths by hand and check whether the code does what the surrounding code assumes it does. Generated code is plausible by construction, which is exactly what makes it hard to review quickly.
Exercise the path a real user takes
Most generated tests cover the case the author already had in mind. We test the other one: the browser’s actual request format, the empty input, the second click, the version of the library that is installed rather than the one in the example.
Find the assumptions nobody wrote down
Silent retries, timeouts that do not exist, a library used the way it worked two major versions ago. These pass review because they look ordinary.
Make failure visible
Instrumentation on the paths that matter, so the next intermittent problem has a location instead of a theory. A system nobody can observe is a system nobody can fix under pressure.
Leave the criteria behind
Written down: what we checked, what we found, and what to look at next time. The goal is that your team stops needing us for this, not that it keeps calling.
Typical projects
One critical path, one week, fixed price
We take the path where being wrong is most expensive — checkout, authentication, whatever moves money or personal data — and read it properly. A written report at the end. Self-contained: you can stop there, and act on it with anyone.
Audit a feature that has been failing intermittently
Reproduce the failure, find the assumption behind it, fix it, and instrument the path so the next one is visible in minutes rather than weeks.
Review a codebase before it grows further
Read the parts that carry the most risk, write down what breaks first and why, and prioritise by consequence instead of by how ugly the code looks.
Set up a review process a team can sustain
Checks that run on every change, and a short written standard for what a human still has to look at. Automation where it is reliable, judgement where it is not.
Take a working prototype to something you can operate
Error handling, limits, secrets out of the code, logs that say something, and a deployment that can be rolled back.
What you get
- A written report: what was reviewed, what was found, and the consequence of each finding
- The fixes applied in your repository, through your review process
- Tests that cover the path a real user takes, not only the happy one
- Instrumentation on the paths that fail quietly
- A short standard your team can apply without us
Questions we get asked
Are you against using AI to write code?
No. We use it daily and it is a real gain. The problem is not that a model writes code, it is that plausible code passes review faster than anyone can verify it. The speed is worth keeping; the missing step is the one we do.
Can you not just run a static analysis tool?
Those catch a category, and you should have them. They do not catch a function that is correct in isolation and wrong for the system around it, which is most of what we find. That requires reading the code with the rest of the system in mind.
Will you tell our team they did it wrong?
No, and it would be useless if we did. Most of what we find is not carelessness: it is code that looked right, in a language nobody had time to question. The report goes to whoever asked for it, and the point is what to do next.
How does it start, and what does it cost?
One critical path, one week, fixed price, one written report. You know what you are buying before the first call. From there you can stop, hand the report to anyone, or keep going — and most of what we find is worth fixing whoever fixes it.
How is this different from the architecture review?
The architecture review looks at the shape of the system: how the pieces fit, what breaks first under load, what the design will cost you next year. This looks at the code itself, especially what was written recently and fast. If you do not know whether the problem is the design or the implementation, start with the review.
Start a conversation
Tell us what you are building, or what is currently breaking. You will get a straight answer from an engineer, not a sales script.