DEV Community: Alvaro Llamojha

Agent-as-a-Service: Comparing Claude Managed Agents and Amazon Bedrock AgentCore

Alvaro Llamojha — Sun, 12 Apr 2026 23:36:06 +0000

Agent-as-a-Service

I've come to realise that building a good and secure agent is not straightforward, it relies on a good harness and good infrastructure. It needs a runtime, isolation boundaries, session handling, recovery logic, credential management, observability, and some workable approach to governance once more than one team starts building them. The scaffolding required to make that agent do real work safely and reliably.

That is a lot of work and a lot of moving pieces, and why should you do it yourself when someone else can handle it for you? This is where Agents as a Service come in.

Anthropic recently announced Claude Managed Agents and AWS had its own solution already Amazon Bedrock AgentCore.

They are both responses to the same problem, but they solve it from different starting assumptions. Anthropic is packaging a managed Claude-native worker runtime. AWS is packaging a modular platform of agent infrastructure services. One is closer to managing the worker itself. The other is closer to managing the factory around the worker.

Claude Managed Agents

Claude Managed Agents is Anthropic’s answer to Agent as a Service. The product is opinionated by design. Instead of exposing a set of low-level infrastructure building blocks and asking users to assemble them, Anthropic gives you a managed runtime for running a Claude-based agent over time.

The important part in here is that Anthropic is taking ownership of the runtime concerns around the agent itself. Session handling, execution flow, the harness around the model, and the relationship between long-running work and the execution environment are treated as part of the managed product.

Architecturally, this is where Anthropic’s approach stands out. The system separates the orchestration layer from the tool execution environment and persistent session state. In practice, that means the session can outlive the specific container doing the work. If execution fails or a container dies, the agent does not have to lose the whole thread of work with it.

This approach reduces the amount of infrastructure a team has to build before the agent becomes useful. You are closer to a working system earlier. It also means you are buying into Anthropic’s way of structuring agent execution. That is the trade-off here. You get speed and a more integrated runtime, but the abstraction is more opinionated and more tightly coupled to the Claude ecosystem.

If your team is already committed to Claude (and only to Claude) and wants the shortest path from prototype to production, that is exactly the appeal.

Amazon Bedrock AgentCore

AWS is not really trying to package the entire agent experience into one tightly integrated harness. Instead, it does what it knows best. It is building a broader system of services around the operational realities of agents. Runtime is part of that system, but it is not the whole story. Around it, AWS has added Memory, Gateway, Identity, Observability, Policy, Browser, Code Interpreter, and Registry.

It assumes that production agent systems have multiple distinct concerns, and those concerns should have separate surfaces, separate controls, and separate service boundaries.

Runtime handles execution. Identity handles authentication and authorization. Gateway helps expose tools and services in a cleaner way, including MCP-oriented patterns. Memory deals with short-term and longer-lived context. Observability and Policy exist because once agents start taking actions, inspection and guardrails stop being optional. Registry exists because once multiple teams start building agents, tools, prompts, and workflows, discovery and governance become real platform problems.

It is worth mentioning that while you can use Amazon Bedrock catalogue of models (including Claude models), you can also bring your own model and integrate it into the runtime. This gives you the flexibility you need in an era where a new model seems to appear every week.

So, while Claude Managed Agents feels like a managed worker runtime, AgentCore feels more like a platform substrate for agent systems. It is less about hiding the moving parts and more about standardizing them.

That makes it a better fit for teams that already think in platform terms, care about explicit boundaries, or need their agent stack to sit naturally inside broader AWS operations.

Pricing reflects the philosophy

In Claude Managed Agents pricing, you pay for model usage, and on top of that Anthropic charges a session-based runtime fee while the agent is actively running. Claude Managed Agents keeps pricing relatively simple: you pay the normal Claude token rates, plus $0.08 per active session-hour while the agent is running, which makes it easier to estimate from the outside because the extra runtime cost is tied to the session itself rather than broken into infrastructure-style units.

Amazon Bedrock AgentCore pricing is more granular and more AWS-like. You pay for model inference separately, and then pay infrastructure-style pricing for Runtime at $0.0895 per vCPU-hour and $0.00945 per GB-hour, with other services such as Gateway and Memory billed by usage as needed.

Which one actually fits better

This is not a winner-takes-all comparison. The better product depends on where you want the abstraction boundary to sit.

If you want the provider to manage the worker, Claude Managed Agents is closer to that model. Anthropic owns more of the harness, the session lifecycle, and the execution flow. That is attractive when speed matters, when you already trust the Claude stack, and when your main goal is to get a capable Claude-based worker into production without building too much surrounding infrastructure yourself.

If you want the provider to manage the factory around the worker, AgentCore is closer to that model. AWS gives you a broader set of services for runtime, memory, identity, gateway, observability, policy, and discovery. That is a better fit for environments where those concerns need to be explicit, separate, and governable.

