The cost YAGNI was never about

The cost of restructuring has also gone down.

The cost of shoring up behavior with tests ahead of a restructure has gone down because of AI.

The cost of implementing a zero downtime migration has gone down because of AI.

A big part of the rust hype has been the low cost of restructuring within an application, even before AI. And now even more so.

The opportunity cost of not being able to safely restructure has gone up substantially.

This is the number one thing I optimize for now: the ability to quickly and safely change significant parts of the code and product.

> This is the number one thing I optimize for now: the ability to quickly and safely change significant parts of the code and product.

This was always a good thing. Its value has nothing to do with the advent of AI coding.

> The opportunity cost of not being able to safely restructure has gone up substantially.

This bit is contradictory with everything else you said. Prior to AI coding it would take a lot longer to perform restructures. If anything, the thing you're now optimising for has gone down in value. It's still valuable, but perhaps a little less.

Nothing I have read by Kent Beck has ever suggested that he would be useful in a chip company, where lots of people toil for a long period of time in order to produce something that no customer can possibly see until it's finished, and that must be sold in quantities of millions in order to make money.

> This is not an argument that prediction is hard, as if a sharper architect escapes it.

I disagree with this. The argument _only works_ if prediction is hard.

Kent Beck compares unwritten code with a financial option to buy something at a given price.

But that's just an analogy, and it can be taken too far. If you haven't written any code, do you have infinite options? You haven't spent any time yet, but still, that doesn't seem quite right. It might be used to justify staying in the planning stage and putting off writing code indefinitely, to avoid committing to anything.

Why might the analogy work anyway?

Maybe the cost is reading the code? Code that hasn't been written doesn't need to be read. And if you're using a coding agent, it doesn't clutter up the context with irrelevant detail.

Also, code that hasn't been written yet doesn't need testing. Tests you haven't written yet don't take any time to run.

These are good reasons to try to keep a project as small as possible. By putting off features, you delay codebase growth as long as you can.

This suggests that you can avoid a lot of costs by running someone else's code. If you can use a standard API then you don't need to understand the implementation in detail or run its tests. But there are risks to adding dependencies.