Maintaining an open source library is intense 😬
And, guess what, it may be even more intense now with AI 💁🏼♂️
Even something as new as @typeonce/effect-machine is an open door to a huge rabbit hole.
A few notes on why and how 👇
Easy to make it work, hard to make it reliable
Any prototype made with AI is fast and satisfying.
All those games and apps "one-shot" by AI that you see on socials, that's easy.
This is the same for "new libraries", you can get to 70/80% rather fast 🙌
effect-machine also had plenty of references in effect core and xstate. You can one-shot a state machine library with no issue 💁🏼♂️
But after the first couple hours and a working MVP, the scope starts to expand.
And suddenly you exit the territory of "vibe-coding", and you enter real engineering. Yes, even with agents.
Unlimited possibilities, unlimited bugs
2 hours, MVP ready.
It was so easy and fast, that you want to add more and more. More prompts, and more features start to appear.
And it all works as you test and use the API 🤔
But then you notice the first bug, and ask the agent to fix it. Then other 2 bugs appear, and you ask again.
It won't be long until you start questioning the actual quality of the implementation 👀
The MVP worked for the few initial requirements, it breaks as you engineer more features on top 🙌
Often times, it's worth rewriting the full MVP with a similar public API, but completely different internals.
What about performance?
Second iteration looks good. What started as 2 hours became most likely 2/3 days, already.
You are now more concerned with a clean implementation, as the agent adds more features based on your prompts.
As the API starts stabilizing, you start wondering: what about performance? 🤔
The agent sets up a few benchmarks, and, as expected, performance is bad. So you jump into this rabbit hole as well.
And that's the third full iteration, as you change the whole internal implementation to make the library faster.
And it's been a couple of weeks now 👀
What about devtools?
Agents produce code so fast, that you can start thinking about devtools in parallel as well.
So you setup the codebase to allow multiple package releases: devtools, linting, integrations 🏗️
Each added piece expands the scope and the library surface. And it all seems to be working fine.
It never ends (for the most part)
And the loop starts back again:
- New features
- New bugs
- Fixing the bugs
- Refactoring to avoid a whole set of bugs
- Rewriting to increase even more performance
- Another few bugs here and there in devtools
Even if an agent is rather quick to fix each, issues pile up faster (at least as fast as the agent can fix them).
And what was a 2 hours MVP, it's now 2 months into a library that it's all on you, your time, and your capacity to keep up with the agents and the library scope 🙌
That's roughly what happened with @typeonce/effect-machine 💁🏼♂️
Now imagine scaling this to the level of a stable library with many users 🙌
It was intense before agents, it's intense just as much now with them.
Meanwhile, another considerable jump in @typeonce/effect-machine:
@typeonce/effect-machine-devtools@typeonce/effect-machine-react@typeonce/oxlint-plugin-effect-machine
Improvements in effect-machine on the frontend with React Define the machine, get a reference, and effect atom to select what you need, where you need it 👇
The goal remains to eventually merge this into core effect 🔜
See you next 👋