The article presents a function making use of global variables, declares it bad, and then proposes that the solution is functional programming.

There's nothing wrong with promoting functional programming, but the implication that all non-FP code is hard to test and/or uses global state is naive.

It really isn't. Having worked for several decades on "both sides", this really is my experience. The functional side is better typed and has fewer side effects of this kind. It is more normal, as in more common, to have code work correctly as soon as it compiles. This is my lived experience having worked with Java, Scala, F# and Rust since 1999.

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.