I recently participated in the Code with Kiro hackathon, where I built Credi, a web application that analyzes social media profiles to identify credible voices and distinguish trustworthy content from promotional noise. You will be able to try Credi at credicredi.com soon, but this blog post is mainly about my experience using Kiro.
What I Worked on
Credi performs thorough investigations of social media profiles to assess credibility, originality, intent, correctness, and usefulness of content. It evaluates eight specific criteria for a given social media profile to assess the credibility of the content.
The technical implementation included:
- Social media scrapers for Twitter/X and LinkedIn with rate limiting and caching (I experimented with a few options, and ended up using a 3rd party because of how restricted LinkedIn and X are)
- Multi-agent consensus framework using multiple models from different vendors
- Structured LLM output with Zod validation and LangChain integration
- Retry mechanisms and error handling for reliable AI responses
- Next.js frontend with TypeScript and Tailwind CSS
- SQLite database with Prisma ORM for analysis storage
I have quite extensive experience with Typescript, Node.js and SQL databases, but never used Prisma or Next.js before. So it was a delight that I didn't have to bother much with the code and Kiro took care of all the implementation details and configuration.
Working full-time, I spent parts of weekends and some weekday afternoons over the course of a month. I am impressed by the amount of functionality delivered in that timeframe, and I credit this largely to the spec-driven approach Kiro enforced and my own obsession over getting that first requirement phase right.
The most time-consuming aspects weren't coding. They were getting requirements right and solving non-technical problems like engineering trustworthy analysis prompts and navigating social media API restrictions. The smoothest part was feature development, which I again attribute to having obsessed over the specs beforehand.
Kiro's way of writing and maintaining specs might be my favorite feature. It's structured approach made complex and large problems manageable. Having documented clear requirements and design documents, I would constantly find myself just referring back to them either to remember what the goal was, or to remind the agent about the vision and the design decisions we made earlier.
The Problem with Current AI Development Tools
I've been following generative AI trends closely and have experimented with most AI development tools over the past months: Claude Code, V0, Replit, Cursor, Codex, and Loveable. I use Cursor daily at work. These tools are undeniably better than traditional IDEs, like the difference between coding in Notepad versus VSCode, and I believe everyone should be migrating to them now if they haven't already.
But vibe coding by itself doesn't enable anyone to build products that can grow or businesses that last. Vibe coding excels at prototyping and writing one-off scripts. It falls short on anything beyond that. Writing the code was never the bottleneck in building software and it is not the bottleneck today either.
Gergley Orosz put it very well in this post:
Building good software has always been hard, but rewarding when you get it right. I don't think AI changes this - in fact, these tools can create the illusion that it's now easier than before to create it.
The hype around vibe coding feels like dream-selling, at least with the current capabilities of the AI models. Many of these tools advertise themselves in way that feels like people with no technical knowledge can now build Saas businesses, while I see development agencies that operate solely by taking half-baked AI-generated projects and making them production-ready.
Where Kiro distinguishes itself is that it takes the foundational engineering principles that makes software maintainable and scalable very seriously.
Spec-Driven Development, The Wow Factor
Kiro takes a step back in the development process. Instead of jumping straight into code generation, it enforces a structured development process that mirrors proper software engineering practices.
Requirements Phase
The requirement gathering phase impressed me from the first moment. I started with a long conversation, obsessing over every detail during this phase. Kiro doesn't just ask "what do you want to build?" It guides you through creating comprehensive user stories and acceptance criteria. It drafts requirements allows you to iterate on it, and the more patient and detail-oriented you are, the better the results you will get.
This handholding during the requirements phase clearly targets senior software engineers and product people. Kiro doesn't try to replace engineers, it empowers them by structuring the experience in the way a good software engineer should approach building a software. It solves the writer's block equivalent in the development process and also streamlines the process that is most often neglected: requirement gathering and design.
Design Phase
The design phase is probably my favorite part. Instead of immediately writing code, Kiro creates a class diagram with all modules, services, and interfaces based on the requirements from previous step. It writes the interfaces and public-facing methods for all modules with function declarations, giving you a black-box view of how everything should work together.
This is the proper flow of designing a system from scratch, but most developers skip it and and jump straight to implementation, myself included. As someone who learned system design at school and worked in the industry for a couple years, I've noticed this proper design process is often neglected in practice. Seeing Kiro try to repopularize it is very refreshing.
Task Management and Execution
Once the design is finalized, Kiro generates a list of tasks that need to be done. This is where I have most of my criticisms towards how it is implemented.
The initial set of tasks that it created for me was very much like how Claude Code prioritizes things to do. It started with setting up User's table, authentication, permissions, etc. If I started implementing with that initial task list, the hackathon deadline would've passed before I even started building the main idea of the app. My other issue was that it did not think of each task as an independent, testable micro-feature. I wanted to entirely detach from the code, but wanted to be able to test every single developed piece as a user to verify its behavior.
I had to slightly tweak Kiro's task generation process to reorganize tasks so each one is user-testable and iteratively improves existing software. This positioned me mainly as a user without having to worry about the code. This project was the first working product I developed where 100% of the code is written by AI and has a maintainable and scalable code. You can find the codebase here. The specs are all defined in the .kiro directory.
When you click on the "start task" button to execute a task, Kiro opens a new session per each task. Since requirements are gathered and design is finalized, the model has the high level context of the project, without the distractions from other tasks. I had reached the same conclusion through experimentation myself, and was doing a similar thing at work. With current context size of models, one session per task usually results in more reliable generated code.
Technical Advantages
While the features below are not distinguishing factors, they are worth a mention as they made my experience of using Kiro a bit more pleasant.
Improved Diffing System
Kiro's diffing system is an improvement over Cursor. It hides unchanged lines and only shows modified segments from the last message in the conversation. In Cursor, I need to accept/reject changes, otherwise changes within a conversation merge together when I give it subsequent prompts. Kiro's sequential approach feels more natural and automatically considers all its previous changes accepted when you give it a new prompt in a conversation.
Command Control
The regex-style command trust list provides a nice balance, maintaining control over the agent while providing more agency. You can allow it to run commands that start with npm run * or allow it to do npm * and so on. You can specify which commands the agent can run automatically versus which require approval. I first used it in Kiro, but then noticed Cursor has the same functionality.
Verbosity
The agent is less verbose and more to the point. They've done a good job with their system prompts. I copied Kiro's response style from this gist and added it as a cursor rule at work, and I find it much more pleasant.
Project Steering
Kiro automatically generates three steering files: product.md, tech.md, and structure.md. These function similar to .cursorrules but automatically adding some to maintain style consistency in the generated code is a nice touch.
I utilize cursor rules a lot at work, and I see an immense value in them for code consistency when multiple people work on a project and also for passing context that cannot be found in code (e.g. project history, use cases, vision, and other contextual information that humans usually have in mind when coding). Same applies to these project steering documents.
Initially I wasn't aware of this feature, otherwise I would've used it very early on to avoid a problem like this one during initial scoping of the project.
Feature Management
Initially I started the project with a big prompt to Kiro and had the requirements for the entire project in a single spec. My workflow started to get messy once I found out I may need more modifications, or implementing a feature properly required some additional work that was unrelated to the task in progress (e.g. I needed to add Zod Schemas and retry mechanism to get reliable structured outputs from the LLMs). Kiro solves this very neatly by detecting when you're talking about a new spec.
Kiro notifies you when you're discussing a new feature during task implementation and asks if you want to create a new spec. This helps organize features and write context without leaving your current task. You can later work through the new task list for that spec. This allows natural codebase growth while maintaining evolution history and your current focus.
I've Become a Fan
Since using Kiro, I've been manually applying some of its procedures at work in Cursor. I use Kiro's system prompt shared in this gist to create specs and tasks similar to Kiro.
This unified structure and the spec-driven approach for all projects has shown to be valuable even for coding enterprise software. The primary benefit in my opinion is that all those spec documents help the agent stay aligned with the goal of that feature for much larger and more complex tasks. This is especially useful when developing complex features, making architectural changes or doing large refactors.
It's still in Beta
The product isn't mature yet and has bugs. For instance, I encountered issues with agent being quite disconnected from terminals when running commands. Or there were times where it swallowed my prompts and forgot about them. However, the hackathon collected over 1400 bug reports and feature requests. I also created several GitHub issues during development and commented on a few others:
- Task ordering for user-testable iterations
- Function body collapsing for abstraction focus
- Dedicated Terminal for Kiro
Seeing how active the repository is and how responsive the maintainers are keeps me optimistic about the future of this product.
Climbing The Abstraction Levels
I've realized that once AI models have clear requirements and well-defined function declarations, their logic implementation is usually reliable. As long as I can test entire modules or features as a user and verify functionality, I don't care how functions are implemented.
I can totally see that in the near future a feature like this will be implemented where Kiro by default collapses the body of the functions, and us as the Kiro operators can solely focus on the abstractions and see how different modules in the code are connected to each other.
This would create more space for developers to think about abstractions and detach from implementations. It's similar to the evolution from assembly to C, or C to Python. This abstraction level increase and will allow software engineers to build more complex software and tackle problems that were previously not worth the cost. And I personally enjoy thinking at this level much more than spending hours wrestling with a simple language or API specific bug.
It will also enable smaller teams to build bigger things, expanding the small startup economy solving extremely niche problems.
Who should Use Kiro?
Kiro's design decisions seem particularly valuable for two groups:
Tech enterprise employees can benefit from spec-driven development and the ability to think at higher abstraction levels. The structured approach aligns with enterprise development practices and can speed up delivery of features. It also helps maintain the history of evolution of softwares through documenting the specs, allowing both developers and AI agents to make more conscious decisions having all the quirks of legacy code documented.
Early tech startup founders heavily benefit from the integrated documentation, requirements, and task management. All software information exists in the codebase where the agent has full access, reducing the need for external task management tools or complex integrations, additional MCPs to pull tasks and documents. Now having an entire product's data live in a GitHub Repository does not seem too far-fetched and might in some cases even be a very logical and efficient decision.
Final Words
Kiro's features aren't magic or groundbreaking individually. The innovation lies in putting engineering and design work into a template and creating a unified, abstract workflow for engineers to collaborate with AI agents.
I believe that the best person to operate a software engineer agent like Kiro or Cursor is a software engineer. Kiro maintainers know this and tried to build a tool that promotes good software engineering princinples. These princinples are not necessarily limited to software engineering, they are essential for building anything scalable, maintainable, and long-lasting.
The distinguishing factors are UX choices that make Kiro a powerful assistant for professional, industry-level engineers rather than weekend personal projects. Kiro's design decisions focus on empowering engineers to build and maintain more complex products rather than removing them from the equation.
If you also participated in the Hackathon, I'd like to know about your experience. Please comment or reach out to me at mo@ganji.me
Top comments (0)