Forem: kirodotdev

I Built an Interactive Learning Engine Inside an AI Chat App — Here's Every Technical Decision

Asad marcus — Fri, 24 Apr 2026 15:41:05 +0000

There's a problem that every AI chat app eventually runs into that nobody really talks about openly: text is a terrible medium for teaching certain things. Not because the AI gives bad answers, but because the format itself gets in the way.

Ask an AI to explain how a sine wave changes with frequency and it'll give you a mathematically correct, well-worded paragraph. You'll read it, nod, and still not feel what happens when frequency doubles. You need to see the wave. You need to drag a slider and watch it compress in real time. You need the concept to be live in front of you.

I built AimiChat as my AI web app, and this problem was bothering me enough that I spent a few weeks building a full interactive learning visualization engine directly into the chat interface. The AI doesn't just answer questions anymore. It generates live, interactive widgets embedded inside its responses. Adjustable math graphs, step-through code walkthroughs, physics simulations, inline quizzes, the whole thing.

I built this using Kiro as my AI IDE, and honestly the experience taught me a lot about what that kind of tooling is actually good for at a deeper level. This post covers the full technical architecture, the specific problems I ran into and how I solved them, and honest detail about where Kiro genuinely changed how I worked versus where I still had to drive things myself.

If you're building anything with streaming AI responses, interactive DOM components, or you're just curious about Kiro and what it actually means to use an agentic IDE in practice, I hope this is useful.

Understanding the Problem Space First

Before getting into implementation, it's worth understanding why this is hard. The difficulty isn't in building a graph renderer. Canvas graphs are straightforward. The difficulty is the intersection of three things happening at the same time.

The AI returns text. Every AI model, regardless of provider, returns a stream of tokens that your frontend assembles into a string. Your markdown parser turns that string into HTML. There's no native concept of "and also render a live React component here."

Responses stream in progressively. The response doesn't arrive all at once. Tokens come in over one to ten seconds and you're updating the DOM incrementally so the user sees text appearing in real time. This means your parser runs many times on the same message, each time on a slightly longer version of the text.

Interactive widgets have lifecycle requirements. A Canvas graph needs to mount once, attach event listeners once, and stay mounted. If anything resets innerHTML on its parent, which streaming forces you to do constantly, the widget is destroyed and its listeners are orphaned.

These three constraints create a genuine architectural puzzle. You can't mount widgets during streaming. You can't wait until streaming is done to parse because the user would see a blank screen. And you need the widget configs to survive DOM resets. Every approach that seems obvious breaks on one of these three.

The solution I arrived at is a two-phase registry architecture. But understanding why simpler approaches fail is important before understanding why this one works.

Kiro: What It Actually Is and How I Used It

Since this is a community post about building with Kiro, I want to give you an honest picture of what it is rather than just repeating the marketing summary.

Kiro is an AI-powered IDE built on VS Code, developed by AWS. The surface-level description is "it has AI assistance built in" but that really undersells what makes it meaningfully different from GitHub Copilot or cursor-style tab completion.

The key concept in Kiro is specs. When you start a significant piece of work, Kiro generates a spec document: a structured breakdown of what you're building, broken into requirements, then tasks, then implementation steps. This spec lives in your project and Kiro uses it to maintain context across an entire feature's development, not just the current file.

For this project I wrote a prompt describing the interactive learning system. What types of visualizations I wanted, how they'd integrate with the chat streaming system, the security constraints around eval, the JSON contract between the AI model and the renderer. Kiro turned that into a spec with tasks like "implement recursive descent math parser," "build two-phase streaming architecture," "implement graph renderer with parameter sliders," and "add JSON repair pipeline for AI output." Each task had acceptance criteria.

What this gave me practically: when I was three widget types into building eleven, and I asked Kiro to help me implement the simulation renderer, it understood the full contract from the spec without me re-explaining it. That's the real value. Not tab completion. Persistent project-level context that makes each individual task faster because you're not starting from zero each time.

Kiro also has agent hooks, which are automated actions that trigger on file save, test run, or other events. I set up a hook that ran a basic smoke test on the widget registry whenever I added a new renderer type, catching mismatches between the type string I registered and the function I exported. Small thing, but it caught two bugs before I found them manually.

The other Kiro concept worth knowing is steering documents. These are markdown files you put in your project that give Kiro persistent instructions about your codebase conventions. Things like "always use the escapeHtml() utility instead of setting innerHTML directly with user data," or "responsive canvas sizing always uses devicePixelRatio for retina support." Kiro reads these before generating code. It meant I stopped seeing the same category of mistake in generated code after I documented my patterns once.

Designing the Widget Protocol

The first real design decision was how the AI model communicates what widget to render and with what data. I settled on custom fenced code blocks with an interactive- prefix as the language identifier.

A normal markdown code block looks like this in the raw text:

// Simplified streaming loop
eventSource.onmessage = (event) => {
    accumulatedText += event.data;
    const html = markdownToHtml(accumulatedText);
    messageDiv.innerHTML = html; // This runs 50-200 times per message
};

Every time innerHTML is assigned, the entire subtree is torn down and rebuilt from scratch. Any Canvas elements lose their contexts. Any event listeners are orphaned. Any widget state is gone. If you mounted a graph on the 30th token, it's destroyed by the 31st.

The instinct is to try to be smart about partial updates, only re-rendering the parts that changed and preserving existing widgets. This sounds reasonable but breaks quickly because streaming text can change earlier parts of the message and tracking which DOM nodes correspond to which parts of the markdown is genuinely complex.

Phase 1: Register, don't render

The solution is to make the markdown parsing phase completely inert with respect to widgets. When the regex finds an interactive-* code block, it does two things and only two things.

First, it stores the config in an external Map keyed by a stable hash:

// The registry lives outside the DOM, so innerHTML resets can't touch it
const _ilBlockRegistry = new Map();

function _hashCode(str) {
    let hash = 0;
    for (let i = 0; i < str.length; i++) {
        hash = ((hash << 5) - hash + str.charCodeAt(i)) | 0;
    }
    return 'il-' + Math.abs(hash).toString(36);
}

The hash takes both the widget type and the JSON string as input, so the same widget config always generates the same ID regardless of how many times streaming re-parses the message. This is the key insight: content-addressed IDs survive DOM resets because they're deterministic.

Second, it returns a placeholder div instead of any real widget markup:

