← Latest papers
💻 computer science

AI for software engineering: from probable to provable

This paper argues that to overcome the challenges of vague requirements and hallucinations in "vibe coding," AI-driven software engineering must be integrated with formal specification methods and program verification to ensure correctness.

Original authors: Bertrand Meyer

Published 2026-04-24
📖 4 min read☕ Coffee break read

Original authors: Bertrand Meyer

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Idea: From "Vibe Coding" to "Proof Coding"

Imagine you are building a house. Right now, everyone is excited about a new tool called "Vibe Coding." This is where you tell an AI, "Build me a house that looks like a castle," and the AI magically generates the blueprints and bricks.

The paper argues that while this is fun and fast for small projects (like a garden shed), it is dangerous for building skyscrapers or hospitals. Why? Because AI is a statistician, not a logician. It guesses the most likely answer, not the correct one.

Here is the breakdown of the problem and the proposed solution.


1. The Problem: The "Confident but Wrong" Student

The author compares current AI (Large Language Models) to a cocky, brilliant, but sloppy graduate student.

  • The Good: This student has read every book in the library. They can write code fast and sound very confident.
  • The Bad: They are prone to "hallucinations." They might invent a library that doesn't exist or suggest a bridge design that looks great but collapses under the weight of a bicycle.

The Trap: In fields like medical diagnosis or translation, being "mostly right" is fine. If a translator gets 95% of a sentence right, you still understand the story. But in software, being 99% right is the same as being 0% right.

  • Analogy: If a plane's autopilot is 99% right, the other 1% is the difference between a smooth landing and a crash. You cannot have "almost working" software.

2. The "Domino Effect" of Errors

Software is made of thousands of tiny pieces (modules) connected together.

  • The Analogy: Imagine a chain of 1,000 people passing a message. If each person is 99.9% accurate, the chance that the message arrives perfectly at the end is only about 37%. If you have 5,000 people, the chance of the message arriving correctly drops to less than 1%.
  • The Reality: AI is great at generating one piece of code, but because it makes small, random errors, those errors multiply when you try to build a massive system. The whole thing becomes unreliable.

3. The "Hippie vs. The Disciplinarian"

The paper uses a funny image to describe the clash between AI and Software Engineering:

  • The AI (The Hippie): Wearing a tie-dye shirt, full of creativity, empathy, and wild ideas. They want to generate code instantly based on "vibes."
  • The Software Engineer (The Disciplinarian): Wearing a stiff suit, serious, and obsessed with two things: Correctness and Cost. They don't care how cool the code looks; they care if it works without crashing.

The paper asks: Can these two get married? Can we use the Hippie's creativity to generate ideas, and the Disciplinarian's rules to make sure they are safe?

4. The Solution: "Vibe-Contracting" (The Marriage)

The author's answer is Yes, but only if we combine AI with Formal Verification.

Think of Formal Verification as a Mathematical Inspector.

  • Instead of just asking the AI to "write code," you first ask it to write a Mathematical Contract (a precise rulebook) of what the software must do.
  • Then, you use a computer program (a proof tool) to mathematically prove that the code the AI wrote actually follows the contract.

The New Process:

  1. The AI suggests a design and a contract (the "Vibe").
  2. The Human checks the contract to make sure it makes sense.
  3. The Proof Tool acts like a strict referee, checking every line of code against the contract.
    • If the code passes the math test: It is Proven Correct.
    • If it fails: The AI tries again, or the human fixes the contract.

5. Why This Matters

  • For "C" Projects (Casual): If you are making a simple app for a dance club, "Vibe Coding" is fine. If it crashes, you just restart.
  • For "A" and "B" Projects (Critical/Business): If you are building a banking system, a medical device, or a power grid, you cannot rely on "probable" answers. You need provable answers.

The Bottom Line

The paper concludes that we shouldn't fire all the programmers. Instead, we should upgrade our toolkit.

  • Old Way: AI guesses code -> Humans hope it works.
  • New Way: AI generates ideas -> Humans and Math Tools prove it works.

The author calls this "Vibe-Contracting." It's about using the AI's speed and creativity to draft the plans, but using the rigor of mathematics to ensure the building won't fall down. It's the only way to move from "Probably works" to "Proven to work."

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →