DEV Community: fikuri

Building Shoots: a hybrid event-driven agent system for photography

fikuri — Mon, 31 Aug 2026 09:23:06 +0000

I created this article for the purposes of entering the All Things Agentic Hackathon.

Shoots is an Android and web photography Companion. A photographer takes ordinary
Shots. Shoots reviews them in the background, preserves the Evidence behind its
reading, and can offer one optional Experiment when the record supports it.

This is the technical version of the project. It is about how a file becomes a
durable learning record, how the agents communicate, and where I deliberately
refused to let a model make the decision.

The design in one sentence

The model panel reads a single Shot. The system around it does the work: it
creates a durable Run, moves tiny events through independently retryable stages,
re-reads state at every boundary, records every outcome, and only settles a Shoot
after every member Run is accounted for.

That distinction matters. I did not want a chain of agents passing prose to one
another until it sounded convincing. I wanted constrained model calls inside a
workflow whose state, retries, and outputs could be inspected later.

Repository structure

The codebase is deliberately split by responsibility rather than by screen or
agent name:

android/
  phone/         # approved Camera media
  work/          # background upload and retry
  data/          # cache, API, identity
  ui/            # Android screens

backend/app/
  api/           # FastAPI ingress and push endpoints
  domain/        # pure rules and state transitions
  imaging/       # EXIF, pixels, visual artifacts
  agents/        # ADK agents and prompts
  services/      # workflow orchestration
  infra/         # storage, Pub/Sub, Drive, secrets

frontend/src/
  stores/        # API and SSE state
  pages/         # web audit desk
  components/    # receipts and visual Evidence

infra/           # Google Cloud deployment and Scheduler

The important boundary is domain/. It has no I/O. It owns the rules that must be
reproducible: grid-cell conversion, taxonomy validation, panel consensus, Criteria
checks, Technique Map projections, and Run state transitions. services/ can call
models and storage. domain/ cannot.

Two kinds of orchestration

Shoots has two coordination layers, because model orchestration and background
work have different failure modes.

1. An in-process ADK panel reads one Shot

The Analyst is an ADK SequentialAgent. Its first step is a ParallelAgent with
three readers. Its second step is a Synthesizer.

gridded Shot + camera facts ──> Technician
gridded Shot                ──> Composer
clean Shot                  ──> Storyteller
                                  │
                                  ▼
                    structured readings + measured facts
                                  │
                                  ▼
                   Synthesizer, with no image input

The readers do not all see the same prompt and image. The Technician gets EXIF and
the gridded Shot. The Composer gets the gridded Shot for composition and light. The
Storyteller gets the clean Shot. The Synthesizer gets their structured readings and
the measurements, but no image.

Each reader returns a Pydantic schema, not an unbounded paragraph. Before a model
claim reaches storage, code drops unknown Technique IDs, invalid cell references,
and unsupported geometry. domain/panel.py then requires agreement between
readers, or a higher-confidence read from the Technique's accountable reader.
Measured facts can veto a conflicting visual claim.

For example, a model can say where it sees a motion technique, but phase-correlation
code can rule out a locked-off camera. A model can locate a region with grid cells,
but it never emits pixels or a hand-drawn overlay.

ADK coordinates the small panel inside the Analyst. Pub/Sub coordinates the durable work outside it.

2. Pub/Sub coordinates independently retryable stages

Agent stages do not call the next remote stage directly. They publish a small,
ID-only message, then the next handler re-reads the Shot and its current state.

source accepted
  -> create Shot + durable Run
  -> media.new
     -> Ingest
  -> media.ingested
     -> Analyst
  -> media.analyzed
     -> Cartographer
     -> Judge
  -> media.judged
     -> Scribe

The actual message is intentionally boring:

await ctx.bus.publish(TOPICS["media.analyzed"], {"shot_id": shot.id})

That one choice avoids a lot of accidental complexity. Pub/Sub never carries a
stale Analysis object or an agent's prose. A handler loads the authoritative
records it needs, writes one idempotent outcome, and can safely see the same event
again.

media.analyzed fans out to Cartographer and Judge. They get separate push
subscriptions, retry policies, and dead-letter paths even though they start from
the same event. Judge always emits media.judged, including when there is no
Experiment Verdict, so Scribe can still write the reviewed output.