function processInteractiveBlocks(html) {
    return html.replace(
        /<pre><code[^>]*class="[^"]*language-(interactive-[\w][\w-]*)[^"]*"[^>]*>([\s\S]*?)<\/code><\/pre>/g,
        (match, type, encodedJson) => {
            if (!INTERACTIVE_TYPES[type]) return match;

            let jsonStr = encodedJson
                .replace(/<[^>]+>/g, '')
                .replace(/&lt;/g, '<')
                .replace(/&gt;/g, '>')
                .replace(/&amp;/g, '&')
                .replace(/&quot;/g, '"')
                .replace(/&#39;/g, "'");

            const id = _hashCode(type + jsonStr);
            _ilBlockRegistry.set(id, { type, jsonStr });

            return `<div id="${id}" class="il-placeholder">
                <div class="il-loading-spinner"></div>
                Loading visualization...
            </div>`;
        }
    );
}

The placeholder is just a div with an id and a loading spinner. Recreating it on every stream tick is fine because it has no state, no listeners, no canvas context. It's just markup.

Phase 2: Mount once, after streaming ends

The rendering phase runs exactly once, triggered by your streaming completion event:

eventSource.addEventListener('done', () => {
    messageDiv.innerHTML = markdownToHtml(accumulatedText);
    renderInteractiveWidgets(messageDiv);
});

function renderInteractiveWidgets(container) {
    const placeholders = container.querySelectorAll('.il-placeholder');

    placeholders.forEach(el => {
        const config = _ilBlockRegistry.get(el.id);
        if (!config) return;

        try {
            const parsed = JSON.parse(config.jsonStr);
            el.innerHTML = '';
            el.classList.replace('il-placeholder', 'il-rendered');
            INTERACTIVE_TYPES[config.type](el, parsed);
        } catch (err) {
            el.innerHTML = `
                <div class="il-error">
                    <div class="il-error-title">Could not render visualization</div>
                    <details>
                        <summary>Show raw data</summary>
                        <pre>${escapeHtml(config.jsonStr)}</pre>
                    </details>
                </div>
            `;
            el.classList.remove('il-placeholder');
        }
    });
}

The renderer gets a clean, stable div that nothing will ever reset. It can mount canvas elements, attach resize observers, start animation loops, all of it safe.

Building a Safe Math Expression Evaluator

The graph renderer needs to evaluate user-parameterized math expressions like sin(a * x) + b * cos(x / 2) in real time as sliders move. The obvious approach is eval(). The obvious approach is also a serious security risk in a web app where the expression comes from an AI model responding to arbitrary user input.

The correct approach is a recursive descent parser. This is a well-studied technique in compiler design and it's worth understanding even outside this specific context.

How recursive descent parsing works

A recursive descent parser is built around the grammar of your expression language. Every grammar rule becomes a function. The functions call each other recursively, and the call depth at any point mirrors the nesting depth of the expression.

For a math expression language, the grammar looks like this:

expression  := term (('+' | '-') term)*
term        := power (('*' | '/') power)*
power       := unary ('^' unary)?
unary       := '-' primary | '+' primary | primary
primary     := number | constant | function_call | '(' expression ')'

The ordering here encodes operator precedence. Addition and subtraction are at the top level, so they're evaluated last. Multiplication and division are nested one level deeper, so they bind more tightly. Exponentiation is deeper still. This is why 2 + 3 * 4 evaluates to 14 and not 20. The term() call for 3 * 4 completes before the addition at the expression() level sees either operand.

Here's the tokenizer first:

tokenize(expr) {
    const tokens = [];
    let i = 0;
    while (i < expr.length) {
        if (/\s/.test(expr[i])) { i++; continue; }

        if (/[0-9.]/.test(expr[i])) {
            let num = '';
            while (i < expr.length && /[0-9.eE]/.test(expr[i])) {
                num += expr[i++];
            }
            tokens.push({ type: 'num', val: parseFloat(num) });
        }
        else if (/[a-zA-Z_]/.test(expr[i])) {
            let id = '';
            while (i < expr.length && /[a-zA-Z0-9_]/.test(expr[i])) {
                id += expr[i++];
            }
            tokens.push({ type: 'id', val: id });
        }
        else {
            tokens.push({ type: 'op', val: expr[i++] });
        }
    }
    return tokens;
}

And the parser, where each grammar rule is a function:

parse(tokens, vars = {}) {
    let pos = 0;
    const peek = () => tokens[pos];
    const next = () => tokens[pos++];

    const expression = () => {
        let left = term();
        while (peek() && (peek().val === '+' || peek().val === '-')) {
            const op = next().val;
            const right = term();
            left = op === '+' ? left + right : left - right;
        }
        return left;
    };

    const term = () => {
        let left = power();
        while (peek() && (peek().val === '*' || peek().val === '/')) {
            const op = next().val;
            const right = power();
            left = op === '*' ? left * right : left / right;
        }
        return left;
    };

    const power = () => {
        let base = unary();
        if (peek() && peek().val === '^') {
            next();
            base = Math.pow(base, power());
        }
        return base;
    };

    const unary = () => {
        if (peek() && peek().val === '-') { next(); return -primary(); }
        if (peek() && peek().val === '+') { next(); return primary(); }
        return primary();
    };

    const primary = () => {
        const t = peek();
        if (!t) return 0;

        if (t.type === 'num') { next(); return t.val; }

        if (t.type === 'id') {
            next();
            if (MathEval.CONSTS[t.val] !== undefined) return MathEval.CONSTS[t.val];
            if (MathEval.FUNCS[t.val] && peek()?.val === '(') {
                next();
                const args = [expression()];
                while (peek()?.val === ',') { next(); args.push(expression()); }
                if (peek()?.val === ')') next();
                return MathEval.FUNCS[t.val](...args);
            }
            if (vars[t.val] !== undefined) return vars[t.val];
            return 0;
        }

        if (t.val === '(') {
            next();
            const v = expression();
            if (peek()?.val === ')') next();
            return v;
        }

        next();
        return 0;
    };

    return expression();
}

The security guarantee here is total. This code only ever calls functions from the FUNCS whitelist and reads values from the CONSTS and vars objects. There's no code path that executes arbitrary JavaScript.

Kiro helped me get the recursive structure scaffolded quickly. What I had to work through myself was the right-associativity for exponentiation, which is easy to get wrong. If you write power() as left-recursive like term(), you get left-associativity and 2^3^2 gives the wrong answer. I also had to sort out the ordering of checks in primary() because you need to check CONSTS before checking FUNCS since E as a constant and exp as a function share a namespace, and a bug here gives silent wrong answers with no error thrown.

Handling AI-Generated JSON That Isn't Quite Valid

Here's a real-world problem that doesn't appear in blog posts about AI systems often enough. The model's output is almost right, but not quite, in ways that vary by model version, temperature setting, and prompt phrasing.

The specific failure modes I ran into:

Trailing commas. The model sometimes emits { "a": 1, "b": 2, } which is valid JavaScript but not JSON. JSON.parse throws.

Single quotes. Occasionally { 'title': 'Sine Wave' } instead of double quotes.

Colons corrupted to >. This one is subtle. When the markdown parser applies HTML encoding, : can become > in certain highlight span wrappers, giving you "title">"Sine Wave" instead of "title":"Sine Wave".

Highlight spans inside the JSON. Syntax highlighters wrap parts of code blocks in <span> elements for coloring. The JSON content has spans injected into it before you ever see it.

The repair pipeline addresses these in a specific order that matters:

// Strip syntax highlight spans BEFORE any entity decoding.
let jsonStr = encodedJson.replace(/<[^>]+>/g, '');

// Decode HTML entities
jsonStr = jsonStr
    .replace(/&lt;/g, '<').replace(/&gt;/g, '>')
    .replace(/&amp;/g, '&').replace(/&quot;/g, '"')
    .replace(/&#39;/g, "'");

// Collapse whitespace for non-canvas types
if (type !== 'interactive-canvas') {
    jsonStr = jsonStr.trim().replace(/\n\s*/g, ' ');
}

// Remove trailing commas
jsonStr = jsonStr.replace(/,\s*([}\]])/g, '$1');

// Fix > corruption
jsonStr = jsonStr
    .replace(/"(\w+)">([\d.]+)/g, '"$1":$2')
    .replace(/"(\w+)">"([^"]*?)"/g, '"$1":"$2"');

// If still invalid, try single-to-double quote conversion
try {
    JSON.parse(jsonStr);
} catch {
    const singleQuoteFix = jsonStr.replace(/'/g, '"');
    try {
        JSON.parse(singleQuoteFix);
        jsonStr = singleQuoteFix;
    } catch {
        const combined = singleQuoteFix.replace(/"([^"]+)">\s*/g, '"$1":');
        try {
            JSON.parse(combined);
            jsonStr = combined;
        } catch {
            // All repairs failed, store as-is and surface error at render time
        }
    }
}

The ordering of the first two steps is the non-obvious part that Kiro helped me reason through. If you decode HTML entities before stripping tags, then <span> becomes <span> before the tag stripper runs, which is fine. But <10 becomes <10 which looks like a malformed tag to the stripper and gets incorrectly removed. Strip tags first on the encoded string, then decode the entities on the cleaned result.

Canvas Rendering: DPI, Coordinates, and Performance

The graph renderer draws to an HTML Canvas element. Canvas has a subtle gotcha that causes blurry output on retina displays if you don't handle it. There are two separate size concepts.

The CSS size is what you set with canvas.style.width and canvas.style.height. This controls how much space the element takes up in the layout.

The buffer size is what you set with canvas.width and canvas.height. This is the actual resolution of the pixel buffer the browser renders into.

On a retina display, window.devicePixelRatio is 2 or 3 on some phones. If your CSS size is 700px wide but your buffer is also 700px, the browser has to upscale the buffer 2x to fill the CSS space and the result is visibly blurry. The fix is to make the buffer 2x the CSS size and then scale the drawing context by the same factor:

function resizeCanvas() {
    const containerWidth = wrapper.getBoundingClientRect().width - 32;
    const dpr = window.devicePixelRatio || 1;

    canvas.width = containerWidth * dpr;
    canvas.height = (containerWidth * 0.55) * dpr;

    canvas.style.width = containerWidth + 'px';
    canvas.style.height = (containerWidth * 0.55) + 'px';

    ctx.setTransform(dpr, 0, 0, dpr, 0, 0);
}

After this, all your drawing code works in CSS pixel coordinates. ctx.fillRect(0, 0, 100, 100) draws a 100 CSS pixel square that looks sharp on any display density.

The coordinate transform from math space to canvas space is then layered on top:

function toCanvasX(x) {
    return pad.left + ((x - xRange[0]) / (xRange[1] - xRange[0])) * plotWidth;
}

function toCanvasY(y) {
    return pad.top + ((yRange[1] - y) / (yRange[1] - yRange[0])) * plotHeight;
}

The y-inversion is important. In math, y increases upward. In canvas, y increases downward. So yRange[1] - y gives you the correct mapping.

For plotting the actual curve, I sample 400 points across the x range and handle discontinuities explicitly. Functions like tan(x) have vertical asymptotes where the value jumps from large positive to large negative. Without handling this you'd get a visible vertical line at the asymptote:

const points = [];
for (let i = 0; i <= numPoints; i++) {
    const x = xRange[0] + (i / numPoints) * (xRange[1] - xRange[0]);
    const y = MathEval.evaluate(f.expr, { x, ...paramValues });
    if (isNaN(y) || !isFinite(y) || y < yRange[0] - 50 || y > yRange[1] + 50) {
        points.push(null);
    } else {
        points.push({ cx: toCanvasX(x), cy: toCanvasY(y) });
    }
}

ctx.beginPath();
let penDown = false;
points.forEach(p => {
    if (!p) { penDown = false; return; }
    if (!penDown) { ctx.moveTo(p.cx, p.cy); penDown = true; }
    else ctx.lineTo(p.cx, p.cy);
});
ctx.stroke();

Performance: IntersectionObserver for Animation Loops

The interactive-canvas widget type runs a continuous requestAnimationFrame loop for animated visualizations like oscillating waves or particle simulations. On a page with several of these in a long conversation, running all of them all the time is expensive even when they're off-screen.

The fix is IntersectionObserver, which fires a callback whenever an element enters or leaves the viewport:

let active = false;
let animFrame = null;

function loop() {
    if (!active) return;
    animTime += 0.016;
    draw();
    animFrame = requestAnimationFrame(loop);
}

const observer = new IntersectionObserver(entries => {
    const isVisible = entries[0]?.isIntersecting ?? false;

    if (isVisible && !active) {
        active = true;
        loop();
    } else if (!isVisible && active) {
        active = false;
        if (animFrame) cancelAnimationFrame(animFrame);
    }
}, {
    threshold: 0.1
});

observer.observe(widgetElement);

This means only the widgets currently visible on screen are running their animation loops. With five physics simulations in a long conversation, this is the difference between 10ms/frame and 50ms/frame.

LaTeX Rendering with KaTeX

Many of the widget titles and descriptions contain mathematical notation. I integrated KaTeX rather than MathJax because KaTeX renders synchronously. MathJax is more complete but uses an async API that adds complexity when you're updating the DOM incrementally during streaming.