So the real decision is not whether one product is universally better. The real decision is whether you want a more opinionated managed runtime or a more modular agent platform.

If you want a managed Claude worker runtime, Claude Managed Agents is the cleaner answer.

If you want a modular enterprise platform for agents, AgentCore is the stronger answer.

Conclusion

Managed agent services are becoming important for the same reason managed databases, serverless runtimes, and managed messaging systems became important. Teams do not want to keep rebuilding the substrate around the thing they actually care about.

In the case of agents, that substrate includes execution, isolation, sessions, tools, credentials, observability, memory, policy, identity, and governance. That is the space both Claude Managed Agents and Amazon Bedrock AgentCore are trying to own.

Claude Managed Agents reduces complexity by owning more of the runtime harness itself.

Amazon Bedrock AgentCore reduces complexity by standardizing the surrounding services as a platform.

If you have already tried Claude Managed Agents, AgentCore, or both, let me know how it felt in practice. Share your experience in the comments.

Cómo sacar el máximo partido a Kiro

Alvaro Llamojha — Mon, 16 Mar 2026 22:20:04 +0000

Empecé con Kiro hace unos meses, en octubre de 2025, durante un hackathon llamado Kiroween. Fue básicamente mi punto de partida para empezar a probar Kiro como IDE y entender qué estaba intentando hacer AWS con esta propuesta. Mi objetivo era probar Kiro y ver en qué se diferenciaba de otras herramientas que ya estaba usando.

En aquel entonces tampoco había demasiadas guías sobre Kiro. Así que casi todo lo que hice fue exploratorio: abrir proyectos, probar el vibecoding, entender eso del spec-driven development y ver cómo respondía el IDE.

Con el paso de los meses y metiéndome más en la comunidad de Kiro, empecé a descubrir todo lo que realmente hay detrás del IDE. No es solamente un editor con IA. Hay todo un sistema alrededor de cómo gestionar el contexto de la IA, cómo configurar el comportamiento del IDE y cómo gobernar lo que hace.

Ahí es donde empiezan a aparecer conceptos como:

steerings
hooks
MCPs
powers
agentes
prompts
skills

Si ya estás usando Kiro, o estás pensando en usarlo, y aun no sabes como encajan todas estas piezas, este artículo es para ti.

TLDR: instalar Kiro

Si todavía no tienes Kiro instalado, aquí tienes los enlaces:

Con eso deberías poder tener el IDE funcionando en unos minutos.
A partir de aquí es donde empieza lo interesante.

Steerings

Los Steerings son simplemente archivos Markdown donde defines instrucciones, reglas o contexto que quieres que Kiro tenga en cuenta cuando trabaja en tu proyecto.

No solamente sirven para dar instrucciones. También pueden contener información estructural sobre tu proyecto.

Por ejemplo:

La estructura y organizacion del repositorio
Convenciones de código y nomenclatura
Arquitectura del proyecto
Como generar la documentación

Uno de los casos más comunes es pedirle a Kiro que genere los Foundational Steerings.

Cuando haces esto, Kiro escanea tu proyecto y genera varios archivos dentro del directorio de configuración de Kiro. Normalmente incluyen:

producto
estructura
tech

Todo esto se genera usando el contexto que Kiro detecta en el repositorio. Es un buen punto de partida porque te da una base de documentación que la IA puede usar cuando trabaja en el código.

Steerings que recomiendo usar

Además de los foundational steerings, hay varios tipos que son bastante útiles añadir en proyectos reales.

Por ejemplo:

Reglas de trabajo en el proyecto

Cómo trabaja el equipo en ese repositorio. Esto puede incluir cosas como:

Convenciones de nomenclaturas
Estructura de carpetas
Vision y Mision del projecto

Esto ayuda mucho a que Kiro no empiece a generar cosas que se salgan del estilo del proyecto.

Estilo de documentación

Puedes definir cómo se documenta el código, qué secciones deben aparecer, o cómo se escriben los READMEs.

Convenciones de arquitectura

Si tu proyecto sigue un patrón concreto, hexagonal, event driven, clean architecture, etc., tener eso definido en un steering ayuda bastante a mantener consistencia.

Cuanto más claro le dejes a Kiro cómo funciona tu proyecto, mejores resultados vas a obtener.

Hooks

Los Hooks son otra pieza bastante potente dentro de Kiro. Básicamente son prompts que se ejecutan automáticamente cuando ocurre un evento.

Unos ejemplos de esos eventos son:

Cuando se crea, modifica o elimina un fichero
Al empezar o terminar una tarea
Manualmente

Un ejemplo bastante simple:
Si estás modificando archivos Markdown, puedes tener un hook que:

Ejecute un lint
Formatee el Markdown
Revise enlaces rotos