Local development uses an InProcessBus. Production uses Pub/Sub push requests to
/pubsub/<stage> on Cloud Run. The handlers are registered the same way in both
modes. Transport changes, but the stage code does not.

The state machine is more important than event order

Every accepted Shot gets a durable Run before the first event is published. A Run
has a separate outcome for Ingest, Analyst, Cartographer, Judge, Scout, and Scribe.
The outcomes can be complete, skipped, retrying, or terminal.

ActivityEvent records explain what happened. Run state decides whether the
work is finished. This prevents a misleading result such as "review complete"
because Scribe happened to finish while Cartographer was still retrying.

Once every member Run of a natural camera period has settled, Shoots creates a
Shoot Record. Only then does the Shoot-level Scout choose a typed route: explain
supported work, ask one consequential question, offer an evidence-backed
Experiment, or stay silent. The model writes within a route that code already
selected. It does not get to invent a new task for the photographer.

many Shot Runs settle
        │
        ▼
Shoot barrier
        │
        ▼
Shoot synthesis -> typed Scout decision -> Shoot Record

This is also why a Shoot is not just a time window. It is a revisioned record with
exact member Shots. A later Camera Shot can create a newer revision without
rewriting the earlier record.

Making retries safe, including model cost

At-least-once delivery is normal with Pub/Sub. I treated it as a design condition,
not an error case.

A stable source reference makes a redelivered import a no-op.
Ingest and Analyst claim the Shot before doing expensive work. The Analyst uses a timed ANALYSING lease, so a duplicate delivery does not buy another panel run. A genuinely abandoned lease can later be reclaimed.
The process-local StageGate limits expensive Analyst panels on one Cloud Run instance. Pub/Sub owns the durable backlog, so the gate is not a fake global queue.
Failed deliveries go to a dead-letter path, but that is not considered finished. Cloud Scheduler scans durable retrying Runs and republishes the original stage event. It does not mutate the Run to "complete" behind the normal handler.

The result is a repair path I can audit. A replay records which stage was retried
and when. It does not pretend the failure never happened.

Where model authority ends

I use Gemini 3.7 Flash for bounded visual interpretation and writing. Deterministic
code owns evidence rules, state changes, and anything that sounds like a fact.

The boundary is easiest to see in three places:

Panel consensus. Gemini can propose Technique Evidence, but code validates IDs and grid cells, applies quorum rules, and lets hard evidence veto a claim.
Visual Evidence. A model can bound a possible area using grid cells. OpenCV and NumPy then render a measurable artifact inside that boundary. For edge evidence, the renderer uses Canny edges. For detail, it uses a Laplacian map. If the renderer cannot support the location, the interface shows no persuasive overlay.
Crops. The Composer may propose a crop. Pillow renders it, then a separate Gemini rater compares the original and crop for at most two rounds. Shoots only keeps the crop when that comparison explicitly improves. It remains a tested suggestion, not an objective quality score.

The cyan marks are measured contrast edges in the model-located area. They support a narrow claim about visible edge structure, not a verdict on the composition.

This is why Shoots does not store an overall aesthetic score. It stores Evidence,
Findings, a labelled visual reading, and the exact model and prompt version that
produced that reading. A Reproduce Verdict is reserved for Criteria that were
declared before the photographer tried again. Explore and Compare do not get a
pass/fail label.

Durable artifacts, not a chat history

Firestore holds the Photographer record, Shots, Analyses, Runs, ActivityEvents,
Technique Map projections, Experiments, and Shoot Records. Cloud Storage holds
original files and display assets. Google Drive is an optional import and reviewed
output adapter.

Scribe can prepare a Deconstruction draft from stored Evidence. It cannot treat the
current image as permission to invent a new claim. The writer gets supported
Evidence IDs; domain code validates those references and the photographer reviews
the result before sharing or downloading it.

The Deconstruction is a draft built from already-stored Evidence. It never posts itself.

What I measured

I ran a recorded production Drive-import workflow with 75 test files in three
batches. All 75 completed. Shoots wrote 75 reviewed copies to Google Drive and
produced three settled Shoot Records. Five failed Shots recovered through six
automatic repair replays.

The median backend Run took 48.72 seconds. The complete session took 40 minutes and
7 seconds from the first import request to the final Shoot Record. Because the
batches overlapped, multiplying the median by 75 would be misleading.

