Intro
After experimenting with AI tools like memory-bank, Spec Kit, and Boomerang Tasks, I found that simple .md files for project context and planning often work better.
They keep you in control, preserve project knowledge, and avoid “monstrous” setups that drift away from your actual work.
The Path So Far
This is a short reflection on how I built my AI-assisted workflow — from early code generation experiments to trying to make VSCode as “aware” as Windsurf.
At first, I used AI chat for code generation — no project context, just verbose descriptions and snippets for examples or refactoring.
Then I added AI autocomplete via Continue — still using it.
Next came Claude 4 wrapped in Windsurf, plus the console tool factory.ai and claude code later.
In parallel, I tried a “semi-free” Windsurf setup using VSCode + RooCode — semi, because without a paid backend, you hit the limit quickly: Gemini 2.5 Pro just doesn’t pull it off.
That’s my current baseline setup.
MCP, Context7, and the Memory-Bank Phase
At some point, I heard about MCP and rushed to set up context7, thinking every self-respecting dev already had it running.
Turned out it wasn’t that useful for my particular workflow.
Next came memory-bank — an attempt to preserve project context and bring the VSCode + RooCode setup closer to Windsurf, where it comes out of the box.
In various videos, memory-bank often appeared in clickbait titles like:
“Speed up your AI agent 100x by saving context and cutting token usage!”
That was… partly true.
But some limitations surfaced quickly:
either you have one big bank across all projects (which sometimes confuses them and creates new banks randomly),
or a separate workspace for each project — which is inconvenient.
Soon it became clear: a .md file could do 80% of what I needed.
You can simply write your context and tell the model (via .rules) to always read it — because, well, we do have hands.
Then I started including not just architecture notes but also plans, problems, steps, and key decisions.
All in a separate file — since .rules should stay universal and project-independent.
Boomerang Tasks and Spec Kit
Then I watched a few more videos and got the feeling that I was doing something “wrong,” while serious people were doing it properly.
So I tried Boomerang Tasks (with RooCode) and Spec Kit.
Boomerang didn’t show real advantages over a regular .md context/plan file, especially since the file can be edited directly, instead of waiting for the plugin to “catch up.”
Maybe it was the backend’s fault, but that’s also the point: Boomerang is tied to RooCode, while your context file works equally well with Droid or Windsurf.
That flexibility matters, especially when you prefer a lightweight, cost-efficient setup.
With Spec Kit, results were similar.
When refactoring a small 2D game on Go + Ebiten + ECS, the very first “refactor step” expoded the scope and hit the daily token limit before finishing.
In the end, Spec Kit didn’t replace my manual, more controlled way of defining refactoring steps.
You don’t expect a “serious” tool to face same problems as your homegrown scripts — but it happens.
That was the end of my Spec Kit story.
Lessons Learned
These trials taught me a few things. Now I work like this:
Ask the AI to analyze project problems and produce two plans — minimum and maximum (in the Leninist sense: program-minimum and program-maximum).
Execute the minimum plan.
Review the maximum plan separately — decide which steps to split or delay.
If I’m starting a new project, I may use Spec Kit — but often a simple plan made with chat is a good starting point that followed with manual fixes and careful revision.
For now, doing it in chat+hands manner, without fully automated task slicing gives better results.
Why?
a) the project context stays with you,
b) one or two .md files are far easier to manage than those monstrous setups like memory-bank or Spec Kit.
Why I Still Value Manual Control
Why keep manual control where an AI agent could technically handle everything — if only you crafted the perfect prompt?
Two reasons.
First:
When working on large projects, heavy vibe-coding quickly makes the project no longer yours.
For simple cases it doesn't matter.
But when working with edge cases, memory allocation trade-offs, algorithmic subtleties or complex component dependency (like in game dev), preserving project knowledge is critical.
Vibe-coding destroys that knowledge fast.
I’ve found that maintaining a few manual steps helps me stay in sync with the project and skip (or severely reduce) the “re-read everything every few days” routine.
In this sense, local .md files are useful: simple, transparent, and preserving the best parts of tools like memory-bank or Boomerang Tasks without their overhead.
Second:
A good prompt usually appears after a few hours of bad ones.
Experience and understanding, as I see it, come only through the struggle.
Final Thought
Automation is powerful.
But context ownership is better.
If the tool starts thinking for you, it will also start forgetting what you meant.
A plain .md file won’t do that, but it gives you just enough automation support, keeps things easy to handle by yourself, and offers a kind of two-chair balance between automation and manual work.
Top comments (1)
Thanks for taking the effort to go into all the migration details.