I want to coin another term, "Pyrrhic Productivity."

[dk@tldr.nettime.org]

I want to coin another term, "Pyrrhic Productivity." When AI-coding agents promise speed by removing human effort but end up slowing work by breaking the feedback loops that produce understanding and shifting skilled work from doing to specifying and controlling.
1/9

[dk@tldr.nettime.org]

The term is inspired by Pyrrhus of Epirus, who, after defeating the Romans, is said to have remarked, "Another such victory and we are lost."
2/9

[dk@tldr.nettime.org]

What we've learned from Agile, XP, etc., is that software development productivity comes from small iterations and tight inner loops. Write code, run it, observe behaviour, learn, adjust. This keeps feedback immediate and drives learning.
3/9

[dk@tldr.nettime.org]

You know how and why things break, start to get a clear picture of the problem domain, and learn to identify patterns, anti-patterns, and code "smells."
4/9

[dk@tldr.nettime.org]

With spec-driven workflows, agile tight inner loops become slow outer loops that depend on high-fidelity specifications.

Work shifts from coding to making specs, prompts, lemmas, tests, etc. The agent generates code really fast, but feedback becomes hidden.
5/9

[dk@tldr.nettime.org]

Debugging moves from fixing code to adjusting specs and tests.

You must anticipate correctness conditions in advance, and creating the specifications and verification is also technical, sometimes even more so than coding.
6/9

[dk@tldr.nettime.org]

Since specification and verification can never cover everything, the agent always satisfies the known checks while new issues appear, leading to a specification and regeneration whac-a-mole.
7/9

[dk@tldr.nettime.org]

Over time, the codebase becomes Ptolemaic: as the agent adds epicycles, guards, exceptions, and compensations to keep the system passing its proofs.

The result is a Pyrrhic victory: The time saved writing code is instead consumed by specification and verification.
8/9

[dk@tldr.nettime.org]

You can’t add quality into a system through inspection, and you can’t add learning through specification.
9/9

[hugoestr@functional.cafe]

@dk One thing that XP got right is that often the specs emerge from the feedback loop. We are learning more about the business problem and the technology limitations via coding.

A solution not working is known. The engineer's value is knowing why it didn't work and communicating this to the spec authors