Dear Investors.

Over the last year, I have spent a lot of time building and working with coding agents. Somewhere along the way, I realised the thing that worries me most about them is also the thing that makes them so powerful: they can now produce code much faster than we can properly understand it.

A good coding agent can make a large change across a repository in minutes. It can add tests, refactor files, update APIs and confidently tell you everything works. The problem is that someone still has to decide whether that change actually belongs in production.

That part has not become 10x faster.

We still review code at roughly human speed. We still need to understand how a change interacts with the rest of the system. We still need to notice when an implementation is locally correct but architecturally wrong, when an agent made a subtle assumption, or when a test proves much less than the agent claims it does.

I think this is becoming one of the most important problems in software engineering.

Critique started as an AI code reviewer, but it has gradually become something more specific. It sits beside coding agents like Claude Code, Codex, Cursor or our own CritiqueCode and independently reviews the work they produce.

The important word is independently.

Critique does not simply ask the coding agent whether it finished correctly. When a review starts, the reviewer can be given the task and the repository without receiving the author’s conversation, confidence, worklog or claimed test results. I deliberately built that separation because otherwise the reviewer begins from the same assumptions as the agent that wrote the code.

Critique treats the author’s claims as claims, not evidence.

If an agent says it fixed a race condition, Critique can investigate whether that failure actually existed and whether the new code really prevents it. It can run controlled checks, inspect callers and dependencies, trace the surrounding system, route security-sensitive changes through deeper review, and distinguish between something a model merely suspects and something that has actually been reproduced or supported by evidence.

The same principle applies to repairs. If Critique finds a defect and an agent attempts to fix it, that repair should not be considered successful simply because the fixing agent says it worked. Critique can verify the repair independently before allowing it back into the workflow.

I have also been building a broader change-control layer around this. Critique can track the provenance and risk of a change, attach review evidence to it, apply merge policy and preserve proof of verified repairs.

The eventual question is not just “what comments did the AI reviewer leave?” It is “what do we actually know about this change, and should it be allowed to ship?”

While building all of this, I noticed another problem that I now think may be even larger.

Critique already builds a surprisingly detailed understanding of a repository for its own reviewers. It can map symbols, callers, callees, tests, dependency relationships and changed public interfaces. It can work out which parts of a codebase sit in the blast radius of a change.

We give all of that context to machines.

Then the human reviewer still gets a diff.

That feels backwards.

If an agent produces a 3,000-line change, the answer cannot be to ask a human to read faster. The system should instead tell them what changed behaviourally, where it propagates, which assumptions matter, what has already been proven and which decisions still genuinely require human judgement.

That is where I want to take Critique next.

I want a reviewer to open a change and quickly understand: this touched authentication, these seven callers depend on it, these tests cover the changed path, this behaviour was reproduced before the fix, this part remains uncertain, and these two architectural decisions still need a human.

The metric I care about is not how many comments Critique can generate. It is how much correct understanding a human can acquire per minute of attention.

I think this becomes increasingly valuable as coding agents improve. Better agents do not remove the review problem. They create more plausible code, more quickly. And plausible code is precisely the code that is hardest to reject casually.

There is already a real system behind the idea: a local reviewer CLI, an independent review and evidence runtime, repository intelligence, verified repair, change-control infrastructure, and CritiqueCode, our own coding agent that uses the same review machinery. I am also working on a hosted version of CritiqueCode so the entire author, review, repair, ship loop can happen from the browser.

What I need now is focused runway to turn those pieces into the product I think should exist between coding agents and production software.

If you invest in developer infrastructure, AI systems or the future of software engineering, I would love to talk.