Otro ejemplo:
Si estás modificando código, podrías tener un hook que genere automáticamente documentación sobre los cambios que se han hecho.

Esto abre la puerta a automatizar bastantes cosas dentro del flujo de desarrollo.

Cómo empezar con hooks

Los hooks tienen distinta maneras de dispararse: hook triggers

Mi recomendación es empezar siempre con hooks manuales.

Primero pruebas qué hacen, verificas que el resultado es el esperado y te aseguras de que no están haciendo nada raro.
Cuando ya estás contento con el resultado entonces sí puedes empezar a automatizarlos.
Recuerda que los hooks lanzan una tarea en Kiro, si tienes muchos hooks automatizados eso puede acarrear un coste elevado de creditos. Esa fue una de las primeras lecciones que aprendi con los hooks.

MCPs

Los MCPs son otra de las piezas importantes dentro de Kiro y de la IA en general.

Para explicarlo de una manera muy sencilla, un MCP es básicamente como una API para que la IA lo use. Los MCPs permiten conectar la IA con servicios externos. Le da acceso a información o herramientas que normalmente no estarían dentro del contexto del proyecto.

Algunos ejemplos bastante comunes:

Cocumentación de AWS
Context7 para documentación técnica
Integración con Atlassian, como Jira o Confluence

Puedes conectar Kiro con documentación, herramientas externas o sistemas internos del equipo y hacer que la IA pueda trabajar con todo eso.

Powers

La parte no tan buena de los MCPs es que añade contexto dentro de la sesión de IA. Y cuantos mas MCPs tengas activados mas contexto va a consumir, causando que te cueste mas las tareas.

Muchas veces no necesitas tener todos los MCPs activos todo el tiempo. Y aquí es donde entran los Kiro Powers.

Los powers permiten encapsular tareas o dominios que se repiten mucho. Includas tareas que usen MCPs.
Imaginate que tienes un MCP de la base de datos Supabase. Pero para esta tarea sabes que no vas a necesitar la base de datos. Si lo encapsulas con un Power, Kiro lo invocaria solo cuando necesites la base de datos, liberandote el contexto que usaria ese MCP cuando no lo uses.

Hace tiempo escribir un articulo sobre la creacion de mi primer Power (esta en Ingles, sorry): Construyendo mi primer Kiro Power - Posthog Observability.

Agentes customizables

A principios de este año, Kiro anuncio los agentes customizables o sub-agentes. Los agentes ya existian dentro de Kiro, esto lo habréis visto si ya habéis hecho el spec-driven development en el IDE o el modo plan con el CLI. Ambos usan agentes que ya están definidos dentro de Kiro, para ejecutar una tipo especifico de tarea.

Los agents tienen una structura y un prompt propio que lo hace comportarse de la manera especificada.

Lo que hacen es que tienen una estructura y un prompt interno en el cual solamente aparece el agente. Tiene ciertas herramientas en las cuales están habilitadas o no. Y pueden tener selecionado un modelo.
Por ejemplo, el agente del plan se comporta como un guia para planificar una tarea dada, te hace preguntas acerca de la tarea y te hace un plan detallado. Este agente tiene la herramienta de escribir ficheros deshabilitada, ya que solamente es un plan el que vas a hacer, no vas a hacer la implementación.

El plan es un agente que ya estaba pre-definido por Kiro. Ahora tú puedes hacer los tuyos propios, lo que significa que puedes llevar esto al siguiente nivel. O cuatro niveles mas alla. Y por que cuatro? porque con los sub-agentes puedes tener cuatro agentes corriendo en paralelo.

Cómo uso yo los agentes customizables

Los agentes que siempre uso son agentes que estén relacionados con lo que estás haciendo en el proyecto como tal.

Por ejemplo, tengo un proyecto que es de TypeScript, pues tengo un agente que es experto en TypeScript. Tiene un prompt especifico de como trabajar como un experto de TypeScript. Y le doy a habilitar tools de write y read.

Consejo de LLMs para planificación y arquitectura

Otro ejemplo que tengo es para tareas de planificación, arquitectura y toma de decisiones.

Normalmente, si le preguntas al mejor modelo que tengas, te puede dar una opción que sea bastante buena, pero lo ideal es que tengas varias opciones, ya que la IA es no-deterministica y puede alucinar.

A la hora de hacer planificación, arquitectura, toma de decisiones, asuntos en los cuales sea más crear un plan o un diseño, y no una implementación, en la vida real te juntas con un equipo, haces una lluvia de ideas y tienes diferentes opiniones por parte del equipo.

¿Cómo llevariamos esto dentro de Kiro? Tienes agentes customizables que tienen un prompt específico, por ejemplo en planificar. Como en los agentes customizables tú puedes decir qué modelo está usando, le puedes dar un modelo distinto para el mismo tipo de agente. Por ejemplo: Opus, Sonnet, Haiku y Auto, cuatro modelos.

