Vibe coding as a coding veteran: from 8-bit assembly to English-as-code

Here's a summary of the themes expressed in the Hacker News discussion:

The "Vibe Coding" Phenomenon and its Impact on Developer Workflow

A central theme is the experience of "vibe coding," where developers accept a probabilistic outcome from LLMs, often leading to acceptance of code without deep scrutiny, especially for less critical tasks. This approach has fostered a sense of laziness and a shift in the developer's role.

• "I've come to view LLMs as a consulting firm where, for each request, I have a 50% chance of getting either an expert or an intern writing my code, and there's no way to tell which." - stavros
• "Sometimes I accept this, and I vibe-code, when I don't care about the result." - stavros
• "I've also had a similar experience. I have become too lazy since I started vibe-coding." - kaptainscarlet
• "My coding has transitioned from coder to code reviewer/fixer vey quickly." - kaptainscarlet
• "LLM assisted coding ('vibe coding') is just project management. You ask it to do things, then you check the work to a sufficient degree." - theshrike79

The Role of LLMs as Advanced Metaprogramming Tools

Several users see LLMs as a new form of metaprogramming, capable of handling repetitive tasks like CRUD endpoints in a more flexible way than traditional metaprogramming tools. The ability to specify variations in a more natural language, combined with code generation, is highlighted as a key advantage.

• "Because, like a carpenter doesn't always make the same table, but can be tired of always making tables, I don't always write the exact same CRUD endpoints, but am tired of always writing CRUD endpoints." - stavros
• "I think your analogy shows why LLMs are useful, despite being kinda bad. We need some programming tool to which we can say, 'like this CRUD endpoint, but different in this and that'. Our other metaprogramming tools cannot do that, but LLMs kinda can." - js8
• "I think now we have identified this problem (programmers need more abstract metaprogramming tools) and a sort of practical engineering solution (train LLM on code), it's time for researchers (in the nascent field of metaprogramming, aka applied logic) to recognize this and create some useful theories, that will help to guide this." - js8
• "Leaky abstractions. Lots of meta programming frameworks tried to do this over the years (take out as much crud as possible) but it always ends up that there is some edge case your unique program needs that isn’t handled and then it is a mess to try to hack the meta programming aspects to add what you need." - iterateoften

The Debate on Code Reading vs. Code Writing Difficulty

A significant portion of the discussion revolves around the statement "reading code is harder than writing it." While one user asserts this, others argue that reading good code is easier than writing it, and that the difficulty is tied to code quality and familiarity. The challenge of building mental models from unfamiliar code is emphasized.

• "Since reading code is harder than writing it, this takes longer..." - stavros
• "Reading bad code is harder than writing bad code. Reading good code is easier than writing good code." - talles
• "I beg to differ." - stavros
• "I think it has to do with mental model. If you already know what to write and it is reasonably complex you'll have a mental model ready and can quickly write it down... While reading someone else code you'll have to constantly map the code in your mind with code written and have to then compare quality, security and other issues." - blackoil
• "Yeah, it's exactly this. Having to create a mental model from the code is much harder than having one and just writing it out." - stavros
• "This is the sign of seniority IMO. First you learn to write code. Then you learn to write code that can be read. Then you learn to modify code. Then you learn to read other people’s code. Then you learn to modify other people’s code." - fnordpiglet

Concerns about Skill Atrophy and Future Developer Training

A recurring worry is the potential for skill atrophy due to over-reliance on LLMs. This leads to questions about how future generations of developers will acquire core skills if repetitive tasks are offloaded to AI, and who will mentor them.

• "The lazy reluctance you feel is atrophy in the making. LLMs induce that." - therein
• "That's my biggest worry, atrophy. But I will cross that bridge when I get to it." - kaptainscarlet
• "Until you lose access to the LLM and find your ability has atrophied to the point you have to look up the simplest of keywords." - latexr
• "Why don’t you use a snippet manager?! It’s lightweight, simple, fast, predictable, offline, and includes the best version of what you learned." - latexr
• "...where will the new generations of senior devs come from? If, as the author argues, the role of the knowledgeable senior is still needed to guide the AI and review the occasional subtle errors it produces, where will new generations of seniors be trained? Surely one cannot go from junior-to-senior (in the sense described in TFA) just by talking to the AI? Where will the intuition that something is off come from?" - the_af
• "Businesses are ramping down from hiring juniors, since apparently a few good seniors with AI can replace them... And then juniors won't have this wealth of 'on the job experience' to be able to smell AI disaster and course-correct." - the_af

