I guess fundamentally my objection to vibe coding and LLM contributions in general is that, at least to me, the process of figuring shit out is the point.
-
I guess fundamentally my objection to vibe coding and LLM contributions in general is that, at least to me, the process of figuring shit out is the point.
I think cutting out that journey is bad engineering, because design docs are rarely correct on the first try.
@ariadne When you skip the figuring out part when using LLMs, you're using them wrong. It should be a tool that can actually aid you in the figuring out part.
-
@ariadne I've been sharing this a lot, which captures the problem quite well: https://ergosphere.blog/posts/the-machines-are-fine/
-
@ShadSterling @ariadne
I was thinking specifically of experienced researchers (or other domain specialists) that do know how to develop well, but it's not the job they're there to do or that they want to be doing.For inexperienced or bad coders I absolutely agree with you.
-
@ShadSterling @ariadne
I did not say I want it. I say that I understand why they would want to. And, judging from what I see at work, increasingly are doing. -
I guess fundamentally my objection to vibe coding and LLM contributions in general is that, at least to me, the process of figuring shit out is the point.
I think cutting out that journey is bad engineering, because design docs are rarely correct on the first try.
@ariadne this is why I **hate** reviewing LLM codes.
a human-made change-set has intent, a reason why a given line is there because they had a thought process and the code followed that.
I often ask _why_ during a review, and usually there are 2 outcomes:
- the code is good but I didn't see the logic (so I learn something)
- it's wrong and the author made a mistake (so the they learn something and we fix it)with agentic code this conversation crumbles in 2 seconds and I'm left frustrated.
-
@ariadne this is why I **hate** reviewing LLM codes.
a human-made change-set has intent, a reason why a given line is there because they had a thought process and the code followed that.
I often ask _why_ during a review, and usually there are 2 outcomes:
- the code is good but I didn't see the logic (so I learn something)
- it's wrong and the author made a mistake (so the they learn something and we fix it)with agentic code this conversation crumbles in 2 seconds and I'm left frustrated.
@ariadne (I know there's nothing new in my reply, others already phrased it much better, and the Chesterton's fence principle is also buried somewhere in my argument, but had to say it with my own voice.)
-
Even worse, it leads to deskilling. Cutting out that process makes people dumb to the solution. There is not even an abstract idea of how it works anymore, just a prompt that was given, ... Which might not even match expectation.
-
@ariadne@treehouse.systems And LLM output is at least 80% hallucinations. #Llmssuck
80% nonsense wouldn't be a problem. LLMs suffer from the paradox of automation: if you approach but do not reach correct automation, it's often worse than not automating at all. They are specifically built to do exactly this because they produce output that is statistically likely to look correct.
A tool that produces output that looks correct but is not is worse than a tool that produces output that looks incorrect.
A tool that produces dangerously wrong output half the time is easier to use than one that produces dangerously wrong output 5% of the time, because you're trained to assume that the latter is normally correct.
-
I guess fundamentally my objection to vibe coding and LLM contributions in general is that, at least to me, the process of figuring shit out is the point.
I think cutting out that journey is bad engineering, because design docs are rarely correct on the first try.
@ariadne agreed. Most of my most successful projects have started with me writing the documentation for what I want. By the time code comes around it’s mostly implementation of the pre-thought documentation.
-
R relay@relay.infosec.exchange shared this topic
