Article Content

I recently wrote about my experience at AWS re:Invent 2025, where I spent some time waffling about my interpretation of Werner Vogels' "Renaissance Developer" vision. I'd implore you to read it if you'd like a little more context on where this post has come from.

In sum, Kiro was unsurprisingly a massive focus at re:Invent; along with agentic AI more generally. If you haven't heard of Kiro, you ain't down with the cool kids, sucker.

Basically, it attempts to address the ambiguity of vibe-coding by using "specs", which align much more closely with the formal process of requirement -> design -> task breakdown that you're probably familiar with. I'd suggest you have a look into it before diving into this post.

The whole "Renaissance Developer" piece was effectively addressing the human side of these rapid innovations; "how is this going to affect my job/livelihood?", "am I going to become obsolete?". And of course the answer is, as with any kind of ground-breaking progression, "you'll be fine, if you adapt".

So, how do you adapt?

First of all, if you haven't used Kiro yet but you haven't actually been living under a rock, you're probably thinking:

Yes, yes, Kiro, Kiro, Kiro. But is it actually any good?

My honest answer to that is: It doesn't really matter.

It doesn't really matter what your opinion is on vibe-coding. Perhaps you think it's a great way to accelerate time to market. Perhaps you think it's a great way to generate technical debt. Perhaps both of the above.

But the reality is, even if in five years' time we're all drowning in SlopScript, in the short term, it's inevitable. It's inevitable for the same reason that your product owner says, "we can accept some technical debt if it gets it over the line before the end of the quarter". It's stupid, but we live in a society (lol) governed by money, and money is governed by consumption, and consumption is governed by greed, which does nought but wail for more and more, quicker and quicker. This force will ultimately govern our relevance in the field of software engineering — even if we as engineers disagree.

Personally, I've been using Kiro since ~September, and it's become my de facto IDE since. These are my own mixed feelings on it...

  1. To address the elephant — I don't hate AI. I'd go as far as to say that it irritates me when I see someone love a franchise/service/whatever, then discover AI was used at some point, then flip out about it. AI is a tool; it can be used properly, and it can be used badly. I wouldn't be angry if I had a handyman use a drill to do some work on my house, but I would be angry if they drilled straight through a cable.
  2. I don't even hate vibe-coding. Again, it depends on what those vibes are. Are they structured, comprehensive, behaviour-driven vibes? Or are they subjective, vague, hocus-pocus vibes? You're just "vibe coding" when your customer/project manager throws a requirement at you. But you've (hopefully) been given good vibes to work with. It's not fair to bash AI for what is very much a human semantics/process problem.
  3. ...But, that's kind of where the crux of it lies. As I mentioned in the re:Invent post, humans suck at giving instructions, and AI is great at following instructions. Put it like this: Imagine that tomorrow your customer came to you and said, "Make me a homepage for a site about <Product X>. Use modern and aesthetically-appealing design", and then just expected it to be done, without you asking any questions. This is why vibe-coding is bad. People are drilling holes through cables.

Side point: I also think AI is still massively overvalued (I am bearish on S&P Tech over the next year), and its environmental and sociopolitical harm is saddeningly disproportionate. I do think tools like Kiro are where the insane speculative returns will materialise to some extent, but still.

My conclusion, therefore, is that vibe-coding is inevitable, and we must simply address its deficiencies head-on. You can use Cursor or whatever else you like, but imo Kiro is what (so far) addresses said deficiencies best.

How to make Kiro not suck

A clip of Luigi from Luigi's Mansion sucking up a ghost with a vacuum.

By which I mean, every tool sucks if you don't know how to use it well. The problem is, people don't tend to assume, say, Python will be good if they don't know how to write it. Vibe-coding is just so accessible that it's easy to think there isn't a "trick" to it, and so, it ends up sucking. I observed the same phenomenon when in worked with low-code, and it seems to crop up with any technology in which there's no significant entry barrier. Anyway, I digress. Let me give you some tips.

Build something first

Before you even speak to Kiro, build something yourself. I say this because, lovingly, Kiro kind of overengineers stuff by default. I talk about this a little more below.

As a few examples:

  • If you're building a website: Build ~half of your homepage, or whatever seems sufficient to portray:
    • The style,
    • The structure,
    • Its purpose,
    • ...So, have a good mix of diversely-styled content sections, plenty of text content to summarise the site.
  • If you're building something not-so-visual (e.g., IaC, backend code, etc.):
    • Write some modules/functions out at the level of abstraction that you would expect/want from real engineers.

Basically, treat Kiro as a very talented junior dev. It'll figure out how to build what you want, but it's better suited to brownfield contexts where it's got existing (hopefully good) code to base itself on. You might also benefit from explicitly stating that you want it to copy the existing style and structure of your codebase in your steering docs, but I find it does this anyway.

Have Kiro build things as simple as possible

As I mentioned earlier, Kiro really likes building things "enterprise-grade". I.e., in many cases, overengineered. It will happily create you the most watertight abstraction with a full Ishkur-article-sized (😉) README for something that you would otherwise have written fifty lines for and called it a day.