A la hora de hacer un plan, le pido a Kiro que use mi Consejo de Agentes en paralelo. Kiro lanza estos cuatro modelos corriendo en paralelo haciéndome un plan independiente cada uno. Una vez terminan, el agente por defecto me compila esos cuatro planes, cogiendo lo mejor de cada uno.

Esto es algo que cambia el modelo de hacer una planificación completamente. Haces un brainstorming de varios modelos y te aseguras de tener siempre lo mejor de lo mejor. A lo mejor un modelo puede alucinar, pero que cuatro alucinen a la vez es más difícil.

Spec-driven development

La parte que me llamó más la atención de Kiro es el spec-driven development que ya estaba incluido dentro del IDE.

Para los desarolladores este no es un concepto del todo nuevo, es parecido a definir un ticket, darle unos requerimientos, sacar el diseño y luego implementar el ticket basado en distintas sub-tareas.

El spec-mode de Kiro te crea unos requerimientos, un diseño y genera una lista de tareas, todo en ficheros markdown, en los cuales tú los puedes revisar y tener contexto de tu aplicación o tu repositorio.

Si os interesa que escriba un articulo mas centrado en Spec-Driven Development, dejadme un comentario con vuestro interes.

Conclusión

En este artículo hemos visto lo que son los Steerings, Hooks, MCPs, Powers y los agentes customizables, y hemos visto por encima el spec-driven development.

Todas estas funcionalidades dentro de Kiro se define como el contexto de la IA. Si habeis escuchado hablar del Context-Driven Development, es este contexto al que se refieren.

Este articulo es el resultado de un aprendizaje que he hecho a lo largo de los meses. Y el aprendizaje es continuo, me sigo encontrando nuevas funcionalidades, como por ejemplo los skills, que no los he mencionado, pero es algo que también está incluido dentro de Kiro y es se han hecho muy famosos recientemente.

Si no estás usando Kiro, te recomendaría que lo pruebes, tanto el IDE como por la línea de comandos, el CLI, y que pruebes el spec-driven development.

Y si te interesa saber mas sobre Kiro, el Context-Driven Development y de Spec-Driven Development, o quieres comentar tu experiencia con Kiro, no dudes en contáctarme o escríbelo en los comentarios.

Running Kiro CLI from a Raspberry Pi 400

Alvaro Llamojha — Thu, 15 Jan 2026 14:32:35 +0000

A few years ago, I got a Raspberry Pi 400 as a birthday present. I looked up projects, ideas, cool builds, but nothing really grabbed me. So it went back in the box.

Recently, I’ve been building with Kiro for a couple of months now, and one day I found the Raspberry Pi and the idea came to me.

What if I could run Kiro CLI from the Raspberry Pi?

Raspberry Pi setup

I had to buy a microSD and a power cord first before I could get hands on. For the OS on the Micro SD, I used Raspberry Pi Imager selected the default Raspberry Pi OS (Debian-based), went through the configuration, plugged in the Micro SD and connected the Pi. After a couple of minutes, I was able to SSH in.

