Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The silent death of good code

amit.prasad.me

Post reply on HN
Print view View original

81–90 of 105 posts

Re: The silent death of good code

#81

Post by itsboring »

anonymous908213 wrote: post #72
love2read wrote: post #61

Earlier quoted context omitted.

So funny when people point at electron as if it singlehandedly makes every program unusable. Also, I would assume there are not many significant pages on $B/Trillion companies that take 5 seconds to load text that are used frequently. > I know I'm tired of reading them, but don't people get bored of writing them? People never get tired of reading or commenting on commentary on their hobbies.

New Reddit and Outlook.com are two off the top of my head. It is not uncommon to be looking at a spinner for several seconds. There are other websites that are not primarily for text but are still insane. Twitch.TV, an old favorite of mine, now routinely takes 10+ seconds despite having Amazon money behind it. Youtube routinely takes several seconds to load the page, which is still unacceptable even for a video websi…

Not to mention that it seems like everything has to go through like 10 redirects just to log in, and then you have to dismiss various pop-ups before you can just do whatever you went there to do. Some will say that the last part is just a UX problem, but in my opinion, sluggishness is the king of UX prooblems.

On the topic of Electron, I’m really torn. I can’t help but feel some gratitude for the fact a few of the work tools I need work on Linux (stuff like Slack, Teams, Zoom).

Re: The silent death of good code

#82

Post by sibeliuss »

jmspring wrote: post #77
sibeliuss wrote: post #8

> This same colleague then invested time into understanding the kernel subsystem, the exact reasons why the original C program was written how it was, and rewrote the Rust translation himself. The difference was night and day; the code flowed naturally, explained itself and the underlying subsystems, and may genuinely be some of the nicest parts of the entire codebase. This is the point that everybody needs to calm d…

I'm not sure how this guideline makes sense. LLMs are great at dumb things I shouldn't have to type but can be well defined before they write something. This statement, makes almost zero sense - A perfectly reasonable rule in software organizations is: For greenfield code, LLMs are strictly required for 1st-pass prototyping (also required!). And then: Hand writes (within reason) for production code. Your company will…

The statement makes sense with software that has users, and scales past a certain size. Claude is the map, not the territory.

Re: The silent death of good code

#83

Post by phendrenad2 »

Good "code" may be going away, but good architecture isn't. There's still tremendous value in learning good software engineering practices. Extreme Programming, Agile, Design Patterns, Antipatterns, TDD, SOLID, DRY, and all of the classics by Martin, Fowler, Beck, Freeman/Pryce, Brooks, Evans, McConnell, Thomas/Hunt. People who let an agent determine their architecture are in for a world of hurt.

Re: The silent death of good code

#84

Post by anon-3988 »

My observation is that "good code for human" != "good code for LLM"

For example, I think LLM benefit from having very verbose code that repeats and repeats the same important code/comments/strings/exceptions all over the place. We are going to produce more code than ever before.

From what I have seen so far, productivity will go up but there will more and more rot underneath the systems that we build. The fact that LLMs are tireless is both a blessing and a curse. It will never stop writing code until you tell it to.

We will arrive in a future where we NEED LLMs to understand our own code. At that point, do you hire another highly skilled and expensive individual to manage the complexity of your codebase or spend 100$ more ask an LLM to fix it (and promise we will do the refactor in the future!)

In a sense, we have had this before. We no longer write assembly. We don't program against the hardware anymore, even if you are writing C, you are writing against the abstract C machine. We are no longer writing against any machine, it is more of a concept now. This is just another step of abstraction. "Can you please change this list to be sorted alphanumerically" will no longer involve a calculated change in UI code. It is more like telling the computer what to do.

The way I am using LLM now is to get the rough general direction. "Can you please write me an NFS driver for this new filesystem with stub functions", then it spits out ~500 lines of code that I can now study. After I am done learning, I will usually rewrite everything myself. But this is probably not productive for future LLM uses. It might be better to keep the code as is if I want to keep using LLMs to iterate.

Frankly, I don't know how I feel about this. It is probably just a part of getting older and seeing the world move past you? For god's sake I am not even 30 yet.

Re: The silent death of good code

#86

Post by OptionOfT »

EPWN3D wrote: post #79

No one likes good code because it takes a lot of upfront time. - PMs hate it because you're busy putting up scaffolding instead of painting - Managers hate it because they have to cover for it - Other engineers hate it because they could be doing it better - VPs and directors hate it because they can't think beyond the release cycle, so the engineer is an architecture astronaut who should focus There is basically no…

I like good code because it makes me not get pinged at 2AM when things fall over.

Re: The silent death of good code

#87

Post by nemothekid »

