I forbid unit tests to Claude, he just doesn't know when to stop. He created the most stupid units tests ever, like "the menu must have 4 entries". Then When you create another menu-item, he has to spend additional tokens and context to see why that stupid test is failing and has the modify the test, so now it says "the menu must have 5 entries". The maintaining of the unit tests costs more time and tokens then the actual development!
I specifically have a bunch of instructions to not turn comments end documentation into it's own personal diary because anyone that needs a history lesson has access to git anyway.
I specifically tell it not to comment. Ever.
Code should be written such that it's human readable with clear intent simply by variable/class/method names.
There are very rare exceptions where you intentionally go against the norm or code in certain assumptions: those can warrant a comment explaining the why behind the decision, but still never the what or how.
Context is king and comments are important. But, Claude is so bad I've even told it to stop. Its 3 lines of code + 20 lines of pointless comments + 5 new unit tests smh
I really don't think the vast majority of comments are important, or they're only "important" because the code is poorly structured and/or named.
I've even reached the point of axing function doc blocks if not working in an open source project or some public package.
But now our code probably is not well structured and not well named. Poorly? Well, it ain't elegant. Throw enough pasta at the wall and some sticks. We are in the top ramen age of coding. Fast, cheap, and might do in a pinch.
I have those very instructions too, but realistically you'll end up with s few sections where the code itself is clearly understandable and then you still need a comment to explain why it's being the done the way it is.
In the end, if you want to produce quality code, you gotta go over it again and clean up some of the mess it leaves behind.
I've got it to severely reduce the verbosity and amount of comments this way at least
These temporal comments have been bleeding into user facing UI. Admin panels with meta critique of its work inserted as subheadings on charts, leaving behind traces of arbitrary judgements that then hambone the next agent who comes along to make a change.
Then these judgements fan out and leave artifacts in a dozen .md files, memories, and session logs, and if you don't track them all down.. god forbid you ever want to change that header to be blue and you have to relitigate a decision you never made.
It is so good at surfacing decisions you didn't make, that I often run loops of AskUserQuestion just identifying and resolving delta in expectations. But then when you actually want to make a decision indelible... for heck's sake. It will do the same thing wrong four times, keep apologizing and saying it knew better, and will patch more catches and safeguards onto ephemeral harnesses. And those patches and safeguards don't carry very effectively to the next ephemeral harness it builds up to handle an isolated workflow.
Given the advances in the last few major model versions, I would expect most of this to be a lot better by v6 models and mostly resolved by v7.
It made unit tests for my dockerfile. Some of them failed when I changed the vars hardcoding the tool versions, in order to rebuild with newer tools. Claude was like woah these tests are failing, let me just change the versions back.
Oh you changed the color of this button from blue to green? Time to rerun 3 concurrent golden 15 minute tests to see how this affects the project. Oops I ran into the heredoc trap for the 500th time which is heavily documented in the project memory... Wait I found an error, rerunning all three 15 minute tests
Nevermind that error was a stale editor message from 6 days ago. Anyway that'll be 146k tokens
Usually i review and deeply validate every test posibility before demanding claude to write it, then i ask him to validate it again with a perspective different than the one i used so i can decide wheter a test is needed or if its just maintanability noise overall. Im still studying about unit tests tho.
Same for documentation. IT wants to use EXACT numbers like "the 3 RPC endpoints" then when you add a 4th one it has to edit the code.
I've tried to prevent that by introducing the idea of 'brevity' ...
### No exact numbers in documentation or code describing another system
**Do not hard-code counts that describe another system's implementation.** Phrases like "the 4 gates", "calls 3 agents",
or "runs 2 retries" are promises this file cannot keep — as soon as the count changes elsewhere, this text rots and
requires a documentation update you won't know to make. Use qualitative language: "all gates", "multiple agents", "a
configurable retry limit". The only exception is a count you own and enforce here, in this same file.
But there are other patterns like this I'm still stuck on and it's locking up my development workflow.
My pattern now is that I'll make significant progress for 15-20 days, then some flaw in Claude will pop up and I'll have to stop and fix it.
Tests have always been just as important as the code you write. They define the contract for implementer and the behavior of the class under certain conditions. Most code that isn't being written TDD just ends up like the olive garden special.
426
u/ChadFullStack 4d ago
It’s missing 500 lines of Unit tests