function renderKaTeX(text) {
    if (!text || typeof katex === 'undefined') return escapeHtml(text);

    let result = escapeHtml(text);

    result = result.replace(/\$\$([\s\S]*?)\$\$/g, (_, tex) => {
        try {
            return katex.renderToString(tex, { displayMode: true, throwOnError: false });
        } catch {
            return escapeHtml(tex);
        }
    });

    result = result.replace(/\$([^\$]+?)\$/g, (_, tex) => {
        try {
            return katex.renderToString(tex, { displayMode: false, throwOnError: false });
        } catch {
            return escapeHtml(tex);
        }
    });

    return result;
}

The throwOnError: false option is important for production. If the AI generates slightly malformed LaTeX, you want graceful degradation to raw text rather than an uncaught exception that kills the widget render.

Display math gets processed first. If you process inline $...$ first, the regex will match the first $ of a $$...$$ block and corrupt it.

How Kiro Actually Changed My Day-to-Day

I want to be specific here because "AI-powered IDE" covers a lot of ground and most descriptions stay vague.

Adding new widget types is where Kiro made me genuinely faster. Once I had the graph and code-trace renderers working, I had a clear pattern. Kiro could read my existing renderers, understand the contract, and produce a solid first draft of the timeline or flowchart renderer that already matched my conventions. I'd typically spend maybe 30-40% of the time I would have spent writing it from scratch, with the rest going toward refinement rather than structure.

The spec-based context also caught bugs I'd have missed. When I refactored the hash function from random IDs to content-based IDs, Kiro flagged three places where I was still generating IDs the old way. Each would have been a silent bug with no error, just widgets that occasionally failed to render.

Visual quality is still something I had to drive manually. The rendering math, the gradient fills, the glow effects on plotted curves, the tooltip positioning, all of that required iteration with eyes on the actual output. Kiro could implement a line renderer. Whether it looked right was something I had to evaluate myself. That's honestly the right boundary. Code structure is something an AI IDE can carry a lot of. Aesthetic judgment isn't.

The steering documents were underrated honestly. I put in conventions like "always use devicePixelRatio for canvas sizing" and "never set innerHTML directly with user data." Kiro followed these consistently in generated code and I stopped seeing the same categories of mistake repeatedly.

What I'd Build Differently

I'd go schema-first. Defining TypeScript interfaces for every widget config before writing any renderer would have saved a lot of pain. Right now the JSON repair pipeline and the renderers' defensive defaults are doing work that a proper schema validator could do more clearly. Something like:

interface GraphConfig {
    title?: string;
    description?: string;
    functions: Array<{
        expr: string;
        label?: string;
        color?: string;
    }>;
    parameters?: Array<{
        name: string;
        label?: string;
        min: number;
        max: number;
        default: number;
        step?: number;
    }>;
    xRange: [number, number];
    yRange: [number, number];
}

I'd also separate the streaming buffer from the display layer. Right now they're more coupled than I'd like. The cleaner approach would be an intermediate representation where you parse markdown into a tree of content nodes and widget placeholder nodes, then render the tree to DOM once at the end rather than rebuilding innerHTML incrementally. More complex upfront, cleaner long-term.

And for the canvas widget type specifically, I'd add server-side static analysis of the generated draw functions before shipping at scale. For now the attack surface is limited, but it's something that should be handled properly before this gets in front of a lot of users.

The Result

When a user asks "show me how frequency and amplitude interact in a sine wave," they get a graph with two sliders and a crosshair tooltip. When they ask "walk me through merge sort," they get a step-by-step code trace with variable state visible at each step. When they ask about quantum mechanics, they get an animated canvas simulation they can pause and scrub.

This is what AI-assisted learning should look like. Not longer text answers. Active answers that respond to interaction.

The full app is at aimichat.app while still in beta. Every interactive learning widget is available on all plans, and the feature works on any topic the AI decides warrants a visual explanation.

If any part of this architecture is something you're working on, whether that's streaming widget systems, safe expression evaluation, canvas rendering, or the two-phase DOM approach, I'm happy to go deeper in the comments.

Analyzing React Best Practices with Kiro Powers

Salih Guler — Wed, 21 Jan 2026 08:59:21 +0000

Developers pair-program with AI assistants to build software outside your expert areas. One big example I have observed is, backend and cloud engineers building frontends. However, they all have the same concern: how do you verify the frontend code quality and be sure you follow the best practices?

On last Wednesday (Jan 14th), Vercel announced the set of AI skills to follow the best practices for React and Next.js applications, addressing this exact need. Therefore, I decided to bring these best practices to Kiro as well by building a Kiro Power.

Before we move forward, a disclaimer: This is not an official version, it is just me using Kiro to build a Kiro power :)

Power Builder

We have been talking about Kiro Powers but what are they? Kiro Powers inject specialized context and tools into Kiro agents on-demand, providing focused knowledge exactly when needed. Unlike traditional context injection that loads everything upfront, Powers activate specific capabilities dynamically.

You might be wondering, why not just use MCP? Even though MCP is a great solution for many problems, it comes with trade-offs. To find an answer or a content, it still needs to go through information and it has an impact on the context window. However with powers, you can focus and bring only what you need and save some context window.

To build Kiro Powers you can use the Power Builder. You can add it with a single click to your project.

Once you add that, now Kiro has the resources and context to build new Kiro Powers.

Prompt that bringing all together

Writing a proper prompt is one of the most fun but also challenging parts of building with AI nowadays. We have to have crisp, well written instructions on what we want to build and how we want to build. We can't say "build me a sign up" page and expect AI to build everything without missing a point with the design that we are imagining.

There are great resources such as this FAQ section from Open AI on how to write prompts but I highly recommend the the great article that my colleague Danilo Poccia wrote on how you can optimize your AI assistant to optimize itself and it helped me a lot to optimize my prompt as well.

Each step in this prompt serves a purpose: Step 1 ensures complete feature coverage, Step 2 guarantees proper Power structure, Step 3 defines clear specifications, and Step 4 creates a review checkpoint before execution. This structure helps you adapt the prompt for your own Power creation.

1. I want to create a Kiro Power from the Vercel agent-skills repository. Clone https://github.com/vercel-labs/agent-skills and analyze all files including subfolders to understand the complete feature set.

2. Research the official Kiro Powers documentation online to understand the correct folder structure, POWER.md frontmatter syntax (name, displayName, description, keywords, mcpServers), and steering file best practices.

3. Create a Power called "react-best-practices" with:
a. Publisher: "Salih Güler"
b. All agent skills converted to steering files (exclude Vercel deployment content)
c. Proper keywords that match how developers naturally talk about React/Next.js optimization
d. A README explaining how to install and use the Power

4. Prepare a detailed plan first and propose it to me before creating any files. Show me:
a. Which agent skill files you found and what they cover
b. How you'll organize them into steering files
c. The proposed keywords for activation
d. The POWER.md frontmatter you'll use

Once I ran the prompt, Kiro activated the "Power Builder", went through the files, came up with a plan to map rules to steering files and created a plan to create a POWER.md file and asked me if I want to execute it. After I said yes, all was done in a few seconds:

Using Kiro Powers

You can use Kiro Powers in three different ways. You can use the official ones with a click and install. You can use them from GitHub repositories and from your local folders.

You can use the GitHub repository reference or the local folder to install the power.

Running the React Best Practices on an Actual Project

I built a project to teach some students about how to build a full-stack application with AWS.

When I built it, I was more prototyping and building to create a starting point for my students. With this I will check how much improvement that we can make on the project.

Once you run the project, it analyzes your codebase and identifies improvements. In my case, it found:

Missing error boundaries in React components
Unoptimized image loading without Next.js Image component
Client-side data fetching that could move to server components

Here's the full analysis:

After you are good with all, you can tell it to implement everything for your project. Once it is done, you can check the project on how many files changed and what changes happened.

You can also define a global steering file rule to commit the changes by splitting them logically.

Conclusion

AI transforms how we build software daily. Kiro Powers offer a focused approach to code quality—activating expert knowledge when you need it without overwhelming your context window.

What you learned:

How to convert existing agent skills into Kiro Powers
The difference between Powers and MCP servers
A practical workflow for code quality checks

Considerations:

Powers work best with well-defined rule sets
Initial setup requires understanding Power structure
Results depend on your project's complexity

