I let Kiro build my API. It worked. Here is the honest debrief.

TLDR: Kiro delivered real productivity on a non-trivial proof of concept. The tool works, the workflow is sound, and the goose bumps are genuine. But agentic coding shifts the risk, not the responsibility. You still own the code, the intent, and the knowledge your team builds around it.

If you are not yet a member of Medium, you can access this content using this friend’s *link.*

A few months ago, my use of LLMs was modest at best: autocompleting code, vibe-coding the occasional 50-line script. Then I discovered Kiro and spec-driven development.

Over a handful of days, I built an API with a Lambda and DynamoDB backend, a proof of concept that ended up being anything but minimal. It supported two major versions of the API spec, handled client key authentication, hosted a customized Swagger UI with access control, and shipped to both dev and live environments. All of that including a ramp-up period to learn the tool from scratch.

And the claim checks out: I did not write a single line of code, configuration, or documentation. I felt goose bumps, the kind I used to get in the old days experimenting in GFA Basic on my Atari ST, when getting a multi-faceted 3D sphere to bounce across the screen was considered a respectable challenge.

The approach

Kiro’s workflow has been documented elsewhere, so here is a quick summary of how it played out for me.

I started by describing my project and technical choices in a set of steering files: a read-only API built on OpenAPI spec, API Gateway, Lambda, and DynamoDB. These files are loaded at the start of each LLM session to anchor Kiro’s output to your intent.

From there I decomposed the work into features, starting small with a first endpoint. In Kiro’s chat, you open spec mode and describe the use case you want to implement. Kiro translates it into a structured list of user stories, something along the lines of “as an API client, I can invoke the helloworld endpoint, the application returns an HTTP 200 if everything is ok.” When you think the scope is clear, ask Kiro if it has any questions. The answers tend to be sharp and surface blind spots you hadn’t considered, which is good practice with any model or tool.

Once the requirements were set, Kiro generated a technical spec grounded in my steering files. I changed very little of it. It then produced an execution plan: a decomposed list of verifiable units of work. This step matters more than it might seem. Each task should map to a chunk of code you can verify quickly, through automated tests or a focused code review. You can ask Kiro to execute tasks one by one or run the full plan.

Kiro operates as an agentic workflow (reading existing code, generating new code, running it, and analyzing the output). The first few executions are a bit tedious since you have to authorize each tool call, though you can grant permanent permission as you go. One thing to watch: Kiro has no memory across tasks, so it can repeat the same mistakes (using a wrong path, or looking for a configuration file that does not exist). When you spot a pattern like that, update your steering files immediately.

There is much more to the tool: support for additional extensions, and hooks that trigger automatically at the end of an operation (running tests or updating documentation, for instance).

Once a feature is complete and validated, you move on to the next one. All artifacts are persisted in a .kiro folder in your repo, so you can always trace back the original intent behind any feature. I started with a basic healthcheck endpoint, then progressively added access control, version management, and a customized Swagger UI.

A few quirks and non-obvious lessons

Who is Joris?

When I started using Kiro it was still fresh off the press. Occasionally the file write and update tools failed, and the model would try increasingly creative workarounds to achieve its goal (including transforming me into a tool and asking me to do things on its behalf). Once you get used to Kiro’s productivity, those extra iterations feel disproportionately frustrating. The issue faded after a while, so consider it a growing pain.

Running unit tests at the end of each task is an obvious good practice, but for some reason Kiro did not execute them systematically, and lost in my excitement, I let it go. Let’s not fool ourselves: Kiro and Claude regularly generate non-working code, and even when testing was part of the validation loop, Kiro occasionally skipped failing tests and reported the task as approved. I clearly had not approved it. Update your steering files, include test execution in every task, and experiment with hooks. This is a critical point that needs fine-tuning.

In a similar way, my execution plans failed to trigger a redeployment systematically. A couple of times I received a confident “job done” message, only to realize a minute later that nothing was working in the deployed environment, or that the production rollout had simply been forgotten. Be explicit about your rollout strategy, integration testing, and validation steps.

