Bend 2 and the Vibe-Coding Trap

Bend 2 is being marketed as a language designed for the AI coding era, where humans write "laws" and the AI handles implementation and proofs, with the compiler checking their validity. While this concept seems promising, there are significant issues with the approach. The primary focus of this article is not on the shortcomings of Bend itself but on a common trap in vibe-coding, a method of programming where developers build extensive solutions before fully understanding the problem, potentially overlooking better options.

The demo on Bend's homepage requires 58 lines of code to establish rules stating that the player cannot touch a flag, leading to a game loss. Additionally, the LLM generating the program needs to write a staggering 442 lines of code to prove these "laws." The issue lies in the fact that vibe-coding allows developers to construct a comprehensive solution before gaining enough insight into the problem, often missing more efficient solutions that could have been identified with a basic survey of the field.

In this case, the field in question is formal verification, a term conspicuously absent from Bend's website or codebase.

To illustrate the problem, the same program demonstrated by Bend was recreated in SPARK, a language and compiler for formal verification. The process was performed manually, without the assistance of an LLM, resulting in a significantly more straightforward and efficient approach. The laws defined in both Bend and SPARK were identical, but the SPARK version required only about 120 lines of code to prove the correctness of the program.

The author of Bend missed the opportunity to leverage formal verification, instead opting for a verbose specification and proof process that could have been improved with some basic research. This example highlights a broader issue: vibe-coding makes it too easy to create a design that is outdated or fundamentally flawed, as developers can quickly obtain a result without the necessary research.

If a developer requests a language enabling formal verification through proof building from basic principles, an LLM would likely generate such a language, but it would never suggest exploring existing solutions that could drastically reduce the effort involved.