Bend 2 and the Vibe‑Coding Trap: Why Skipping Prior Research Leads to Redundant Formal Verification Efforts

Takeaway

Bend 2 demonstrates how relying on LLMs to generate a language and its proofs without first researching the formal‑verification landscape leads to unnecessarily large specifications and proofs, duplicating work that mature tools like SPARK already handle efficiently.

What Bend 2 Claims to Offer

  • AI‑assisted development model: humans write laws, an LLM generates implementations and proofs, and the compiler checks proof soundness.
  • Demo code: the official demo requires 58 lines of laws and a 442‑line proof to guarantee that a player can never win the game.
  • Implicit promise: the language promises a new, AI‑driven workflow for formally verified software.

The Vibe‑Coding Trap Defined

Vibe‑coding is the practice of building a substantial solution before acquiring enough domain knowledge to recognize that a far better, existing solution already exists.

  • Developers prompt LLMs with high‑level goals.
  • The LLM produces a complete artifact (language, compiler, proofs) without surfacing prior art.
  • The result is often verbose, redundant, and lagging behind the state of the art.

Formal Verification Exists – But Bend 2 Ignored It

  • The term formal verification does not appear on Bend’s website or in its codebase.
  • Established languages such as SPARK (Ada), Coq, Lean, and Isabelle/HOL provide mature ecosystems for specifying and automatically proving program properties.
  • A simple recreation of Bend’s demo in SPARK requires only the program and a handful of annotations; GNATprove verifies it with 12 automatic checks and no manual 400‑line proof.
function Replay (Keys : String) return State
  with Post => not Replay'Result.Won
               and Cell (Replay'Result.X, Replay'Result.Y) /= 'F';

The SPARK version demonstrates that the same safety guarantees are achievable with far less boilerplate.

Community Reactions Highlight Key Points

@z7 – The claim that the author “didn’t know formal verification exists” is false; the author has posted extensively about the field.

@captainmuon – Existing formal‑verification languages suffer from usability issues; developers want a syntax closer to mainstream languages, which is part of why Bend was created.

@mentalgear – Emphasizes the need to research prior work before asking LLMs to generate large artifacts, to avoid wasteful token consumption.

@LightMachine – Provides a detailed rebuttal, noting that the author intentionally designed Bend’s explicit proof language for performance reasons and has a decade‑long background in formal methods.

@simonw – Suggests a practical workflow: start every LLM‑assisted project with a “search‑enabled” query to surface prior art.

@thomasahle – Points out that SPARK’s automatic proofs rely on SMT solvers (brute‑force) and do not scale to complex mathematics, whereas Bend aims for expressive, symbolic proofs.

These comments illustrate a spectrum of opinions: some view Bend as reinventing the wheel, while others see it as a purposeful experiment addressing usability and performance gaps.

Why the Redundancy Matters

  1. Token and compute waste – Generating a 442‑line proof consumes considerable LLM resources that could be avoided with existing tools.
  2. Maintenance burden – A custom proof language requires its own ecosystem, documentation, and auditing, increasing long‑term overhead.
  3. Opportunity cost – Time spent re‑implementing known techniques could be redirected to novel research or higher‑level applications.

Lessons for LLM‑Assisted Development

  • Start with a literature search: before prompting an LLM, ask it to list existing frameworks, languages, and libraries relevant to the problem.
  • Identify the minimal viable integration: often a thin wrapper around an established tool (e.g., SPARK, Coq) suffices.
  • Treat LLM output as scaffolding, not final design: use the generated code to prototype, then replace large custom components with proven alternatives.
  • Document assumptions and trade‑offs: make explicit why a new language or proof system is needed beyond existing solutions.

Conclusion

Bend 2 serves as a cautionary example of the vibe‑coding trap: building ambitious, AI‑generated systems without first understanding the existing state of the art leads to duplicated effort, verbose artifacts, and missed opportunities for leveraging mature verification tools. By incorporating a disciplined research step before LLM prompting, developers can avoid reinventing the wheel and focus on genuine innovation.

Sources

Related