This Power is part of promptz.dev (a website that you can find great prompts and context files to enhance your development workflow) for broader availability (and you can check the source code and create issues on the on the promptz.dev repository. Try it on your React projects and share feedback—your input helps improve the Power for everyone.

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.

The Paradigm Shift from Reactive to Proactive AI in Software Development: A Comparative Analysis of AI IDEs

Asad marcus — Sun, 11 Jan 2026 15:04:06 +0000

A Comparative Analysis of Agentic IDE Architectures: AWS Kiro vs Cursor, Claude Code, GitHub Copilot, and Codeium

Executive Summary

This analysis compares AWS Kiro, a spec driven agentic IDE released in July 2025, against four incumbent AI coding assistants: Cursor, Claude Code, GitHub Copilot, and Codeium (Windsurf). The core tension examined is the architectural shift from reactive autocomplete to proactive specification based generation.

Key Findings

Finding	Assessment
Paradigm Shift	Kiro's mandatory Spec First workflow (User Story → Design → Code) is a distinct architectural choice that empirically reduces logic errors by preventing hallucinated objects common in reactive chat interfaces
Context Reality	While Kiro claims superior context persistence via graph based indexing, independent benchmarks indicate all tools still face significant reasoning degradation beyond ~32k tokens. The advantage lies in retrieval strategy, not raw memory
Enterprise Readiness	Kiro dominates in compliance inheritance, leveraging AWS's existing SOC/HIPAA posture. However, it lacks the friction free developer experience and plugin maturity of Cursor or VS Code native Copilot
Developer Autonomy	Contrary to the automation trend, Kiro's approach succeeds by restoring control. By allowing developers to edit specs rather than just code, it aligns better with 2025 research on professional developer psychology

Overall Verdict: Kiro represents a genuine architectural innovation for complex, greenfield enterprise development. However, for rapid iteration and maintenance of existing legacy codebases, reactive tools like Cursor and Copilot likely remain superior due to lower friction.

Introduction
Subject A: AWS Kiro Deep Dive
Subject B: Competitor Analysis
Point by Point Comparison
Analysis of Similarities and Differences
Conclusions and Recommendations

1. Introduction

1.1 The Evolution of AI Assisted Development

Between 2021 and 2024, the industry standard for AI coding was reactive: autocomplete (Copilot) and chat (ChatGPT/Claude). The interaction model was simple:

Developer writes code → AI suggests completions
Developer asks question → AI responds

By late 2024, agentic loops emerged. Tools like Cursor Composer and Windsurf Cascade began automating multi file edits, introducing a new paradigm:

Developer describes intent → AI plans changes → AI executes across files

As of January 2026, AWS Kiro attempts to formalize this into a fully proactive paradigm, one where the AI doesn't just respond to requests but actively structures the development process itself.

1.2 Research Questions

This analysis investigates four core questions:

Architectural Validity: Does the shift from Chat to Spec Driven constitute a genuine paradigm shift, or is it workflow theater?
Context Persistence: How do Kiro's context mechanisms compare to RAG based competitors in real world scenarios?
Developer Autonomy: Does the agentic model enhance or diminish developer control over their codebase?
Enterprise Readiness: Which tool is best positioned for regulated, large scale enterprise deployment?

1.3 Scope

Dimension	Coverage
Subject A	AWS Kiro (Spec Driven Agent)
Subject B	Cursor, GitHub Copilot, Claude Code, Codeium/Windsurf
Analysis Dimensions	Architecture, Context Persistence, Developer Autonomy, Enterprise Readiness
Time Frame	Data available as of January 2026

2. Subject A Overview: AWS Kiro

2.1 Background

Attribute	Detail
Release	July 2025 (Preview)
Core Engine	Amazon Bedrock AgentCore / Claude 4 Sonnet family (Sonnet 4.0, 4.5, Opus 4.5)
Architecture	Code OSS fork with graph based state engine
Primary Differentiator	Mandatory spec driven workflow

2.2 The Spec Driven Workflow

Unlike chat interfaces where a prompt immediately triggers code generation, Kiro enforces a waterfall like agentic loop:

Step	Description
1. Ingestion	Developer defines a high level goal. This ensures clarity before any design or code is generated.
2. Structuring	Agent produces User Stories and Technical Design documents, creating a formal blueprint for implementation.
3. Review (Human Gate)	Developer reviews, edits, and approves all artifacts, restoring control and ensuring correctness.
4. Execution	Agent generates production ready code and automated tests based on the approved specifications.

2.3 Core Features

Specs System

Kiro's specs are structured documents that capture:

requirements.md – User stories and acceptance criteria
design.md – Technical architecture and implementation plan
tasks.md – Generated tasks and code that trace back to spec items

Steering Files

Persistent instructions in .kiro/steering/*.md that guide AI behavior across all interactions:

Team coding standards
Project specific conventions
Always included or conditionally included based on file patterns

Agent Hooks

Event-driven automation that triggers AI actions:

fileEdited → Run linting
promptSubmit → Execute pre checks
agentStop → Generate documentation
contextualHooks → Trigger actions based on code context, file type, or spec state

MCP Integration

Native Model Context Protocol support for extensibility without vendor lock in.

Kiro Powers

Reusable, declarative capability bundles that constrain and standardize agent behavior:

Encode allowed actions, guardrails, and expected outputs
Enable consistent API creation, refactoring, migrations, and reviews
Reduce hallucinations by limiting the agent’s action space

Sub Agents

Modular AI agents that can be delegated tasks by the main agent for specialized execution, enabling more scalable and compartmentalized workflows.

2.4 Value Proposition

Kiro's thesis: Vibe Coding creates technical debt.

When developers use chat based AI to generate zode without explicit design, they get:

Code that looks correct but lacks cohesive architecture
Hallucinated objects and inconsistent patterns
Difficulty maintaining or extending the codebase

By forcing an intermediate design state, Kiro claims to solve this at the source.

Reminder: This post evaluates Kiro's Spec-First workflow, not Vibe Mode. Vibe Mode may yield faster output but at higher risk of errors.

3. Subject B Overview: Competitors

3.1 Competitive Landscape

Tool	Type	Philosophy	Primary Interaction
Cursor	AI Native IDE	Flow State	Fluid mix of inline edits, chat, and agentic Composer mode. Optimizes for speed
GitHub Copilot	Extension + Platform	Integration	Deep GitHub ecosystem integration. Workspace offers agentic plans, but primarily reactive
Claude Code	CLI / Agent	Autonomous Logic	Terminal first agent. Strengths in complex reasoning loops and tool use
Codeium (Windsurf)	AI Native IDE	Deep Context	Cascade engine focuses on deep awareness of current repo state

3.2 Cursor

Strengths:

Exceptional developer experience (DX)
Composer mode for multi file agentic edits
Rules for AI for persistent instructions
Shadow workspace for safe code testing
Rapid iteration speed

Weaknesses:

Context is largely ephemeral (session based)
Less structured approach to complex projects
Enterprise compliance requires additional configuration

Best For: Startups, rapid prototyping, developers who prioritize flow state

3.3 GitHub Copilot

Strengths:

Deepest integration with GitHub ecosystem
Copilot Workspace for agentic planning
Enterprise tier with strong compliance
Familiar VS Code experience
CI/CD pipeline integration

Weaknesses:

Primarily reactive (ghost text suggestions)
Agentic features still maturing
Less flexible than dedicated AI IDEs

Best For: GitHub native teams, enterprise standardization, CI/CD heavy workflows

3.4 Claude Code

Strengths:

Superior complex reasoning capabilities
Terminal first, scriptable interface
Excellent tool use and multi step planning
Strong Project Memory via CLAUDE.md
Anthropic's safety focused approach

Weaknesses:

Less polished UI/UX
Requires comfort with CLI
Context limited by session

Best For: Complex reasoning tasks, terminal native developers, autonomous workflows

3.5 Codeium / Windsurf

Strengths:

Cascade engine for deep repo awareness
Predictive editing based on codebase patterns
Strong free tier
Good context retrieval

Weaknesses:

Less mature than Cursor
Enterprise features still developing
Smaller ecosystem

Best For: Cost conscious teams, deep codebase context needs

4. Point by Point Comparison

4.1 Architectural Philosophy: Reactive vs. Proactive

Kiro (Proactive/Structured)

Kiro treats code as a downstream artifact of specifications. It is structurally impossible to generate code without a plan.
Evidence: OSVBench (April 2025) data shows Specification Driven Approaches reduce logic errors by 23 to 37 percent compared to direct generation.

The mechanism:

Without Specs: "Build a user auth system" → [LLM generates code] → Hallucinated patterns
With Specs: "Build a user auth system" → [LLM generates spec] → [Human reviews] → [LLM generates code matching spec]

Reminder: Vibe Mode shortcuts this process, generating code directly without specs, which can increase risk of logical or architectural errors.

Competitors (Reactive/Flexible)

Tool	Approach
Cursor/Windsurf	Mixed initiative: user can ask for a plan, but tool defaults to immediate execution
Copilot	Primarily reactive suggestions based on cursor position
Claude Code	Can plan when asked, but doesn't enforce it

5. Analysis of Similarities and Differences

Kiro's rigidity is a double edged sword:

Aspect	Kiro	Competitors
Bug reduction	✅ Supported by research	⚠️ Depends on user discipline
Time to first token	❌ Slower (spec generation required)	✅ Immediate
Simple tasks	❌ Overhead may frustrate	✅ Frictionless
Complex tasks	✅ Architectural integrity	⚠️ Risk of vibe coding

Verdict: The paradigm shift is real regarding capability. However, labeling it a paradigm shift may be marketing hyperbole. It's technically an evolution of tool use capabilities rather than a fundamental change in software theory.

6. Conclusions

Reminder: Throughout this analysis, Kiro's Spec-First workflow is evaluated, not Vibe Mode. Vibe Mode may produce faster results but at higher risk of logic or architectural inconsistencies.
AWS Kiro is not merely another IDE. It is an attempt to enforce software engineering best practices through tooling.
Its Spec Driven Architecture is scientifically sound, backed by 2025 research showing that separating design from implementation significantly reduces hallucination rates.
However, its success depends on the Developer Experience (DX) trade off: Will developers accept the friction of generating specs for the sake of robustness?

Disclaimer: This analysis reflects the state of AWS Kiro and competitor AI coding tools as of Late 2025. It was generated in a AI researcher created by Kiro, leveraging public benchmarks, vendor documentation, and early reports. Some claims may be outdated as tools evolve rapidly, and future research or updates may conflict with findings presented here.

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

I Resurrected 1980s Teletext to Cure My Doomscrolling (Built with Kiro)

Md. Rafi — Fri, 05 Dec 2025 19:57:22 +0000

The modern web is exhausted. It’s infinite, noisy, and designed to keep us scrolling forever. I missed the "finish line"—that feeling when you’ve read the news, checked the weather, and you are done.

So, for the Kiroween Hackathon, I decided to build Teletext Zero.

It’s a "Slow Web" browser that forces the chaotic internet into a strict 1980s TV format: 40 columns, 24 rows, 8 colors, and absolutely no scrolling.

Building a retro-constraint engine like this usually takes weeks of tedious CSS math and state management. I built it in a weekend using Kiro, an AI-native IDE.

Here is how I used Kiro’s "Hybrid Workflow" to switch between being a rigorous Architect and a creative Artist.

The Problem: Logic vs. Vibes

Every developer knows the struggle.

The Architect Brain wants strict rules, type safety, and robust architecture.
The Artist Brain wants to mess around with shaders, animations, and "feel."

Usually, you have to compromise. With Kiro, I didn't have to.

Phase 1: The Architect (Spec-to-Code)

To make Teletext Zero feel real, I couldn't fake the constraints. If the text wrapped wrong or the grid broke on a mobile screen, the illusion would die.

Instead of writing React components manually, I used Kiro's Spec mode. I wrote a requirements.md file that defined the laws of my universe:

The Grid: Must be exactly 40x24 characters.
The Input: Keyboard only (3-digit page dialing).
The Palette: Only the standard 8 Teletext colors.

Kiro took this spec and generated the entire engine. But here is the kicker: it didn't just write the code; it wrote Property-Based Tests (using fast-check). It mathematically proved that no matter what text I threw at the engine, the layout would never break or scroll.

I had a bulletproof foundation in minutes.

Phase 2: The Artist (Vibe Coding)

Once the logic was solid, I needed it to look like a haunted TV found in an attic.

I switched Kiro to Vibe mode (conversational coding). This is where the magic happened. I didn't write CSS classes; I just described the aesthetic:

"Make it look like a 1980s Trinitron. Add scanlines, a phosphor bloom on the text, chromatic aberration on the edges, and a subtle screen curvature vignette."

Kiro generated complex CSS shaders and keyframe animations instantly. It tweaked the text shadows to simulate that fuzzy, glowing look of old cathode ray tubes. It was like pair-programming with a retro-graphics expert.

Phase 3: The "Kiroween" Twist

Since this was for a Halloween hackathon, I added a ghost in the machine.

Using Vibe mode, I instructed Kiro to build Page 666.

The Logic: If the user dials 666, the system degrades.
The Visuals: Random character corruption and background red flashing.
The Audio: Kiro helped me wire up the Web Audio API to play static hiss that syncs with the visual glitches.

The Result

Teletext Zero isn't just a toy; it works.

Page 200 pulls live BBC News via RSS.
Page 300 pulls tech news from The Verge.
Page 400 uses the browser's Geolocation to fetch live weather from Open-Meteo.

And because of the Spec-driven foundation, the Kiro-generated "Word Wrap" logic takes those long web articles and perfectly truncates them into 40-character summaries. It respects the grid.

Conclusion

Kiro changed my mental model of development. I used Spec to enforce rigor where it mattered (the engine) and Vibe to embrace chaos where it was fun (the aesthetics).

I didn't just write code; I directed a vision.

🔗 Try Teletext Zero here: https://rafi.is-a.dev/Teletext-Zero/
💻 Check the Repo: https://github.com/MdRaf1/Teletext-Zero

Have you tried AI-native IDEs yet? Let me know in the comments!

Built with #kiro

Bringing Yahoo Chat Rooms Back to Life: How I Built Lingo with Kiro

Deep — Fri, 05 Dec 2025 18:33:58 +0000

🟣 Lingo — Bringing Yahoo Chat Rooms Back to Life for Language Learning

Remember Yahoo chat rooms? Those chaotic, wonderful digital hangouts where strangers became friends, ideas flowed freely, and the internet felt alive?

For me, they were more than a pastime—they were formative. I learned expressions, cultures, and even bits of other languages simply by talking to real people.

So when Kiroween announced the “Resurrection” theme, I immediately knew what I wanted to build.

🧩 The Problem I Wanted to Solve

I’ve always wanted to learn new languages, and I’ve tried everything—apps, textbooks, structured courses. They helped, but only to a point.

Whenever I had to actually speak, my mind froze.

But when I started talking to real people—native speakers, language exchange partners—everything changed:

Vocabulary became tools I could actually use
Grammar rules made sense in real conversation
Learning felt natural and fun

Languages aren’t learned through instruction alone. They’re learned through interaction.

That idea became the heart behind Lingo.

🌍 What Lingo Does

Lingo resurrects the magic of old-school chat rooms and combines it with powerful AI to create a modern language-learning playground.

🏠 Global Language Rooms

Choose a language—Spanish, French, Japanese, Korean, German, Italian, Portuguese, Chinese—and jump into:

Live group chat rooms
Private conversations
Text chat with formatting
Voice message support

It’s social, real-time, and authentic.

🤖 AI Language Buddy (7 Modes of Learning)

Your AI partner lives directly inside the chat. It’s not just a translator—it’s a coach.

The 7 Modes:

Learn Mode — Step-by-step lessons
Chat Mode — Natural conversation practice
Translate Mode — Real-time translation with cultural notes
Grammar Mode — Instant corrections with explanations
Pronunciation Mode — Voice input + feedback
Practice Mode — Role plays (e.g., ordering food)
Vocab Mode — Contextual vocabulary building

Every response is bilingual.

There's even Simple Mode for beginners—with emojis, slow explanations, and encouragement.

🎮 Mini Games (Halloween Edition)

Learning should be fun, so Lingo includes:

Hangman with spooky animations and sounds
Word Scramble Battle with difficulty levels and leaderboards

It turns vocabulary into play.

🖥️ Retro Desktop Interface (Yahoo Messenger Vibes)

Lingo lives inside a nostalgic Windows XP-style UI:

Draggable windows
A taskbar with a start menu
Changeable themes: Retro Yahoo, Halloween, Cyberpunk, Minimal
Keyboard shortcuts
Smooth animations

It feels familiar, playful, and surprisingly modern.

🛠️ How I Built It with Kiro

This project was only possible because Kiro acted like a full dev team by my side.

1️⃣ Vibe Coding

I started with a simple description:

“Yahoo chat rooms for language learning.”

Kiro instantly generated:

React components
Retro CSS
Draggable windows
Taskbar system
Window manager logic

Within minutes I had a working UI skeleton.

2️⃣ Spec-Driven Development

For each feature, I wrote what I wanted, and Kiro figured out the how:

AI Buddy with 7 modes
Voice input + bilingual formatting
Hangman + Word Scramble
Theme system
Text formatting toolbar

Kiro built the logic, and I iterated.

3️⃣ Agent Hooks

Kiro’s automation made the project production-ready:

test-component-on-save — runs tests automatically
firebase-security-audit — audits my database rules
Auto-formatting and dependency checks
Build optimization hooks

It felt like having a senior engineer reviewing every commit.

4️⃣ Steering Documents

These controlled the AI’s teaching style:

How to correct without discouraging
When to translate vs. when to challenge
Tone, personality, cultural sensitivity
Lesson sequencing logic

With steering docs, Gemini became a real tutor, not a random assistant.

⚙️ Tech Stack

React 19 — UI
Vite 5 — Fast builds
Firebase — Real-time chat, auth, presence
Google Gemini — AI Buddy
Web Speech API — Voice recognition
Vercel — Deployment

Everything is real-time and client-side.

🧠 Challenges I Overcame

🔄 Real-Time Chat Sync

Managing message order, timestamps, and presence required a smart Firebase data model.

🤖 AI Personality Consistency

Steering documents solved early issues with tone and inconsistency.

⚡ Retro UI Performance

Balancing animations (ghosts, bats, draggable windows) while keeping everything smooth took optimization.

🔐 Firebase Security Rules

Ensuring public rooms were open but private chats were locked-down required detailed rule writing.

🌟 What I’m Proud Of

I resurrected Yahoo Chat with purpose, not nostalgia alone
The AI Buddy genuinely teaches, not just translates
Real-time chat + AI coaching feels magical
I built an entire multi-feature platform solo in days, thanks to Kiro
Lingo helps people learn languages the way humans naturally learn—through conversation

🔍 The Potential of Perspective-Driven Code Reviews - Gaining New Insights

snickerjp — Fri, 05 Dec 2025 17:58:47 +0000

Introduction

The Importance of Perspective in Code Reviews

Code reviews are a crucial process that serves as the cornerstone of quality assurance, but the content and priorities of feedback can vary significantly depending on the reviewer's perspective. This report analyzes reviews from two different perspectives - operational and architectural - by AI "kiro" using actual Terraform code reviews as a case study, and examines the new insights gained by changing perspectives.

Two-Perspective Reviews by kiro

In this report, we requested AI "kiro" to conduct reviews from the following two perspectives:

🔧 Operational Perspective: Emphasizing safety, maintainability, and practicality in team development for daily operations
🏗️ Architectural Perspective: Emphasizing code design elegance, scalability, and architectural soundness

While these perspectives are not necessarily opposing, they differ in priorities and focus points. By requesting the same AI to review from different perspectives, we can objectively analyze how perspective differences affect feedback content.

🔧 Operational Perspective Review by kiro

Review Overview

The operational perspective review was analyzed using the following four evaluation criteria:

Item	Rating	Details
Security	🔴 Needs Improvement	Hardcoded sensitive information
State Management	🔴 Needs Improvement	Using local state
Code Quality	🟡 Good	Some room for improvement
Operability	🟡 Good	CI/CD not implemented

Major Issues Identified

1. State File Management (Most Critical)

❌ Problem: Managing state files locally
⚡ Risk: Conflicts in team development, loss risk, no backup
✅ Solution: Implement S3 backend + DynamoDB locking

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket"
    key            = "alb-rules/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

2. Security Concerns

❌ Problem: ARNs hardcoded in tfvars files
⚡ Risk: Sensitive information leakage
✅ Solution: Environment variables, Parameter Store utilization, .gitignore configuration

3. Stricter Version Management

❌ Problem: Provider version range too broad (~> 5.0)
✅ Solution: More specific version specification (~> 5.30.0)

4. Operational Improvement Proposals

🏷️ Unified tag strategy (localize common tags)
✔️ Add variable validation (IP format, priority range validation)
🔄 Build CI/CD pipeline
📊 Monitoring and alerting setup

Implementation Roadmap

The operational perspective presented a phased improvement plan:

📅 Phase 1 (1 week): Remote state file implementation
📅 Phase 2 (2 weeks): Security enhancement
📅 Phase 3 (1 month): CI/CD construction
📅 Phase 4 (3 months): Modularization and policy management

🏗️ Architectural Perspective Review by kiro

Review Overview

The architectural perspective focused on code design quality and future scalability.

Overall Rating: B+ → A (after improvements)

Evaluated Strengths

⚡ Dynamic Resource Generation: Excellent automatic splitting logic for ALB limitations (4 IPs/rule)
📋 Variable Separation: Externalization of configuration through terraform.tfvars
🏷️ Tag Standardization: Consistent tag strategy
🎯 Constraint Handling: Creative solutions for AWS limitations

Major Improvement Proposals

1. Modularization Recommendation (Priority: Low)

Migration from current flat structure to module-based structure
🗂️ Environment-specific directory separation (production/staging)
♻️ Creation of reusable modules

2. Dynamic Retrieval via Data Sources (Priority: Medium)

Dynamically retrieve hardcoded ARNs using Data Sources
More flexible and maintainable design

# After improvement
data "aws_lb" "main" {
  name = var.load_balancer_name
}

data "aws_lb_listener" "https" {
  load_balancer_arn = data.aws_lb.main.arn
  port              = 443
}

3. Enhanced Input Validation (Priority: High)

🌐 CIDR format validation
🔢 IP count validation
💬 More detailed error messages

variable "devinvm_ip_addresses" {
  description = "Devin VM IP addresses"
  type        = list(string)

  validation {
    condition = alltrue([
      for ip in var.devinvm_ip_addresses :
      can(cidrhost(ip, 0))
    ])
    error_message = "All IP addresses must be valid CIDR notation."
  }
}

4. Output Improvements

📝 Add detailed descriptions
📊 Output rule summaries
🗂️ More structured output format

Comparative Analysis

Common Ground: Issues Identified by Both Perspectives

The following items were identified by both kiro's operational and architectural perspectives and are items that should definitely be improved:

✔️ Adding Input Validation
- 🔧 Operational perspective: Preventing operational mistakes
- 🏗️ Architectural perspective: Improving code quality
📌 Stricter Version Management
- 🔧 Operational perspective: Preventing unexpected behavior
- 🏗️ Architectural perspective: Ensuring reproducibility
State Management Improvement
- 🔧 Operational perspective: Team development safety
- 🏗️ Architectural perspective: Infrastructure reliability
Security Enhancement
- 🔧 Operational perspective: Protecting sensitive information
- 🏗️ Architectural perspective: Design soundness

Differences: Priority Variations by Perspective

Readability Aspect

Perspective	Priority	Approach
🔧 Operational	🟡 Medium	🏷️ Tag unification, clear naming conventions
🏗️ Architectural	🔴 High	📦 Modularization, structured output

Analysis: Architectural perspective emphasizes structural code readability (modularization). Operational perspective emphasizes clarity in daily work (tags, naming).

Maintainability Aspect

Perspective	Priority	Approach
🔧 Operational	🔴 High	🔄 CI/CD, 📊 monitoring, 🔍 drift detection
🏗️ Architectural	🔴 High	📦 Modularization, 🔍 Data Source utilization

Analysis: Both prioritize maintainability, but operational perspective focuses on "operational processes" while architectural perspective focuses on "code design".

Performance Aspect

Perspective	Priority	Approach
🔧 Operational	🟢 Low	No specific mention
🏗️ Architectural	🟢 Low	No specific mention

Analysis: For this Terraform code, performance was not a major concern for either perspective.

Priority Differences

Operational Perspective Priorities

🔴 Highest Priority (Immediate Response)
  ├─ State Management
  └─ Security

🟡 Medium Priority (Medium-term Improvement)
  ├─ CI/CD
  └─ Monitoring

🟢 Low Priority (Long-term Improvement)
  └─ Modularization

Architectural Perspective Priorities

🔴 Highest Priority
  └─ Input Validation

🟡 Medium Priority
  ├─ Data Source Implementation
  └─ State Management

🟢 Low Priority
  └─ Modularization

Important Discovery:

🔧 Operational perspective: "State Management" as highest priority → Focus on problems that could occur immediately
🏗️ Architectural perspective: "Input Validation" as highest priority → Focus on code quality fundamentals

Both perspectives rated "Modularization" as low priority because the current code is simple and functions adequately.

Different Focus Points by Perspective

Kiro's operational and architectural perspectives focus on significantly different points even when looking at the same code.

Items Emphasized by Operational Perspective (Not mentioned by architectural perspective)

🔄 CI/CD Pipeline Construction: Reducing human errors through automation
📊 Monitoring & Alert Setup: Early problem detection and response
🔍 Drift Detection: Detecting discrepancies between actual infrastructure and code
Phased Implementation Roadmap: Realistic improvement plan
Team Development Conflict Risks: Safety during multi-person work

These focus on "actual daily operational challenges".

Items Emphasized by Architectural Perspective (Not mentioned by operational perspective)

📦 Detailed Module Structure Design: Ensuring reusability and scalability
🗂️ Environment-specific Directory Separation: Logical structuring
📤 Output Structuring and Detailing: Systematic information organization
🔍 Specific Implementation of Dynamic Retrieval via Data Sources: Highly flexible design

These focus on "design considering future changes and extensions".

Important Insight: Both perspectives capture problems on different time scales. Operational perspective looks at "today and tomorrow", while architectural perspective looks at "months and years ahead".

Analysis

Value Brought by Perspective Diversity

From kiro's two-perspective comparison, we gained the following important insights:

Complementary Perspectives: Operational and architectural perspectives don't oppose each other but complement each other. Operational perspective captures "current" problems, while architectural perspective captures "future" problems.
Importance of Common Issues: Items commonly identified by both perspectives (input validation, version management, state management, security) are important matters that should definitely be addressed.
Value of Priority Differences: The difference between operational perspective's "State Management priority" and architectural perspective's "Input Validation priority" should be judged based on project circumstances (team size, development phase, risk tolerance) rather than which is correct.

Balancing Operational and Architectural Perspectives

Recommended Approach

Initial Stage: Prioritize operational perspective
- State management, security, etc., ensure basic safety
- Establish team development foundation
Growth Stage: Incorporate architectural perspective
- Code structuring, modularization
- Scalability improvement
Maturity Stage: Integration of both perspectives
- Balance operational processes and code design
- Continuous improvement cycle

Application to Development Teams

Perspective-driven reviews can provide the following benefits:

Junior Developer Growth: Learn practical skills from operational perspective reviews and design philosophy from architectural perspective reviews
Reviewer Burden Reduction: Clarifying perspectives makes review intentions clear and discussions constructive
Team Diversity Utilization: Members with different backgrounds can contribute from their respective perspectives

Importance of Code Simplicity

Through this analysis, we confirmed that "code simplicity" is valued by both perspectives:

Architectural perspective also values practical design over excessive abstraction
Operational perspective emphasizes clear, maintainable code over complex structures
Both perspectives rated the current implementation (ALB limitation handling) as "excellent" and "creative"

This is because code maintained by diverse members requires understandable and easily modifiable code.

Conclusion

New Insights from Changing Review Perspectives

From this report's analysis, the following values became clear:

Comprehensive Quality Improvement: Problems overlooked by a single perspective can be complemented by multiple perspectives
Priority Clarification: Common issues should definitely be addressed, while perspective-specific issues can be judged based on circumstances
Learning Opportunity Creation: Reviews from different perspectives provide valuable opportunities to broaden developers' horizons
Promoting Constructive Discussion: Clarifying perspectives makes "why that feedback is given" clear and deepens discussions

Recommendations for Future Review Culture

1. Perspective Clarification

Clearly marking perspectives (operational, architectural, security, etc.) in review comments makes intentions easier to understand.

2. Encouraging Diverse Perspectives

Foster a culture that actively seeks feedback from reviewers with different backgrounds within the team.

3. Accepting Gradual Improvement

Rather than seeking perfection, distinguish between operational perspective's "immediately necessary improvements" and architectural perspective's "future improvements", accepting gradual improvement.

4. Utilizing AI Reviews

As demonstrated in this report, using AI to efficiently obtain reviews from multiple perspectives can reduce human reviewer burden while improving quality.

Concrete Actions You Can Start Tomorrow

Perspective-driven reviews can be started today without special preparation.

🤖 Perspective-Specific Reviews Using Generative AI

The simplest method is to 🎯 specify perspectives when requesting reviews from generative AI:

Example 1: 🏗️ Architectural Perspective Review Request

"Please review this Terraform code from an 🏗️ architectural perspective.
Focus on design elegance, scalability, and future maintainability for feedback."

Example 2: 🔧 Operational Perspective Review Request

"Please review this Terraform code from an 🔧 operational perspective.
Focus on daily operational safety, team development practicality, and troubleshooting ease for feedback."

By simply 📝 splitting requests into two, you can gain insights from different perspectives. Please try it!

👥 Team Implementation

🏷️ Add Perspective Tags to Review Comments
- Tags like [🔧 Operational Perspective] [🏗️ Architectural Perspective] clarify intentions
📝 Specify Expected Perspectives in Review Requests
- "Please review focusing on 🔧 operational issues"
- "Could you provide feedback from a 🏗️ design perspective?"
👥 Perspective Role Assignment
- Operations staff review from 🔧 operational perspective, architects from 🏗️ design perspective
- Obtaining both perspectives enables comprehensive quality improvement

🎉 Final Words

Perspective-driven reviews are not mere "✅ checking tasks" but 👥 venues for sharing team-wide knowledge and experience. By combining 🔧 operational and 🏗️ architectural perspectives with various other viewpoints, we can build more robust and maintainable codebases.

This initiative promotes 🌱 junior developer growth, shares 👨‍💼 senior developer insights, and ultimately contributes to 📈 overall project quality improvement. Accepting perspective diversity and building better software together through constructive discussion is the essential value of development teams.

📚 References

Please feel free to check out my first post:

Understanding the Differences: Kiro IDE, Kiro CLI, and Amazon Q Developer - DEV Community

How Kiro Transformed My Development Workflow — Building Dashtact in Record Time

Fouad Abatouy — Fri, 05 Dec 2025 16:55:49 +0000

👻 GHOSTNET — A Cyber Maze Survival Game Built on Kiro AI

Pragati GP — Fri, 05 Dec 2025 15:26:21 +0000

👻 GHOSTNET — Enter the Maze. Outsmart the System.

Welcome to GHOSTNET, a cyber-maze adventure where YOU become the hacker navigating glowing alleys, collecting digital cubes, escaping enemies, and beating the network from the inside.

This blog dives into:

the concept behind the game
how the mechanics work
why Kiro makes development faster
and the fun twist that makes GhostNet stand out

Let’s jack-in.

🕹️ What is GHOSTNET?

GHOSTNET is a short, intense cyber-maze survival game.

You’re not just a player.

You’re a system infiltrator, an undercover hacker inside a glowing grid filled with traps, secrets, and patrolling ghosts.

Your mission:

collect every Digital Cube
avoid the Ghosts
find the Exit Portal
escape before the network wipes you out

If a ghost catches you → game over.

If you miss a cube → the exit rejects you.

Simple. Addictive. Brutal. Perfect.

🧩 The Game Concept

The world of GhostNet is built using:

glowing neon alleys
unexpected intersections
deadly blind turns
strategic cube placements

Each digital cube represents:

a broken piece of encrypted data
a fragment of the system’s truth
your key to activating the final exit

The ghosts represent corrupted watchdog AIs.

They don’t chase… they lurk.

They wait.

They predict.

They watch every move you make inside the maze.

You are in their world. You are the glitch. They are the system.

✨ The Tech Behind the Game: The Frank-Christ Layout

GhostNet uses a Frank-Christ inspired grid, meaning:

dynamic intersections
maze-like structure
predictable paths mixed with unpredictable danger
perfect for maze-based logic and chase mechanics

It makes the player:

think quickly
calculate turns
stay alert at every corner

This structure is simple to understand but hard to master, which is exactly why GhostNet becomes addictive.

🤖 Why We Built It With Kiro

Kiro makes game prototyping insanely fast.

Plus Points of Using Kiro:

lightning-fast code testing
instant debugging
real-time iteration
easy asset management
smooth event-trigger logic
perfect for beginners AND power users

Kiro helps turn:

rough sketches → working systems
ideas → prototypes
imagination → playable levels

GhostNet exists because Kiro lets you build without limits.

🌐 Gameplay Loop

Spawn in the maze
Scan for the first cube
Walk alley by alley
If there’s a ghost → back up or die
If there’s a cube → collect it
Grab all cubes
Find the glowing exit
Escape before the network crashes you

Fast. Simple. Addictive.

🎮 Why Players Love GhostNet

short but intense
neon aesthetic that feels alive
danger hidden around every corner
clean and satisfying movement
exploration + survival + puzzle combined
every run feels different

This is the kind of game people finish… and restart immediately.

🧠 Design Philosophy

GhostNet focuses on:

clarity
simplicity
tension
player curiosity

The maze isn’t just “streets.”

It’s a system.
The cubes aren’t “collectibles.”

They’re data fragments you must reconstruct.
The ghosts aren’t “monsters.”

They’re AI protectors doing their job.
You’re the intruder.

The network wants you gone.

That conflict is the heart of the game.

🌀 What’s Next?

Future updates may include:

moving ghosts
timed portals
multiple levels
special cube types
stealth zones
player powers

GhostNet is only the beginning.

🏁 Final Thoughts

GhostNet is more than a game.

It’s a neon puzzle. A digital chase.

A test of instinct, timing, and courage.
Built on Kiro.

Powered by creativity.

Driven by players like you.
Welcome to the network.

Survive if you can.

Requiem Records: How Kiro Haunted My Codebase into a Screaming Success

Krithika — Fri, 05 Dec 2025 12:00:32 +0000

Three days ago, We had a wild idea: build a haunted vinyl diary web app where users record their voice, and the app transforms their words into gothic horror stories. The concept was clear in my mind dark aesthetics, creepy animations, voice-to-story generation but the path to building it? That was the real horror story.

What you're about to read isn't just another "We built an app" story. This is about how an AI-powered IDE didn't just help me code it fundamentally transformed how We think about development. In 72 hours, We went from a rough concept to a fully functional, production-ready web application with features We didn't even know that we needed.

Quick Project Snapshot

Category: It is for the Resurrection category for kiroween competition
Platform: Accessible in Web
Each Room/Screen:

Intro Screen
Main Hub
Recording Room
Log Room
Story Room
Vinyl Room
Senance Room Core idea: The idea is recording out voice and turning it in a scary story

The Project: Building Haunted Vinyl Diary for Kiroween

Requiem Record is not just a web app, it is a ritual of memory and fear.
Users step into a gothic, gamified world where their own voice becomes the trigger for horror.

Every whispered confession, fear, or memory is recorded, transcribed in real time, and reborn as a personalized gothic nightmare — written by an AI that turns emotions into chilling folklore.
The app features:

Voice recording with real-time transcription
AI-generated scary stories based on your words
Horror music playlist with 10 atmospheric tracks
Gothic UI with blood-red text and haunting animations
Fully responsive design
Cinematic video transitions

Tech Stack: Vanilla JavaScript, Web Audio API, Speech Recognition API, LocalStorage, CSS3 Animations

Before Kiro: The Ghosts That Haunted My Development Journey

Planning Paralysis

Before Kiro, We lived in a loop of overthinking. We had notebooks overflowing with ideas. UI sketches, feature lists, story logic, audio concepts, yet We were paralyzed when it came time to code. I didn’t know where to begin. Should we start with the UI? The recording engine? Local Storage? Story generation? Every path felt equally important and equally risky. The fear of choosing the “wrong” first step kept me frozen, planning infinitely and building nothing.

Debug Nightmares

Whenever something finally stopped working...and it always did, everything spiraled. A tiny bug meant hours of console.log() breadcrumbs across files, chasing ghosts in spaghetti code. The deeper we dug, the more we forgot our original intention. Debugging didn’t feel like solving problems; it felt like losing ourself inside them.

Feature Creep Curse

The scariest part was how easily excitement became self-destruction. “Maybe we should add this one more feature…” turned into days of derailment. A new animation, a new mood filter, a new diary mechanic, each small idea multiplied into new threads of work. The finish line kept pulling away, and we became trapped in the illusion of progress while the project refused to end.

Where All This Led

We weren't stuck because of lack of passion, we were drowning in it. we were building constantly, but never finishing. we had creativity, but no direction. We weren't fighting the code… We were fighting ourself.

And that’s when Kiro appeared.

Vibe Coding Revolution: How Natural Language Built My App

Here's where things got wild. With Kiro, We could literally describe what we wanted in plain English:

Me: "We need a vinyl room with a playlist of 10 horror songs. Each song should play completely without skipping. Show which track is playing with a pulsing animation."

Kiro: Generates complete implementation with:

Playlist UI with 10 tracks
Event delegation for click handling
Audio playback with proper cleanup
CSS animations for active track
Error handling for failed loads

But it wasn't just code generation. Kiro understood context. When we said "the text is blurry," it knew we were talking about the story display and that the blur was coming from a CSS filter on the parent element. It didn't just remove the blur, it moved it to a pseudo-element so the background stayed blurred while the text remained sharp.

The Magic Moment: We said "make the text blood red and clearer" and Kiro:

Changed color to #8B0000 (dark blood red)
Increased font size for readability
Added proper z-index layering
Removed the blur filter from text
Applied blur only to the background
Adjusted font weight for clarity

This wasn't autocomplete. This was understanding.

Spec-Driven Development: From Requirements to Reality

The real revolution for me was Kiro’s spec-driven workflow. Instead of jumping into code and improvising my way through features, Kiro pushed us to think like an engineer first and a coder second. Everything began with a requirements phase rather than an implementation phase, and that one shift alone transformed chaos into clarity.

1. Requirements Phase

Kiro helped us transform vague, emotional ideas into structured and testable requirements using the EARS (Easy Approach to Requirements Syntax) format. What previously felt like a shapeless feature “We want people to record memories” became an actionable specification. For example:

Nothing was ambiguous anymore, every single requirement was clear, measurable, and directly tied to a visible user outcome.

2. Design Phase

Once the requirements were locked in, Kiro generated a complete design document that became the guiding blueprint for the entire project. It included Mermaid-based architecture diagrams that illustrated how each component interacted, well-defined component interfaces with single responsibilities, and data models describing how audio, entries, and transcriptions would persist across the application. The design also specified correctness properties for property-based testing and outlined error-handling strategies before a single feature was coded. For the first time, I never had to stop and ask, “What were we building again?” the design doc always held the answer.

3. Implementation Phase

Kiro then broke the design into 47 actionable tasks, each one small enough to complete confidently but meaningful enough to push the project forward. Tasks were sequenced intelligently and tied to the exact requirement they satisfied. A typical section looked like:

Every task was specific, testable, and positioned in the order that made the most technical sense. Instead of guessing what to do next, We followed a crystal-clear roadmap, and development became smooth, predictable, and deeply satisfying.

Agent Hooks Magic: Automating My Workflow

The feature that completely changed the rhythm of our development was Kiro’s Agent Hooks. They allowed our project to react automatically to our actions, almost like the codebase was alive and working alongside us. We configured hooks so that the moment we saved a file, Kiro would immediately run the tests associated with the component we had just edited. It looked like this:

{
  "trigger": "onFileSave",
  "pattern": "js/*.js",
  "action": "npm test -- {{filename}}"
}

With a single hook, the endless cycle of “wait, did we run the tests?” disappeared. Every save meant instant feedback, no excuses, no forgetfulness, and zero stale bugs left behind.

We then pushed automation even further. Whenever a specification document changed, Kiro would automatically regenerate the task list to reflect the new requirements. In other words, feature updates and planning stayed perfectly synchronized without manual effort:

{
  "trigger": "onFileChange",
  "pattern": ".kiro/specs/*/design.md",
  "action": "regenerate-tasks"
}

