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

The Bitter Prediction

4zm.org

Post reply on HN
Print view View original

91–100 of 189 posts

Re: The Bitter Prediction

#91

Post by wizzwizz4 »

mckn1ght wrote: post #89
wizzwizz4 wrote: post #82

Earlier quoted context omitted.

I find legacy systems fun because you're looking at an artefact built over the years by people . I can get a lot of insight into how a system's design and requirements changed over time, by studying legacy code. All of that will be lost, drowned in machine-generated slop, if next decade's legacy code comes out the backside of a language model.

That’s fine if you find that fun, but legacy archeology is a means to an end, not an end itself.

Legacy archaeology in a 60MiB codebase far easier than digging through email archives, requirements docs, and old PowerPoint files that Microsoft Office won't even open properly any more (though LibreOffice can, if you're lucky). Handwritten code actually expresses something about the requirements and design decisions, whereas AI slop buries that signal in so much noise and makes "archaeology" almost impossible.

When insight from a long-departed dev is needed right now to explain why these rules work in this precise order, but fail when the order is changed, do you have time to git bisect to get an approximate date, then start trawling through chat logs in the hopes you'll happen to find an explanation?

Re: The Bitter Prediction

#92

Post by mckn1ght »

xg15 wrote: post #77

A question that came up in discussions recently and that I found interesting: How will new APIs, libraries or tooling be introduced in the future? The models all have their specific innate knowledge of the programming ecosystem from the point in time where their last training data was collected. However, unlike humans, they cannot update that knowledge unless a new finetuning is performed - and even then, they can on…

There will still be people who care to go deeper and learn what an API is and how to design a good one. They will be able to build the services and clients faster and go deeper using AI code assistants.

And then, yes, you’ll have the legions of vibe coders living in Plato’s cave and churning out tinker toys.

Re: The Bitter Prediction

#93

Post by mckn1ght »

wizzwizz4 wrote: post #91
mckn1ght wrote: post #89

Earlier quoted context omitted.

That’s fine if you find that fun, but legacy archeology is a means to an end, not an end itself.

Legacy archaeology in a 60MiB codebase far easier than digging through email archives, requirements docs, and old PowerPoint files that Microsoft Office won't even open properly any more (though LibreOffice can, if you're lucky). Handwritten code actually expresses something about the requirements and design decisions, whereas AI slop buries that signal in so much noise and makes "archaeology" almost impossible. When…

Code is code, yes it can be more or less spaghetti but if it compiles at all, it can be refactored.

Having to dig through all that other crap is unfortunate. Ideally you have tests that encapsulate the specs, which are then also code. And help with said refactors.

Re: The Bitter Prediction

#94

Post by 1oooqooq »

my ai-pilled co worker committed some code using a promise with a lambda that resolved it in a one liner, the parameter was called resolve.

for some reason he also included a import for "resolve from dns".

(the code didn't even need a promise there)

Re: The Bitter Prediction

#95

Post by wizzwizz4 »

mckn1ght wrote: post #93
wizzwizz4 wrote: post #91

Earlier quoted context omitted.

Legacy archaeology in a 60MiB codebase far easier than digging through email archives, requirements docs, and old PowerPoint files that Microsoft Office won't even open properly any more (though LibreOffice can, if you're lucky). Handwritten code actually expresses something about the requirements and design decisions, whereas AI slop buries that signal in so much noise and makes "archaeology" almost impossible. When…

Code is code, yes it can be more or less spaghetti but if it compiles at all, it can be refactored. Having to dig through all that other crap is unfortunate. Ideally you have tests that encapsulate the specs, which are then also code. And help with said refactors.

We had enough tests to know that no other rule configuration worked. Heck, we had mathematical proof (and a small pile of other documentation too obsolete or cryptic to be of use), and still, the only thing that saved the project was noticing different stylistic conventions in different parts of the source, allowing the minor monolith to be broken down into "this is the core logic" and "these are the parts of a separate feature that had to be weaved into the core logic to avoid a circular dependency somewhere else", and finally letting us see enough of the design to make some sense out of the cryptic documentation. (Turns out the XML held metadata auxiliary to the core logic, but vital to the higher-level interactive system, the proprietary binary encoding was largely a compression scheme to avoid slowing down the core logic, and the system was actually 8-bit-clean from the start – but used its own character encoding instead of UTF-8, because it used to talk to systems that weren't.)

Test-driven development doesn't actually work. No paradigm does. Fundamentally, it all boils down to communication: and generative AI systems essentially strip away all the "non-verbal" communication channels, replacing them with the subtext equivalent of line noise. I have yet to work with anyone good enough at communicating that I can do without the side-channels.

Re: The Bitter Prediction

#96

Post by [deleted] »

xg15 wrote: post #75
whiplash451 wrote: post #67

The thing is: the industry does not need people who are good at (or enjoy) programming, it needs people who are good at ( and enjoy) generating value for customers through code. So the OP was in a bad place without Claude anyways (in industry at least). This realization is the true bitter one for many engineers.

> generating value for customers through code. Generating value for the shareholders and/or investors , not the customers. I suspect this is the next bitter lesson for developers.

[deleted]

Re: The Bitter Prediction

#97

Post by [deleted] »

whiplash451 wrote: post #67

The thing is: the industry does not need people who are good at (or enjoy) programming, it needs people who are good at ( and enjoy) generating value for customers through code. So the OP was in a bad place without Claude anyways (in industry at least). This realization is the true bitter one for many engineers.

[deleted]

Re: The Bitter Prediction

#98

Post by keybored »

xg15 wrote: post #75
whiplash451 wrote: post #67

The thing is: the industry does not need people who are good at (or enjoy) programming, it needs people who are good at ( and enjoy) generating value for customers through code. So the OP was in a bad place without Claude anyways (in industry at least). This realization is the true bitter one for many engineers.

> generating value for customers through code. Generating value for the shareholders and/or investors , not the customers. I suspect this is the next bitter lesson for developers.

Yes, there you go. The users are just a propaganda proxy.

The bitter lesson is that making profit is the only directive.

Re: The Bitter Prediction

#99

Post by keybored »

zkmon wrote: post #62

It's not true that coding would no longer be fun because of AI. Arithmetic did not stop being fun because of calculators. Travel did not stop being fun because of cars and planes. Life did not stop being fun because of lack of old challenges. New challenges would come up. If calculators made the arithmetic easy, math challenges move to next higher level. If AI does all the thinking and creativity, human would move to…

> New challenges would come up. If calculators made the arithmetic easy, math challenges move to next higher level. If AI does all the thinking and creativity, human would move to next level. That level could be some menial work which AI can't touch. For example, navigating the complexities of legacy systems and workflows and human interactions needed to keep things working.

You’re gonna work on captcha puzzles and you’re gonna like it.

Re: The Bitter Prediction

#100

Post by selimthegrim »

float4 wrote: post #30
M4v3R wrote: post #14

To me it’s the exact opposite. I was writing code for the past 20+ years and I recently realized it’s not the act of writing code I love, but the act of creating something from nothing. Over the past few months I wrote two non-trivial utility apps that otherwise I would most probably not write because I didn’t have enough time to do that, but Cursor + Claude gave me the 5x productivity boost that enabled me to do so,…

For me it's a bit of both. I'm working on exciting energy software with people who have deep knowledge of the sector but only semi-decent software knowledge. Nearly every day I'm reviewing some shitty PR comprised of awful, ugly code that somehow mostly works. The product itself is exciting and solves a very real problem, and we have many customers who want to use it and pay for it. But damn, it hurts my soul knowing…

Are you guys hiring by any chance?
Post reply on HN