[chatmasta]

> business people don't understand why you can't just put their app in production

I’d flip that around and say that engineers don’t understand that sometimes you _can_ just put their app into production. It might take some cleanup, and some clever ways of deploying it in isolation, but some of these “vibe coded prototypes” — many made by technical business people (they do exist) – are much closer to production-ready than you might initially assume.

I’d encourage you to challenge your assumptions before dismissing the possibility. I’ve personally seen this workflow produce real production code, used by customers, in an extremely rapid feedback loop. Now is the time to adapt, not push back. Keep an open mind or you’ll be left behind.

[SlinkyOnStairs]

> Keep an open mind or you’ll be left behind.

An open mind to what? To yolo deployment of dodgy code straight into production? Moving fast and breaking things?

> I’ve personally seen this workflow produce real production code, used by customers, in an extremely rapid feedback loop.

Yes. I've seen it as well. I've also seen what happens. It goes wrong.

Should the engineers building your cars, your house, all other infrastructure also "keep an open mind" to slopping up their work?

Your next words will be "I'm not working on something safety critical".

You are. Even the most basic CRUD app handling personal data of any kind of safety critical these days. Data leaks alone KILL.

[chatmasta]

An open mind to not having a knee jerk reaction to “this is vibe coded therefore it’s not production-ready.” The delta between the prototype and production is likely far lower than you think, and many engineers are sneering at the prototype without actually looking at it or attempting to spend a few weeks applying engineering discipline to bring it up to scratch.

[SlinkyOnStairs]

Re-read what you wrote yourself.

What is being sneered at is these prototypes being put into production. What is being demanded is that additional engineering time to make sure it's actually up to scratch.

[yourapostasy]

> Now is the time to adapt, not push back. Keep an open mind or you’ll be left behind.

That’s not the gating factor. Who picks up the liability accountability and picks up the pager duty at o’dark thirty when it breaks in production, that’s the big gate. That long tail of accountability for operational risk weeds out a ton of Eager Ethan’s who want to see something go live yesterday. Because the success of launching has many fathers while the failures in the operational long tail is an orphan.

Get them to sign up for the long tail troubleshooting operations of the product. They are after all, now the SME on the product having built 90% of it. The full promise of AI in such a world is deploying and operating an AI-forward application is an artificial distinction, and full conviction means fully committing to the operational model.

[gwerbin]

I actually agree with you, although I don't agree with the "open your mind or be left behind" sentiment. I left it implicit in my example, but in my actual experience they actually can't put it in production as it is because there are genuine broken things or features they can't add without rewriting big chunks of the system. The worst are the ones that are not obviously broken but are just wrong, like incorrect numbers in a financial report.

But yes, I do agree that some engineers and some engineering teams are slow and cautious where it's not needed, to the point of obstructing rapid prototyping and iteration. And yes I agree that AI will be good to help push them to overcome it.

[8note]

> rewriting big chunks of the system

the costs of doing this is much lower than it has been

testing to make sure thats safe to do maybe hasnt caught up, but its no longer an unreasonable task

[gwerbin]

It's not about turning out the necessary lines of code. It's about doing the critical thinking, validating of assumptions, etc. which was not done the first time around.

Yes, AI can assist with the brute force of broad scale factoring. But without the humans and domain experts involved, you are going to either keep flailing around at the cost of millions of tokens, or something actually really bad in production that you don't even understand and won't work for your business.

The lines of code have never been a bottleneck for the actual engineering team. That's why AI is so good for expediting the prototype cycle and allowing stakeholders to develop their own prototypes, but why you still need someone who actually knows what they're doing to finish the project, whether they are manually typing the lines of code or letting Claude do it.

[Ancalagon]

I cannot wait for those business people to run the ops themselves for their vibe coded apps in production.

[condwanaland]

In my experience, business people are chomping at the bit to build and manage the ops for their apps, but it's always an "IT Operating Model" that is thrown back at them

[Ancalagon]

I have never met a product or sales person chomping at the bit to manage the PagerDuty of the apps they peddle to management

[mekdoonggi]

Vibecode a clone of the production stack and give them the keys and tell them to figure it out lol

[okamiueru]

As someone who's had to deal with a fair share of these types of sentiments, they have been, without exception, based on incompetence, and demonstrably wrong.

That isn't to say that there aren't cases where "just do the happy path" is actually sufficient, and the right thing to do. However, and bit overly simplified, but the non-happy-path is almost always the important parts of a system. It's the monitoring. Disaster recovery. Error handling and correction. Well thought out data models that prepare for future features, etc.

[_the_inflator]

In all honesty: no, and no.

Security, legal considerations, internal controls and tracking for monitoring.

See, corporate means usually financial services. Money laundering is a thing here and there are deliberately checks and controls implemented as well as boundaries which don't allow for "deploy to PROD instantly" processes since they pose a red flag.

For example, PEN testing is mandatory as well as token handling to connect to the right backend.

Legal, as a hint, has a show stopping word in here. Every text, that surfaces, needs to be approved first, and also documented. "How inflexibel and anti-business" you might think, but here is the kicker: the wrong words as well as wording gets you into trouble faster than you can imagine.

Here is one example out of many dangerous mistakes, that cost you dearly besides a noticeable shitstorm:

We (one of the largest banks operating globally) were 2017 (!) already closely monitored which means, every change would not be undetected. And we are not talking about days later, but instantly, seconds later.

We have to follow certain obligations in certain countries to conform to legislation. So we are also obliged to incorporate changes, but these had to follow strictly the letters of the law. So if you deploy this change 5 minutes too early or too late for a specific day, you could be hit by a lawsuit. Ridiculous you might say and I somehow have to agree but my opinion does not play a relevant role here or better: won't change because I follow law while keeping my opinion.

And this is also something that disallows for the "vibe code to PROD" myth: Usually many teams and departments are involved.

I am glad I worked in corporate, because my understanding went from the cocky and totally arrogant "One team from us would beat you all easily. You are totally outdated." line to the "Well, now I understand that it is a difference to be under scrutiny globally and have to define responsibility as well as accountability depending on the context. And god forgive me, that I had no insights into a huge regulated machine, that has serious redundancy, however it works and rebels do more harm than good."