I also ran a separate five-Shot metered sample with real Gemini calls. The model-only
estimate was about $0.039 per Shot, or $2.95 projected to 75. That is not the
historical bill. It excludes cloud infrastructure, Drive transfer, discounts,
credits, optional Experiments, and visual-story generation.

The 75 files included repeats and deterministic variations of real hobbyist Shots.
That proves the workflow, repair path, and delivery. It does not prove that Shoots
makes someone a better photographer. That needs people using it over time and
telling me whether the Experiment was useful.

The source is open at github.com/fikri2992/shoots. The project entry is Shoots on Devpost.

I make an app to help you make money while traveling

fikuri — Sun, 17 May 2026 18:07:57 +0000

This is a series of content I created for the Build with MeDo Hackathon at MeDo.
Read my first article about medo here full review about medo.dev

Introduction

In Indonesia, Jastip (concierge service) is very common. China has a similar culture called Daigou (buying on behalf).

The key similarity between Daigou and Jastip is one simple thing: "Access".

How Jastip works is basically someone from a different location with "access" to certain products offers them to others on social media. If people want to buy, the seller does not need to own the inventory or stock. They just need to be there at the store and ready to purchase. This Jastip service includes a service fee and sometimes delivery service. There are many kinds of products being sold, from snacks to luxury goods you cannot easily find in Indonesia.

People in Indonesia take this to another level by making it a full side quest while travelling. They plan a trip for fun, and to help finance the travelling, they do a Jastip side quest with many products, often from cross-country travel.

Then I found that China already has a similar culture with Daigou, but it is more focused on luxury items that are often hard to find in China or have some kind of rarity or reputation from the origin country (or so from what I read on the internet).

The interesting thing about China and Indonesia's Jastip/Daigou culture is how they operate. In China, Daigou mostly operates on WeChat livestreaming, and the storefront is built inside WeChat using mini programs.
On the other hand, in Indonesia, interaction and transaction usually happen on either WhatsApp groups or Instagram chat. It is very fragmented and causes multiple issues.

So to help my fellow Indonesians make money while travelling, I made an app to manage this kind of thing using medo.dev.

Show me the money

To motivate you to read further, let me put a motivational image for you.

Yes, the money. With this app, you can not only plan for travel, but also make some money with Jastip.

How, you may ask?

1. You can create a campaign

When creating a campaign, you set the starting date and end date of your Jastip.
But Jastip across countries is hard. You need to calculate currency, and I am also afraid of people doing hit and run.

Don't worry, this app handles the currency exchange automatically for you, and there is deposit payment for your buyer. They can use that deposit to buy from you later, but if they do not buy, you can redeem the deposit.

What's next after creating a campaign, you may ask?

2. You can open the campaign and check

Talk with the AI assistant so you are better informed about weather, currency, pricing strategy, adding products if you already have something in mind, or just reading the news in case something happens.

3. Talk with our smart AI agent

Our AI is not like ChatGPT or Gemini, where you need to give information about what you are doing, where, or when. It understands your Jastip context, and it is integrated deeply with MeDo's large language model.
You can also take notes for important information from the AI and check them from the notes tab.

4. Check who is already interested

Check your member tab to see who is already interested and has put down deposit money.
They actually pay with their debit/credit card (using MeDo Stripe skills). It will be yours to claim later.

5. Talk with your buyer directly

Instead of information scattered in WhatsApp and Instagram, you can interact directly here in the app. You can also send images if you want.

6. Lastly, download the invoice or just export everything into Excel for later.

You can enjoy your travel and manage the Jastip using our platform.

7. and heres from buyer side of the app

From the buyer side, the flow is browse campaign, join with deposit, send request, chat, and track the transaction.

Next is how did I make this app?

nd how did it only take me a week to do so...

1. Register to Medo.dev

Ok, MeDo is a full-stack AI coding platform. It sounds very much like a buzzword, but trust me, it is real. You may already have heard about v0, Lovable, Bolt, or Replit, but there is nothing like it. MeDo is more complete, and you only need MeDo (and Stripe apparently for payment).

2. Create new project

3. Next, you just wait until your idea is built

Here's the fun part. Medo.dev is actually not frontend first. It is product first. It will create the full product spec and requirements before it even starts coding. Everything is included, from what should be built, how the folders and system are structured, and what is out of scope, which is very important to make your product align with your vision.

You can edit it or not, it is up to you. Next, click generate the app and then wait.

4. PLUGINSSS (apparently now they call it skills)

