Every review we run on a pull request asks the same narrow question: is this change all right? Nobody asks the wider one until the week before launch, when someone senior is handed the repository and asked "can this go live?". That review is usually rushed, depends on who has time, and ends in a document of concerns that nobody turns into work.
We built a go-live check into CodeLynq to make that question something you can ask with a button, on any project, as often as you like. This is what it checks, how it reaches a verdict, and what it cannot tell you.
Three things a go-live check should cover
A useful go-live review is not a list of a hundred items. It answers three questions, and every finding belongs under one of them:
- Code and architecture. Does the code hold together in production, not only on a developer's laptop? Hard-coded localhost, debug flags left on, default secrets, missing migrations, error handling missing on the calls that will fail, N+1 queries and unbounded loads.
- Security and data. Authentication and authorisation on every endpoint, injection, secrets in the repository, CORS and CSRF, personal data in logs, data that is never deleted, a database that would not survive a redeploy.
- Flows. Do the things the product exists for work end to end? Sign-up, login, the core actions, payments if there are any: entry point, handler, storage, response. A flow that is half built, unreachable, or breaks on an empty input or a double submit is a launch problem.
How the check runs
A go-live check clones every repository in the project and does three things in order. First it runs the scanners that apply to the checkout: gitleaks and semgrep where they are installed, pip-audit for a requirements file, npm audit for a package.json, or your own scan command if you set one. Then it runs the project's test command, the same one runs use to verify their work. Then an AI agent reviews the whole checkout with the scanner and test output in front of it.
That agent is read-only. It can read, list and search files; it cannot edit them or run commands. A check that could change the code it is judging would not be a check. It also gets the project's own context: the architecture principles, constraints and domain notes your team wrote, so "this breaks a rule we hold" can be a finding, not only generic best practice.
Findings, not an essay
The agent has to end with a structured list: for each finding a category, a severity from critical to info, a short rule id, a description, a recommendation and a file location. Critical means exploitable or losing data now; high means it must be fixed before launch; medium should be fixed soon.
Two decisions here came from thinking about how this fails. If the answer does not contain a readable list, we ask once more, and if it still does not, the check fails with that reason. The alternative, recording "no findings", would tell you your project is clean when nobody actually checked. And the verdict is not the agent's to give. We derive it from the findings: any critical or high finding means not ready, only mediums means ready with warnings, otherwise ready. An answer that says "looks good" above a critical finding is not ready.
Serious findings become tasks
A report is where findings go to be forgotten. So critical, high and medium findings from a go-live check become tasks on the project's backlog, as drafts, with the problem, the location and the recommendation already written in, and bug fields filled so a run starts by reproducing it. Lower findings stay on the report. One check files at most fifteen tasks, whatever the agent returns.
Running the check again should not double your backlog. Each finding gets a fingerprint from its category, rule and file, deliberately without the line number, which moves with every unrelated edit, and without the title, which the model rewords between runs. A finding that matches an open task is linked to that task instead of filed again. The agent is also shown what is already filed and asked to reuse the same rule and location when it sees the same problem, because the fingerprint is only as stable as the words the model picks.
What it does not do
- It does not click through your app. "Do the flows work" is judged from the code and from your test suite. Nothing is deployed and no browser signs up a test user. If the project has no test command, no tests run, and the agent is told so and asked to report missing tests on critical flows as a finding. Your test suite is doing a lot of the work here.
- It is not a penetration test. It reads code; it does not attack a running system. For a regulated launch, it is the review before the pentest, not instead of it.
- It costs model usage. A check reads the whole project, so it is charged to credit like a run.
- It runs on our workers. For now checks run on the platform, also for organisations that use a self-hosted runner for their runs.
Where it fits
The gates on each run, which we described in four checks an AI run should pass, look at one change. The go-live check looks at everything nobody is changing, which in most projects is most of the code. Run it a few weeks before launch rather than the day before, so the tasks it files have time to become pull requests, and run it again once they are merged. The second verdict is the one worth showing to whoever signs off.