You might ask, "why? It's great that it does a good job of things engineers wouldn't have the time to perfect to that extent". Sure — particularly for documentation, it's fantastic. Drives bus factor right down (though you might want to sprinkle a little, je ne sais quoi, "don't write like you've got a stick and fifteen emojis up your backside" in your steering docs).

But here's the rub:
It's probably not that it's doing a better job than an engineer would, but that it's building bells and whistles that an engineer would YAGNI out the window. It's all fine and dandy to have loads of convenient extra interfaces, but crucially, it makes it harder to review the code it writes. And that's the important part. I might suggest having a ballpark git diff estimate for the change in your head — if Kiro goes substantially above that, have a sniff around for anything it's overdoing.

I would strongly recommend adding something to your steering docs, like: "The objective is to write as little code as possible, while still robustly fulfilling the requirements for the task specified".

Break things down aggressively

Hot take: The tasks generated by Kiro specs still kinda suck. They're very waterfall-y, and often not granular enough. For instance, for this website, it had ~12 tasks; often handling things page-by-page. But I don't think this captures the nuance of software engineering very well. It's why agile came about. You don't really just make a page. I mean, you might, but you'll often build out the style, structure in one page first, fiddle with that a bit, branch out, realise that that style doesn't work so well when applied somewhere else, so on, so forth. In my experience, it's kind of hard to "trust the process"; sometimes, I have left Kiro to its tasks and it has shaped itself up as it's gone along. Other times, it starts shoddy, and finishes shoddy. I think the requirements and design generation are fantastic for supplying more succinct, informative context to the agent. But I would take the time to break down the tasks for yourself.

To that end, I'd suggest really breaking things down, if you can. In your steering docs, be firm about how much Kiro is allowed to touch your top-level logic. Have it built everything in small, simple modules, and only go anywhere close to your execution entrypoints for instantiating those modules. Think about it this way: If you're told to build something, if it's anything more than slightly complex, you'll almost definitely have questions to ask. Kiro doesn't have the power to do that (but I think as time goes on we will start to see agents being more interactive with the user in this sense), so you want to distill everything you tell it to do into the simplest, clearest, unquestionable work item.

And this leads me on to my next point...

Actually have a Git strategy

Please have an actual commit strategy. Create branches representative of features, bug fixes, etc., as you would when building something by hand. I pretty much commit after every prompt. The "restore" feature makes that less necessary, but I'd still recommend it. The reality is that, with AI-generated code, you'll miss something in your reviews. Just the same as you do other people's code when you review PRs. It happens. But with real PRs, you (hopefully) have an audit trail; commit descriptions, descriptive, granular, atomic commits. It's all too easy to forego this with Kiro/Cursor/Antigravity. Please don't. That way lies self-hatred.

Final thoughts

  • Of the core Kiro features that you see when you open its panel on the left-hand side:
    • Specs are good, but tasks are kind of not there yet. Tweak them heavily.
    • Agent hooks are... potentially useful, but in my experience, quite annoying.
    • Steering docs are OP; use them. Conversely, if you don't, your code may well be an overengineered mess.
    • "Powers" (backed by MCP) are very good. That's a very broad statement, because it depends on the "power", but I used the bog-standard web search (via the Brave API) and AWS Documentation search powers, and it managed to (mostly) understand an AWS API that was only a few weeks old as of the time I wrote it.
  • Review everything. I shouldn't have to say this. But also, I understand that you might not, if Kiro has spewed out a 3,000 line diff. Hence some of the above tips to get Kiro to cut it down a little.

So, what do I have to show for all this?

Well, this website, for one.

I had about half the homepage sitting in a repository collecting dust for about three months. I knew SvelteKit enough to do the thing, but finding time was the problem. Especially for me — I suck at front-end. Fortunately, I tend to be pretty good at articulating a vision at least, and so Kiro managed to turn what already existed and how I suggested to extend it into pretty much what I had imagined; and reasonably robustly, too. It's not perfect (I know it can look funny on some tablet resolutions, for example), but that's as much my fault as Kiro's. I've since learned a lot about how to do things better, as well.

Enkirosis

The rapture is coming.

Those who do not adopt AI-assisted coding will be left behind.

Maybe not eternally.

Perhaps in five years' time we all realise this was a horrible mistake, and we go back to coding by hand. Or perhaps we're all just enslaved by robots. Or both.

But certainly for now, it really is the most critical thing to get to grips with, and weave into your tech stack.

Frankly, I welcome this with open arms (when we ignore the afore-mentioned environmental problems and such). To be perfectly honest, I've always been much better at architecture and high-level problem solving and diagnostics than I am at actually coding — Kiro actually kind of lets me play to my strengths a bit.

Kiro is a tool, and much like any other tool, if used professionally, it becomes an extension of oneself.

Enkirosis has been attained.

An image of the Mesopotamian God Enki carved into stone.