Introduction
When I first got my hands on Kiro, it honestly felt like a cheat code. Back then it was still in preview, no limits, no weird restrictions. I started playing around with its spec-based coding and it felt like a dream — like telling the AI exactly what I wanted and just watching it happen.
Before Kiro, I was stuck in the usual loop: chat with AI, review every single line, fix things manually. But this time? It was different. With Kiro + Claude Sonnet 4, it felt flawless. Almost like I wasn’t coding, I was just… vibing. I never thought I’d let an AI take the wheel like that, but I did — and I enjoyed it.
The Sweet Dream Phase 🌙
I had always used AI in the traditional chat-based mode — reviewing every snippet, cross-checking line by line. But Kiro introduced me to something different: spec-based development. Instead of explaining endlessly in chat, I could define the requirements, and Kiro would implement them directly.
For the first time, I experienced what I like to call “vibe coding.” It wasn’t just about generating code; it was about letting the AI truly flow with the project. Paired with Claude Sonnet 4, Kiro felt flawless. I almost couldn’t believe how smooth those early days were — like having a built-in security check before my ideas became real code.
The Reality Check ⚖️
But as I built my task manager app — which I called Get Donee — my relationship with Kiro began to shift. While vibe coding felt liberating, the cracks showed up when I reached the UI refinement and debugging stages.
UI tweaks often turned into a guessing game. I’d provide JSON, images, or detailed descriptions, but Kiro sometimes returned designs completely different from what I imagined. Extra padding here, unexpected widgets there
And the most painful part? Debugging.
Since my setup can’t run an emulator, I had to build and test on my phone each time. Whenever I asked Kiro to fix something, it often created random extra files — test files, design files, even implementation files I didn’t need. Sometimes it touched files I never asked it to. And a lot of the “fixes” didn’t even work.
I quickly realized: if you want debugging to work, you have to be super strict. Like, “change this exact line, in this exact file, to this exact code.” No wiggle room, no vibe coding.
Also once it just removed the whole widget instead of fixing it properly.🙃 a true Genius way to fix ! LOL
🤔 Mixed Feelings
I won’t lie — Kiro still feels revolutionary in some ways. Spec-based coding is something I never thought I’d enjoy so much. But at the same time, the over-engineered fallback code, the UI struggles, and the random file chaos made things way harder than I expected.
The new pricing and spec count limits also created some chaos (though they’ve improved it now). Plus, being locked into just Sonnet 3.7 and 4.0 inside the IDE feels kinda restrictive.
🌟 Final Thoughts
So yeah, my experience is… mixed. On one hand, Kiro gave me this sweet dream of vibe coding where I felt unstoppable. On the other hand, when it came to refining and debugging, it turned into a bit of a nightmare.
Still, building Get Donee with it was one of the most interesting dev experiences I’ve had. I don’t regret trying it — I actually learned a lot about where AI fits into my workflow.
Top comments (0)