I've been working on articulating this for about a month, and I've had trouble doing it. It's challenging because the psychology of software engineering is complicated, and the reasons businesses continue to buy software are complex. It's never really been about the specifics of any product. There's more to it.
If I were a business manager, and someone on my team said, "Look how much money we could save with this vibe coded app we made that replaces Vendor X," it would make me nervous.
And I think it would make me nervous for the same reasons that using open source would have made a business manager nervous 20 years ago.
Is it proven?
Possibly?
Is it supported?
No?
Okay... how much is this going to cost me when something goes horribly wrong?
No idea, huh.
Hard pass.
The other thing people keep saying is, "It's so cheap and easy to do!" And all I can figure is that those people have never tried to "reverse engineer" (we're still using the wrong term, the correct nomenclature for what's happening is "contract reversal"), anything like these apps, otherwise they wouldn't say it.
If it's bigger than a breadbox, or older than a couple of years, it's going to take effort, time, reengineering, and firsthand knowledge of the application itself.
These things are still slow and tedious, because it's not a problem of parallelism, and throwing more agents at a problem that neither you or they understand isn't going to make it happen faster.
On the other hand, that math changes quite a bit if you feel like you're in a coercive relationship with a vendor, and there aren't many options.
Why do you think they went after Adobe first?
More later.
I love you all.