---
title: "Discussion on \"Why we removed tests from a codebase built with AI tools\" | Hashnode"
description: "Discussion on \"Why we removed tests from a codebase built with AI tools\". AI tools made me care about code coverage. Then the tests piled up, so we deleted the ones that couldn't fail. Here's what we cut and what we kept."
url: "https://hashnode.com/posts/why-we-removed-tests-from-a-codebase-built-with-ai-tools/6af4c607c327486e5afac35a"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Why we removed tests from a codebase built with AI tools](https://jeremeevans.hashnode.dev/why-we-removed-tests-from-a-codebase-built-with-ai-tools?utm_source=hashnode&utm_medium=feed)

AI tools made me care about code coverage. Then the tests piled up, so we deleted the ones that couldn't fail. Here's what we cut and what we kept.

14h ago · 9 min read · jeremeevans.hashnode.dev  
Read the article

-   [#testing](https://hashnode.com/tag/testing)
-   [#ai](https://hashnode.com/tag/ai)
-   [#dotnet](https://hashnode.com/tag/dotnet)

## Written by

[Jereme Evans](https://hashnode.com/@jeremeevans)

@jeremeevans · Seattle, USA

  
[View profile](https://hashnode.com/@jeremeevans)

Good tools make hard work easy. Bad tools make easy work hard.

I'm a full-stack software engineer with 26 years of experience, starting with Y2K fixes. I've worked on Visual Studio at Microsoft, mapping software for emergency preparedness, systems connected to sorting machinery, and web platforms. I'm building Taproot I/O, the web publishing platform behind my personal site, with Claude Code and OpenAI Codex. I write about .NET, TypeScript, architecture, testing, and what works when building with AI tools. I selectively consider independent projects with clear goals and a well-defined scope. My preference is thoughtful planning, asynchronous collaboration, and scheduled conversations. My original articles are at https://www.jeremeevans.com.

## Responses 1

Markdown supported · ⌘↵ to post

[Ascendra Ventures](https://hashnode.com/@ascendra-ventures)

[7h ago](https://hashnode.com/posts/why-we-removed-tests-from-a-codebase-built-with-ai-tools/6af4c607c327486e5afac35a/comment/6af526b55ab12c11c61a754c)

The reversal on coverage makes sense to me. When the thing writing code can produce something that compiles and does the wrong thing, coverage stops being a vanity number and becomes a measure of how much of the output anything is actually checking. And because the same tools write tests quickly, they also write too many, which is how you get to 1,700 files of copied setup.

The rule you landed on, that a test has to fail when something real breaks, is the right filter. Removing 2,000 lines and seeing coverage go up slightly is a nice proof that a lot of those tests were checking nothing.

At Ascendra Ventures we apply a similar check at handover: for each acceptance criterion we want one test that has been shown to fail with the behaviour removed. It keeps the suite smaller and gives the client something meaningful to run after we leave.

How do you decide which tests to delete in practice? Do you mutate the code to see which tests stay green, or is it a manual review?