Suddenly, the entire workflow became self-maintaining. We never ended up with outdated tasks, forgotten tests, or misaligned specs. Development finally felt like flow instead of management, We could focus on creativity and problem-solving while the system quietly handled discipline and structure in the background.

Steering Documents: Giving Kiro Clear Direction

Steering docs acted like a style guide for our AI development workflow. By defining my standards up-front, Kiro consistently generated clean, predictable, and scalable code—removing the usual tech-debt chaos from the start.

MCP Integration: Unlocking Kiro’s Full Project Awareness

Integrating the @modelcontextprotocol/server-filesystem gave Kiro deep visibility into my entire codebase — not just the file we were working on. This transformed the AI from a code assistant into a full project-aware collaborator.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"]
    }
  }
}

A simple filesystem MCP server connected Kiro to the full project directory.

What Kiro Gained

Awareness of full folder and file structure
Ability to search and open related files automatically 3.Cross-file refactoring suggestions 4.Detection of naming and logic inconsistencies across modules

Real-World Example

When we asked “make the vinyl room buttons work”, 2.Kiro found the UI manager file 3.Located event handlers in app.js 4.Detected a CSS stacking/z-index conflict 5.Updated all three files in one coordinated fix

The Outcome
No more context explaining, copy-pasting code, or hunting through folders Kiro understood the whole project and applied changes precisely where they needed to happen.

