3 ms·
The more hard constraints one imposes on generative AI output, the more that it becomes exponentially harder to constrain that output to those constraints: so m
by mjburgess 2y ago
The more hard constraints one imposes on generative AI output, the more that it becomes exponentially harder to constrain that output to those constraints: so much for "embracing the exponentials" -- constraint-exponentials dominate vibe-exponentials.
With only a few dimensions of constraints there are zero relevant examples in training data, with only a few more, there are zero similar examples. This is why programmers are employed: it is always a R&D job, if it existed under relevant constraints, it would be purchased and installed.
The art of vibe coding, such as it can be developed as an art, is in segregating system design to localise (constraint-induced) novelty. There are certain applications of genAI where it makes sense to give up on a plan, and take good-enough. Software "in the large" is not such a place.
It's no accident its data scientists who began vibe coding -- it's a fundamentally "in the small" activity with no hard constraints: much like the throw-away exploratory programming of data science. Hence, I suppose, the alarm and confusion amongst software engineers -- perhaps they just aren't aware they're speaking to a radically different kind of "throw away programmer" that exists in the AI space, they've always been vibe programmers.
- hadlock 2y ago> This is why programmers are employed: it is always a R&D job, if it existed under relevant constraints, it would be purchased and installed. Clearly you've never had the pleasure of working at a NIH (not invented here) syndrome culture company. At one company, we didn't have budget to buy a ticketing system, but somehow we prioritized engineering building one from scratch. Another time I was talking with an engineer at Roblox and the engineer interviewing me was building a config scanning and management system from scratch for pretty generic linux installs. I can think of at least two companies that offer a product that did everything they needed and more, plus it was a full featured, stable production ready system, vs theirs which had serious teething issues and was obvious they were struggling to scale it. There's no shortage of these kinds of config management systems out there but they decided to build their own anyways. At another company our "staff" infra guy wrote 40,000 lines of bash because he didn't like how Jenkins worked for deploys. These are all very standard things that keep getting coded over and over for whatever reason. I haven't tried it yet but I'm pretty sure you could "vibe code" a Jira or Jenkins clone in a couple of days and at least pass the PoC sniff test. I've certainly done it for some throw-away prometheus exporters to get some crude visibility into third party services we have to use.
- dingnuts 2y ago> I'm pretty sure you could "vibe code" a Jira or Jenkins clone in a couple of days and at least pass the PoC sniff test. oh man, just think of the security implications of a "vibe coded" CI system, holy shit I'm going to have to get into consulting because there is going to be SO MUCH MONEY to be made digging organizations out of self-created holes like this one. Jira too, considering the importance of RBAC there, if you tried to replace that in a couple of days, inevitably that's a lawsuit waiting to happen. Lol I love also that I got a downvote before I was done editing this comment. Love it. Be mad, I'll be rich. This is a whole new category of "I could build that in a weekend," lol, no you couldn't.