Still a programmer

My experience with Kiro, Speckit, and OpenSpec

When spec-driven development started to gain attention in 2025, I was intrigued. The promise of building software guided by a clear, AI-interpretable specification felt like a refreshing mix of discipline and creativity. Over the past year, I decided to give it a serious try — testing three tools along the way: Kiro, Speckit, and OpenSpec. While this isn’t a full technical review, it’s my reflection on how each tool shaped my workflow and thinking.

General Reflections on Spec-Driven Workflows

First impressions: spec-driven development feels more structured and puts me in better control of the coding process. But that structure comes with an initial cost — I spent a lot of time just reading and absorbing the spec before even starting.

Over time, I decided to skip the hassle and just speed read, focus on key goals, and iterate fast rather than obsessing over perfection. I know there is always plenty of chance to make amendment during implementation phase. Or just start a new, when is not recoverable.

A few takeaways stood out for me:

  • Always ensure you have a working environment when you’re about 30% into the task. It keeps assumptions real.
  • Don’t over-polish the spec too early. It’s better to build, see what breaks, and restart if needed. You’ll refine your specs naturally through iteration.
  • The more you do, the faster your intuition grows. Eventually, you’ll be able to “one-shot” a spec that works on the first try.

Kiro

I spent the most time with Kiro, mainly thanks to the free Pro+ credits from a hackathon. Here’s my take:

  • Is a good IDE/tool to use and build stuff, but not ideal if you’re on a tight budget. The 50 free credits don’t go far.
  • I most of the time uses auto mode for the model, which worked decently but sometimes required wrestling with outputs to get it right.
  • That is, until my last project, credit is about to expire — I used Opus for everything. Surprisingly, it worked far better with fewer iterations, though it burned more credits. The time saved was worth it.
  • During tasks.md creation, I also strongly suggest to go with optional tests. Skip them. Kiro already generates minimal working tests, and I found the extra testing just wastes credits and complicates things.

Overall, I’d rate Kiro 7/10. It gets the job done with less manual effort, but the code quality can feel a bit messy.

Speckit

Among the three, Speckit impressed me the most. It felt like collaborating with a senior engineer who constantly asks the right design questions.

  • The tool guided me through structured design choices during the spec-ing phase.
  • The PR that I send out, my colleague was impressed with how clean and targeted the generated code was.
  • Other cool observation was for example, for new APIs or unknown libraries, Speckit builds small POCs internally to gather real syntax and document it in markdown files. That attention to detail dramatically reduces bugs during implementation.
  • Although, it then to burns more tokens as illustrated above, I love the output it produce, is undeniable.

If you’re a seasoned developer comfortable with AI-assisted builds, I strongly recommend this one. My rating: 9/10.

OpenSpec: Easy to Start, Limited in Depth

I only used OpenSpec once, during a company hackathon, so take this with a grain of bias.

  • It’s very beginner-friendly. The tool is designed make it easy for newcomers to pick up.
  • To me it does feel very close the traditional vibe coding, except for the additional layers of docs.
  • That simplicity also limits its ability to handle complex projects.
  • Since I’d already worked extensively with Kiro and Speckit, OpenSpec felt a bit shallow during the spec design phase.

That said, I know senior engineers who swear by OpenSpec for building AI-feature prototypes. It just didn’t click for me. My score: 5/10.

Final Thoughts: Is Spec-Driven Already Fading?

Spec-driven development had its strong moment in 2025, but I’m already noticing a shift for 2026. The rise of OpenClaw and agentic coding — systems that let background AI agents continuously refine and validate code — is gradually changing how we think about “design before build.”

Once AI reaches a stage where it can validate and verify its own output reliably, spec-driven methods might fade into the background. But until then, learning to think in specs remains a valuable muscle for every developer building with AI.

Disclaimer: this article is mostly written with AI (just being lazy), the opinion and bullets are solely personal experience putting in words (no screenshot).