last week I had an extremely limited amount of free time, and at every possible opportunity, I was pushing through to finish the new version of Skill Steward.
why am I pushing so hard in this specific direction instead of working on something else?
I hit a scaling bottleneck for all projects. Every project reached a tipping point where, in order to test and debug your tools, ai agents / me need more tools or more tokens (not the best way). Ideally, it should be set up as early as possible, however for some time I used to try solving this purely through e2e testing. the scaling problem and software ecology explained in the Google video: https://www.youtube.com/watch?v=2n41YjR5QfU&vl=en
and because all my projects are kinda linked (intentionally, this is my way of developing personal projects:)):
the game engine depends on the quality of mcp_flutter and ~30 other packages. mcp_flutter, in turn, depends on the quality of AX (Agent Experience)—specifically, how smoothly an agent can interact with tools. This demands yet another layer of support: tools built on top of tools.
Shippik and the research board for it are small, but they also still need proper testing and development. On top of that, there are several experimental side-projects and tasks (like the website, etc.).
and to top it all off, my main job has entered the picture and is taking up 110% of my time right now—and it requires a governance layer of its own.
to resolve all of this - I've extracted all architecture patterns into Steward—and a new type of generative architecture I am building so that the exact same practice can be applied across everything simultaneously.
As the AI agent and I defined it:
Engineering Stewardship is an old-new idea: step back from only managing an AI agent as a program, or only developing product features, and tend the software ecology around the work. That ecology includes charter, decisions, docs, skills, specs, scripts, programming languages, existing tools, debugging loops, validation gates, release processes, handoffs, and the harnesses that make a repository legible to humans and agents.— Full document in a separate branch: https://github.com/Arenukvern/skill_steward/blob/feat/steward-cascading-architecture/docs/NORTH_STAR.mdx
so, where is the epic fail?
last week, I started testing a new stage of adapting Engineering Stewardship—which involves continuous improvement through tool creation (aka dogfooding aka PDSA/PDCA).
I chose flutter_mcp_toolkit as the experimental repository, where I had already been prepping the next version (v4) with an even more decoupled, granular architecture (more on that later).
as a result: I managed to successfully start basic dogfooding (gathering feedback via PDSA cycles), however, because I needed to release some packages, I decided to add a GitHub workflow... which accidentally ended up merging straight into the stable branch. OoO
takeaways:
- branch protection is necessary for stable produ if a project is purely experimental, it's still not worth the time.
- steward concept works.
- flutter_mcp_toolkit is now in an unstable, v4 pre-release state.
disclaimer: written by hand, translated by AI
Top comments (0)