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.
-
@ariadne
I write code because it's fun. Vibe coding would be like having a program play Stardew Valley for me - though writing that program would be fun
If you're experienced but it's not the fun part - a researcher doing data analysis, say - then I see the value. Get it done faster, get back to the fun.
The scary one is beginners using it instead of learning for themselves. Especially when - like grad students - they really need to learn and to understand what the code is doing.
@jannem @ariadne we already have a problem with scientists who are not programmers writing unintentionally and non-obviously incorrect code, and getting non-obviously wrong results published. I don’t see value in replacing code that represents their intent and that they could explain to a programmer who could improve it, with code that doesn’t represent their intent and they can’t explain
-
@ariadne I've been sharing this a lot, which captures the problem quite well: https://ergosphere.blog/posts/the-machines-are-fine/
-
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 it's also pretty much the concept of education, but hey who am I to say, I'm just a lecturer in a college where we've decided to encourage AI because we prefer this to reading typos.
-
@jannem @ariadne we already have a problem with scientists who are not programmers writing unintentionally and non-obviously incorrect code, and getting non-obviously wrong results published. I don’t see value in replacing code that represents their intent and that they could explain to a programmer who could improve it, with code that doesn’t represent their intent and they can’t explain
@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.
-
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 Couldn‘t agree more.
-
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