The skill integrations in medo.dev blew my mind. In v0, Lovable, and Bolt, you are kind of forced to register for an outside backend service like Supabase. But medo.dev does this automagically, so you do not have to have a Supabase account and click connect or something like that. It just WORKS.

login just works
crud just works
upload image just works
realtime chat app just works
even payment using stripe is just WORKS

And it is not only the backend. Even LLM, image generation, video generation, text-to-speech, and speech-to-text are included. No need to juggle multiple providers, grab API keys, store them, then integrate them. IT JUST WORKS.

You can just pay using a single credit system for all of the services. No need to set up multiple payments or subscribe to multiple websites to get API keys anymore.

I was really blown away by the depth of the integration, so I started to dig into the code.

5. The LLM skills

So in my experience using the medo.dev LLM skills, the default is not really great, but you can just prompt it. Make sure to always prompt it to make the output token to the max.

You can also ask it to call tools, using other skills as tool calls that the LLM can invoke. My biggest problem with the LLM skills is that it seems to be hardcoded to Gemini 2.5 Flash, while there are already newer models like 3 Flash or later.

You can actually make an agent in the LLM skills, not just a placeholder. For example, I built this AI assistant to be able to talk to its own CRUD API, so it can change the title at the top on the fly in realtime by calling directly to the internal API. Mind = blown.

Some tips and tricks using MeDo

Based on my few weeks using medo.dev, here are some tips and tricks that helped me boost productivity and save credits.

Basics

MeDo gives you an integrated backend and frontend workspace. You can look at the code, but you can also access files, logs, and infrastructure directly inside the app.

A single Fast Build prompt costs about 15 credits, while Deep Build costs 30 credits. As of writing this, new accounts usually get 300 credits on registration and 100 credits from daily login. That is around 10 Deep Build prompts or 20 Fast Build prompts.

Tip 1: Put related tasks in one prompt

From my experience, credits are counted per message, not by how hard the problem is or how many tool calls it uses.

There are limits if you ask for too many things at once, but if the tasks are related, it is usually better to put them in one prompt. This helps you get more value from each credit spend.

Tip 2: When debugging, ask for logs and checks

When something breaks, do not only ask MeDo to fix it. Ask it to add logs and checks first so it can understand the real problem.

Example prompt:

What is the best approach to fix this [issue]? Please add logging and checks to help identify the issue.

This helped me a lot when a problem was not fixed in one run.

Tip 3: Ask for design suggestions before giving strict direction

MeDo can be overly eager when you give it very strict design direction.

In my case, I gave it a reference and told it exactly what I wanted, but it still tried to be "creative" and the result was frustrating.

What worked better was asking for a few options first.

Example prompt:

Give me 3 design variants for this particular [problem]. The goal is to [specific goal], and I prefer it to look like [your preferences].

This way, MeDo gives you a few layout and style directions first. You can then choose one, adjust it, or ask for another variant.

This saved me a lot of credits because I stopped forcing one direction through many follow-up prompts.

Tip 4: when stuck, try to clear the context before sending a new prompt

Sometimes you get that little annoying bug, whether it is frontend or backend.
In my experience, it always helps to use the clear context button before sending another prompt. Clearing context can make the agent think and do the task better and faster.

this is the button, don't mind my negative credits i overused it lol

So that's what I am building and how I am building it, with tips and tricks.

medo.dev the good, bad and ugly from my personal experience

fikuri — Sun, 17 May 2026 13:58:57 +0000

So I joined the MeDo hackathon and used their platform for several days. At first, I thought it was just another v0, Lovable, or Bolt. But after building with it, I realized MeDo offers a very different way to prompt, build, and ship a product.

This is my personal review after around two weeks of using it: the good, the bad, and the ugly. I was genuinely impressed by the deep integrations and some unique features that I think many people might miss. But the platform also has rough edges that are worth talking about.

Background

In today's developer world, many programmers use tools like Claude Code and Codex. They are powerful and flexible. You can build almost anything with them, but you still need to manage everything yourself: setup, environment, dependencies, backend, database, deployment, and debugging.

Of course, you can ask Claude Code or Codex to help with that. But if you do not already know what you need, things can get messy fast.

For non-technical users, or developers who do not mainly build web apps, tools like v0, Lovable, and Bolt feel easier. You do not need to set up much. You prompt, and you see the output quickly.