IhateAI_3 wrote: post #78
charcircuit wrote: post #68

Earlier quoted context omitted.

That commenter is try is trying to imply that AI agents are a form of crutch. Like if you are bad at programming you use an AI agent to program for you. In reality programmers of all skill levels are migrating to using AI agents for programming.

Just because a high skilled programmer can use an LLM with some effectiveness doesnt mean someone with less skills will be able to match their ability. You LLM-kiddies are worse than nft people in 2021 claiming they're making art. I really cant wait until the inference providers 5x their prices and you guys realize you're completely incompetent and that you've tied your competency 1:1 to the quality and quantity of t…

My motivation for learning how to use agents has nothing to do with my ability. In fact I didn't think LLMs provided value for a very long time - the work I do tends to be embedded in nature ad LLMs were really bad at generating useful code.

Opus 4.5 changed that and like every programming tool I've used in the past, I decided to sit seriously with it and try and learn how to use it. If coding agents turn out to be a bust, then oh well, it goes into the graveyard of shit I've learned that has gone nowhere (Angular, Coffeescript, various NoSQL databases, various "big data" frameworks). Even now one of my favorite languages is Rust, but I really took the plunge into the language before async/await and people also called it overhyped.

If coding agents are real, I don't want to be struggling to learn how to use them while everyone else is being 10x more productive. There's no downside to learning how to use them for me. I've invested my time in many hyped software frameworks, some good and some bad.

Re: The silent death of good code

#88

Post by nemothekid »

amitprasad wrote: post #19
nemothekid wrote: post #6

This is something I've been thinking about as I start to adopt more agent-first coding. There is a real advantage to having good code especially when using agents. "Good Code" makes iteration faster, the agent is unlikely to make mistakes and will continue to produce extensible code that can easily be debugged (by both you and the agent). A couple months ago I refactored a module that had gotten unweildly, and I trie…

Right: Having "Good Code" is an investment into future velocity. IMO we shouldn't strive to make an entire codebase pristine, but building anything on shaky foundations is a recipe for disaster. Perhaps the frontier models of 2026H2 may be good enough to start compacting and cleaning up entire codebases, but with the trajectory of how frontier labs suggest workflows for coding agents, combined with increasing context…

>Perhaps the frontier models of 2026H2 may be good enough to start compacting and cleaning up entire codebases

I don't think this will happen - or rather I don't think you can ask someone, human or machine, to come in and "compact and clean" your codebase. What is "clean" code depends on your assumptions, constraints, and a guess about what the future will require.

Modularity where none is required becomes boilerplate. Over-rigidity becomes spaghetti codes and "hacks". Deciding what should be modular and what should be constant requires some imagination about what the future might bring and that requires planning.

Re: The silent death of good code

#89

Post by IhateAI_6 »

charcircuit wrote: post #80
IhateAI_3 wrote: post #78

Earlier quoted context omitted.

Just because a high skilled programmer can use an LLM with some effectiveness doesnt mean someone with less skills will be able to match their ability. You LLM-kiddies are worse than nft people in 2021 claiming they're making art. I really cant wait until the inference providers 5x their prices and you guys realize you're completely incompetent and that you've tied your competency 1:1 to the quality and quantity of t…

>with some effectiveness doesnt mean someone with less skills will be able to match their ability I never said they would. >Of course you'll still be coping by claiming you're so productive using some budget kimi 2.5 endpoint I would. I already run my persistent agent on Kimi 2.5 and use Kimi CLI.

okay llm-kiddie, you're doing magic tricks on yourself like a toddler who's entertained by the sound the Velcro on their shoes makes. Have fun frying your brain and lighting money on fire.

Re: The silent death of good code

#90

Post by yoyohello13 »

amitprasad wrote: post #55
ElatedOwl wrote: post #47

Earlier quoted context omitted.

The author effectively argues deep thinking is dead, that people are no longer going to take the time to understand the problem and solution space before they solve it. I think that’s untrue, I think it’s /more/ important than before. I think you’re going to have significantly more leverage with these tools if you’re capable of thinking. If you’re not, you’re just going to produce garbage extremely fast. The use of t…

Just because you or I may invest effort into deep-thinking, it does not mean that others will. I'm not worried about this at Modal, but I am worried about this in the greater OSS community. How can I reasonably trust that the tools I'm using are built in a sound manner, when the barrier to producing good-looking bad code is so low

We’re already there. Seeing OpenClaw and the new thing LocalGPT on the front page. It’s clear these projects are pretty heavily vibe coded and I have no trust that they are tested, secure or even work as advertised. It’s going to suck when all projects become that. When you can’t trust that a library works as advertised.
Post reply on HN