The author doesn't promote functional programming in the strictest sense, he just suggests to use functions that do not have side effects. He argues against changing state.

You can even do it in .NET using dependency injection (which is a kind of an OOP) concept: just supply dependencies as constructor parameters and do not change state in the service/handler.

You can follow the same concepts with ease using Go and no one will argue Go is a functional programming language.

So, the idea is not to do straight functional programming but to apply some lessons from the functional programming.

And I find the article to be very logic and even if I did not apply the same rules as the author, I empirically observed that coding agents shine where they don't have to argue much about state, the more state there is to keep track of, change and reason about, the harder it is for both humans and coding agents to do changes without breaking things.

And since I like the author's ideas I am willing to spend some tokens and put them to the test.

The only things I would add on top of this is modularization, either by using Vertical Slice Architecture or by designing a modular monolith where each module is isolated and has its own contract. Because, the less source code an agent has to reason about, the better are the results.

So my next greenfield experimental project will feature: compound engineering, TDD, SUPER and SPIRALS (as in the article) and modularization.