But once you want to build a complete product, you still need more than a frontend. You need backend, database, authentication, AI APIs, image generation, payments, and many other services.

Yes, tools like v0, Lovable, and Bolt can connect to those things. But you still usually need to create your own Supabase account, connect it, manage API keys, register for OpenAI, Anthropic, GCP, or another provider, and wire everything together.

And then there is the classic problem: API keys. The same API keys people accidentally push to GitHub and then get abused by someone else.

That is where MeDo starts to feel different.

The Good

1. You do not need to open another service, mostly

At first glance, MeDo looks similar to v0 or Lovable. But the difference is that many things are already built into the platform.

Need a backend? It is already built in through Supabase.

Want to add an LLM? Just prompt it. It is already integrated.

Want image generation? It is already built in.

Want text-to-speech? It is already built in.

Want a weather API? It is already available.

Want payment? You still need Stripe, and you still need to register your business and get the API keys. So yes, the legal/business side still exists.

But overall, many services that usually require separate setup are either built in or available through plugins. I think this is MeDo's strongest USP. You do not need to manage and pay for many separate services. You mostly manage MeDo.

Imagine your vibe-coded app starts getting traction. If you use v0, Lovable, or Bolt, you may need to upgrade Supabase, top up credits on GCP or another AI provider, and manage other API services separately.

With MeDo, the experience feels more centralized. You pay and top up credits in one place. As a product builder, I think this is very useful, especially for non-developers who just want to build and publish a real app.

2. Deep backend and frontend integration

Because the backend and frontend live inside one platform and one codebase, the AI agent can understand more of the full product.

That makes building and debugging easier.

For example, I had an issue where a service integration returned a 403 error. The problem was not really in the frontend code. The backend had not redeployed with the correct key. The agent checked the Supabase function logs, looked at the backend code, understood that the problem was the backend not restarting, restarted it manually, and the bug was fixed.

That kind of end-to-end debugging is where MeDo feels powerful.

3. Plugins, plugins, plugins

The plugin system is one of the most interesting parts of MeDo.

The available plugins are diverse and keep growing. I saw plugins for exchange rates, global stock data, data analysis, Word documents, PowerPoint, and more.

To be clear, these plugins are not always like traditional third-party integrations where you connect an external service yourself. Many of them feel more like skills or templates integrated into the platform and database.

But because the model can use them inside the same environment, they become very useful. You do not need to manage every integration manually. MeDo handles a lot of that inside the platform.

4. Design direction and starter templates

I still think v0 is stronger for frontend design. That is probably the thing v0 does best.

MeDo is slightly below v0 in pure frontend polish, but I like that it gives starter references and does not always force the same visual style. It gives you enough structure to begin, while still leaving room to push the app in a different direction.

This part still needs more testing from me, but so far the design workflow feels promising.

The Bad

1. It is still buggy

The biggest downside, in my opinion, is that the platform still buggy. Maybe this is because it is new, but sometimes messages fail multiple times and you need to clear the context manually.

this can be frustrating in my personal experience.

2. The platform feels slow

The slowness is not always about the model generation itself. The platform UI can also feel slow.

Opening the plugin list takes a few seconds. Some images seem unoptimized or not cached well, so they load slowly again and again.

This is not a deal breaker, but it makes the product feel less smooth than it could be.

The Ugly

1. Language inconsistency

The platform still feels China-first in some places, with English as a second layer. Some parts of the UI are not translated, or the interface suddenly switches to Chinese.

Sometimes the model also replies in Chinese or uses Chinese placeholder text in the generated UI.

This is probably fixable on their side, but it stood out during my usage.
for example

2. Unclear model identity

MeDo has "fast" and "deep build" models. I assume they use their own proprietary model, although the behavior sometimes feels close to Claude model in my opinion.

The problem is that I do not know what model is actually being used. I do not know the benchmark, the strengths, the weaknesses, or how I should prompt it.

Should I prompt it like Claude? Like Codex? Like another coding model?

That uncertainty is annoying as a builder. I wish the platform was more transparent about what model is being used, or at least how users should think about each mode.

Final Thoughts

MeDo is not just another frontend generator. for me it is feels like the true "full-stack" development platform, you only need this platform to get your app from zero to one from above and beyond

It is still buggy. It can be slow. Some parts still feel rough for English-speaking users. But the core idea is strong.

