Most AI coding tools compete on writing code faster, which is a crowded fight. Qodo picked a different angle by focusing on code integrity, meaning tests, review and the verification work that developers reliably postpone. That is a more interesting position because the bottleneck in most teams is not typing speed, and the documentation is built around that argument. Test generation is the headline capability and the framing is smarter than the obvious version.
Rather than aiming at line coverage, the material talks about behaviours, edge cases and the inputs that a function is likely to mishandle. Anyone who has inherited a codebase with ninety percent coverage and no confidence knows why that distinction matters, and the documentation explains it well enough to be worth reading on its own terms. The honest caveat, which the material soft pedals, is that generated tests need genuine review. A test that captures current behaviour rather than intended behaviour will happily lock in a bug forever, and no tool can tell the difference without knowing what you meant.
The documentation presents generated tests as closer to finished than they are, and anyone adopting this needs to treat the output as a draft that a human confirms. That is still a large saving over writing them from scratch, and it is not the zero effort story implied. The open source pull request agent is a genuine point in the product's favour. Being able to read the code, run it yourself and see exactly what is sent to a model is a level of transparency that the commercial competitors do not offer, and for a security conscious team that matters.
The documentation covers self hosting properly and I would rather have this option than not, even if most users will take the managed version. IDE integration is documented clearly across the main editors, and the material does not assume you are using any particular one. That is a small thing that a surprising number of tools get wrong. The rebrand is the biggest practical friction.
Codium became Qodo, both names appear across documentation, blog posts, community discussions and search results, and working out whether an article describes the current product takes effort. There is also a separate unrelated product with a confusingly similar name in the same market, which compounds the problem when you search for anything. The documentation could resolve this with a clear note and largely does not. Product boundaries are unclear in the way that open core products usually are.
Which capabilities are free, which need a subscription, and which are enterprise only is not consistently signalled, and you can read about something for a while before discovering it is not available on your plan. A clearer feature matrix would fix this. The market position is genuinely difficult and the documentation cannot solve it. General purpose coding agents now generate tests as part of their normal operation, which squeezes a specialist tool from above.
The specialist arguably does it better and more thoroughly, and explaining why that is worth a separate tool and a separate subscription is a harder sell than it was a year ago. The material does not make that case as forcefully as it needs to. Three point five. Sensible documentation for a product with a defensible specialisation, undermined by naming confusion and an oversold account of how ready the generated tests are.
Worth evaluating if test coverage is your actual problem, and read the output carefully before you trust it.