标签：#kiro

A cat astrologer, spec-driven and running on Amazon Bedrock A companion to A Builder in Paris: Do Devs Dream of Électrique Chats? Last month I wrote about the idea. Six rainy days in Paris, a closed laptop, and a hackathon I did not mean to enter, and somewhere between the Musée de l'Orangerie and a lot of walking, an idea arrived. Cats are inscrutable. The people who love them are obsessed with understanding them anyway. Astrology is an old framework for making the unknowable feel readable, and maybe, just maybe, it helps us understand them a little. Her name is Madame Minou , a French cat astrologer who reads your cat's stars from a café terrace. That first article was the idea . This one is the build. Vibe-coded, but on rails Was it vibe-coded? You know it! AI wrote the lines, and I said "no, not like that" more times than I can count. But it was vibe-coding on rails, and the rails were Kiro. Before a single line of app code, I wrote the requirements in EARS notation, a design doc, and a build-ordered task list, all living in .kiro/specs . Decide what "done" means before letting anyone, human or model, start building. The specs are what kept the vibes on track. Then the steering files. .kiro/steering held the enduring rules of the project: product principles, security guardrails, technical direction, and UI law. These were the thing that kept a long, multi-session build from drifting. When a new session opened, the steering files were already the shared context. "The café blue" was one token, not five guesses. Security was not optional. The garbled café sign was a deliberate easter egg, not a bug to fix. From there, the loop: Kiro implemented one approved block at a time, ran each task's PASS/FAIL QA gate on itself before moving to the next, and only stopped for my review on the two things that actually mattered. I directed and approved. Kiro proposed and built. Spec first, block by block, human in the loop. The facts are sacred Here is the part that looks like a

1. Why I use Kiro I've been using Kiro for almost 1 year now, I'm using it as a Cloud Architect and also to build side projects for fun. The main reason I use Kiro over other tools is how it works with you as an engineer. Over the months, I've noticed certain patterns in how I use Kiro. Let's go over them: Index 1. Why I use Kiro 2. Pair Programming with Kiro 3. Repeatable workflows as Skills 4. Using Plan, Specs and Agents 5. Council of agents 6. Documentation, Documentation, Documentation Final thoughts 2. Pair Programming with Kiro The most common way that I use Kiro is in Pair Programming. Pair Programming is when there are 2 developers working together on the same task, they can work in tandem or one of them can be the one guiding/planning while the other one does the code. In my case, with Kiro, I'm the one doing the guiding and planning while Kiro is the one executing and implementing the code. I'm also using Kiro as my rubber duck. If I have a new idea or I'm working on a blocking bug, I talk to Kiro so it can give me a different point of view, investigate and steer me into good practices. The main reason for me to do it this way is because once the session is over, I can run a prompt/skill to record everything from the session: Kiro, summarize this session and save it into a .memory folder with the format yyyymmdd and as a markdown So then everything that we've done is going to be recorded there. Do you remember everything that you've done yesterday? Maybe. But what about last week? And what about one month ago? I definitely don't remember it. In the classic Software Development Life Cycle, we have tickets, and we have a way that we can recall all this information, but the more detailed context of why you did it is going to be completely missed. Now, with tools like Kiro, this is possible to remember. You just have a .memory folder where you summarize all your sessions. So in the future, we could have a situation like this: Oh, I don't remember what changes