Kiro: the good, bad and ugly part in my personal experience

fikuri — Sat, 13 Sep 2025 14:58:39 +0000

As a developer who's worked with various IDEs, AI-coding tools, and agent-assisted workflows, I recently spent some time using Kiro. It bills itself as an agentic IDE that brings "Spec-driven" development into the mainstream. In this post I'll walk through what’s great, what's frustrating, and what downright exposes rough edges from my hands-on experience.

What is Kiro

Before we go into the pros & cons, a quick overview to set the context.

Kiro (by AWS) is an AI-powered IDE built on a VS Code core.
Its standout idea is spec-driven development (SDD). Instead of just vibe coding (talk with an AI to jump in and code), you start by defining requirements, then design, then implementation tasks.
Supports "steering" (steering files: product.md, tech.md, structure.md) to give context so the AI agent has real project context to work with. Kinda like rules to be honest but more transparency since Kiro shows you whats steering that loaded to context.
Hooks / agent hooks: automations or triggers that run on file events etc., to enforce standards, generate docs/tests, etc.

1. Spec

This feature basically gives you three documents requirements.md, design.md, and tasks.md that flow naturally from one another.

requirements.md is a collection of user stories generated from your prompt.
design.md is a technical guideline created using both the requirements and your original prompt, with some extra research to make sure it uses correct technical terms, diagrams, and architectural notes.
tasks.md pulls it all together, breaking the design down into actionable checklists with states like in progress, done, and failed.

The Good

In my month of working with Kiro, the Spec feature stood out as a surprisingly useful thinking partner. It's great at taking a rough prompt and slicing it into different perspectives-whether that-s from a user's point of view, from a developer’s perspective, or even through acceptance criteria. The benefit I felt from this structure was the ability to self-assess my own prompt and refine it into manageable chunks with clear success criteria. Sometimes I'd start with a very broad, messy prompt. Running it through requirements.md gave me a spread of user stories that became a kind of prompt inspiration engine that I could select, refine, or even pivot based on what it generated.
The design.md stage was also a game changer. It translated my vague ideas into more concrete, technical language. There were times when I didn’t know the exact term or pattern I needed, but the design doc filled that gap, often pointing me toward the right flow, architecture type, or even the correct jargon. It wasn't just generating code it was helping me learn more from it.
Finally, the tasks.md output turned that high-level thinking into a neat checklist. What I loved most is how it integrated with my workflow. For example, I could tell it to create a new branch and commits from the requirement, and it would produce proper branch names and git messages without me having to overly explain. When I started the tasks, it automatically followed the flow outlined in the spec. In practice, this meant I could automate my git flow through the spec alone, without hand-holding the AI every step of the way.
Another success case I had with the Spec feature was using it to create a design system, basically a UI template guideline. At first, it was just an experiment, because my app looked like every other vibe-coded project. You can’t just tell Kiro “make it pretty,” but you can be precise in the spec prompt. For example:

"Create a spec for a design system. Scan through the #codebase and transform every component into [your style]."

And it worked like magic. In one run, I transformed a standard shadcn look and feel into a full neobrutalist UI style. All from a single Spec. That moment genuinely impressed me. It felt less like AI throwing random CSS at the wall, and more like having a design system generator built right into my workflow. The neat part? You can even use images as references, and Kiro will generate a surprisingly solid design system spec doc around them.

The Bad

My first frustration with the Spec feature is how rigid the flow is. It only comes in three flavors requirements, design, and tasks. You have to follow them in that order. Let's say I just want a design doc. Nope, I have to generate requirements first. Or maybe I want to jump straight to tasks from my prompt. Again, not possible. I'm forced to walk through the same steps every single time. What frustrated me even more was the pricing model. Apparently, creating a spec is charged as a "vibe" request because it's generated through the chatbox. But… why? Specs are supposed to be structured, not casual chat. This means every time I try to refine or have a conversation about a spec, I’m burning vibe credits. That felt like paying extra just to use the feature the way it’s meant to be used.

The Ugly

