# I Haven't Written a Test in a Year *Draft for public journal - January 2026* --- ## TL;DR I haven't written a test in a year—but my codebase still has 1,358 test files (1,001 Ruby + 357 JavaScript) and nearly 12,000 tests passing. The tests exist; I just didn't write them. AI writes the tests now. I review them. This sounds like negligence, but it's actually a skill shift: from test-writing to test-reviewing. What I've lost is muscle memory and syntax fluency. What I've gained is coverage I never would have written and time for test strategy instead of test implementation. The uncomfortable truth: I'm a worse test-writer and a better test-reviewer than I was a year ago. These are different skills, and the market hasn't caught up. --- ## The Confession I haven't written a test in a year. Let me sit with that for a moment. For a developer who built an entire philosophy around "Bugs as Missing Test Cases," this sounds like professional negligence. Like I've abandoned the craft. But here's the thing: - **1,358 test files** in the codebase (1,001 Ruby + 357 JavaScript) - **~12,000 tests** passing on every build - Integration, models, jobs, services, helpers, mailers, linters—all covered - All of them running. All of them green. The tests exist. I just didn't write them. --- ## What Actually Happened AI writes the tests now. I review them. This isn't vibe-testing—accepting whatever the AI generates because it looks plausible. This is a systematic workflow: 1. I implement a feature (or AI does, and I verify) 2. I describe what the tests should cover 3. AI generates the test file 4. I review the generated tests 5. I run them, verify they test what matters, request changes if needed 6. Tests get committed The 20-30 minutes I used to spend writing a test file? Now I spend 10 minutes reviewing one. The output is the same—often better, because AI doesn't get bored writing the tedious edge cases. But the skill has fundamentally changed. I used to write good tests. Now I catch bad tests. Same outcome. Different process. Different expertise. --- ## What I Review For When AI generates a test file, I'm not checking syntax. I'm checking judgment. **Does it test the right thing?** AI tests what it sees. I know what the code is *supposed* to do, which isn't always what it does. The test needs to verify intent, not just current behavior. **Does it catch the edge cases I know about?** I've lived in this codebase for years. I know where the dragons are. If the AI-generated tests don't poke at the known failure modes, they're not good enough. **Is it testing behavior or implementation?** Bad tests break when you refactor. Good tests break when you break functionality. AI often couples too tightly to implementation details—I have to push back toward behavior. **Will it break for the wrong reasons?** Date-dependent tests. Order-dependent assertions. Hardcoded values that become false in six months. AI doesn't feel the pain of maintaining tests over time. I do. This review process takes domain knowledge. It takes experience with what breaks. It takes judgment that AI doesn't have. --- ## What I've Lost I won't pretend this shift is pure gain. There are real losses. **Muscle memory for test syntax.** I used to type `assert_equal` without thinking. Now I sometimes pause on the argument order. The syntax has faded because I don't practice it. **The "thinking through tests" design benefit.** Writing tests first—real TDD—forces you to think about the interface before the implementation. When AI writes tests after the fact, you lose that design pressure. The code might be tested, but it might not be well-designed. **Edge case intuition from the writing process.** Something happens when you manually type out test cases. You think of cases you wouldn't have thought to ask for. The writing *is* the thinking. Reviewing someone else's tests (even AI-generated ones) doesn't trigger the same discovery process. **Speed when AI isn't available.** If I had to write tests without AI tomorrow, I'd be slower than I was a year ago. That dependency is real. --- ## What I've Gained But the gains are also real. **Coverage I wouldn't have written.** Be honest: how many tedious edge cases do you skip because life is short? AI doesn't skip. It will generate the boring permutation tests that you technically know you should write but never do. My coverage is higher because AI has more patience than I do. **Faster iteration on test quality.** "This test is too coupled to implementation. Rewrite it to test behavior." That sentence takes three seconds to type and gets me a better test faster than rewriting it myself. **More time for test strategy.** What should we test? How should the test suite be organized? What's the failure mode we're not covering? These strategic questions matter more than the syntax. Offloading the typing lets me think at a higher level. **Fresh perspective.** AI suggests test cases I wouldn't have thought of. It doesn't have my blind spots. Sometimes it tests something and I think: "Oh. Yeah. That could definitely break." The collaboration surfaces gaps in my own thinking. --- ## The Uncomfortable Truth Here's what I need to say out loud: **I'm a worse test-writer than I was a year ago.** If you put me in a room with a whiteboard and asked me to write test cases from scratch, I'd be rustier than I was in 2024. The skill has atrophied from disuse. **I'm a better test-reviewer than I was a year ago.** I've spent a year reading and critiquing AI-generated tests. I know what bad AI tests look like. I know what's missing, what's over-specified, what will break in six months. My review skills are sharper than ever. **These are different skills.** Writing and reviewing are not the same expertise. The market doesn't recognize this yet. Job interviews still ask you to write tests on a whiteboard. They don't ask you to review AI-generated tests for quality. But the job has changed. The interview just hasn't caught up. --- ## What This Means Testing expertise isn't obsolete. It's transformed. The knowledge of *what* to test matters more than ever. Knowing which edge cases break, understanding the domain, recognizing when a test is too fragile—this judgment is exactly what AI lacks. The expertise is the same; the expression is different. **Knowing what to test matters more than knowing how to type it.** I still apply "Bugs as Missing Test Cases" every day. When something breaks, I still ask: "What test would have caught this?" The philosophy is unchanged. But the hands that write the test are different now. **Quality judgment can't be automated (yet).** AI can generate a test that passes. It can't generate a test that will still be valuable in two years. It can't weigh the maintenance cost against the coverage benefit. It can't feel which tests are worth having. That judgment is human. **The skill transfer is real.** A developer who never learned to write tests won't be a good test reviewer. You need to have written bad tests to recognize them. The foundation is still required—it's just not the daily practice anymore. --- ## Connection to the Larger Theme This is part of a broader shift I've been writing about: from implementor to orchestrator. I used to write code. Now I verify code I didn't write. The pattern is the same. The skill is verification and judgment, not production. This is another case of the fitness-of-use question: How do you evaluate quality when you didn't create the artifact? The Reality Filter I wrote about for code applies equally to tests. Spot-check the assertions. Probe the edge cases. Ask "what's your source for this test case?" The answer isn't to reject AI-generated tests. It's to develop systematic verification skills. To become a better reviewer because you're no longer a writer. I haven't written a test in a year. But I've reviewed a thousand of them. And the codebase is better for it. --- *[Author bio / contact placeholder]* --- ## Revision Notes **What this piece does:** - Provocative hook that reframes into nuance - Honest about losses (muscle memory, TDD benefits, dependency) - Specific about what review actually involves - Connects to larger implementor→orchestrator theme - Links to Reality Filter and 2500 Hours pieces **Open questions for next draft:** - Add specific examples of bad AI tests caught? - Include concrete before/after of review process? - Too defensive about the losses? Or not honest enough? - Add section on team dynamics (how does this affect code review)?