Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vibe Coding is not an excuse for low-quality work

addyo.substack.com

Post reply on HN
Print view View original

181–190 of 213 posts

Re: Vibe Coding is not an excuse for low-quality work

#181

Post by bee_rider »

smcg wrote: post #72
Buttons840 wrote: post #69

Earlier quoted context omitted.

More than one project manager has insisted that everything about the system must be documented--that's called the source code. As you say, by the time you specify everything , you've written the code.

Theoretically a PM could say "the code is disposable and obsoleted by the next deployment. let's just document our prompts." I don't know if that's a good idea but a lot of people are going to try it.

The prompts are the source code in that case.

The LLM is some sort of transpiler.

Somebody will have to add some syntax to these LLM prompting systems to include text that doesn’t get converted. So the next round of PMs can ask you to documents your prompts).

Re: Vibe Coding is not an excuse for low-quality work

#182

Post by jhbadger »

SCdF wrote: post #5

So what have we redefined vibe coding to mean exactly? The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't. Are people now using this term to mean "giving an AI agent broad tasks"? [1] https://x.com/karpathy/status/1886192184808149383?la…

It's like doomscrolling. Originally it meant compulsively reading depressing content about the state of the world, wars, etc., explaining the "doom" part, but eventually it evolved (or perhaps devolved) into just meaning obsessively checking any sort of online content whether or not it was depressing.

Re: Vibe Coding is not an excuse for low-quality work

#183

Post by bee_rider »

Buttons840 wrote: post #69
ndepoel wrote: post #18

This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications. Turns out most of those outsourcing parties won't truly understand the core ideas behind the system you're trying to build, won't think outside the box and make corrections where necess…

More than one project manager has insisted that everything about the system must be documented--that's called the source code. As you say, by the time you specify everything , you've written the code.

Someone should come up with a tex2fortran conversion LLM.

Re: Vibe Coding is not an excuse for low-quality work

#185

Post by spamizbad »

skydhash wrote: post #88
spamizbad wrote: post #55

Earlier quoted context omitted.

The second type of quality is necessary to achieve the first type of quality for systems with nontrivial levels of complexity. It doesn’t need to be perfect, or even close to perfect, but it does need to be “good enough” - Your end users will eventually notice how long bugs take to get fixed, how long and how often outages occur, and how long it takes to get new functionality into your software. But beyond your end-u…

Software architecture was never about code elegance, it’s about making it easier to get reliable results. And that’s mostly about using automated tooling to check correctness and easy to understand and to modify modules. That’s the easiest way to get both definitions of quality as it’s way esier to test isolated modules and their integration than testing the whole system as a whole. And way easier to correct wrong co…

> Software architecture was never about code elegance, it’s about making it easier to get reliable results. And that’s mostly about using automated tooling to check correctness and easy to understand and to modify modules.

The first isn't entirely true, and automating tooling is actually quite poor at doing any sort of architecture analysis since the "right" architecture is heavily dependent on factors you cannot see in the code itself: What sort of SLO are you setting? What is your services load and usage pattern (read heavy? write heavy? blend?). Read heavy and high availability? You may want CQRS, but if the service is only experiencing light loading that could easily be over-engineering. Tooling won't help you identify that; you'll need experienced engineers to make judgements.

Re: Vibe Coding is not an excuse for low-quality work

#186

Post by calderwoodra »

marcusb wrote: post #20
SCdF wrote: post #5

So what have we redefined vibe coding to mean exactly? The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't. Are people now using this term to mean "giving an AI agent broad tasks"? [1] https://x.com/karpathy/status/1886192184808149383?la…

The definition seems to have pretty rapidly moved to 'used an AI coding assistant in some capacity'.

More specifically, using AI bots that can write functions, sometimes entire classes, refactor code, etc.

GitHub copilot which is mostly single line completions isn't "vibe coding".

I think vibe coding also entails some "what it did was so simple, I didn't bother to check it".

Re: Vibe Coding is not an excuse for low-quality work

#187

Post by alganet »

dymk wrote: post #184
alganet wrote: post #104

Earlier quoted context omitted.

Why are they being sold as DROs then?

Do you mean VMCs or something?

I meant a Digital Readout, a DRO. A digital nechanism that provides metrology assistance to machining operations.

LLMs for code are currently sold as sort of that.

Re: Vibe Coding is not an excuse for low-quality work

#188

Post by mulmen »

otabdeveloper4 wrote: post #153
bluefirebrand wrote: post #73

Earlier quoted context omitted.

The term for this is "unicorn" Entirely fictional creature that doesn't exist Every person who I have seen embracing AI coding has been getting lazier and lazier about verifying

> yeah bro, leave the easy and fun part (googling and typing code) to an AI, and let the human deal with the tedious and error-prone part (checking all the edge cases) What did you really expect?

Huh, I have never found searching for information and typing code particularly fun. The part I enjoy is seeing something work.

Re: Vibe Coding is not an excuse for low-quality work

#189

Post by camdenreslink »

bee_rider wrote: post #180
ken47 wrote: post #134

The hype levels are so overwhelming that AI coding could never hope to meet them. I've tried having a highly-ranked AI coding app write unit tests for a relatively complex codebase. 80% of the generated test cases failed. But an experienced human such as myself could use those as a starting point since it took care of some of the tedious boilerplate. It genuinely saved me some time and annoyance, but could never hope…

I do somewhat worry that AI will harm language development. Boilerplate… is bad, right? If our languages were more elegant, we’d need less of it. It is necessary because things don’t have sane defaults or sufficient abstraction. In particular, if the AI is able to “guess” what boilerplate you wanted, that boilerplate ought to be knowable beforehand (because the AI is not actually guessing, it is a deterministic set o…

I think there will be an ossification of current languages/frameworks/libraries. The technologies that already have a large amount of documentation, tutorials, example code, etc. will have a huge advantage over a brand new language because all of that content will be in the pretraining for all LLMs. Would you rather use JavaScript/TypeScript and Python (which will work relatively well with LLMs), or some brand new thing that will barely work at all with LLMs.

Re: Vibe Coding is not an excuse for low-quality work

#190

Post by camdenreslink »

closewith wrote: post #170
dbbk wrote: post #169

Earlier quoted context omitted.

LLMs don’t even understand fucking TypeScript, which you would expect a computer program to be able to understand. I can’t get it to write valid Drizzle code to save my life, it will confidently hallucinate method imports that don’t even exist.

The question is which LLM, invoked how? Claude Code refactored numerous projects for us into TS, often one-shotting it. Saying LLMs don't understand TS (which may be true, in that LLMs questionably understand anything) says more about your perception than model and agent abilities.

I have also had a really hard time getting Claude and Gemini to create valid TypeScript in somewhat complex legacy projects. Sometimes it will do the most kludgey things to sort of make it work (things a human developer would never consider acceptable).
Post reply on HN