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 this and, producing huge gobs of code that combine multiple ideas and end goals in a difficult to follow fashion, which seems to be a result of all vibe coding, is an unreviewable habit. Breaking up the output of a vibe prompt into reviewable commits takes longer and is harder than just coding the commits myself I’ve found
-
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 Very much agree, borne out by experience.
-
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 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 definitely.
-
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
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.
-
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 I love thinking about the design and figuring it out. Way more fun than letting an AI just come up with some weird glob
-
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.
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.
-
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 I feel like any sort of thing I value from computers, LLMs do the opposite, and so typically do what I hate with computers (or the industry).
Like I'd say LLMs are tech that's unreliable and patch-preventing, and so horribly inefficient it's almost de-automatisation, with also centralisation so heavy it seems more meant to control people than controlled by people. -
R relay@relay.mycrowd.ca shared this topic
-
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 The elephant-goldfish process is supposed to help with ironing out the design document before the LLM starts coding. I've used it at work due to demands to use AI, but it takes all the joy out of software engineering. No flow states when supervising a gaggle of agents.
-
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.
Unless you are going to do it as explained in "They Write the Right Stuff": https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20Write%20the%20Right%20Stuff.pdf
The docs will leave out a ton implicit knowledge that resides spread out over the whole engineering team.
No one does it the "right way" b/c it is very very very expensive.
-
R relay@relay.publicsquare.global shared this topicR relay@relay.an.exchange shared this topic
-
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
We want (we need) a mix of tasks to work on. Some hard things that we finally figure out. Some easy wins. The fist pumps! The rabbit holes! The process! -
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 Yes, and initially writing the code is only a small portion of the work. To support and build on that code, you need team members who understand it in detail, who know the "why" of the design, who have clue about what compromises were made and what needs to be fixed. Outsourcing that to an LLM means that you get a result that is difficult to maintain, that no one on your team really understands the details of.
-
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@treehouse.systems And LLM output is at least 80% hallucinations. #Llmssuck
-
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@social.treehouse.systems but how will make the 472,495,194th SaaS no one wants in time to be profitable
-
@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 funIf 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.