Surprising Discoveries

Kiro Learns Your Style: After a few iterations, Kiro started matching our coding style without prompting
Context is King: The more context we provided, the better the results
Specs Are Living Documents: Updating the spec mid-project helped Kiro stay aligned
Property-Based Testing is Powerful: Kiro made it accessible; caught bugs we never have found

Recording Screen - Capturing Souls

What it does: Records voice audio with a pulsing red indicator, timer, and back button.

How Kiro helped:

Microphone Access: Built robust Recording Service with proper error handling for permission denied, no microphone, device in use, etc.
MediaRecorder API: Implemented browser audio recording with proper blob creation and duration tracking
UI Feedback: Created pulsing recording indicator, live timer display, and button state changes
Error Handling: Added extensive logging and user-friendly error messages for debugging recording issues

Transcription Integration: Connected to Transcription Service for live speech-to-text

Story Screen - The Horror Transformation

What it does: Plays a video, shows a diary, then displays your voice recording transformed into a gothic horror story.

How Kiro helped:

1.Story Generation Service: Created StoryGenerationService with 1,200+ unique story combinations using:

15 different spooky locations
8 themes with 4 adjectives each
10 story styles (diary entry, confession, warning, etc.)
Transformation Algorithm: Built a system that takes YOUR actual words and transforms them into horror narrative Implemented proper event listeners and timeouts
**Animation: **Added handwriting-style text animation with paragraph delays

