I’ve been taking a deep dive into Spec Kit from GitHub over the last few weeks, and it’s the clearest example I’ve seen yet of where our field is headed. IT jobs aren’t disappearing, but the walls between programming, architecture, and project management are. You can’t really separate them anymore, and Spec Kit makes that convergence obvious.
The heart of it is simple. Sitting down and seriously thinking about what you’re building has always been the key to success. Spec Kit just formalizes that process. It’s not magic, and if you already know how to write specs and plans you could do the same work yourself, but it enforces structure and maybe most important, keeps the format consistent. Even with my experience, I’ve found it useful to have guardrails against drift. I’ve written before about how the future of engineering belongs to people who understand why they’re building, not just how they code, and Spec Kit feels like a direct response to that very point.
One of the things that doesn’t get talked about enough is how useful that standardized output is up and down the org chart. A project manager or executive can look at it and immediately see the business value. It becomes a kind of information bus for the whole hierarchy. From there it’s not hard to imagine AI-driven processes that pull updates straight into business plans, or auto-generate Jira and Confluence tasks. It’s early, but you can see where this is going. Planning and communication will become much more frictionless.
Still though, let’s be clear. Spec-Driven Development is still development. Programming skills and knowledge matter as much as ever, maybe even more. The shift is toward higher-order work. Reviewing code, steering the AI with good methods, and applying senior-level judgment on architecture, logic, optimization, and security. AI will take the boilerplate, but the craft remains ours. That same balance between what AI takes on and what humans still own was something I looked at in AI and Jobs: A Balanced View on Job Creation and Destruction, and Spec Kit is a very practical example of how that balance plays out in real software shops.
That said, Spec Kit isn’t always the right tool. If your team already has a high velocity and low bug count, there’s no urgent reason to switch. For mid- to low-complexity work, it can be overkill. And watch your tokens. Spec Kit burns through context fast, and million-token windows are the “64K of RAM” stage of LLMs. It sounds big, but I’ve maxed it out surprisingly quickly. Nothing is worse than running out of tokens mid-plan and realizing it would have been easier to do it by hand.
On the plus side, installing Spec Kit also gives you prompt templates that are excellent for learning and for lighter features where you don’t want to waste tokens. I’ve found those worth the install on their own.
The other thing to remember is maturity. Spec Kit is brand new, even by AI standards. It’s moving fast and improving, but still rough around the edges. For example, early versions dumped directories like “templates” into your project root, which was a recipe for collisions. They fixed that quickly, but it’s a reminder that the kit is still finding its legs. Some CLI integrations aren’t seamless yet either, so you’ll need a few workarounds.
I meant to write a short post, but after a few weeks working with it I wanted to capture my thoughts. I definitely recommend trying Spec Kit if you’re curious about where AI-assisted development is headed. Once the rough edges get smoothed out, this could change how we plan and communicate in ways we didn’t think possible. In many ways, it feels like the next logical step from the ideas I shared in Spec-Driven Development: An Expansion of Engineering, Not a Threat.
What about you? Have you tried Spec Kit yet? If not, how are you approaching AI-assisted development in your projects?