Performance and Language/Domain Specificity of LLMs

The discussion touches upon the varying performance of LLMs across different programming languages and problem domains. While Python and JavaScript are often cited as well-supported due to vast training data, languages like Haskell or Prolog are presented as more challenging, though recent improvements in models like Claude are noted. The ability to handle nuanced technical explanations and context is also discussed.

• "LLMs usefulness is correlated strongly with its training data and there’s no doubt been a significant amount of data about both the problem space and Python. I’d love to see how this compares when either the problem space is different or the language/ecosystem is different." - mycentstoo
• "I tried haskelling with LLMs and it’s performance is worse compared to Go." - Insanity
• "Post-training in all frontier models has improved significantly wrt to programming language support. Take Elexir, which LLMs could barely handle a test ago, but now support has gotten really good." - danielbln
• "GPT3.5 was impressive at the time, but today's SOTA (like GPT 5 Pro) are almost night-and-difference both in terms of just producing better code for wider range of languages (I mostly do Rust and Clojure, handles those fine now, was awful with 3.5) and more importantly, in terms of following your instructions in user/system prompts..." - diggan
• "ChatGPT is pretty useless at Prolog IME" - j Szymborski
• "No models have succeeded yet, but usually because they try and put more than 8 bits into a register. Algorithmically it seems like they are on the right track but they don't seem to be able to hold the idea that registers are only 8-bits through the entirety of their response." - Lerc

The Subjectivity and Nuances of Prompt Engineering

There's a debate about the effectiveness and scientific basis of "prompt engineering." Some users express skepticism about the efficacy of elaborate prompt "rituals," while others suggest that even minor textual variations can impact LLM output due to how tokens are processed. The difficulty in establishing control groups and validating prompt effectiveness is a point of contention.

• "There is so much subjective placebo with “prompt engineering” that anyone pushing any one thing like this just shows me they haven’t used it enough yet." - SV_BubbleTime
• "It’s a subjective system without control testing. Humans are definitely going to apply religion, dogma, and ritual to it." - SV_BubbleTime
• "I'm not saying I've proven it or anything, but it doesn't sound far-fetched that a thing that generates new text based on previous text, would be affected by the previous text, even minor details like using ALL CAPS or just lowercase, since those are different tokens for the LLM." - diggan
• "The issue is that you can’t know if you are positively or negatively effecting because there is no real control. And the effect could switch between prompts." - SV_BubbleTime
• "Threatening or tipping a model generally has no significant effect on benchmark performance. Prompt variations can significantly affect performance on a per-question level. However, it is hard to know in advance whether a particular prompting approach will help or harm the LLM's ability to answer any particular question." - cdrini

A New Paradigm: AI as a Partner vs. Tool

The discussion implicitly explores whether LLMs are becoming more akin to a programming partner requiring careful guidance and validation, rather than a simple tool. The ability of LLMs to engage in complex technical dialogue, even generating insightful explanations for bugs, is noted as a significant advancement.

• "My coding has transitioned from coder to code reviewer/fixer vey quickly." - kaptainscarlet
• "You can trust them if you can trust yourself." - BinaryIgor
• "I had serious doubts about the feasibility and efficiency of using inherently ambiguous natural languages as (indirect) programming tools... No more doubts: LLM-based AI coding assistants are extremely useful, incredibly powerful, and genuinely energising. But they are fully useful and safe only if you know what you are doing and are able to check and (re)direct what they might be doing — or have been doing unbeknownst to you." - BinaryIgor
• "Can a human do it? I doubt. We used it to build a new method to apply diffs generated by LLMs to files." - faangguyindia