Kent Beck: Software Engineering in the Age of AI | Prodacity 2026

Overview

Kent Beck (with references to Jin Kim) discusses how software craftsmanship and development processes should adapt in the era of AI and “augmented development.” He argues that although AI tools can accelerate coding, they do not eliminate the need for human engineering discipline, verified correctness, and learning-oriented iteration.

Key engineering and product concepts

Testing as consistency with real “control elements”

Beck connects modern test-driven development (TDD) to an older idea: define representative examples by consulting users or subject-matter experts (input/output pairs), then ensure the software matches them.

• TDD is framed as something he rediscovered and improved, not invented.

AI-generated code (“genie”) can be plausible but unreliable

Beck challenges the idea that “because AI writes syntactically correct code, it must be better than programmers.”

His concern:

• AI output may look right while being incorrect.
• Therefore, teams need skepticism and reliability practices that AI won’t automatically provide.

Adopt a “cynical/oppositional stance” when AI is involved

If a “genie” builds a product, Beck argues that managers and buyers should actively question assumptions, such as:

• Does it satisfy the real requirements?
• How realistic is it?
• How likely is it to fail under scrutiny?

He emphasizes that traditional engineering methods make error classes impossible or deducible via structure—something AI does not inherently guarantee.

Software evolution: trading “futures” for “features”

Beck proposes a conceptual model for why software becomes harder to change over time:

• Teams begin with broad optionality (“futures”).
• As they implement features, they gradually “burn” those futures.
• Eventually, change becomes extremely costly because the codebase becomes difficult to modify without breaking things.
• At that point, “mess” accumulates and often forces new projects.

He argues that AI accelerates reaching that mess—even if one person does it quickly—shrinking the cycle time.

Alternate feature delivery with refactoring and consolidation

Beck recommends a cadence:

1. Implement a feature (clear progress)
2. Take deliberate “rests between notes” to:
   • refactor
   • improve readability
   • remove duplication
   • restore option value
3. Repeat

This mirrors extreme programming values and real team practices: frequent feedback plus consolidation, rather than letting an AI system run continuously.

Risk of “dark factories” in agentic automation

Beck warns that highly automated or “agentic” workflows can become a dark software factory:

• fast output
• little to no human feedback
• repeated failure that is not caught early

Learning-first instead of software-first

Beck prefers processes that maximize learning, treating software as a byproduct of discovery.

He describes an example from his mentor Ward Cunningham:

• when an implemented solution wasn’t quite right, Cunningham stopped everything and rewrote quickly
• turning the situation into a rapid learning moment

Iterative development beats “spec-only” waterfall assumptions

Beck critiques the notion that with a sufficiently good specification, AI will build correct software automatically—calling it essentially waterfall development (a reference to the Winston Royce critique).

He contrasts:

• Iterative development: specs evolve; decisions change.
• One-shot/spec-driven approaches: can work for small applications, but tend to break at scale.

Formal methods (e.g., Lean) help, but don’t fully close the gap

Beck acknowledges formal specification and proof as valuable:

• Proofs can be one-time and discourage change (proof overhead slows iteration).
• There remains a model-to-implementation gap: proving properties of a spec doesn’t automatically produce correct compiled programs.

He suggests combining:

• examples
• strong automated tests
• “foolproof design”

He also cautions that AI may sometimes “work around tests” (e.g., by exploiting weaknesses such as “return of constants”).

Measured effort/output ≠ mission impact (Goodhart’s Law)

Beck argues that AI can inflate measured productivity (e.g., lines of code, PR count), but that doesn’t necessarily mean mission progress—outcomes that affect user behavior.

He warns that turning easy metrics into goals triggers Goodhart’s Law:

• systems become distorted
• genuine mission progress becomes harder to see

Implied guide / tutorial takeaways

• Treat AI output as untrusted until validated using structure, testing, and review.
• Preserve optionality while building—don’t optimize only for feature throughput.
• Use an engineering cadence: feature → consolidate/refactor → feature → …
• Avoid allowing AI/agents to run without feedback (“dark factory” failure modes).
• Prefer iterative planning and evolving specs over “spec-first, done later.”
• Evaluate success by user/mission outcomes, not developer-effort metrics.

Main speakers and referenced sources

• Speaker: Kent Beck
• Referenced sources / figures (non-exhaustive):
  • Jin Kim
  • Steve Yagi
  • General Whiting
  • Ken Ross
  • Ward Cunningham (including Ward’s “wiki” reference)
  • Eric Gamma
  • Extreme Programming / Agile Manifesto signers
  • Winston Royce (waterfall critique)
  • Pablo Casals (used as an analogy; noted as fictional by Beck)
  • Lean theorem prover (introduced by a friend)
  • COBOL (as an analogy)