I Spent 30 Minutes Writing Specs in AWS Kiro—and Finally Understood Why That Production DB Deletion Could Have Been Prevented
I spent 30 minutes writing a spec using AWS Kiro's EARS notation. The shared blind spot behind the Lovable vulnerability and Cursor production DB deletion incidents finally became clear—the closing chapter of my vibe coding trilogy.
Two incidents happened back to back.
In late March, the security firm Outpost24 published the results of an investigation. They had found vulnerabilities in 10.3% of apps auto-generated by Lovable. SQL injection (an attack technique that steals information by inserting malicious SQL statements) and authentication bypass were rampant.
Then in May, a Cursor agent deleted a production database. It started when a developer told the agent, “Clean up the database.” Tables in the production environment were wiped out, and data was lost.
After writing those two articles, I kept asking myself the same question. Not “How could it have been prevented?” but “Why wasn’t it prevented?”
The answer converged on “because there was no spec”—and it was only after I started seriously using AWS Kiro that this clicked.
In early May 2026, SiliconANGLE reported the latest news on Kiro. Preview participants had exceeded 250,000, and a transition to general availability was approaching. I felt this was the moment to write the closing chapter of the trilogy.
The “Same Hole” Both Incidents Revealed
At first glance, the Lovable case and the Cursor case look like completely different incidents. One was a security flaw, the other a failure of permission control.
Even so, to me they looked like the same “hole.”
The code Lovable generated had no validation (input verification logic) for SQL injection protection. Why? Because the prompt to Lovable didn’t include the requirement “implement SQL injection protection.”
The Cursor agent had unrestricted permission to write to and delete from the production database. Why? Because the constraint “deletion of production data requires human approval” was never defined.
In both cases, “what must not be done” was never written down.
Vibe coding is a development style where you just give natural-language instructions to an AI and it writes the code for you. I rediscovered the joy of writing code thanks to this style. But pushed by speed, the step of “writing a spec” was getting skipped.
I spent years in customer success, listening to thousands of user voices. What I learned there is that “putting requirements into words” determines product quality. Teams that can’t articulate “this is what I want” build products that show problems later.
The same thing was happening in AI-assisted development.
Stack Overflow’s 2024 Developer Survey (over 90,000 respondents) gives us one telling number. 63% of developers said they “spend more time debugging than expected.” Even when AI writes the code, debugging remains a human job. And much of that debugging traces back to “gaps between requirements and implementation.”
Both of those incidents, when you boil them down, were gaps between requirements and implementation. Because security requirements and permission constraints were never written, the AI never implemented them.
After writing the late-March Lovable article and the early-May Cursor article, I’ve arrived at one conclusion: “Before instructing the AI, write down what it must not do.” And Kiro had a built-in mechanism to make that happen.
What Is AWS Kiro?
AWS Kiro is an AI IDE developed by AWS (Amazon Web Services). AWS is Amazon’s cloud business division.
Cursor, Claude Code, and GitHub Copilot function as “AIs that complete and generate code.” Kiro adds a flow on top of that: “write the spec first.” The process of articulating “what to build” before writing code is built in. That’s its defining feature.
It’s built on top of VS Code, and preview participants have exceeded 250,000. The free plan offers 50 credits per month (enough to try out a few mid-sized projects). The paid plan is $19/month for 200 credits.
What makes Kiro distinctive is that development revolves around three files.
The first is requirements.md. Kiro converts natural-language requirements you write into a spec document in EARS notation. EARS is covered in detail in a later section. The second is design.md. The architecture and design philosophy are recorded here. The third is tasks.md. Implementation tasks are listed in priority order.
These three files function as “living design documents.” Because requirements are made explicit before code is written, the AI enters implementation already knowing “what must not be done.”
The effect is huge even for solo development. When I look at a spec I wrote three weeks ago, I immediately understand “why I designed it this way.” Code “kind of written” through vibe coding can become incomprehensible—even to me—a week later. With a spec, that loop gets broken.
EARS Notation as a Design Language
EARS (Easy Approach to Requirements Syntax) is a framework for writing requirements. It originated in 2009 within the aerospace propulsion division of Rolls-Royce, the British aircraft engine manufacturer.
Its roots lie in the aerospace engineering tradition of “writing requirements without ambiguity.” Companies like Airbus (the European aircraft manufacturer), NASA, Bosch, and Intel have adopted it.
The grammar is simple. The representative patterns look like this.
# Basic functional requirement
The system shall [action]
# Conditional requirement
When [condition], the system shall [action]
# Prohibition requirement
The system shall not [action] unless [exception condition]
# Event response requirement
When [event occurs], the system shall [action] within [time constraint]The difference from natural language is “ambiguity.”
The instruction “build a user management feature” can be interpreted dozens of ways. But write it like this, and the implementation choices narrow down to roughly one.
When a user attempts to log in,
the system shall validate credentials
and return an error within 500ms if authentication fails.When ambiguity disappears, the quality of the code the AI generates goes up. Even more important, though, is the effect that “the act of writing itself organizes your thinking.”
When you try to write requirements in EARS notation, questions naturally surface: “What happens if this feature throws an error?” “How do we handle unauthorized access?” “Holes” you weren’t thinking about beforehand come into view.
Coming from a CS background, I see this as exactly the same structure as designing a user interview. If you don’t organize “what to ask” beforehand, you miss things. Code requirements are no different.
I almost got tripped up at first by EARS notation, thinking “do I have to write it in English?” In reality, Kiro learns the EARS “structure” from your Japanese input and generates the spec for you. The English requirement definitions come out automatically, so English fluency isn’t needed.
I Actually Wrote a Spec
I handed Kiro the requirement “an internal tool where employees can post daily reports.”
My initial input looked like this.
What I want to build: A tool where employees can write and post daily reports
Constraint: Only the author and their supervisor can view them
Usage environment: Both smartphone and PC supported
Concern: Worried that other users might see someone else's report
Concern: Don't want admins to be able to illegitimately pull all the data
Concern: Want a confirmation step after the submit button is pressedKiro received this and generated requirements.md. Here’s an excerpt.
## Authentication and Access Control Requirements
When a user attempts to access the system,
the system shall verify the user's identity
before granting access.
The system shall not display reports belonging to other users
unless the viewer holds the supervisor role for that employee.
When an administrator requests bulk data export,
the system shall require a secondary approval from
a different administrator account.
## Data Integrity Requirements
When a user submits a report,
the system shall display a confirmation dialog
showing the report content before final submission.
The system shall not allow report modification
after submission unless the submitter initiates
an explicit edit request within 30 minutes.
## Security Requirements
The system shall encrypt all report data at rest
using AES-256 encryption.
When a login attempt fails three consecutive times,
the system shall temporarily lock the account
for 15 minutes.Honestly, when I first saw this, my heart skipped.
My input didn’t contain a single mention of “encryption.” I hadn’t written one line about “brute force protection” (defense against exhaustive password-guessing attacks). But Kiro had filled in “what’s needed as security requirements” and woven it into the spec.
That was the moment I felt the heart of Kiro.
Let me share a gotcha upfront. If your initial input is too sloppy, the spec will be thin too. The boundary for generation quality is “not 3 lines, but 6–10 bullet points including concerns.” Writing about “concerns and constraints” beats writing about the “number” of features—it produces more defensive requirements and a richer spec.
In the next step, Kiro generated tasks.md. “Implement authentication API (priority: high)” came first, followed by “data encryption (priority: high)” and “daily report submission form (priority: medium).” The priority order of design and implementation is automatically derived from the spec.
I no longer get stuck on “I don’t know where to start.” The task list functions as a “map.”
I Tested “What If There Had Been a Spec During That Incident”
I redesigned the Cursor production DB deletion case using Kiro’s EARS notation.
The structure of the incident is simple. A developer told a Cursor agent, “Help me clean up the database.” The agent had write and delete permissions on the production environment. With no confirmation step, the operation executed and production data vanished.
Written as requirements in EARS notation, it would look like this.
## Production Environment Protection Requirements
When the agent executes any operation in the production environment,
the system shall require explicit human approval
before execution proceeds.
The system shall not perform DROP, DELETE, or TRUNCATE operations
without displaying the affected row count
and receiving a typed confirmation from the user.
When a destructive operation is requested,
the system shall execute a dry-run first
and show the preview of changes before proceeding.If this had been in the spec, the agent would have recognized that “trying to modify production without a dry-run violates the spec.” Kiro’s steering hooks feature warns you when code tries to behave in ways that contradict the spec.
Steering hooks are a feature that fires warnings when code conflicts with the spec. When the spec is changed, or when the implementation looks like it’s about to drift from the requirements, Kiro automatically checks and notifies. The structure becomes one where the code is “monitored” by the design document.
A common problem in the field is that code and spec drift apart as development progresses. It’s not unusual for the initial design document to go untouched by anyone three months in. Steering hooks function as a mechanism for “keeping the spec alive as a living document.”
The Lovable vulnerability incident can be re-examined through the same lens. If the spec at app-generation time had included the following requirement, Lovable would have tried to generate code that satisfied it.
The system shall validate all user inputs
against an allowlist to prevent injection attacks.Many of the 10.3% of vulnerabilities were the result of the requirement “implement validation” simply not existing.
There’s a case study from Rackspace (a US cloud managed services company) reported on the AWS Industries Blog. After moving to a development flow combining Kiro and EARS notation, project completion time was reportedly reduced from 52 weeks to 3 weeks.
Development speed didn’t drop. If anything, it went up. The process of “deciding what to build first” reduced the loop of fixes that had to happen later.
Three Steps to Start This Week
I’ll walk through them in the order I got tripped up after install.
Step 1: Install
Kiro can be downloaded from the official site at kiro.dev. It installs as a standalone app based on VS Code. It carries over your existing VS Code settings (themes and some extensions), so the barrier to migrating environments is low.
You’ll need to link an AWS account. If you don’t have one, you can create it for free. The free plan is enough to start. 50 credits a month was enough to build one or two prototypes.
Step 2: Write Your First Spec
After opening a new project, the first thing to do is not write code.
Open Kiro’s “Spec” tab and write down “what you want to build.” You don’t need to aim for a perfect spec. What matters is bullet-pointing “what you’re worried about” and “states you don’t want to occur.”
In particular, I always make sure to write these three:
- Security concerns (unauthorized access, data leaks)
- Permission constraints (who can and cannot do what)
- Behavior on error (when something fails, how should it behave)
When you write these, the “defensive requirements” in the requirements.md Kiro generates become dramatically richer.
Step 3: Convert to Tasks and Implement
Once requirements.md is generated, ask Kiro to “convert this to tasks.” A tasks.md is generated, with a priority-ordered implementation list. From there, you advance the implementation one task at a time, in dialogue with Kiro.
The decisive difference from regular vibe coding is that “what to do next” is always made explicit. tasks.md functions as a map.
One thing to add. At first, you may feel “the time spent writing a spec is wasteful.” When you actually try it, a 30-minute spec saved hours of debugging later. The return on investment, in my experience, was over 10x.
Wrap-Up: A “Design Phase” Has Returned to Vibe Coding
The trilogy converges here.
In the late-March Lovable vulnerability article, we saw “the code AI generates has holes.” In the early-May Cursor production DB deletion article, we confirmed “giving an agent too much permission causes real-world damage.” What I was able to confirm this time is that “in both incidents, the outcome would likely have been different if a spec had come first.”
The appeal of vibe coding lies in its speed and ease. I don’t want to lose that. But over these three months, I’ve seen plenty of what happens when you skip “the 30 minutes to write a spec.”
What Kiro presents isn’t a “tradeoff between speed and quality.” It’s the practical fact that “a 30-minute design document raises the quality of your code.”
I’ve now started writing a spec before using Kiro on every project. Five lines or ten lines is fine. Just being able to “notice you can’t build it” has dramatically reduced the time I burn later.
In an era with AI, I think there’s no longer a divide between pros and amateurs when it comes to “building products.” We’ve entered an age where humans with ideas and design skills can produce results. Kiro is a tool that distills design skill down to the habit of “writing a 30-minute spec.”
There was a time when I was so afraid of production environments that I left coding behind. Now, I can prevent breakage with a spec before it happens. That’s the place this trilogy has arrived at.
Sources
- Outpost24 “Vibe Coding with AI-Powered Platforms: Security Challenges” (2026) https://www.outpost24.com
- SiliconANGLE “AWS Kiro: spec-driven AI development” (2026-05) https://siliconangle.com
- XenoSpectrum “AWS Kiro Spec-Driven Development” (2026-05) https://xenospectrum.com
- Stack Overflow 2024 Developer Survey https://survey.stackoverflow.co/2024/
- AWS Industries Blog “Rackspace: how AI-driven development transformed delivery” (2026) https://aws.amazon.com/jp/blogs/industries/
- AWS Kiro Official https://kiro.dev
Related Articles
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