Worth watching the abstraction level as well. Kiro’s default behaviour resembles a junior engineer who has just discovered object-oriented programming: you quickly end up with a sprawling class hierarchy, some branches of which will never grow leaves or prove useful. For a proof of concept, I would have generated far less code on my own. You can ask Kiro to produce more concise and simpler output, but you have to ask.

I also experienced a popular “I cannot access the /home/waldo folder,” which triggered an anxious internal monologue of “who is Waldo, what is he doing with my computer,” followed by a swarm of tokens evaporating as Claude retried its previous action somewhere else entirely.

Things will likely improve as models and system prompts evolve, but for now, update your steering files every time you spot a recurring issue and hope for the best.

Finally, the breakdown into iterative features works well for managing progression and complexity. That said, there is no easy way to track the order in which features were implemented, and as with any iterative approach, it can be difficult to consolidate a clear picture of the overall product intent. A feature implemented early may become obsolete after a later one. You can ask Kiro to generate a summary document capturing the overall intent, but scrutinize its content carefully before trusting it.

Keeping an eye on tokens and credits

Kiro uses a subscription model with a number of tiers, each granting a monthly credit allowance that maps directly to LLM token consumption. The exact amount you burn through depends on the model you are using. Kiro is primarily built on Claude models but also gives you access to a number of open-source models, which you can use to optimize tasks that require less reasoning capacity.

I had the chance to run my experiment on an enterprise plan. After a solid two days of work I had consumed around 40% of my credits, then I got distracted by meetings and other projects. Usage is scoped to your repo, but it will likely grow as your codebase expands or as you iterate on steering files, tool configurations, and context. You can hit the ceiling faster than expected.

Some of Kiro’s iterations can feel wasteful. With no memory across tasks, it may keep repeating the same mistake (the wrong Python command, for instance) until you intervene. But when you run the numbers, the balance is still clearly positive. At the time of writing, doubling your credit allocation costs a few hundred dollars, and at this level of productivity the return is hard to argue with.

Points of attention and conclusion

I spent days doing what a good template and scaffolding could have done in hours. To be fair, the task is more comparable to creating that initial template, where creativity and sound engineering judgment are genuinely required. Still, it is a good illustration of how easy it is to lose yourself in a costly effort when you pick the wrong tool for the problem at hand.

That said, the overall productivity gain is real, and so is the knowledge extension that comes with it. The previous generation of coding tools was incremental. This one is going to change how we write, test and troubleshoot software.

What it will not do is manage your code for you. You remain accountable for everything it generates, and you had better understand it.

The tool will amplify your productivity, and might even reduce your technical debt by taking care of software dependencies and code smells.

Researchers are beginning to document what happens when you let the tool decide too much, and they identify two emerging risks: cognitive debt and intent debt.

Cognitive debt refers to the progressive loss of shared understanding of a codebase across a team. People build mental models of a project over time, and those models help them reason about code they did not necessarily write. Accumulate enough cognitive debt and the team will start resisting change, while onboarding newcomers becomes increasingly difficult.

Intent debt appears when the original goals and constraints behind a project are forgotten. Unclear or drifting specifications are not new, but LLM tools can accelerate this type of drift significantly.

I would argue that Kiro and spec-driven development address intent debt at least partly. Cognitive debt remains a valid and serious concern, particularly in larger organizations.

The tools are moving fast. The question is no longer whether agentic coding works. It is whether your team is ready to own what it produces.

On my end there is still a lot of Kiro I have not explored, but I decided to extend my breadth rather than my depth and become fluent with Claude Code next, so I have a meaningful comparison point.

References

• www.lazgar.net
• kiro portal https://kiro.dev
• Cognitive and intent debt https://arxiv.org/pdf/2603.22106v4
• Cognitive surrender https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646
• Recap on coding agents concepts https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html