Comment by linsomniac | Hacker News Reader

Comment by linsomniac | Hacker News Reader

>they empower people with minimal development experience to create their own programs.

The author goes out of their way to play up the toy aspect of the LLMs when driven by the inexperienced. No mention is made of them being used by experienced developers, but I get the impression he feels they aren't useful to the experienced.

I'm just playing with a small client/server tool (rsync but for block devices), and vibe coding allowed me to figure out some rough edges of my design document, and experiment with "what would it look like built with threads? As async code? As procedural?) I would never have done that before because of the sheer amount of time it would take, I'd have picked what I thought was best and then lived with the sunk cost falacy until I had no other choice. It did a pretty good job of catching reasonable exceptions in the communication code which I probably would have just let throw a traceback until I got a bug report. It did a great job of adding logging and debugging options. And I had it take 4 attempts at making a "fancy" --progress display and picked the one I liked the best.

LLMs give a level of exploration to software development that we haven't seen since the good old days when HP set up several groups to each build their next generation workstation environment, and then picked the best one.

IMHO, the experienced software developers stand at a unique position to take advantage of these LLMs that far outstrip what an inexperienced developer can do.

> vibe coding allowed me to figure out some rough edges of my design document, and experiment with "what would it look like built with threads? As async code? As procedural?”

This doesn’t fall under my understanding of the phrase “vibe coding”. In the tweet from Karpathy which many point to for coining the phrase, he says that when vibe coding you essentially “forget the code exists”. I think it’s distinct from regular ol LLM-assisted development

We used to call that "the zone", and it's not exclusive to coding.

https://en.wikipedia.org/wiki/Flow_(psychology)

I only forget that time exists when I'm in flow state, not code.

That's actually the term I prefer, but I couldn't remember it

Not in that sense. When you're coding and "in the zone", the code doesn't cease to exist - it's more like it becomes the extension of you.

I surely did a hybrid approach, but for a large swath of it I was pretty purely "vibe coding", where I wasn't looking at the produced code at all.

I initially had Gemini 2.5 build some code and then did a code review of it. I tweaked my design document and then had Claude and ChatGPT take a stab at it and at this point I wasn't looking at the code at all. These implementations had some deadlock or early termination problems so I asked for some different async and threaded implementations, but ultimately they went off into the weeds in ways I couldn't really reason about, so I went back to a straight select/procedural implementation and had it start tracking outstanding blocks, which got something working reliably. Then I asked for fancy progress displays, tried several attempts at that. Then at this point I started cleaning up the code some, had it add type annotations, etc...

Big swath of pure or nearly pure vibe coding in the middle there.

I'm a little confused on how this helped your design doc? It seems like you picked the design that the LLM could best implement?

I was really curious about how it helped you iron out the problems but couldn't figure it out from your description

Running the first generated version to test, I realized I needed to specify: "Make sure that the client processes messages from the server while it is generating and sending hashes of the source file", because the first implementation would spin on generating the hashes and deadlock because the server end would write messages back to the client that the client wasn't reading and fill up the output buffers, which would fill up the client output buffers once the server stalled. This was obvious just from running it and knowing how all this stuff works (rather than by code review).

Then I started seeing issues with how I had phrased the terminal conditions, the client terminating immediately upon reaching the EOF on input file, and not reading any further server messages. I considered making a 3-way ACK to signal end, but instead changed the design to tell it to keep track of outstanding un-acked packets and only send the EOF/EOFACK when there were no outstanding messages.

