Spec-driven loops and old engineering muscle memory
I had a small déjà vu moment recently.
Years ago, when I was part of an R&D team working on the control plane for 5G base stations, everything started with structure: thick specs, requirements derived from standards and customer needs, and a clear separation between defining, planning, and building.
The flow was always the same: define the feature, break it into stories and tasks, then implement it during the sprint. Heavy at times, sometimes slow, but solid engineering.
Recently, while playing with spec-driven tooling - specifically spec-kit - something clicked. The flow itself has not changed: define a feature, generate a plan, derive tasks, implement. What has changed is who does the work.
Today it often starts with just me and an idea. The plan and tasks can be generated automatically, and my role shifts to reviewing, challenging assumptions, filling gaps, and testing what actually gets built. Less manual decomposition, more thinking and verification.
That contrast reminded me of around 2021, when I first used GitHub Copilot inside VS Code. Not autocomplete in general, but real Copilot in its early days. I noticed the beta waitlist, signed up, and got to see it while it was still rough around the edges. Back then, it felt like a nice productivity boost.
Now, working locally with tools like specify, the entire loop fits in one place. You install specify, run specify init, pick your model - Copilot, Codex, Gemini, others - and wire the generated prompts into your local agent.
The workflow becomes very explicit:
/speckit.specifyto capture requirements and constraints/speckit.planto turn that into an implementation-oriented summary (docs, key decisions, assumptions)/speckit.tasksto derive user stories and concrete tasks/speckit.implementto have the local agent implement and run through verification
At each step, I review the output, correct what’s missing, and keep it honest against reality.
All of this happens at the LLM level, but you stay in control.
The engineering principles are the same as years ago, and the need to truly understand the problem has not changed. There is just a lot more leverage now.
It is interesting to watch software development evolve not by throwing old ideas away, but by compressing them and moving the bottleneck back to where it belongs: clear thinking. I am pretty sure some of what we do manually today will feel just as nostalgic sooner than we expect.