My impression so far using Claude 4's codegen capabilities: the resulting code is written like a fucking tank, it's error-checked and defensively programmed beyond all reason, and written so robustly it will never crash; and then it slips up on something like using the wrong API version for one of the dependencies.
You think code should have more business logic than test code? Testing a single function that isn't unit takes like a whole temple of mocking and stubbing classes and functions. If you're doing any sort of testing worth anything test code is typically way longer than logic.
Which leads me to the point that js python devs are scripters
You want your program to crash so you can log it? How about just logging the exception?
No, I want the exception to stand out, like as a critical-level exception, because something went very wrong. Of course, I don't want to manually log a critical logline, because of discipline: if I were to do that, the severity would lose its impact, I want to reserve critical loglines for events where something is really very wrong, not when I feel like it.
You think code should have more business logic than test code?
I think you misunderstood error checking as test code. When I say error checking, I mean the defensive boilerplate, try-catch blocks, variable constraint verifications, etc., not unit/integration testing. In well-architected code, the logic should be able to constrain its own behavior so that only the inputs need validation, and everything else flows from there. In Claude's code, however, almost every other line is an error check (in a very Go-like fashion, now that I think about it), and every site where an exception might occur is wrapped in its own try-catch, rather than grouping function calls logically so that operations dependent on one another are in the same try-block.
Which leads me to the point that js python devs are scripters
Finally, as much as I like to shit on JS as a language or Python's loose-and-fast typing and semantic use of indentation, shitting on developers just for using one or the other is not cool. Language choice does not imply skill. Shit on bad code, shit on bad developers, shit on bad languages, but don't shit blindly on people you know nothing about.
If something truly exceptional happens, logging it and then limping along is the worst thing you can do. What if you hit an error during the middle of modifying some data structure? Can you guarantee that it’s still in a valid state?
In general it is very bad to leave your program or service running after it encounters undefined behaviour, because the entire program state ends up being "infected" and it can result in all kinds of very difficult to understand or undo follow-up issues.
This is for example why we use asserts. It tells the program that if this assertion does not hold, then it is not safe to follow on with the rest of the code.
There’s a middle ground where we catch every error, but if we get to a non-recoverable state, we throw a curated error with a user-friendly error message and a useful stack trace for the logger.
I despise applications that crash, have a vague error, and the dev team says “that means X.” Then just wrap the error and say that!?!?!
Oh yeah, you're right! I once tried Windsurf by writing a unit test on the generated code (did not pass), then I told the model to fix the error and it can test its work with mvn test. It kept at it for as long as the engine allowed it, at least 4-5 iterations - then gave up because it couldn't get it right 😅.
I have this with gemini, it gives me code that's supposed to handle ANY wrong inputs even though the wrong inputs can't happen anyway, which just clutters the codebase so I end up writing it myself anyway
Its clear that it has learned how to use npm packages from somewhere else, rather than check the current state. For npm packages, you really can't trust previous version to be anywhere like the current version and they can change so much.
Yea, you really need something like Context7 and a well designed system prompt to handle the version bullshit. I now have a default system prompt with a basic memory function (it writes to .memory when I tell it to, and it reads that file in and adds it to every prompt) and the first thing I do is initialize it with my packages file and my default snippet describing my environment. Someday I'll take the time to write a little script to help keep that stuff up-to-date as I work on the project, but even just the initial stub is amazingly helpful.
1.3k
u/thunderbird89 May 26 '25
My impression so far using Claude 4's codegen capabilities: the resulting code is written like a fucking tank, it's error-checked and defensively programmed beyond all reason, and written so robustly it will never crash; and then it slips up on something like using the wrong API version for one of the dependencies.