The design is that the client generates a bunch of "xxhash64" messages for each block of data, and the server replies to each one with either "ok" (I already have that data) or "send" (send me that data). The "send" is replied to with either "data" (here's the data) or "zero" (the block is entirely NUL).

How does the inexperienced developer become experienced under said circumstances?

I agree they may not and that’s very interesting. As an experienced developer myself I’m starting to think these tools are likely going to increase our market value not decrease it.

It's not implausible that we'll wind up with something like the extremely long-lasting market for COBOL developers. A niche skill that's absolutely essential in a few places, and which can command high salaries as a result... for a few people. Only so many huge legacy banking systems, after all.

The problem, as with COBOL, would be the loss of the existing pipeline that created new competent high-level developers.

IBM just launched a new mainframe with AI accelerators https://www.ibm.com/products/watsonx-code-assistant-z in part to help rewrite production COBOL into Java https://www.ibm.com/products/watsonx-code-assistant-z

Sounds fantastic! And it might also help with ageism, when "learned programming long before LLMs" is recognized as a differentiator.

I, for one, welcome this change very much, disastrous as it sounds.

"The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x." -- Kent Beck

You can examine the code at any time, ask for an explanation, and even make changes yourself. In other words, you get out of it exactly what you put into it.

If you choose to let the AI do all the coding and never dig into the actual code, you'll learn more about how to communicate with an LLM than you will about how to write code.

> ask for an explanation

That is risky. The AI might just hallucinate an explanation.

So can any human-based sources. A healthy learning experience with AI takes discipline, just as it does with humans.

The amount of errata in technical books is very small compare to the length of the book. I believe it ranges from none to a page or two.

That sounds like a similar failure rate for using newer models in technical contexts. Especially for popular technologies where there are enough resources such that someone other than the original creators could reasonably write a book about it.

I think that's an oversimplified metric when comparing the ability of an AI to analyze and describe code. Imaging you're reading a book on a challenging new topic. Even if the book is 100% right, there will be many passages you don't understand, and may even misinterpret. A book won't correct you, offer alternate explanations, or break down concepts any further than what was already written.

An LLM, for all its flaws, can do these things exceedingly well (provided it has good source material, of course). This gives you the ability to get answers to your questions and correct your mistakes. I'd argue that these benefits far outweigh the errors an LLM makes in breaking down and explaining material, and make an LLM better than a book in many (not all) cases.

> Even if the book is 100% right, there will be many passages you don't understand, and may even misinterpret.

Which is why no one reads only one book on a particular subject, especially if one is new to the domain. Often you bring in an alternate, but correct perspective from another book. The risks of hallucination with LLMs' responses outweighs the advantage of multiple perspectives (even if a broken clock is right twice a day, you still want a working one)

No one reads only one book on a subject? People act on mere headlines all the time. Reading one whole book would be a huge win over the status quo

> The risks of hallucination with LLMs' responses outweighs the advantage of multiple perspectives

You can ask a model a question multiple times. You can ask different models the same question. You can ask the same question different ways. You can do this automatically with agentic frameworks or reasoning models. "Multiple perspectives" are compatible with language models.

> You can ask a model a question multiple times. You can ask different models the same question. You can ask the same question different ways. You can do this automatically with agentic frameworks or reasoning models.

LLMs are for generating text, not producing knowledge. The actual knowledge come from the signal/noise ratio of the training data, not the training method.

It's like recording a violin in a noisy environment, encoding it with a low-bitrate lossy encoder and trying to get the PCM of only the violin back.

We've tried to use a better environment for recording specific notes from the violin (better training data), adjust the parameter of the lossy encoder (tuning the model), mix other violin samples to the respone (RAG, MCP), and redefining what a violin should sound like (LLMs marketing).

But the simpler solution is to record it correctly and play it later (AKA going to the source).

I would guess it's been around 1-2 years since you last tried seriously using a language model for any practical use cases, right? It makes sense to not use them if that is your experience, but it's hard to imagine anyone saying this who has actually been following along for the last few years to now. SOTA from 2 years ago now comfortably runs on a single GPU. A high end GPU can easily out perform SOTA from then both in (general!) knowledge reproduction, and capabilities (including saying things like "I don't know" when you ask beyond the encoded knowledge).

That is nonsense. A competent human will provide you with an explanation that is based on logic. LLMs just put together words that are statistically most likely to be used together given the current input. That is why you can get hallucinations with LLMs but not with humans.

This is incredibly meta

That is a question that is very near and dear to my heart right now because my son is 15 and very interested in programming. I don't have any good answers yet, but you definitely need to know so many of the core concepts to be able to steer the LLM around pitfalls.

Reply on news.ycombinator.com