Hacker News Reader

Comment by hugeBirb | Hacker News Reader

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?

View on HN

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.

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.

Please explain this "adapting". The LLM sellers' holygrail is * you just need to crank our model bro *. With this mindset, there is no adaptation needed, save a couple of weeks of getting up to speed with nuances of using the models, the / commands and integration of their APIs into your workflow.

You gotta ignore what the LLM sellers are saying and listen to the people who don't have a financial incentive to sell a particular message.

It's not just corpo talk. The ultimate goal in LLM and AI progress is "replacement" of professional knowledge workers. In the march of the 9s of the accuracy of the generated LLM output, the engineers role would matter less and less.

It's asking engineers to "adapt" to being efficient in filling out the last 10% then 1% then 0.1% then 0.01%.

Yeah i also want to know what the adaption is. Because so far all I'm seeing is removal of the natural incentive to build deeper understanding of the systems. So in the future only the people who are really curious and want to know for knowledge sake are going to know enough to deal with the blind spots of the automatons.

Knowing how the things the LLM's are touching appears to be the only skill of value. Because using these things are trivial for anyone who is familiar with computers, what adaptation and catching up is there beyond waiting and observing what works and then just applying that?

"But the LLM's will know everything" well then we aren't needed at all, just put it on a loop and leave it running. At this endpoint there's nothing to adapt to, only direct means of allocating necessary resources to yourself for subsistence.

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.

> 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.

Reply on news.ycombinator.com