Hacker News Reader

Comment by zmmmmm | Hacker News Reader

The tendency to over-engineer and over-build is one of the main challenges I'm seeing. When it comes for free, why not build a class hierarchy of 8 classes each with a 200 line unit test? Something I might have previously thought really hard to minimalise down to 30 lines is now bloated out to hundreds or even thousands.

Previously, pretty much everyone all agreed on YAGNI and KISS because code was so expensive to create and more expensive to maintain. Now the code generation is "free" - but at a design level, YAGNI and KISS do still matter. But they are enforced now only by sheer will power. You have to actively restrain the code from being created if you don't want it. Perfectly good code - I can't even fault it. I just know, if it doesn't need to exist yet, it's a mistake to create it earlier than needed.

View on HN

Like that quote in Le Petit Prince, real intelligence is knowing what not to build, what can be eliminated until only what's necessary is left.

> La perfection est atteinte non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.

> Perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

That quotation is in fact from "Wind, Sand, and Stars", the memoir of the same author.

On the same theme:

> the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience

- Einstein

> I would have written a shorter letter, but did not have the time

- Pascal

> Simplicity is a great virtue but requires hard work to achieve and education to appreciate, and, to make matters worse, complexity sells better.

- Dijkstra.

Thank you! The GP quote sounded completely unLittlePrince-like! I can believe it as a quote from Saint-Exupery.

Thanks for the correction, I haven't read his memoir so must have gotten the quote second hand. Searching now, perhaps the book is titled differently in translation.

Airman's Odyssey ― Antoine de Saint-Exupéry

And I appreciated the lovely quote by Einstein, about "irreducible basic elements". And Dijkstra on complexity. I often think of "finding the right primitives" in my work, and it's great to see the idea expressed so well by different people.

Honestly these are some of the hardest suggestions in the world and very few developers ever achieve removing as much as possible. In the past very hard compute limits did some of this, but those days died long ago when ram and CPU were subjected to Moores law.

Maybe it's just the crowd that gets on HN, but it seems a lot of developers think much more highly of themselves than is strictly necessary.

I don't think anybody tries into KISS, most software is bloated and LLMs copy it, they fundamentally can't think out of the box.

At the end of the day your work is your work. If you tell Claude or whatever to do a thing it will do that thing however you tell it to do the thing.

You can choose to ignore the fine details and just tell it what to build, or you can spend more time and effort and tell it how to do things, you can ask it to create a plan, review the plan and ask for changes etc, you can review the implementation and ask for changes there. You can simply tell it you don't like how a feature is implemented and ask it for suggestions on how to improve it, include what you don't like about it so it has direction.

It's all about the effort you put in. LLMs are able to write clean beautiful and efficient code, they just can't necessarily do exactly what you want on the first try without any direction. That's why you should figure out what you want, ask for what you want and make sure it's actually building what you want.

That's always been my concern - there's just so much garbage code out there and very few signals about which of it is well written and which is not ... so LLMs will just regurgitate the good enough code that it's been trained on.

Now would be the ideal time for everybody to give it negative feedback when bad code is returned but I'm afraid not enough people care and we'll just settle with what works just like we always have.

I don't think that's it. The context that LLMs work with is simply too small, and can't get bigger. Harnesses and the models themselves are bolting structure over it manually; real people are inventing design machines that are a lot more deterministic than they look, and LLMs are just filling them in.

The design machines aren't good enough yet; and their progress has little relationship to LLMs at all. Designing computer programs and the proper level of abstraction for the easiest maintenance, flexibility and debugging is simply an open problem. There's nothing to train LLMs on that is smaller than the size of an entire program, and its history of code changes.

Get a few of those, figure out a way to analyze and reduce the patterns and lessons in them, and train on that maybe. Until then, there's no way for an LLM to figure out what lacking a particular abstraction is going to end up costing.

This is so true. I've been seeing LLM generated code that does way too much, yet still cant accomplish the stated goals. "maximally flexible" plugin systems, that are too complicated to reasonably write a plugin for quickly, when one could have just built in the needed functionality in a few hundred lines.

When endless bootstrapping and framing is free, you end up generating the most beautiful scaffold while ignoring the building behind the scaffold.

I agree with over-engineering within a feature, but sometimes "overbuilding" additional features that you think your users might actually need is a virtue in the LLM era. Small backlog items can be cleared within hours concurrently with a dozen other tasks, so why not build them? It is a combination of dozens of these quality-of-life features over time that makes a product delightful to use, and whereas previously you might not have had the time for them, now you do.

I think this sorta cuts both ways too. Sometimes AI code has shown me that no, I in fact don't need that big class hierarchy and speculative plumbing that I thought I might need to get the job done.

Keeping the volume of code down is definitely a challenge though.

Reply on news.ycombinator.com