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.

I've explored Clojure after talking to Metabase about how it had benefited them. That said, it was years ago so I can't claim it influenced this work.

The framework was designed to be a language agnostic way of sharing best practices to bias agent behavior towards a more scalable end. I initially used it when I was working with a team to do some massive refactoring/clean up across the codebase. We didn't come to an acronym but similar principles and it was "testable" and easy to push back on PRs that weren't aligned with the principles.

That said, it may be interesting to see if I could replace all that context and just say -- "code it like you would with Clojure"

Have you tried that?

In fact, synthesis of pure Haskell powered by SAT/SMT (e.g. Hoogle, Djinn, and MagicHaskeller) was already of some utility prior to the advent of LLMs. Furthermore, pure functions are also easy to test given that type signatures can be used for property-based test generation.

I think once all these components (LLMs, SAT/SMT, and lightweight formal methods) get combined, some interesting ways to build new software with a human-in-the-loop might emerge, yielding higher quality artifacts and/or enhancing productivity.

it’s not discussed in this post but in another right after I discuss the modeling I was doing on tech debt and finding the game to improve agent outcomes was reducing context.

functional programming accomplishes that. I can’t claim it’s the only way, but it’s one that’s well understood in the community

That said, I don't "vibe" because it creates great code I love reading, but I can monitor and move the same metrics I would if I was managing a team.

I also use code tours a bit, and one of my first tools I needed and built (intraview.ai) was to support this need to get deep in the code the Agents were claiming was ready to ship.