Software Engineering in the Age of A.I.

---

The Thesis

Meyer opens by intentionally “spoiling” his destination: the future is not just AI writing code, but AI supporting the whole software lifecycle, with the software engineer acting as an orchestrator. From my vantage point, that’s the right level of conversation. In every high-accountability program I’ve led, quality has come less from heroics in implementation and more from a controlled lifecycle where requirements, design, verification, and evidence stay connected.

He explicitly keeps the human engineer at the center. For practitioners and leaders, this matters: if we treat AI as an autonomous producer, we inherit its failure modes. If we treat it as a set of accelerators inside a disciplined process, we can get speed and confidence.

TL:DR – Jump to conclusions.

---

The spark: “vibe coding” and why “mostly works” is a problem

To ground the discussion in the current zeitgeist, Meyer references Andrej Karpathy’s “vibe coding” tweet, which advocates an ultra-fast, intuition-driven workflow: “accept all,” don’t read diffs, copy/paste error messages, iterate until it works. Meyer doesn’t spend the whole talk critiquing “vibe coding,” but he uses it as a foil: it highlights the mismatch between speed and assurance.

“vibe coding” is a useful label precisely because it makes the trade-off explicit: you can buy speed by spending less on review, verification, and evidence. In low-consequence contexts that may be fine; in high-consequence contexts it’s a debt instrument with a high interest rate.

The phrase “mostly works” becomes a micro-summary of the verification problem. “Mostly” may be acceptable for prototypes and demos, but it is not a tolerable posture for many real systems, especially when security vulnerabilities, reliability failures, and safety hazards are possible outcomes. The more AI accelerates generation, the more the system needs disciplined ways to detect, prevent, and contain defects.

---

Career anxiety framed as a technical question: skill‑leveling (L) vs skill‑enhancing (E)

Meyer acknowledges the audience’s anxiety about what AI means for the profession, but he quickly reframes the discussion into a technical lens: some breakthroughs are skill-leveling (they reduce differences between experts and novices), while others are skill-enhancing (they amplify the advantage of top performers). This is more useful than generic “AI will replace jobs” discourse, because it forces the reader to ask: Which tasks are being commoditized? Which tasks become more valuable?

He illustrates leveling with tools that provide a shared capability baseline (e.g., GPS navigation); and enhancing with tools that scale distribution and impact (e.g., the printing press, which made great writing scale globally). The relevance to AI-assisted engineering is that code generation may reduce the “entry barrier” for some categories of development, while simultaneously raising the premium on those who can define problems well, reason about tradeoffs, and enforce quality.

For leaders, the takeaway is straightforward: AI may compress effort in implementation, but it increases the strategic value of strong engineering management. Clear requirements, explicit risk decisions, verification strategies, and accountability.

On one side we have the forecast of English simply replacing programming and computer science as a whole.

But then the reality if full of nuances, even Nvidia is still hunting for top talent and the risks and actual failures of lack of process with new AI Agents has surfaced big time.

---

Intellectual discipline: avoid anecdotes, use state‑of‑the‑art, separate hiccups from essentials

Before making claims about AI’s limits or risks, Meyer insists on epistemic hygiene. He argues that negative conclusions drawn from old models or free tiers are weak evidence, because the technology is moving quickly and recently improved. He also distinguishes between early hiccups of a new technology (which often disappear) and essential limitations (which persist because they are structural).

This matters to software engineering: engineering decisions should not be based on isolated demos or one-off failures/successes. Instead, the evaluation should be: are we using the best tools available, what do measured studies show, and what class of failure modes are inherent to the approach?

In regulated environments, we’d simply call this “objective evidence.” The same mindset applies even when the product is not regulated: treat claims (positive or negative) as hypotheses that need disciplined validation.

---

“Just state what you need”: why requirements are the hard part

