At this point I don't get why they don't open source Windows and developer tools, make a foundation to steer the code, accept contributions and borrow ideas from other operating systems.
It seems Windows division has too much power and they used it to break their things.
Also, Windows division is shipping a subpar product now.
In a sane world developer division and Windows division would think things together, developer division would produce the tools and the same tools would be used by Windows, other Microsoft products such as Office and third party developers.
Why that doesn't happen at Microsoft, I don't understand.
And I don't understand why Nadella doesn't do anything about it.
It's that Nadella doesn't really care about Windows, even though the kernel is the root of Azure. In addition, all the newer gui frameworks abandoned RAD interface. That is what made and still does make Winforms and WPF popular.
>finding the game to improve agent outcomes was reducing context
I think modularization will further reduce context. I am planning to play with your SUPER and SPIRALS idea and use modularization on top via Vertical Slice Architecture or modular monolith where each module is isolated and has a contract.
Because previously people had to write code themselves and they had personal preferences. Because the bugs were less when written by a human.
Now personal preferences doesn't matter as much since people won't change the code themselves too much. And because LLM can introduce lots of bugs and make a mess in the code unless you can restrict them somehow.
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.
If a feature spans more microservices it seems that the microservices boundaries are not well defined.
reply