Comment by hugeBirb
8 hours ago
What type of applications are y'all seeing from LLMs? Anecdotally the only thing that has changed for me is the ability to output more code. That's not software. My coworker is a 10x vibe-coder and his flagship application is held together with brittle shell scripts, a sloppy codebase, bad abstractions, piles of markdown files and an ouroboros of generated tests. This is not software. This is just held together with duct tape and a prayer. Although this guy doesn't have any traditional background but still, if LLM generated coding agents were so good even a simpleton like himself should be able to create a miraculous piece of software, right?
the 0x engineer became a 10x vibe-coder responsible for our CICD and vibe-coded testing that was previously manual
He's introduced several 100,000s LoC changes and additions in 10-15 codebases. There are some repos that only he works in ( so no PRs, just merge to master and be done ). He also has self-approved and merged changes without review (he's an admin)
Anyway, now he put in his notice and no one on his team knows how any of this works. We can't get code changes without CICD passing. CICD breaks all the time. The original contractor who made the CICD before him wants nothing to do with it now. We can't generate signed OTA packages.
He went from doing 'too much to finish anything' to 'made so many changes that he had to bypass PRs'.
Now he's leaving.
Engineers have been pointing out this bottleneck for the past year or so. The engineering managers aren't pushing it and the business owners either don't understand or don't care
Hah, ultimate vibe coder nightmare scenario. I wonder if, in six months time, there will be enough stories like this for sanity to prevail a little more.
I REALLY hope management takes notice
it's going to be so expensive. I learned the vibe coder's contract rate is going to be 2-3x his current salary
Software has, with precious few exceptions, almost always been held together with duct tape and a prayer.
Yes I know. There's no nuance on HN. I was using it as a metaphor to show that this person has no idea what they're doing. Which is a huge difference from someone deeply knowing the codebase and tech it'll sit on to make an educated tradeoff. I've seen the duct-tape in real codebases and I knew the engineers who put it there and why. That doesn't exist when your senior engineer is a nebulous "idea of an engineer" that resets its memory every few hours.
The issue is not duct tape, the issue is having someone you can rely on to know what to tape.
People in the know are not suggesting engineers are no longer needed, but that they need to adapt.
3 replies →
> brittle shell scripts, a sloppy codebase, bad abstractions, piles of markdown files and an ouroboros of generated tests. This is not software
I think that's software. It's not good software, but it's software.
This perspective feels a bit like a chef insisting McDonalds or frozen dinners aren't food. It's mass produced, unoriginal, and typically soulless, but it's still food. As Scott would say, maybe a map vs territory discussion.
I don't know if Fast Food is a good example to be using here, because it is pretty unambiguously bad for us
I built an orchestrator connected to email, browser and payments, and it handles a ton of boring stuff like “pay electricity”, or “apt renters want something, deal with that”, or scheduling appointments, dealing with infoline chatbots and everything around that.
Plus navigating personal communication (what’s the address of friend X, who did I promise to go to a dance workshop with) and so on…
In essense, anything Siri promised to be, but really working.
Hi landlord, I lost my wallet and need a refund of last month's rent.
You're absolutely right!
Not like that. When they have an issue that can be solved by my orchestrator I fwd it.
> his flagship application is held together with brittle shell scripts, a sloppy codebase, bad abstractions, piles of markdown files and an ouroboros of generated tests
you just described lots of codebases at highly values companies. Plenty of places, maybe even the majority, do not care about code quality if the code results in a functional application.
Why would it? You still need to be able to understand and describe a problem (if the space is complex, that usually means: many connected problems) and that requires good thinking.
[dead]