Meyer targets a recurring claim: “We won’t need programming; we’ll just tell the computer what we want in English.” He argues that the critical word is “just.” The act of specifying what you want (unambiguously, completely enough, and in a way that survives change) is a large fraction of software engineering difficulty. Requirements engineering requires abstraction, structure, and logic; it is not eliminated by swapping Java for English.

This is where verification and AI intersect sharply. If the requirement is ambiguous, tests and proofs can only validate the wrong thing faster. In other words: AI can accelerate output, but it can also accelerate misinterpretation unless requirements are treated as first-class engineering artifacts.

In practice, this is where I see leaders either win or lose with GenAI adoption: teams optimize for “producing more code,” while under-investing in the hard work of defining what “correct” means and how we’ll know.

---

Déjà vu: why “no more programmers” has been promised before (and what actually happened)

Meyer notes that “end of programming” narratives are not new. He lists prior waves (COBOL, 4GLs, 5th generation computing, component-based development, model-driven development, low-code/no-code) that each promised to remove the need for programmers. The pattern, he argues, is that abstraction levels rise and some skills become less central, but the underlying need for engineering remains.

He then adds an important nuance for the AI era: unlike compilers (which translate high-level code to machine code largely invisibly), AI-generated code frequently still demands inspection. Even if the AI is “doing the work,” we often cannot safely “push a button and forget about the result.”

The key taxonomy: Casual vs Business vs Acute software (ABC) and where AI truly fits today

Meyer’s ABC framing is one of the most practical parts of the talk. He distinguishes:

• Casual software: scripts, websites, experiments, MVPs—where failure is inconvenient but not catastrophic.
• Business software: enterprise systems that are important and costly, though not necessarily life-critical.
• Acute software: mission/safety-critical systems where failure can have severe consequences (transport, aerospace, medical, defense).

This taxonomy clarifies the otherwise polarized debate. AI “push button, forget it” workflows can work well for casual development and can be genuinely transformative. Enabling non-programmers to produce demos and prototypes. But as you move into business and especially acute domains, “mostly works” becomes unacceptable; verification and validation rigor must rise.

This is the lens I recommend for practitioners and leaders: decide explicitly which parts of your stack are “casual,” which are “business,” and which are “acute,” then align your AI usage and verification investment accordingly.

---

The “probable vs provable” clash: why statistics-based generation collides with engineering rigor

This is the conceptual heart of the talk. Meyer argues that modern AI systems (LLMs especially) are built on probability and statistics: they generate the most likely answer, not a guaranteed-correct one. “Hallucination,” in this view, is not a temporary bug; it is a structural consequence of probabilistic generation (even if rates improve).

He reinforces the point with a compositional argument (attributed to Dijkstra): even if individual components are “almost correct,” large systems multiply small error probabilities into unacceptable overall risk. In software, we don’t ship single functions, we ship systems composed of thousands of pieces. This is why “probable” is not enough: engineering needs methods that can establish “provable” properties, at least for critical behaviors.

My pragmatic translation: treat LLM output as a powerful draft generator, not as an authority. The authority is the verification strategy and the evidence it produces.

---

Verification as the “right side of the V”: use AI on both creation and checking

Meyer highlights a fundamental duality: creating software vs verifying it. He references the V-model, not as an endorsement of rigid waterfall, but as a reminder that verification activities must match production activities. If AI increases the speed and volume of generated artifacts, verification must become even more systematic.

He also notes that reality is fractal/iterative: a “V within a V,” repeated at different granularities. This aligns with modern engineering: short cycles, continuous integration, regression suites, and iterative specification refinement.

For leaders, the operational point is that AI doesn’t remove the need for the right side of the V; it increases the throughput pressure on it. If verification capacity doesn’t scale, risk accumulates invisibly until it becomes incident-driven work.

---

Why formal methods struggled and how iterative contracts can make them workable now

Meyer argues that one reason formal methods have struggled in broader adoption is process mismatch: many formal approaches implicitly assume stable requirements and a “specify first, then implement, then prove” pipeline. Real projects don’t behave that way; requirements change, designs evolve, and proofs (like debugging) are iterative.

