←back to thread

The highest quality codebase

(gricha.dev)
559 points Gricha | 3 comments | 08 Dec 25 21:33 UTC | HN request time: 0s | 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 #
pdntspa ◴[11 Dec 25 16:23 UTC] No.46233365[source]▶
That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code.

I am phenomenally productive this way, I am happier at my job, and its quality of work is extremely high as long as I occasionally have it stop and self-review it's progress against the style principles articulated in its AGENTS.md file. (As it tends to forget a lot of rules like DRY)

replies(12): >>46233446 #>>46233448 #>>46233642 #>>46233652 #>>46233782 #>>46234010 #>>46234898 #>>46235480 #>>46238997 #>>46241434 #>>46241981 #>>46242791 #
FeteCommuniste ◴[11 Dec 25 16:28 UTC] No.46233448[source]▶
Maybe I'm weird but I enjoy "actually writing the code."
replies(6): >>46233475 #>>46233559 #>>46233598 #>>46233879 #>>46234180 #>>46236874 #
nyadesu ◴[11 Dec 25 16:35 UTC] No.46233559[source]▶
In my case, I enjoy writing code too, but it's helpful to have an assistant I can ask to handle small tasks so I can focus on a specific part that requires attention to detail
replies(1): >>46233762 #
FeteCommuniste ◴[11 Dec 25 16:49 UTC] No.46233762[source]▶
Yeah, I sometimes use AI for questions like "is it possible to do [x] using library [y] and if so, how?" and have received mostly solid answers.
replies(3): >>46233841 #>>46233909 #>>46234102 #
stouset ◴[11 Dec 25 16:59 UTC] No.46233909[source]▶
Or “can you prototype doing A via approaches X, Y, and Z, and show me what each looks like?”

I love to prototype various approaches. Sometimes I just want to see which one feels like the most natural fit. The LLM can do this in a tenth of the time I can, and I just need to get a general idea of how each approach would feel in practice.

replies(1): >>46234137 #
skydhash ◴[11 Dec 25 17:16 UTC] No.46234137[source]▶
> Sometimes I just want to see which one feels like the most natural fit.

This sentence alone is a huge red flag in my books. Either you know the problem domain and can argue about which solution is better and why. Or you don't and what you're doing are experiment to learn the domain.

There's a reason the field is called Software Engineering and not Software Art. Words like "feels" does not belongs. It would be like saying which bridge design feels like the most natural fit for the load. Or which material feels like the most natural fit for a break system.

replies(3): >>46234299 #>>46234601 #>>46236969 #
1. fluidcruft ◴[11 Dec 25 17:49 UTC] No.46234601{3}[source]▶
For example sometimes you're faced with choosing between high-quality libraries to adopt and it's not particularly clear whether you picked the wrong one until after you've tried integrating them. I've found it can be pretty helpful to let the LLM try them all and see where the issues ultimately are.
replies(1): >>46235990 #
2. skydhash ◴[11 Dec 25 19:27 UTC] No.46235990[source]▶
> sometimes you're faced with choosing between high-quality libraries to adopt and it's not particularly clear whether you picked the wrong one until after you've tried integrating them.

Maybe I'm lucky, but I've never encountered this situation. It has been mostly about what tradeoffs I'm willing to make. Libraries are more line of codes added to the project, thus they are liabilities. Including one is always a bad decision, so I only do so because the alternative is worse. Having to choose between two is more like between Scylla and Charybdis (known tradeoffs) than deciding to go left or right in a maze (mystery outcome).

replies(1): >>46236296 #
3. fluidcruft ◴[11 Dec 25 19:54 UTC] No.46236296[source]▶
It probably depends on what you're working on. For the most part relying on a high-quality library/module that already implements a solution is less code to maintain. Any problems with the shared code can be fixed upstream with more eyeballs and more coverage than anything I build locally. I prefer to keep my eyeballs on things most related to my domain and not maintain stuff that's both ultimately not terribly important and replaceable (if push comes to shove).

Generally, you are correct that having multiple libraries to choose among is concerning, but it really depends. Mostly it's stylistic choices and it can be hard to tell how it integrates before trying.