SSH in (if it's in your local network):

ssh user@<your-pi-hostname-or-ip>

Then the usual housekeeping + tools I knew I’d need for the Kiro install:

# update the Pi
sudo apt update && sudo apt upgrade -y

# dev box basics (I wanted git, and I installed Node because I plan to build a small wrapper later)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
sudo apt install -y git

One thing that becomes important later is that this machine is ARM64:

uname -m
# aarch64 - you can also see this when doing SSH 
ldd --version
# ldd (Debian GLIBC 2.41-12+rpt1) 2.41

Installing Kiro CLI and hitting SIGILL

Once everything was ready, I went straight to the official Kiro CLI install docs and followed the Linux ARM (aarch64) instructions:

Kiro CLI — Linux ARM (aarch64)

I downloaded it and ran the installer:

curl --proto '=https' --tlsv1.2 -sSf 'https://desktop-release.q.us-east-1.amazonaws.com/latest/kirocli-aarch64-linux.zip' -o 'kirocli.zip'
unzip kirocli.zip
bash ./kirocli/install.sh

The install itself looked fine. The binary was in place. Edit the Path in the .bashrc to include the path for the kiro-cli bin:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

And then I ran:

kiro-cli

…and got:

Illegal instruction (SIGILL)

I knew then that this may not be straightforward, and I may had to refresh my processor architecture knowledge. Just in case, I've tried re-installing, rebooting, trying multiple times but still was the same issue.

The fix: use the ARM64 musl build

After going back to the docs (again), I noticed the musl option:

Kiro CLI — Linux ARM (aarch64) with musl

The docs frame it mostly around glibc version. My glibc was new enough (2.41), so I assumed the standard build was the right one.

But at that point, I’d already tried the standard route and it was consistently crashing with SIGILL, so I figured: let’s just try the musl build.

I installed the aarch64 musl version… and that was it. kiro-cli ran successfully.

curl --proto '=https' --tlsv1.2 -sSf 'https://desktop-release.q.us-east-1.amazonaws.com/latest/kirocli-aarch64-linux-musl.zip' -o 'kirocli.zip'
unzip kirocli.zip 
./kirocli/install.sh
kiro-cli

Login (headless, over SSH)

Once the CLI actually ran, the login flow was straightforward.
It printed a login URL in the terminal. I copied it, pasted it into my laptop browser, logged in (I used GitHub), went back to the SSH session, and Kiro CLI was authenticated on the Pi.

Wrap-up

So yes: you can run Kiro CLI on a Raspberry Pi 400. I've tried running simple and complex tasks, and both worked fine.

It took me about an hour end-to-end, including the time lost to the SIGILL crash. The key detail was simply using the ARM64 musl build from the docs instead of the standard one.

What I’m doing next

Now that it’s running, I want to push this a bit further.

I want that PM approach for working with Kiro. A workflows that looks like: I create and curate tickets like a PM, and Kiro acts as the dev taking care of the code implementation (running from the Raspberry Pi).

Do you have a Raspberry Pi and want to try this? What has been your experience with Kiro-CLI? Share it with us in the comments.

Stop Vibecoding AI Monoliths

Alvaro Llamojha — Mon, 05 Jan 2026 21:59:52 +0000

Vibing a Monolith

I’ve been doing a bit of vibe coding over the last few months. I’ve been jumping into forums, watching what other people are building, and I keep seeing the same pattern.

People are building big monoliths with AI. At the start it feels amazing. You move fast, you ship features, the AI is “in the zone”. But then the context keeps growing and growing, and eventually you hit a point where you can’t keep working with the AI anymore. The repo turns into spaghetti, the AI starts missing important details, and you end up needing to ask someone else for help because the project has become a monster.

And I see the exact same thing in my own projects. There’s always a moment where I realize I need a refactor. I need to structure things properly, index things properly, define architecture boundaries, because otherwise the AI is going to miss so much of the context of my application that it becomes actively unhelpful.

Microservices & Monorepo

In my time as a DevOps engineer, working with big companies and startups, I kept coming across something that changed how I thought about scaling codebases: the monorepo.

A monorepo is a single repository where all your applications live. You split it into microservices or micro-frontends, but everything still lives in one place. It’s basically a way to move away from a monolith while keeping a single source of truth.

I don’t want to go deep into what a monorepo is here. You can google it or ask your favorite AI. The important part for this post is how you split your application into microservices and micro-frontends in a way that can actually be managed effectively.

Because the real goal isn’t monorepo as a buzzword. The goal is to stop feeding your AI one massive, tangled blob of context.

Instead of one monolith where the AI has to understand everything at once, you split the system into smaller chunks. Now your AI can work with small, focused context, and each part stays more independent from the rest.

In theory, this should reduce the AI losing focus problem. Fewer wild hallucinations, fewer “it forgot how the auth works”, fewer changes that accidentally break unrelated stuff.

It also enables parallel work. Instead of one monolith that you just keep vibe coding into, you can have multiple sub-agents working on different parts of the application at the same time without constantly conflicting. Frontend, backend, UX flows, infra, whatever.

Monorepo reality check

It sounds simple, right?

Just switch to microservices or micro-frontends, put everything into a single repository, and that’s it.

But no, it’s not that easy.

Monorepos can be a real challenge to handle. There are ways to make it easier, but the tooling complexity is what makes it effort. This is exactly why I probably wouldn’t recommend this approach for a quick MVP.

If you’re trying to launch something fast and you genuinely don’t know if it’s going to live beyond a few weeks, don’t over-engineer it.

But once you have a product you actually want to grow, you know you’re going to add multiple features, you know it’s going to expand, then yes, I’d fully recommend moving to a monorepo approach.

From a Monolith to a Monorepo

I think the best way to approach a monorepo when you already have a monolith is to start splitting your application into different microservices or micro-frontends. That is the first approach.

You need to keep two things in consideration.

First, each of them should be independent from each other. You shouldn’t have any dependencies if possible. That will enable you to keep working on one feature without breaking the others.

Second, backwards compatibility. You can’t just rip the monolith apart and pray. You need a plan so new services can coexist while old functionality still works.

Then there’s deployments. Splitting a system means you now have multiple deployable units, which is great, but you can easily create a CI/CD nightmare if you don’t manage it properly.

There are tools to do this. I would recommend Turborepo for orchestrating tasks and caching across the repo so you are not rebuilding and retesting the world every time you touch one service.

So...Is It Worth It?

Having said all this, is this worth your time?

I would say 100% yes, if your project is going to live long enough to justify the setup cost.

I think in 2026 we’re going to see a move from vibe coding into a more structured AI coding workflow. Spec-driven development, planning, tickets, sprints, basically the stuff we already did as software engineers, because it works.

Instead of evolving one giant monolith forever, we’re going to start evolving into microservices, micro-frontends, and monorepos.

I’m 100% sure there are people working on tools to handle this. I think 2026 is going to be the year where this path becomes much more normal.

First we build big monoliths and ship by vibing with no structure. Then we introduce tickets and sprint planning, which is basically spec-driven development. Now we are hitting the AI version of that same evolution. We need boundaries and context control, and a practical way to do that is to split the system and treat each part as its own focused unit.

If you’re building with AI and you’re building monoliths, have you run into any of these issues? Have you considered moving to a monorepo structure? And if you’re already doing monorepos with AI, what’s been your experience?

Building my first Kiro Power: PostHog Observability

Alvaro Llamojha — Thu, 18 Dec 2025 01:14:24 +0000

When I first explored Kiro Powers, the Datadog Power immediately stood out. I'm a DevOps Engineer focused on Observability and Monitoring. I have experience with Datadog, New Relic and PostHog, so this piqued my attention. I was also participating in a hackathon that used Datadog, so I got to try that Power in a real workflow—not just as a demo. That experience triggered a simple thought: I also use PostHog heavily in another project, and I couldn’t find a PostHog Power. Since PostHog already has an MCP server, it felt like a perfect candidate for my first Power project.

TLDR; You can try my first Kiro Power for Posthog: posthog-kiro-power

What are Kiro Powers?

Kiro Powers are on-demand capability bundles for your AI agent. Instead of always loading every tool and every set of best practices into context, a Power is activated when it’s relevant—so the agent can load the right context and tools at the right time.

A Power typically packages:

MCP servers / tool connections (so the agent can interact with real systems)
Steering / guidance files (best practices and workflow patterns)
Optional hooks (validation or automation depending on the Power)

That “load on demand” part is the key idea for me. Powers are meant to keep the agent focused without overwhelming it with irrelevant context.

If you want the official docs: Kiro Powers

Building the Power with Kiro's Build a Power

The first step for me was using the Power that helps you Build a Power. This power guides you through the structure and basic setup.

My approach was simple:

I told Kiro I wanted to create a Power for PostHog MCP
I provided the PostHog MCP URL/docs as context (link below)
I also mentioned I already had the Datadog Observability Power installed, and asked if we could use it as a template since both are observability-oriented

Normally, I use spec-driven development with Kiro. But in this case, I didn’t. This was small and specific, and I knew exactly what I wanted—so I treated it more like a guided conversation than a formal spec.

“An unexpected error occurred, please retry.”

There’s a common Kiro error that people mention a lot:

“An unexpected error occurred, please retry.”

I’d seen it discussed in the Discord community, but I’d never hit it myself until I installed my own Power.

Because this was my first Power, I initially assumed I’d made a mistake in the implementation or missed a required configuration step. I ended up going down a rabbit hole trying to figure out what was wrong.

In the end, it was much simpler: it was a misconfiguration / bad state in the Power setup. What fixed it was:

Uninstalling a couple of Powers I wasn’t using
Reinstalling cleanly
Re-trying the install
Click on 'Try this Power'

Installing it, testing it, and open sourcing it

For a testing installation, I decided to import power from a folder and it worked fine. I just have to add my PostHog API key and it was ready to go.

Testing was straightforward because my application was already wired up with PostHog. Once the Power was installed, I could ask Kiro to inspect what I already had in PostHog dashboards, existing insights, and the general shape of my data. It actually came back and propose to use Feature Flags with PostHog, which is a really good suggestion, as I am using feature flags in a very basic way.

I also asked Kiro to look at my PostHog setup and propose a plan for adding LLM monitoring, because I’m currently missing that. It gave me a concrete direction, and implementing that is the next feature I want to add after writing this blog post.

This Kiro Power is key as I can focus my development to be more data-driven by just asking Kiro to look into my data on PostHog and use it as context or new features.

How to try it?

In order to install it, you just need the GitHub URL https://github.com/llamojha/posthog-kiro-power/tree/main/powers/posthog, plus your PostHog API key in the MCP config.

Lessons learned and what’s next

Initially, it felt a bit intimidating having to 'build a power'. This all changed once I tried. Having the 'Build a Power' power to help me and guide me building helped a lot. It felt like a conversation with Kiro and it was very straightforward. I fully recommend you try to build a Power even if it's just to find out how it works.

If you already know the tool you want to wrap—an MCP server, a CLI, or a workflow you use often—then creating a Power is mostly about packaging it cleanly and making it easy for the agent to load when relevant.

Next steps

This was a fun and smooth experience so I'm eager to keep building. I have a couple of ideas on what to do next:

I’ve used New Relic as well, so I’m looking into the New Relic MCP side and creating a New Relic Power
I also want to build a more complex Power. Bundle up Hooks and Steerings and test how far the Power concept can go in a larger workflow.

If someone from PostHog is reading this, please feel free to copy my work and make an official PostHog Kiro Power <3.

What was your experience with Kiro Powers? Have you built your own? Share your experience in the comments or join the Kiro Discord

No Vibe No Code: Bootstrapping Ideas

Alvaro Llamojha — Wed, 03 Dec 2025 18:34:20 +0000

1. The Core Problem: Too Many Ideas, Not Enough Finished Things

I always have loads of ideas for projects. Often I start them, and most of the time I don't even finish them. My problem isn’t creativity. The problem is that most of those ideas never make it past the “oh, that would be cool” stage.

So I end up with this growing backlog of “things I could build someday” and no clear way to:

store them
compare them
or decide which one actually deserves my time

I saw an opportunity in this Kiroween Hackathon to build an app where I could:

dump all my ideas
validate them against the hackathon (or any) criteria
and then actually move them towards something shippable

And so No Vibe No Code was created.

2. What is No Vibe No Code?

The core concept is from idea to vibecoding (or spec-coding in Kiro's case)

At a high level, No Vibe No Code is A place to bootstrap your ideas and get them into a Kiro-ready, development-ready shape as quickly as possible.

Here is an example of the user flow:

Step 1: Get an idea (or generate one)

Write your own idea – maybe something that’s been sitting in your notes app for months

Use Dr. Frankenstein, this is basically a chaotic idea generator (inspired by the Kiroween category)

I personally love Dr. Frankenstein feature on No Vibe No Code because it randomly picks a few popular tech companies or a few AWS services -> Smashes them together -> And creates some weird hybrid idea that actually fits nicely for hackathon-style creativity.

Step 2: Validate your idea

Ok, so I have 100s of ideas, but how do I know if they are good ideas? How do I know if they are feasible? Are they even good ideas for this hackathon?

For that, we've added a 'Kiroween Analyser'. This feature will generate a report against the hackathon criteria and score it accordingly.

This validator opens a possibility to add multiple validators that can serve to analyse ideas against specific criteria like hackathons, games, small side-projects, the possibilities are endless. In this case, we were focused on Kiroween.

Step 3: Generate some core documents

Once you have an idea (manual or Frankenstein’ed), No Vibe No Code helps you generate the core docs you need to support your building:

A PRD – to clarify the problem and the user
A technical design doc - to describe how the solution will work at a feature level
An architecture design - to map the high-level components, services, and boundaries (more tech-oriented)
A roadmap for an MVP – to define the smallest version worth shipping and how to get there

The goal is: your idea stops being just a sentence and starts becoming a structured concept.

Step 4: Power up Kiro

Once those docs exist, you can export to kiro:

No Vibe No Code will then:

Generate steering rules for Kiro
Generate spec templates aligned with your roadmap

So instead of opening Kiro with a blank chat and writing “Help me build X,” you:

Walk in with a defined idea
Have a PRD, design, architecture, and MVP roadmap
Already have steering rules and spec scaffolding ready to go

From there, you can just start kicking off specs and building.

That’s the main idea of No Vibe No Code:

from raw idea → structured docs → Kiro-ready boilerplate, with as little friction as possible.

Demo

3. Building Before Kiro

Because of my background as a platform / DevOps engineer, I naturally thought in terms of structure: roadmaps, milestones, and tasks.

So my workflow looked roughly like this:

Create a PRD or Readme with context for the project -> Create a roadmap with milestones to achieve and divided by tasks -> Ask the AI to implement each task based on those documents.

At the time, I didn’t even realise there was a name for what I was doing!!

So when I eventually discovered Kiro and saw its spec-driven development focus, I had this moment of:

“Hold on your horses… they’re doing exactly what I’ve been trying to do, just… better.”

That’s when I decided to go all in on Kiro.

4. My Journey with Kiro

When I first set up Kiro for this project, I went with the default, raw setup:

No custom steering rules
No MCPs
No hooks

Obviously, this wasn't ideal as I was missing a lot of features.

Discovering Kiro’s Best Practices

In my first week, I joined the Kiro Discord and started reading through posts and getting to know best practices and how other people were building with Kiro.

Around that time, Kiro also released the MCP Server directory, which made it much easier to install MCPs.

I also discovered that Kiro could auto-generate some basic steering files for things like: tech, structure and product.

Taking it to the next Level

From there, my Kiro setup evolved gradually:

Started adding steering rules and adapting them to my setup.
Wired in some useful MCPs (context7, github, supabase).
Using rules for inclusion on steering and triggers on hooks

Over days and weeks, this went from:

“Just raw Kiro, let’s see what happens.”

to:

“I have a small ecosystem here that actually understands how I like to work.”

Models - From autopilot to Opus 4.5

When I started this project, I kicked things off using Kiro Auto model. I wasn't sure if I was going to burn all my credits with the other models, and I didn't know the actual difference between those models. Default seems like a good plan.

For a big chunk of the journey, Auto was genuinely fine. Sometimes it produced bugs or weird decisions but nothing too critical.

Later on, when I saw I still had credits left, I decided to experiment a bit.

Sonnet 4.5

I tried Sonnet 4.5 for a few specs. Overall, it felt the same as Auto model bit more expensive. I still had to babysit some results and debug like crazy.

But then... There was an announcement!

Opus 4.5

Opus 4.5 landed, at x2.2 cost and with 500 credits left for the month, I decided to go all in with Opus for the last few specs.

That’s where I actually felt the difference. The code quality was noticeably higher, and there were fewer bugs (still some, but manageable).

Yes, it’s more expensive, but for the final specs, where I really cared about quality and didn’t want to waste time chasing edge cases, it felt absolutely worth it (I ended the month with 50 credits left)

Adding Property-Based Testing to the mix

Kiro announced Property-based testing halfway through Kiroween. It was such a good concept that I couldn't resist spending a spec on this.

After implementing it, I felt more comfortable trusting AI-generated code. It aligned well with the whole “let’s automate the boring but important parts” mindset. It creates a pretty solid safety net.

7. What I’d Do Differently (And how No Vibe No Code can help)

Let's recap on my journey:

Started with a raw Kiro setup (no steering, no MCPs, no hooks).
Added things gradually, as I discovered them.
Let my IDE configuration drift and change over time.
Tweaked the ecosystem spec by spec.

That worked, but it could have been a smoother experience. What I’d prefer instead is a solid boilerplate from day one: sensible project structure, steering rules setup, and documentation to get ready to spec.

And that’s exactly the point of No Vibe No Code. I want a place where I can show up with an idea, press a few buttons, and end up with:

project docs generated.
clear path from idea → MVP.
boilerplate Kiro ready.

If there’s no vibe with the idea and documents, there’s no code

Share your Work and Ideas

You can try it out now!! Go to No Vibe No Code

You can spin up your own No Vibe No Code too!! Open Source GitHub repo: (https://github.com/llamojha/no-vibe-no-code-kiroween)

If you end up playing with this No Vibe No Code workflow, I’d genuinely love to see what you come up with.

In particular:

What Dr. Frankenstein ideas did you generate?
Which ones actually made it past the “haha that’s funny” stage and into a real PRD / design / roadmap?
How was your experience going from raw idea → Kiro → working thing?
If you think I should rebrand to No Vibe No Spec

Let’s get building!!

DEV Community: Alvaro Llamojha

Agent-as-a-Service: Comparing Claude Managed Agents and Amazon Bedrock AgentCore

Agent-as-a-Service

Claude Managed Agents

Amazon Bedrock AgentCore

Pricing reflects the philosophy

Which one actually fits better

Conclusion

Cómo sacar el máximo partido a Kiro

TLDR: instalar Kiro

Steerings

Steerings que recomiendo usar

Hooks

Cómo empezar con hooks

MCPs

Powers

Agentes customizables

Cómo uso yo los agentes customizables

Consejo de LLMs para planificación y arquitectura

Spec-driven development

Conclusión

Running Kiro CLI from a Raspberry Pi 400

Raspberry Pi setup

Installing Kiro CLI and hitting SIGILL

The fix: use the ARM64 musl build

Login (headless, over SSH)

Wrap-up

What I’m doing next

Stop Vibecoding AI Monoliths

Vibing a Monolith

Microservices & Monorepo

Monorepo reality check

From a Monolith to a Monorepo

So...Is It Worth It?

Building my first Kiro Power: PostHog Observability

What are Kiro Powers?

Building the Power with Kiro's Build a Power

“An unexpected error occurred, please retry.”

Installing it, testing it, and open sourcing it

How to try it?

Lessons learned and what’s next

Next steps

Links

No Vibe No Code: Bootstrapping Ideas

1. The Core Problem: Too Many Ideas, Not Enough Finished Things

2. What is No Vibe No Code?

Step 1: Get an idea (or generate one)

Step 2: Validate your idea

Step 3: Generate some core documents

Step 4: Power up Kiro

Demo

3. Building Before Kiro

4. My Journey with Kiro

Discovering Kiro’s Best Practices

Taking it to the next Level

Models - From autopilot to Opus 4.5

Sonnet 4.5

Opus 4.5

Adding Property-Based Testing to the mix

7. What I’d Do Differently (And how No Vibe No Code can help)

Share your Work and Ideas