His proposed remedy is an iterative approach where specification and implementation co-evolve, with contracts placed near code (design by contract). Verification becomes a daily practice: write code and contracts, try to verify, fail, diagnose, then revise either the implementation or the specification.

This is one of the places where I see a real opportunity for AI: not to “replace the prover,” but to reduce the friction in writing and maintaining specs, contracts, and tests, so more teams can adopt higher assurance practices without an all-or-nothing process overhaul.

---

The multi‑agent future: requirements → architecture → contracts → code → tests → proof → DevOps (human‑orchestrated)

Meyer returns to his opening teaser: if we are serious about correctness in an AI-accelerated world, we must use AI across the lifecycle, not only for code. That implies specialized agents for distinct responsibilities:

• Requirements support (including glossary generation and constraint discovery)
• Architecture support (component boundaries, interfaces, tradeoffs)
• Contract/spec agent (from code to contracts and from contracts to code)
• Coding agent
• Test-generation agent (a “big unsolved issue,” labor-intensive today)
• Testing agent (running, triaging, analyzing failures)
• Proof/verification agent
• DevOps/deployment agent

The essential governance concept is the human-in-the-center: hallucinations persist, tools are imperfect, and responsibility remains with the engineer. Therefore, orchestration requires competence and oversight.

In other words: if we build agentic workflows, we should treat each agent like a junior contributor—fast, helpful, sometimes wrong—whose output must be reviewed and verified in proportion to risk.

---

Conclusion

What changes for careers, outsourcing, and quality

Meyer closes by answering the L vs E question. For casual development, AI is leveling: more people can build working artifacts quickly, reducing the value of low-skill outsourcing and routine coding tasks. For business and acute development, however, AI is enhancing: it amplifies the advantage of engineers who combine software engineering fundamentals with AI literacy and verification discipline.

He emphasizes personal responsibility: even if you “accept all,” you own the outcomes. And he warns that acceleration increases bug creation rate unless quality control keeps pace, turning verification into the strategic differentiator.

For my network, I’ll summarize it this way: GenAI adoption without a coherent verification strategy is just accelerating uncertainty. GenAI adoption with verification strategy is an opportunity to deliver faster and raise quality, especially in the systems we can’t afford to get wrong.

Summary – by Bertrand Meyer

• AI support for Software Engineering is here to stay
• “C” class development can be essentially automated

For A and B software:

• AI is not yet ready for a full SE process
• There is a culture clash between the creativity of AI and the rigor of Software Engineering
• Hallucinations remain a major problem
• The only sure way is formal verification and alternatively well planned V&V
• We need a clear process
• Real software development is iterative, stay Agile
• We are only at the beginning

Strategies for Individuals

• The irruption of AI into SE is both:
  • Type-L for C-class developments (Casual)
  • Type-E for the rest (Business and Acute)
• Unclear prospects for low-skill outsourcing
  • AI is going to be cheaper than the cheapest programmers
• Excellent prospects for companies to reclaim ownership (less outsourcing more ownership of culture)
• Every software engineer must master Modern-AI
• You are still responsible for the code!
• Quality is key, particularly correctness, robustness, extendibility, reusability, “maintainability”
• Lessons of software engineering still apply (More than ever)

Bertrand Meyer

Professor at ETH Zurich and CTO of Eiffel Software and Recognyze AI

Bertrand Meyer is Professor of Software Engineering and Provost at the Schaffhausen Institute of Technology in Switzerland and CTO of Eiffel Software (based in Santa Barbara). His is the author of several well-known books on software topics, particularly object technology, programming languages, software verification, and agile methods. He is a recipient of the ACM Software System Award and the IEEE Harlan Mills prize and an ACM Fellow. His previous ACM TechTalks were devoted to Design by Contract, agile methods, and concurrent programming.