Whether vibe coding works for you depends on how tight your requirements are.
“Vibe Coding” vs. Reality
171–180 of 312 posts
Re: “Vibe Coding” vs. Reality
#172I'll share a new wrinkle that casts more shade on the coding LLMs. We have a fair number of offshore resources that are used for dev. They developers are fully integrated into the team, are in all the stand-ups, and substitute for the usual role of junior programmers. They don't get the grunt-work shoveled on them, they get the same work as everyone else, they're just expected to not be as fast. In 6 months 2 out of…
I've been contracting for a fairly largish company (around 300 devs split across ~40 teams). The US based company was bought out by private equity about a year ago and many senior/lead engineers were forced out and contracted out to cheaper overseas labor. The company has been relatively ambivalent about the usage of code assistant AI, but during PR reviews it has become very apparent that its seen widespread adoptio…
Totally lines up with my experience as well. We also have the opposite problem of reams of code generated years ago from a period of unsupervised offshore work where we're slowly paying down the debt but the LLMs will attempt to use the old code for new work. Most of it is spaghetti UI code and nearly impossible to reuse effectively but the LLMs give it their best and we have prompt around it.
Re: “Vibe Coding” vs. Reality
#173Earlier quoted context omitted.
Where we are now, I wonder if is similar to the early days of compiled languages existing, back when people still somewhat commonly wrote assembly by hand and didn't trust compilers. Sure, things like Roller Coaster Tycoon exist, but but writing in a compiled language is so much faster, easier, and more broadly accessible than writing in assembly that compilers took over.
TIL that Rollercoaster Tycoon was written in Assembly. “[Developer Chris] Sawyer wrote 99% of the code for RollerCoaster Tycoon in x86 assembly language for the Microsoft Macro Assembler, with the remaining one percent written in C.” - Wikipedia What a lunatic.
With a good macro library, it’s not that far from writing C.
Re: “Vibe Coding” vs. Reality
#174This is the go community saying a computer will never best human go players. We already have examples of a model finding more performant sorts [0], given the right incentives and time, and the right system for optimizing (LLMs trained on “average code” probably aren’t it) the computer will best us at creating things for the computer. Is “vibe coding” real today? Not in my experience, with even Claude code. My hand ha…
Check the actual paper on the type of sorts it actually got speedup on :-) (hint: a few percentage points on larger n,similar to what pgo might find, the big speedup is for n around 8 or so, where it basically enumerated and found a sorting network)
Re: “Vibe Coding” vs. Reality
#175Earlier quoted context omitted.
The company I worked for 15 years ago outsourced QA to save money. It was sold as paying $15 for a 4080 video card. When they opened the package, instead of a 4080, it was a brick. The salt in the wound was when they realized they overpaid 3x for a $5 brick. If it wasn't for vendor lock-in (they being the vendor), they would be dead. The local QA person could run through 100 or so scenarios a day. The offshore people…
There's an art to outsourcing, and - even worse than with LLMs - it's not something you can ever just do and forget, because without active management, you'll eventually end up wasting money and time while getting nothing in return. QA is a whole other story, too. Outsourcing QA is stupid, but even more stupid and short-sighted is not having QA in the first place , and that unfortunately is becoming a norm. There's l…
>Outsourcing QA is stupid, but even more stupid and short-sighted is not having QA in the first place, and that unfortunately is becoming a norm.
Yes, they were moving in that direction. They centralized the QA team over a suite of probably 15 products, which means no one has any expertise. The QA VP would get mad when QA found bugs because "the dev's were supposed to find all the bugs and the QA was just supposed to just certify the release." The amount of people who don't understand how software dev works in high positions is mind boggling.
They ended up firing all the devs except me and this other guy who gave zero shits and wanted to be a manager. "We" maintained 3 products. Two were pretty standard web apps but one was a full blown decision support system (rules engine) that only I knew. I quit after a few months of killing myself. They paid me a whole lot of money a few years later when they were trying to add features to get a very lucrative government contract.
Re: “Vibe Coding” vs. Reality
#176This is the go community saying a computer will never best human go players. We already have examples of a model finding more performant sorts [0], given the right incentives and time, and the right system for optimizing (LLMs trained on “average code” probably aren’t it) the computer will best us at creating things for the computer. Is “vibe coding” real today? Not in my experience, with even Claude code. My hand ha…
[deleted]
Re: “Vibe Coding” vs. Reality
#177Making the arguing that these tools have flaws seem like a losing battle. Soon those flaws will be fixed[1] and youll have to find new flaws to complain about. Eventually hopefully you'll realize that you just don't like feeling displaced. [1] it's unbelievable what a difference in quality 1 year made for chat gpt
Why are you so certain that flaws will be fixed? Seems like there is a giant leap between a machine spewing words based on probability and actual deep understanding of the code it's suppose to write
Because ai is following a predicable trend of exponentially increasing task length @50% probability: https://x.com/METR_Evals/status/1902384481111322929
If we are the top of an s-curve, the recent samples on that curve would be below the trend line, not above it.
Re: “Vibe Coding” vs. Reality
#178Earlier quoted context omitted.
If its something like "tic-tac-toe in Javascript", thats been done 1000x before, I wouldn't find it all that impressive.
Most of webdev has been done 1000000x before. Though to be fair, Wix and Squarespace already bit a huge chunk out of that market.
> Most of webdev has been done 1000000x before
Not according to your very specific stakeholder demands / environment/naming/data tables/data protection requirements, otherwise you would just use a library.
Those might seem like trivial differences but plenty of things go wrong there, plenty enough that you can't just use a library instead of a programmer, and then they are plenty enough of such errors that vibe coding will also cause issues.
Re: “Vibe Coding” vs. Reality
#179Earlier quoted context omitted.
Nah, the magic/promise of AI is that it has positive chance of getting there, so you can keep feeding it dollars until it eventually gets you the thing you want, and that it's still cheaper than having people do it the old-school way. We're not there yet, but I don't see anything preventing us from getting there in ~5 years. (Remember: 5 years ago, SOTA in this space was letting a genetic algorithm poke at an AST and…
And full self driving is always just 5 years away.
Full self driving is here. (Waymo). LIDAR is required imho.
Re: “Vibe Coding” vs. Reality
#180Earlier quoted context omitted.
Where we are now, I wonder if is similar to the early days of compiled languages existing, back when people still somewhat commonly wrote assembly by hand and didn't trust compilers. Sure, things like Roller Coaster Tycoon exist, but but writing in a compiled language is so much faster, easier, and more broadly accessible than writing in assembly that compilers took over.
My worry about this approach is: there is a reasonably popular saying that writing code is hard but debugging it is twice as hard (at least), which I think is an accurate description. LLMs will greatly increase code production, will they also increase debuggability to match?
I think probably people will also use LLMs to debug.
At this point, I think you can consider vibe-coding with an LLM to be pretty equivalent to using a fairly junior developer with access to stack overflow. It's going to make a lot of mistakes, it's going to make a lot of questionable decisions. Sometimes it will be able to fix its mistakes, sometimes it will spin its wheels and never fix it. It may make a big ball of mud. The entire project may fail.
Two-three years from now, who knows. I'm pretty sure you still won't see 100% reliability in translating English->code, but you also don't see that even with senior developers.