In the last few months, I have been on a crusade to improve test coverage at work. The inspiration for this came from a pessimistic perspective on software development that I have acquired over time- what can break, will break; and every line of code is a liability that needs to be maintained. I was also impressed by the test coverage of open-source libraries, which I found out about when I contributed a tiny patch(https://github.com/pydantic/pydantic/pull/11695) to pydantic. That said, high coverage isn’t really a good metric for code quality, but low coverage surely is.

Aside: High line coverage is deceptive sometimes. It does not imply good branch coverage

Being a small startup that shipped a lot very fast, we started writing tests quite late. As a result, we accumulated “coverage debt”- even while most new code had tests written for it, there was a large chunk of the codebase that was left untested (which had the most critical functionality). This obviously had adverse effects on the stability of the platform. We now carve out time every week to cover this coverage debt. This is painful in the short term, but it has paid off in better stability and higher developer confidence, since a lot of bugs are caught in the CI running on the PR before it is merged.

Vibe-coding and code review

Most people on LinkedIn and Twitter seem to think that more code being written faster is a good thing. But since LLM outputs are not perfect yet, whatever time is saved in generating code for a decently complex project ends up in the review process (as it should). Reading code tends to be more painful than writing it which is why people avoid it. And it gets worse with scale- reviewing a 3000+ line vibe-coded pull request is nearly impossible!

If we continue along this path of generating large volumes of code, tests (particularly integration tests) will prove to be increasingly important. Tests are essentially codified expectations we have from the code. With a well written CLAUDE.md, Claude can use tests as guidelines for generating code and also as feedback steps in an agentic loop. It is also useful to check the tests the developer/AI has changed to understand at a glance what has changed.