The meaningful difference is that you will not experience EOS if (when) anthropic/openai/etc fails to become profitable and is no longer subsidized by capital funding.

While "vibe-coded" apps do help lots of people who didnt have the time/money/skills to create their projects, you should be aware that currently the compute is being subsidized so that users become reliant/used to the service.

Put on the hats of a risk manager or supply chain manager. Yes, that would have mattered. What you insource today, you can repeat tomorrow. If you know the price of an input will multiply in the near future, you should at least develop processes that can handle disruption. If you expect dirt cheap LLM’s to remain available, or even better: improve in quality, feel free to make that assumption explicit and keep using the external supply. I don’t know what the future holds, but the vibe your software organizations cannot go back to manual development once LoC has exploded. I hope firms are making these choices deliberately.

> Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used.

Not to be too snide, but if that's your reductionist view of the work of software development, I'm not surprised you're comfortable vibecoding without a human in the loop.

Thank you for the thorough reply! I also appreciate that you recognized my question as good faith (and my apologies, based on other replies I should have been less brief to avoid misinterpretation.)

It seems my definition of "vibe coding" was wrong after all, at least in this case, and that you're still doing design. My initial read was that this was fully AI-powered, and while that sounded interesting, it did leave me wondering what the humans did :)

This is absolutely my experience. And I'm commenting on HN a lot more now too - but in between, I'm doing competitive analysis, trying out a fix I implemented or a feature I added, marketing, talking to friends about their bug reports...

writing code is the actual fun part of the job though.

it’s a shame we automated that instead of the boring system design shit.

> AMA!

I think I missed where you posted what business you work at

- What you do at Initech is you take the specifications from the customer and bring them down to the prompt engineers?

- Yes, yes that's right.

- Well then I just have to ask why can't the customers take them directly to the vibe coding software people?

- Well, I'll tell you why... because... engineers are not good at dealing with customers...

- So you physically take the specs from the customer?

- Well... No. My secretary does that... or they're faxed.

- So then you must physically bring them to the software people?

- Well... No. ah sometimes.

- What would you say you do here?

- Look I already told you, I deal with the @#$% customers so the prompt engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!

Haha, I actually laughed out loud, thank you for that :)

Living the dream! Son of Anton provides.

To be clear, I didn't mean this as an anti-AI gotcha. They also said:

> We get feature requests, improvements, ideas, feedback

So maybe I misunderstood, but it sounded like the design was external (and based on an existing product to begin with).

Also, my understanding was that "vibe coding" meant more of "make it do X" as opposed to "here's a design for X, implement it."

YES!!! Very well said and captures what I was trying to convey.

There's also certain features of an application that most of us engineers know how it works or how to do it, but it is just so painful to do it by hand. Or other features that you've always wanted because you saw another app do it and it was beautifully done and you can just "have" that feature in your app too.

The joy is in seeing the feature come alive, not so much in fighting the computer.

It's interesting how people view software as a distraction and an annoying side quest/cost center, but never apply that to, say, 90% of what management does. None of that "directly" makes money either!

That tells us a lot more about the leadership and management philosophies at modern companies than anything fundamental about what kind of work actually matters.

I think programming is work, but I get your point :). And yes, of course - I'm mostly just curious how peoples roles at various companies are evolving as they hand off more and more to AI.

To be fair, thraway3837 posted a reply on a sibling comment and offered "AMA" :).

That said, I do see a lot of those posts you're talking about, and I think a lot of AI development is way overhyped. But I also think internal tools like this can be a good use case.

Personally "none of them have read any more than a few lines of code" makes me wary, but if it works for them, then so be it!

I have Claude work on web app testing scripts written in java using JUnit and selenium. The scripts test a vibe maintained flight booking app for an airline I can't mention without doing myself. The app is maintained using copilot by another vender. Claude was given to our team by our employer. We aren't even employees of the airline just contractors under a vendor. Before Claude was adopted everyone secretly used whatever chatbot they preferred. I used opencode with Deepseek v4.

I'm happy to provide specifics, within reason, of course. Ask away. I've since responded to comments with more detail, but if I missed something there, let me know!

You forgot a "vision". /s

“Maintainability” is probably the word you are really looking for. Few devs care whether something adheres to whatever as long as we maintain:

- user experience/expectation (i.e., if feature X worked three years ago, it still works in a consistent way today after a bug fix) - development cadence (if implementation of feature X took N days, a comparable feature Y should take N days) - sanity (can we assume that a fix going in Thursday night or Friday morning doesn’t wreck the weekend)

SOLID, DRY, ACID-compliant, linted, formatted, clean, functional, compositional, etc. May be the means (misdirected or otherwise) but they are not the motivator(or at least should not be).

What matters is whether the day two feature requests, bug reports, CVEs, and traffic load that are coming can be met on time.

Not saying it can’t be done without a developer at the helm, Anyone Can Cook™, but I guess it depends on what harness is in use or has created for the org, and whether that consideration is baked into the guidelines for the codebase (which seems to be, at least to some extent, what this service tries to course correct).

And of course, what is done to the process when incident x happens, again and again. Are we only updating code without paying attention to process that enabled it in the first place?

Maybe that’s the story of vibe coded repos: the code devs were removed but we really still need devops personnel. Also maybe new tech will be more readily adopted.

Interesting times.

Yes, I'm familiar with these talking points. I didn't mention clean code or solid or frameworks or anything like that.

However, the poster explicitly said they don't do what you said (EDIT: I misinterpreted some of these):

RE "talking to customers"

> We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to it, and create a PR

RE "figuring out whether it's actually working for people"

> have senior engineers review the actual functionality and none of them have read any more than a few lines of code

RE "figuring out what the heck to actually build"

> replaced by "vibe" coding

Maybe my definition of vibe coding is wrong?

--

In any case, I don't have some ulterior anti- or pro-AI motive. I'm genuinely curious why and how a project run this way has humans in the loop at all.

>Yeah they say it's not for enterprise usage but ok whatever.

For now, it's clear that they will likely begin restricting the subs or severely cut back their token allowance.

I could also see Claude looking at source code/repos to try and figure out if it's closed source. If true, demand token payment.