Vinyl Room - The Music Sanctuary

What it does: Plays 10 local horror-themed music tracks with a vinyl record aesthetic and playlist.

How Kiro helped:

Playlist System: Built dynamic playlist rendering with all 10 local music files from assets folder
Music Playback: Implemented audio player with track selection, next song button, and now playing display
Event Delegation: Fixed button click issues by using single event listener instead of multiple handlers

Error Handling: Added graceful error messages instead of auto-skipping on audio errors
Volume Control: Set vinyl room volume to 70% for better listening experience

Séance Room - Summoning the Dead

What it does: An interactive ghost summoning experience with 11 unique spirits, probability-based encounters, danger levels, timeout mechanics, and atmospheric effects.

How Kiro helped:

Ghost Data Structure: Created 11 detailed ghost entities with unique backstories, danger levels (1-10), rarity tiers (Common, Uncommon, Rare, Very Rare), and personalized dialogue
Probability System: Implemented weighted random selection algorithm that tracks recently summoned ghosts to prevent repetition and ensure variety
Danger Mechanics: Built dynamic danger level visualization with color-coded bars, heartbeat audio that adjusts speed/volume based on threat level, and progressive vignette effects
Timeout System: Added 20-second idle timer that triggers scary glitch effects, screen shake, distorted text overlay, and warning messages if user doesn't summon
State Management: Orchestrated complex state transitions between SEANCE → SUMMONING → GHOST_ENCOUNTER with proper cleanup and media handling

