The creator of Extreme Programming and the first signatory of the Agile Manifesto, Kent Beck, delivered a one-hour talk titled "Software Engineering in the Age of AI" at the Prodacity 2026 conference in Nashville, and the recording of the talk has been published. He compares generative models to a "genie": plausible code does not equal working code, and, in his opinion, spec-driven development risks turning into waterfall in a new wrapper. At the same time, Beck offers not a prophecy about the end of the profession, but a set of working principles for teams transitioning development to AI assistants.

image

What happened

The full recording of the talk appeared on YouTube on September 29, 2026: the duration is 3112 seconds, i.e., about 52 minutes, and in the first few days the video gathered over 85,000 views. The talk was delivered at the channel conference Prodacity 2026, organized by the company Rise8 in Nashville; a discussion unfolded around the recording on Hacker News. In the material, Beck introduces an assessment of the cost of a feature through "burned options of change": each decision today irreversibly reduces the project's flexibility reserve. The most technically rich place is the experience of applying formal methods with Theorem Prover Lean: a strict verifier could issue a provable signal that the code really works, but, according to Beck's observation, formal verification is currently poorly integrated with the randomness of generation. The talk concludes with the chain "effort — output — outcome — mission," on which the author shows how Goodhart's Law distorts premature metrics: an indicator that has become a goal stops measuring what it was introduced for.

Context

Beck's weight in this discussion is special: Extreme Programming, testing through TDD, and the Agile Manifesto itself have long been built into how the industry writes code, so his conclusions sound not like a fashionable forecast, but as a continuation of his own long-term practice. The talk comes against the backdrop of the current debate about what is better for working with AI assistants — "specs instead of prompts" or an iterative process with fast feedback; vendors are promoting the first path, and Beck here sided with iterativity. The economic background of the talk is simple: the generation of plausible code is becoming cheaper and commoditized, and the shortage becomes the opposite things — verification of the result and connection with business effect. Against this backdrop, the old problem of code generation benchmarks is exposed, where proxy assessments of plausibility have long diverged from the real usefulness of the code.

Why this is important for the industry

For the industry, the talk is not another "AI will change everything," but a dictionary and framework for teams transitioning development to AI assistants. The dichotomy "plausible vs working" turns into a task assessment: generated code can be trusted only after verification, so the center of gravity shifts to tests, reviews, and evals. The criticism of spec-driven development describes a regression mechanism that is currently being massively reproduced in companies' AI pipelines, and spec-approach providers will have to prove iterativity, not promise one-shot. The components of advantage for startups are also changing: the protective layer becomes not the speed of writing code, but the guarantee of operability and connection with business results, and on this gap it is logical to expect new tools — test generators, agent reviewers, run/verify layers. The chain "effort — output — outcome — mission" additionally suggests how to build AI feature metrics: measure outcome, not output.

Why this is important for users

For a reader who writes code with Claude or Copilot and argues about "specs instead of prompts," the talk gives 52 minutes from a person whose practices he already uses daily. The practice consists of several principles: to prefer an iterative loop to one-shot output for copy-paste, i.e., generate, verify, and accept in parts; to replace large specs with early micro-checks; to keep verification — tests, reviews, evals — as the main filter for code that only looks correct; not to tie trust in the process to activity metrics like the percentage of accepted edits, because they easily become an end in themselves. It is separately valuable that Beck does not take the desired for the real and directly names the places where his own approach does not yet work. The video is public and free, so these principles can be applied today.

What is not yet known / limitations

The talk is an expert framework of a practitioner, not a research result: it contains no datasets, protocols, reproducible measurements, data on cost and latency, or APIs or benchmarks. The process thesis about spec-driven development is a statement about the process that cannot be refuted by a benchmark, and there are no confirmations from real company pipelines in the sources; the thesis contradicts the vendor trend, and both sides remain with their opinions. The direction with Lean is also currently an observation: Beck himself notes the mismatch of formal verification with the randomness of generation, but no solutions are provided in the sources. Finally, individual interpretations — for example, the transfer of the chain "effort — output — outcome — mission" from development metrics to the assessment of AI assistants themselves — are interpretations that go beyond what was said in the talk, and reasoning about the future wave of verify tools are extrapolations, not confirmed trends.

Sources

Author

Look at AI, editorial team