The very first time I ran tasks, I noticed how over-eager Kiro was about testing. Unit tests? ✅ Integration tests? ✅ E2E tests? ✅ ✅ ✅. It was like Kiro assumed I was building software for a billion users with an enterprise QA department on standby. Meanwhile, I wasn’t even sure if I had the core feature right, and my vibe credits were burning away on a mountain of tests, half of which didn’t even pass. Instead of helping me move fast, I ended up with this over-engineered jungle of tests, no working feature, and a sinking feeling that the AI was planning for “999 updates from 999 developers” when in reality it was just me, alone, trying to get one feature working. Yes, this is tweakable via steering and that's exactly what I did. Pro tip: if you're not sure what you're building yet, strip out all the tests and optimizations from the design spec. Even if you are sure, limit them as much as possible. Otherwise, you’ll watch your vibe requests evaporate faster than you can say npm run test.

2. Hooks

Hooks in Kiro are basically automations that trigger on file events. They can enforce standards, generate docs, or even keep your tests up to date. Think of them as little invisible helpers running alongside your workflow.

The Good

Hooks shine when they take care of the boring stuff. Generating API docs when I change an endpoint, scaffolding a test file when I add a new module . Those things just happen without me lifting a finger. It really does feel like having a junior dev who quietly cleans up after me, making sure nothing slips through the cracks.

The Bad

The downside is that every hook run costs a full vibe request, no matter how small the automation. If the only available model is Claude Sonnet, I get why it’s expensive, but burning the same credit for a tiny linting fix as for a big multi-file refactor feels… off. I often catch myself hesitating to set up hooks for small, tedious tasks, because the “cost to benefit” just isn’t there.

The Ugly

Here’s where it got frustrating: hooks only trigger if you explicitly save a file or create a new one inside the editor. 🙃 So when I tried to drive automation from outside the IDE, nothing happened. I had a bunch of ideas for how hooks could turbocharge my workflow, but the "automatic" part turned out to be not so automatic. That killed a lot of the excitement for me.

3. Overall Agentic Experience

Kiro calls itself an agentic IDE, and it delivers on that promise in several ways: a chat sidebar, context management, RAG-style indexing of the codebase, terminal execution, and multi-file awareness.

The Good

The context management is excellent, especially with Steering. I found steering a far better approach than static rules or agent.md files. You can create multiple steering files and decide which ones apply to which folders or files, which gives you far more control. And then there’s the main course: the chat sidebar. This is where agentic coding really shines. Powered by Claude Sonnet 4, Kiro can handle long prompts, write huge chunks of code (I’ve seen it generate 2k+ lines in one go), and search context quickly with the #codebase keyword. With a clear, well-structured prompt, it rarely fails. When it works, it feels like coding with a diligent, context-aware partner.

The Bad

But the agent isn’t perfect. Terminal execution, for example, constantly hangs unless I type commands manually. And yes, it still insists on generating tests (sometimes too many). Those are annoyances, but the real headache is pricing. Kiro’s vibe requests sit in a strange middle ground. The free tier is generous (50 per month), but I’ve blown through all of them in a single 2-hour session. Each task the agent works on takes about 5–10 minutes, and with back-and-forth clarification, 20 messages is enough to wipe you out. The pricing feels confusing and opaque: it’s marketed like Windsurf, but tallies up like Cursor. Somehow landing in the worst of both worlds.

The Ugly

If pricing is the "bad" then the ugly part is how vibe requests are consumed by context summarization. Asking Kiro to summarize context burns 1 vibe request. Then re-entering a refined prompt burns another. It feels like the system punishes you for trying to debug or iterate quickly. More than once, I found myself losing momentum. Not because the AI failed, but because I was too busy watching my credits drain away. It’s a real buzzkill when you’re excited to implement a feature and the meter is working against you.

Verdict

Kiro is one of the boldest takes on AI-assisted coding I’ve tried. The Spec feature is structured and surprisingly educational. Hooks are powerful when they work, though they cost too much for small tasks. And the agentic experience is genuinely impressive, but dragged down by confusing pricing and rough edges in automation.

For medium-to-large projects, it feels like a promising glimpse of the future. But for fast-moving, vibe-coded sessions, Kiro’s structure, costs, and quirks can get in the way. It’s not the magic bullet for every dev, but it’s definitely one of the most ambitious steps toward making AI a true coding partner.

I believe more IDEs will soon offer features like planning, documenting, diagnosing, and generating checklists. Right now, Kiro is one of the few that does spec-driven development well, but if it doesn’t refine its approach and fix some of the flaws I’ve highlighted, it risks being left behind as the space matures. The competition is moving fast, and “good at specs” won’t be enough if the overall developer experience feels costly, rigid, or frustrating.