←back to thread

The highest quality codebase

(gricha.dev)
559 points Gricha | 4 comments | 08 Dec 25 21:33 UTC | HN request time: 0.001s | source
Show context
xnorswap ◴[11 Dec 25 16:02 UTC] No.46233056[source]▶
Claude is really good at specific analysis, but really terrible at open-ended problems.

"Hey claude, I get this error message: <X>", and it'll often find the root cause quicker than I could.

"Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest.

It suggested enthusiastically a library for <work domain> and it was all "Recommended" about it, but when I pointed out that the library had been considered and rejected because <issue>, it understood and wrote up why that library suffered from that issue and why it was therefore unsuitable.

There's a significant blind-spot in current LLMs related to blue-sky thinking and creative problem solving. It can do structured problems very well, and it can transform unstructured data very well, but it can't deal with unstructured problems very well.

That may well change, so I don't want to embed that thought too deeply into my own priors, because the LLM space seems to evolve rapidly. I wouldn't want to find myself blind to the progress because I write it off from a class of problems.

But right now, the best way to help an LLM is have a deep understanding of the problem domain yourself, and just leverage it to do the grunt-work that you'd find boring.

replies(21): >>46233156 #>>46233163 #>>46233206 #>>46233362 #>>46233365 #>>46233406 #>>46233506 #>>46233529 #>>46233686 #>>46233981 #>>46234313 #>>46234696 #>>46234916 #>>46235210 #>>46235385 #>>46236239 #>>46236306 #>>46236829 #>>46238500 #>>46238819 #>>46240191 #
plufz ◴[11 Dec 25 16:09 UTC] No.46233156[source]▶
I think slash commands are great to help Claude with this. I have many like /code:dry /code:clean-code etc that has a semi long prompt and references to longer docs to review code from a specific perspective. I think it atleast improves Claude a bit in this area. Like processes or templates for thinking in broader ways. But yes I agree it struggles a lot in this area.
replies(1): >>46233296 #
airstrike ◴[11 Dec 25 16:18 UTC] No.46233296[source]▶
Somewhat tangential but interestingly I'd hate for Claude to make any changes with the intent of sticking to "DRY" or "Clean Code".

Neither of those are things I follow, and either way design is better informed by the specific problems that need to be solved rather than by such general, prescriptive principles.

replies(2): >>46234035 #>>46236034 #
1. SketchySeaBeast ◴[11 Dec 25 17:09 UTC] No.46234035[source]▶
I'm not sure how to interpret someone saying they don't follow DRY. Do you meant taking it to the Zealous extreme, or do you abhor helper functions? Is this a "No True Scottsman" thing?
replies(2): >>46234661 #>>46235561 #
2. Pannoniae ◴[11 Dec 25 17:54 UTC] No.46234661[source]▶
Not GP but I can strongly relate to it. Most of the programming I do is related to me making a game.

I follow WET principles (write everything twice at least) because the abstraction penalty is huge, both in terms of performance and design, a bad abstraction causes all subsequent content to be made much slower. Which I can't afford as a small developer.

Same with most other "clean code" principles. My codebase is ~70K LoC right now, and I can keep most of it in my head. I used to try to make more functional, more isolated and encapsulated code, but it was hard to work with and most importantly, hard to modify. I replaced most of it with global variables, shit works so much better.

I do use partial classes pretty heavily though - helps LLMs not go batshit insane from context overload whenever they try to read "the entire file".

Models sometimes try to institute these clean code practices but it almost always just makes things worse.

replies(1): >>46235262 #
3. SketchySeaBeast ◴[11 Dec 25 18:43 UTC] No.46235262[source]▶
OK, I can follow WET before you DRY, to me that's just a non-zealous version of Don't Repeat Yourself.

I think, if you're writing code where you know the entire code base, a lot of the clean principles seem less important, but once you get someone who doesn't, and that can be you coming back to the project in three months, suddenly they have value.

4. airstrike ◴[11 Dec 25 19:00 UTC] No.46235561[source]▶
I just think DRY is overblown. I just let code grow. When parts of it become obvious to abstract, I refactor them into something self contained. I learned this from an ice wizard.

When I was younger, writing Python rather than Rust, I used to go out of my way to make everything DRY, DRY, DRY everywhere from the outset. Class-based views in Django come to mind.

Today, I just write code, and after it's working I go back and clean things up where applicable. Not because I'm "following a principle", but because it's what makes sense in that specific instance.