Key Features:

11 Unique Ghosts: Each with custom artwork, tragic backstory, and personality
Weighted Probability: Common (40%), Uncommon (25%), Rare (20%), Very Rare (15%)
Anti-Repetition: Tracks last 3 summoned ghosts to ensure variety
Danger Levels:
- 1-2: Harmless (green) - No effects
- 3-4: Unsettling (yellow) - Light vignette
- 5-6: Dangerous (orange) - Heartbeat + medium vignette
- 7-8: Extremely Dangerous (red) - Fast heartbeat + heavy vignette
- 9-10: LETHAL (dark red) - Intense heartbeat + extreme vignette
Atmospheric Audio: Dynamic heartbeat that changes speed/volume based on danger
Visual Effects: Black vignette, screen shake, glitch animations, transition overlays
History Reveal: Players can choose to hear each ghost's tragic backstory or decline (triggers red vignette effect)
Timeout Punishment: Wait too long without summoning and face scary consequences

The Real Victory

Requiem Records isn’t just functional, it’s polished, tested, and production-ready. But the true victory wasn’t the finished product. It was the experience of building it. We enjoyed every step. There were no draining 3 AM debugging sessions, no moments of burnout, and no frustration spirals. Instead, We had meaningful discussions with Kiro about architecture, refined designs through iteration, and focused on creativity rather than wrestling with syntax. It reminded us that this is what development is supposed to feel like.

Final Thoughts

If you’re reading this and haven’t tried Kiro, the best thing you can do is stop reading and start building. I understand the skepticism, I was skeptical too. But here’s the truth: the future of development isn’t about writing more code, it’s about thinking more clearly. Kiro helps you think clearly, and when clarity becomes effortless, the code follows naturally.

Dare to witness the darkness: Deployed
If you’re brave enough… enter my GitHub crypt: Github
Summon the cursed footage here: https://www.youtube.com/watch?v=jmsIqz6gLn4

🎃 Happy Kiroween! 🎃

A CURSED TAROT

Marie Otoo — Fri, 05 Dec 2025 04:15:55 +0000

Imagine attending a Halloween party to enjoy the pumpkin pies and gooky atmosphere, devoid of online scare. It gives a party vibe with a touch of horror. Now, a characteristic spookiness could be added to the scary event and revamped with the Cursed Tarot application.

The Cursed Tarot app was built with Kiro IDE. It is a Gothic app that features a horrifying welcome page to scare users, a horrific tale, with a silent candle flickering eerily, a dark card collection from which to draw a game of electrifying fate, and a smashing zombie game. This wicked app has a Harry Potter theme in the middle, detailing the houses, named in the movie, owl-wise quizzes about the book, and pure randomness. The technological language stack iciness is loosely based on the revived COBOL to serve the backend logic of this cursed application. In addition, the Frankenstein element combines the age-old COBOL with modern HTML in an oddly eerie fashion. It is just chaotic. In an invisible note, the design consists of small ogres, vampires, and werewolves, with haunted mansions in the background.

To conclude, this subtly ghastly application is run locally on a computer with a web browser pre-installed. This is a card game that possesses obsolete technology, intertwined with current stacks for a complete goosebump-inducing experience.

Forem: kirodotdev

I Built an Interactive Learning Engine Inside an AI Chat App — Here's Every Technical Decision

Understanding the Problem Space First

Kiro: What It Actually Is and How I Used It

Designing the Widget Protocol

Phase 1: Register, don't render

Phase 2: Mount once, after streaming ends

Building a Safe Math Expression Evaluator

How recursive descent parsing works

Handling AI-Generated JSON That Isn't Quite Valid

Canvas Rendering: DPI, Coordinates, and Performance

Performance: IntersectionObserver for Animation Loops

LaTeX Rendering with KaTeX

How Kiro Actually Changed My Day-to-Day

What I'd Build Differently

The Result

Analyzing React Best Practices with Kiro Powers

Power Builder

Prompt that bringing all together

Using Kiro Powers

Running the React Best Practices on an Actual Project

Conclusion

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

The Paradigm Shift from Reactive to Proactive AI in Software Development: A Comparative Analysis of AI IDEs

A Comparative Analysis of Agentic IDE Architectures: AWS Kiro vs Cursor, Claude Code, GitHub Copilot, and Codeium

Executive Summary

Key Findings

Table of Contents

1. Introduction

1.1 The Evolution of AI Assisted Development

1.2 Research Questions

1.3 Scope

2. Subject A Overview: AWS Kiro

2.1 Background

2.2 The Spec Driven Workflow

2.3 Core Features

2.4 Value Proposition

3. Subject B Overview: Competitors

3.1 Competitive Landscape

3.2 Cursor

3.3 GitHub Copilot

3.4 Claude Code

3.5 Codeium / Windsurf

4. Point by Point Comparison

4.1 Architectural Philosophy: Reactive vs. Proactive

5. Analysis of Similarities and Differences

6. Conclusions

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

I Resurrected 1980s Teletext to Cure My Doomscrolling (Built with Kiro)

The Problem: Logic vs. Vibes

Phase 1: The Architect (Spec-to-Code)

Phase 2: The Artist (Vibe Coding)

Phase 3: The "Kiroween" Twist

The Result

Conclusion

Bringing Yahoo Chat Rooms Back to Life: How I Built Lingo with Kiro

🟣 Lingo — Bringing Yahoo Chat Rooms Back to Life for Language Learning

🧩 The Problem I Wanted to Solve

🌍 What Lingo Does

🏠 Global Language Rooms

🤖 AI Language Buddy (7 Modes of Learning)

The 7 Modes:

🎮 Mini Games (Halloween Edition)

🖥️ Retro Desktop Interface (Yahoo Messenger Vibes)

🛠️ How I Built It with Kiro

1️⃣ Vibe Coding