Reymont is quickly becoming infamous. He's got open PRs all over the place. Previously hit the frontpage here after showing up, _again_, on Zigs wall of shame for AI pull requests.
Ask most folks about the code generated by the compiler or interpreter and you’ll get blank stares. Even game devs now barely know assembly, much less efficient assembly.
There is still a place for someone who is going to rewrite your inner-loops with hand-tuned assembly, but most coding is about delivering on functional requirement. And using tools to do this, AI or not, tend to be the prudent path in many if not most cases.
Apart from the whole argument about compilers being deterministic and not LLMS.
You don't collaborate on compiled code. They are artifacts. But you're collaborating on source code, so whatever you write, someone else (or you in the future) will need to understand it and alter it. That's what the whole maintainability, testability,... is about. And that's why code is a liability, because it takes times for someone else to understand it. So the less you write, the better it is (there's some tradeoffs about complexity).
You can make LLMs deterministic, but that's not a priority right now. In the same way we used to not capture dev environments and end up in situations where you couldn't rebuild a binary exactly because the OS version, the compiler version, the CRT version, etc... all changed -- of course that's a 20 year old problem now, but was a legitimate problem as recently as 2000.
And again, we're at a point in time where we do collaborate on the source code artifacts. But maybe we won't in the future. It assumes that we see AI progress, I can see a world where asking questions of the AI about the code is better than 99% of developers. There will be the John Carmack's of the world though who know better than the AI, but the common case is that we eventually move away from looking at code directly. But this does rely on continued progress that we may not get.
I mean maybe these juniors are geniuses, but I often find it very non-obvious why LLM-generated code it wrong and it requires me to have an even deeper knowledge. Sometimes the code is correct, but overly complicated.
One small example was a coworker that generated random numbers with AI using `dd count=30 if=/dev/urandom | tr -c "[a-z][A-Z]" | base64 | head -c20` instead of just `head -c20 /dev/urandom | base64`. I didn't actually know `dd` beyond that it's used for writing to usb-sticks, but I suddenly became really unsure if I was missing something and needing to double check the documentation. All that to say that I think if you vibe-code, you really need to know what you're generating and to keep in mind that other will need to be able to read and understand what you've written.
This reads even more like an angry teenager than my angsty high school diary. I'm not sure how many more strawmans and dismissive remarks I can handle in one article.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
"When disagreeing, please reply to the argument instead of calling names. 'That is idiotic; 1 + 1 is 2, not 3' can be shortened to '1 + 1 is 2, not 3."
Is there a similar rule for submissions, or are submitters exempt from adopting HN culture? "Please don't submit shallow arguments, specially criticizing other people's work?"
Because we've recently been getting a series of low quality submissions which obviously drive low quality discussion, but for some reason it's only the commenters who get reprimanded, as if the submissions weren't ruining the mood one by one.
(And to clarify, I haven't been warned, I'm not writing this out of spite.)
You can flag submissions that you think don't belong on Hacker News. Other than that it's best to just turn your attention to other stories that do interest you.
I can see that. Whether or not it's worth the time spent in setting it up is something I can't answer myself yet.
I think my biggest point further down is that you have to _already know_ that it's a bad idea - if you don't you can't instruct the agent to avoid it. What I see is so many more developers who just never get to that point now.
> For many people in this industry this became the default when Google and StackOverflow appeared. Is AI really so much different there if you look at the root cause? I feel AI is just another tool for quick answers without investing time in understanding the problem. That mentality is not new and has not changed in decades with previous knowledge bases. Sadly.
I'm aware it reads a bit like an angry old man yelling at the kids on his lawn, but I'm starting to get extremely frustrated with what I see and thought I'd write down some of the experiences.
Thank you. I think it is unfounded, but it's still a visceral belief and those can be hard to overcome. I'm hoping with time I can change my feelings on it.
Because I am the bluebird of happiness, there are a couple of things you may want to be aware of here.
"I’d be like the few older workers I’d dealt with in my career. I felt like they moved too slow, were stuck in their ways, and unable to change - even when faced with evidence to the contrary."
First, keep in mind that many of your co-workers will still feel this way, even if you provide evidence to the contrary.
Second, after you have been around the dharma wheel too many times, it becomes difficult to hop onto the hype-train as quickly as you used to, which is one reason many of your co-workers will feel that way.
The tech industry has never had a career path for technical people other than directly into management or into a pseudo-management "architecture" roles that are neither technical nor management---you don't get many of the advantages of either and what you can do is mostly based on your personal relationships with managers or technical people. As a result, if you remain technical, you may find that your salary and influence stagnate.
Oh, and 40 is still pretty young. I'm 56 and it wasn't until the last 8-10 years that serious burnout set in. (Salary isn't really an important factor in job satisfaction; influence very much is.)
Personally, I've never had to write a letter like yours because I shot the suggestion of a more management-oriented position down in flames, twice. Lucky me! :-)
This is only tangentially related to the main topic of the post, but thought I might ask for your thoughts on a similar dynamic.
My thesis is that companies should not be (or just be much less) functionally org'd—that is, not divided into Engineering, Marketing, Design, Sales, etc. And that this is the root-ish of many typical problems. I don't really need to argue that's true for my question, but given that most companies are that then leads to functional managers—ie. Engineering Manager or Director of Engineering. The role of that manager sometimes involves being in the weeds of specific work, but mostly doesn't. It's usually not architecting or coding, but mentoring and maybe allocating work. The latter of which might formally be a a responsibility, but is embedded in a network of other people's needs that does some pre-determining.
What does that manager do—and I suppose how do they sleep at night if they care about their work—given they're the mentor and blocker of their IC's rise? What I mean is that if the career path for the IC is sorta mythical, how does that manager guide them? If they're honest, then they're also kinda describing their own role as a bit pointless. That would be a reason the IC shouldn't aspire to the role coming from someone who did and now remains (happily?) in it. Engineering is probably the least problematic in this regard because it tends have a bit of power and sometimes isolation within a company. But take something like design, which fights all the time with product because half of the career path/duties for product design (less so brand or visual designers) is blocked by product. So when a designer tells their manager they're having problems with their PM, there is (1) nothing power-wise for the manager to do because neither they nor their bosses are in the chain of command of product and (2) they themselves never resolved this incompatibility. The best they've done is maybe launched something in spite of it. Or maybe (to the company's benefit?) not launched things because of it.
Does the functional manager just give (knowingly or unknowingly) pseudo-career-advice out of circumstance because that's the job of maintaining civility? Is this mostly a matter of everyone all around (managers and otherwise) looking the other way because employment?
