[tananan]

I generally work on internal-use Python codebases. I would much rather do some basic validation and fail loudly if anything I didn’t account for happens.

One of the issues I run into is that agents are predisposed to write extremely defensive, odd-case-handling code, and that makes me recoil when I have to look into it: the SNR ratio is very low. You get a spaghetti that is unlikely to crash, but really hard to extract the gist of. And finding more global bugs can be difficult because what should be structural impossibilities can be coerced into silent skips.

The article made me think that maybe what I’d like is a language where validation doesn’t triple the lines of code you have to write.

[gumby]

> …agents are predisposed to write extremely defensive, odd-case-handling code… the SNR ratio is very low. You get a spaghetti that is unlikely to crash, but really hard to extract the gist of. And finding more global bugs can be difficult because what should be structural impossibilities can be coerced into silent skips.

Have you tried asking for a summary of the logic being relied on, and asking LLM to simplify the code?

I’m 85% joking, of course, given the current state of automated code generation and the terrible summaries you usually when asking for a summary of text. But in theory that’s what they are supposed to do.

[middayc]

I agree, if you don't have a clear view on what you want to do on certain exception, or you are adding information or translating/wrapping error into a higher level one, then it can be cleaner to let program fail naturally in that specific case. Catch, print error and panic makes no sense in many cases and can make the exception less clear when it happens.