I noticed a pattern while working on @typeonce/effect-machine 🤔
Which is described by this 👇
What it means to build software in 2026: Start from an idea => build a crappy poc => develop tests asserting behaviour => kill the poc and build it again. Loop until satisfied.
Here is how this is shaping the work on effect-machine 🏗️
POC (Proof Of Concept)
effect-machine started here (like anything I guess).
The idea: "how would a
Machinemodule look like insideeffect"? 🤔
I know it can work, and I know it can be worthwhile. So let's go with a POC.
I collected a bunch of ideas from my experience, from xstate, from other effect modules.
I focused the initial part of the work all on having a strong public API interface 🏗️
Test it all
Verification of the POC comes in the form of testing.
I mean, all sort of extensive testing 🧹
Verbosity in tests is not a problem anymore. This mean the agent can add tests that are long and fully specified.
And that's not just unit testing. For effect-machine I have the following:
- Unit testing
- Type testing
- Property based testing
- Type instantiation performance
- Runtime performance
The instruction specify that each change needs to keep the performance, tests, and API shape intact.
Regardless of the internal implementation at this point, the library works and behaves as expected from the checks ☑️
After the full process, I have the following:
- A great public API for the user
- Awesome performance
- All series of static checks and tests
But, what about the internals now? 🤔
Build better
The outside is all clean and good. Now let's look at the inside.
If a library has: - Great public API - Great runtime performance - Great bundle size - Great runtime memory allocation - Large test coverage Does it really matter how the internal implementation looks like anymore? 🤔
What it means to build software in 2026: Start from an idea => build a crappy poc => develop tests asserting behaviour => kill the poc and build it again. Loop until satisfied.
My intuition is the following:
When the outside is clean and verifiable, you can refactor the internals as much as you need 🧹
You have a clear set of measures as a reference. All sort of code can change on the inside, as long as those measure don't regress.
And that's where you have the freedom to refactor, move files, organize better, improve abstractions, and more.
You want to come out of the "local maximum": get an even better build, with the same packaging, but possibly a completely different internal 📦
I had some success with telling the agent to refactor completely (exiting from the local max), but keeping the testing and the API surface helped to do the refactoring safely
The loop is still in progress for @typeonce/effect-machine, but the results are already really good 🪄
I am working on all sort of testing and tooling for the module. You will be able to verify paths, configurations, invariants and much more 🔜
See you next 👋