Breakthrough insight about vibecoding:
Haskell programmers believe in the concept of a function being "done". Meaning for some reasonable type signature there is only one reasonable definition, and maybe even the compiler can infer it at that point. Pilquist, in that talk i mentioned, discussed the notion of a HTTP server that was done, it had no bugs in it, we can use it forever. I don't know if I believe in that but it's an interesting idea. To use typelevel abstraction to box in a definition so tightly that we can eliminate categories of errors by construction. Once a function is done, we never have to change it again, and the whole world can reuse this as bedrock infrastructure.
We see this in physics as well. The Schrodinger eqn, Dirac, Maxwell, these equations are done, they don't have bugs, they are isomorphic to the model they encode and these models can now be leveraged as inputs to other models that generate conclusions of stunning complexity and rigor.
Vibecoding is a reaction to this not being true in product development. Nothing is ever done, in fact code actively rots, you can leave a JS or Python project alone for a year and come back and you can't turn it on because the environment has changed and it was accidentally coupled to the environment.
So if nothing is ever done, what product ownersand developers are doing is giving up, they're just over-rotating into the opposite direction. Which kind of makes sense.
And what I like about this model is that it provides a clear belief predicate for who will like vibecoding and who wont. Belief in if your functions can be done.
Personally, with Electric, my functions aren't done yet, but we think we got the typelevel abstractions right (differential dataflow), we believe at the typelevel, with Electric, UI is done, at least conceptually, in principle. And maybe someday a brilliant CS researcher will be able to generate Electric's internal definitions.