Forem: Asad marcus

How I Used Amazon Quick to Run a Full Security Audit on My SaaS — and Fixed 11 Vulnerabilities in One Session

Asad marcus — Tue, 05 May 2026 16:00:43 +0000

Let me be honest with you: I shipped security vulnerabilities to production and didn't know about them for months.

I've been building an AI-powered platform mostly solo for a while now. What started as a side project has grown into a legitimate SaaS product with paying users, a tiered subscription system, and a codebase that I sometimes have to squint at to remember what a file does.

Here's what the stack looks like today:

Frontend: HTML, CSS, JavaScript with Vite for bundling
Serverless backend: 30+ Edge Functions and serverless functions
Database & auth: Firebase (Firestore + Firebase Auth)
Compute: Separate cloud servers for heavier processing tasks
Integrations: OAuth flows, payment webhooks, external AI model APIs, PDF generation, code execution sandboxing

It's a lot. And like most solo developers who are simultaneously the product manager, the frontend dev, the backend dev, the designer, the support person, and the marketer... security reviews kept falling off my to-do list.

"I'll do a proper audit next sprint."
"Let me just ship this feature first."
"It's fine, the endpoints check the origin header."

Spoiler: it was not fine.

The Problem: You Can't Secure What You Can't See

Here's the thing about serverless architectures that nobody warns you about when you're starting out: every internal function call is an HTTP request.

In a traditional backend, your payment handler calls your user service calls your database layer - all in-process, all behind one API gateway. In my setup, I have edge functions calling serverless functions calling other functions, all communicating over HTTP through publicly-accessible URLs. Each of those internal calls is technically a public endpoint.

When you're building fast and shipping features, you don't think about that. You think: "This function is only called by my other function, so it's fine." But "only called by" is a design intention, not a security control. Anyone on the internet can call any of those endpoints if they know the URL pattern.

I knew this in theory. I even had some origin-checking logic in place. But I'd never done a systematic audit to verify that every sensitive endpoint was actually locked down. With 30+ serverless functions and dozens of internal calls between them, manually tracing every path felt overwhelming.

That's where Amazon Quick came in.

What Is Amazon Quick?

Before I get into the audit, let me explain the tool for those who haven't used it.

Amazon Quick is a desktop AI companion from AWS. It sits on your machine, runs locally, and connects to your actual work environment - your files, your messaging, your email, your calendar. It's not a web app you paste code into. It's a desktop application with direct access to your filesystem.

What makes it useful for something like a security review is that it's not working from snippets you copy-paste into a chat window. It has the full picture:

It can read your entire codebase because you grant it folder access on your machine
It can search inside files using content search and semantic indexing
It can write and edit files directly - no copy-pasting fixes back and forth
It can run code in a sandboxed Python environment for analysis and batch operations
It learns your project context through custom instructions you provide about your stack, conventions, and guardrails

It's the difference between showing someone a screenshot of your code and sitting them down at your desk with the full repo open.

Step 1: Setting Up the Project Context

Amazon Quick lets you set custom instructions that shape how it behaves for your specific project. Think of it like onboarding a new team member - you tell them how your project is structured, what your conventions are, and what they should and shouldn't touch.

This is the part most people rush through. They jump straight into "review my code" without any context. I've learned (the hard way, on other tasks) that spending 20 minutes on good instructions saves you hours of mediocre back-and-forth.

Here's an abbreviated version of what I configured:

# Project Agent Instructions

## Core Principles
- Be concise, practical, and action-oriented
- Ask 1-3 clarifying questions only when needed
- Prefer safe, incremental changes over large rewrites
- Respect existing patterns, file structure, and naming
- Never invent features; confirm requirements when unsure

## Project Context
- Frontend: HTML, CSS, JavaScript, Vite-based assets
- Serverless: Edge Functions and serverless functions
- Integrations: Firebase (auth, firestore), external APIs
- Multiple static HTML pages and feature pages

## Security Checklist
- Do not log secrets or PII
- Validate and sanitize all inputs (especially serverless endpoints)
- Enforce auth and authorization on protected actions
- Apply rate limiting where abuse is possible
- Use environment variables for secrets
- Flag risky patterns (eval, direct HTML injection, unrestricted CORS)

## Do Not Touch (Without Explicit Permission)
- Billing, pricing, or payment logic
- Authentication and authorization flows
- Database schema, security rules, deployment config
- API keys, secrets, or key-management code

## Output Format
For security reviews: findings list → severity → recommended fix
Always include: what you changed, where, why, and any risks

A few things I want to highlight about this approach:

The "Do Not Touch" section is critical. Quick has read and write access to my project folder. It can edit files directly. I need to be explicit about what it can analyze but not modify without asking first. This isn't about preventing mistakes - it's about building a workflow where I stay in control of the high-stakes decisions.

The conventions section saves time. When Quick finds an issue and writes a fix, it needs to know where the fix goes. Telling it your project layout means it won't create random files in the wrong place.

The output format sets expectations. "Findings list → severity → recommended fix" means I get structured output I can prioritize, not a rambling essay about security best practices.

After writing the instructions, I granted Quick access to my project folder. It could now read every JavaScript file, every HTML page, every config file - the full codebase sitting on my machine.

Step 2: The Audit - Watching Quick Think Through My Code

I told Quick: "Run a thorough security review of the project."

What happened next wasn't a single pass. Quick broke the work into distinct phases, and watching it work was honestly fascinating. It approached the problem the way a senior security engineer would.

Phase 1: Reconnaissance

First, it read the top-level project structure and key config files. It was building a mental model of the architecture: what technologies are in play, how things are deployed, where the trust boundaries are.

This matters because a security review without understanding the architecture is just pattern-matching. Quick needed to understand that my edge functions run on one runtime with one environment variable API, my serverless functions run on another, and my external compute server is a separate trust boundary entirely.

Phase 2: Critical File Deep Dive

Next, it identified and read about 20 files it considered security-critical:

Authentication logic - how users log in, how sessions work
Database rules - what's allowed and denied at the data layer
Security configuration - any existing security utilities
Serverless functions handling sensitive operations: key management, tier validation, webhook processing, URL fetching, code execution
Client-side configuration - what's exposed to the browser

It wasn't reading every file in the project. It was making smart choices about what's likely to have security implications. A marketing landing page? Probably fine. The function that handles payment webhooks? Read that very carefully.

Phase 3: Pattern Scanning

Then it searched the entire codebase for known anti-patterns:

Hardcoded secrets or API keys in source files
Missing input validation on serverless endpoints
Dangerous function usage (eval, direct HTML injection)
Unsafe data storage patterns
CORS misconfigurations
Missing authentication checks

This is the "grep for bad things" phase, but smarter. It understood context. Not every innerHTML usage is dangerous. Not every string that looks like a key is actually a key. Quick filtered the noise and focused on actual issues.

Phase 4: Call Chain Tracing

This is the phase that blew my mind.

Quick ran a codebase-wide search to map out every function-to-function HTTP call in the project. It found 94 individual internal service calls spread across 24+ files. Edge functions calling serverless functions, serverless functions calling other functions, external servers calling back into the main stack.

For each call, it checked:

Is the receiving endpoint authenticating the request?
Is the caller sending proper credentials?
What data is being exchanged?
Could an external attacker replicate this call?

This is work that would take a human hours of grep, find, file-hopping, and mental bookkeeping. Quick did it systematically in minutes and presented the results as a structured map.

Phase 5: Report

Finally, it compiled everything into a structured security audit. 11 findings, each with a severity rating, explanation of the risk, and recommended fix. It even generated an interactive HTML report I could open in a browser tab to review alongside the code.

Total audit time: about 15 minutes. For a codebase with 30+ serverless functions, dozens of internal call chains, multiple deployment targets, and several external integrations.

Step 3: The Findings - 11 Security Issues

I'm describing these at a level that's educational without being a how-to guide for attackers. If you're building a serverless app, check your own code for these patterns.

🔴 Critical: Fix Immediately

1. Insufficient Authentication on Internal API Endpoints

The most severe finding. Multiple server-to-server endpoints that handle sensitive operations - the kind that return credentials, manage access levels, control what users can do - were relying on a protection mechanism that looked secure in the code but was trivially bypassable by anyone who understands how HTTP works.

This is one of those bugs that works perfectly during normal usage. Your frontend calls the endpoint, the check passes, everything works. But it completely falls apart under adversarial conditions. It's the security equivalent of a lock that only works when people use the doorknob.

2. Unprotected Usage Management Endpoint

A critical endpoint responsible for managing user quotas, tracking consumption, and enforcing rate limits had no authentication whatsoever. Anyone who knew the URL could manipulate usage counters, bypass rate limits, or mess with other users' quotas.

This one hurt to read. I'd written the business logic perfectly - credit tracking, tier enforcement, monthly resets. But I forgot to put a lock on the front door.

🟠 High: Fix Soon

3. Redundant Secret Storage

I was doing the right thing by hashing sensitive credentials before storing them in the database. But I was also storing the raw plaintext version alongside the hash. Probably a leftover from debugging ("let me store the raw value too so I can verify the hash is working") that never got cleaned up.

A great example of something a basic scanner might miss (there's no "vulnerability" per se, just a bad practice) but a contextual review catches immediately. Quick understood what the hash was for and flagged the plaintext field as defeating the purpose.

4. Server-Side Request Forgery (SSRF) Risk

Two functions accept URLs from users and fetch them server-side - one for scraping web content, one for proxying images. Neither restricted what addresses could be fetched. In a cloud environment, this is a known risk category because server-side requests can reach internal infrastructure that public requests cannot.

5. Webhook Verification Bypass

The payment webhook handler had proper cryptographic signature verification - good. But it also had a fallback path that used a weaker verification method, probably added during development when I was testing without proper signatures. An attacker who could figure out the fallback value (not as hard as you'd think) could forge webhook events and grant themselves premium access.

6. Data Routing Mismatch

An admin function was writing to database records using one identifier scheme, but the actual schema expected a different identifier as the document key. Updates could silently land on the wrong records - or create orphaned documents. A logic bug with security implications, since it could affect who has access to what tier.

🔵 Medium and Lower

The remaining five covered:

Output sanitization patterns that could be tightened (especially for AI-generated content rendered in the browser)
CORS configuration that was more permissive than necessary at the infrastructure level
Input sanitization gaps in a code execution sandbox
An unauthenticated file upload URL generator
A database query pattern with both performance and timing side-channel implications

Not "hair on fire" urgent, but the kind of things that compound over time if left unaddressed.

Step 4: The Fix - 94 Patches Across 24 Files

Finding bugs is useful. Fixing bugs across a 30+ function codebase in one session is something else.

The Strategy

Quick proposed replacing the weak authentication on internal endpoints with a proper shared secret for server-to-server communication:

Generate a cryptographically strong random secret
Store it as an environment variable on every platform that hosts your code
Every internal HTTP call includes the secret in a custom header
Every receiving endpoint validates the secret before processing
No secret, no access - doesn't matter where the request comes from

Simple, battle-tested pattern. The challenge wasn't the concept - it was the execution at scale. 94 fetch calls across 24 files, running on different runtimes with different environment variable APIs.

The Vulnerable Pattern

Here's a simplified version of the problem. My serverless functions were calling each other over HTTP, and the "authentication" on the receiving end was insufficient:

// BEFORE: weak validation on the receiving endpoint

exports.handler = async (event) => {
    const { action } = JSON.parse(event.body);

    // This was the only protection on sensitive actions
    if (isSensitiveAction(action)) {
        const origin = event.headers.origin || '';
        if (!ALLOWED_ORIGINS.includes(origin)) {
            return { statusCode: 403, body: 'Unauthorized' };
        }
    }

    // Returns sensitive data, modifies records, etc.
    if (action === 'get-config') {
        return {
            statusCode: 200,
            body: JSON.stringify(await fetchSensitiveConfig())
        };
    }
};

The check looks like it's doing something, and during normal usage it works perfectly. But the underlying assumption - that only trusted code can call this endpoint - doesn't hold up against anyone with curl.

The Server-Side Fix

// AFTER: proper server-to-server authentication

const INTERNAL_SECRET=[REDACTED_PASSWORD]

exports.handler = async (event) => {
    const { action } = JSON.parse(event.body);

    if (isSensitiveAction(action)) {
        const provided = event.headers['x-internal-secret'] || '';
        if (!INTERNAL_SECRET || provided !== INTERNAL_SECRET) {
            console.log(`[SECURITY] Blocked ${action}`);
            return {
                statusCode: 403,
                body: JSON.stringify({ error: 'Unauthorized' })
            };
        }
    }

    // Now we know the caller is our own infrastructure
    if (action === 'get-config') {
        return {
            statusCode: 200,
            body: JSON.stringify(await fetchSensitiveConfig())
        };
    }
};

Key details: the secret comes from an environment variable (never hardcoded), the check validates against both missing secrets and wrong secrets, and security events get logged for monitoring.

The Client-Side Fix (94 Call Sites)

Every internal fetch call needed the secret header:

// BEFORE
const response = await fetch(INTERNAL_API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ action: 'sensitive-action', userId })
});

// AFTER
const response = await fetch(INTERNAL_API_URL, {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-Internal-Secret': getEnvSecret('INTERNAL_SECRET')
    },
    body: JSON.stringify({ action: 'sensitive-action', userId })
});

One subtle detail: edge functions and serverless functions in my stack use different runtime APIs to access environment variables. Quick handled this correctly for every single file - it knew which runtime each function ran in and used the right API call.

The Batch Patching Process

Here's how Quick handled 94 changes without missing one:

1. Pattern analysis. It confirmed every internal fetch call followed the same structure: a fetch() with a headers object containing 'Content-Type': 'application/json'. This consistency meant it could write a reliable batch patch.

2. Targeted script. Rather than editing each file by hand (error-prone at this scale), it wrote a script that found every relevant fetch call, identified the headers object, injected the secret header, and handled the runtime-specific env var difference automatically.

3. Verification pass. After patching, it scanned the entire codebase again:

=== VERIFICATION ===

  edge-functions/coder.js:         8 patched, 0 missing
  edge-functions/chat.js:          8 patched, 0 missing
  edge-functions/app-chat.js:      5 patched, 0 missing
  edge-functions/api.js:           4 patched, 0 missing
  edge-functions/reason.js:       11 patched, 0 missing
  edge-functions/video.js:         2 patched, 0 missing
  edge-functions/agent.js:         2 patched, 0 missing
  ... and 17 more files

  Total: 94 patched, 0 missing ✅

4. False positive detection. The scanner flagged one line as potentially unpatched. Quick investigated and found it was a call to an external third-party API that happened to sit in the same file near an internal call. It correctly identified the false positive and left it alone.

That last bit - catching its own scanner's mistake - is exactly the kind of thing that prevents "the fix broke something else" situations.

Full Scope

Category	Files	Calls Patched
Edge Functions (core)	9	42
Edge Functions (features)	11	38
Serverless Functions	4	10
External Server	2	4
Server-side endpoints	2	-
Total	28	94

Step 5: Deployment

After the code changes, Quick generated a deployment checklist:

Generate the secret. A cryptographically random 64-character string. Long enough to be unguessable, safe for environment variables.
Set environment variables on every platform that runs your code. One value, shared across all runtimes, so every internal service can both send and verify it.
Deploy. Push the code, rebuild, restart the external server.
Verify. Hit a sensitive endpoint from outside the infrastructure without the secret. Confirm it returns 403 Forbidden.

The whole deployment took about 10 minutes. Most of that was waiting for the build.

What This Experience Taught Me

Serverless Doesn't Mean Secure by Default

I think a lot of us have a subconscious assumption that serverless = managed = someone else handles security. And that's partially true - you don't patch operating systems or manage TLS certificates. But application-level security is still 100% your responsibility.

In serverless, the attack surface is actually larger than a monolith in some ways. Every function is a separate endpoint. Every internal call crosses a network boundary. There's no single API gateway enforcing authentication on internal traffic unless you build one. You have to secure each function individually, and when you have 30+ of them, it's easy to miss one.

The "It Only Works Internally" Assumption Is Dangerous

I had multiple endpoints that were "only called by other functions." No user-facing UI pointed to them. No documentation listed them. They felt internal. But they were all publicly-accessible URLs, discoverable by anyone poking around at URL patterns.

Security through obscurity isn't security. If an endpoint does something sensitive, it needs proper authentication - even if you think nobody will ever find it.

AI-Assisted Security Reviews Are a Legitimate Workflow

I was skeptical going in. I expected Quick to find the obvious stuff (hardcoded strings, missing try/catch) and miss the architectural problems. Instead, it:

Understood cross-file dependencies and traced call chains across 24+ files
Recognized runtime differences and used the correct environment variable API for each
Prioritized correctly - the severity ratings matched what a human security engineer would say
Implemented at scale - didn't just find 94 problems, it fixed all 94 with correct, context-aware patches
Self-verified by running a verification pass and catching its own false positive

Is it a replacement for a professional penetration test? No. But for a solo developer who needs to go from "I think my code is probably fine" to "I've systematically verified and fixed my internal auth," it's remarkably effective.

Good Agent Instructions Are an Investment

Twenty minutes writing project instructions saved me hours. Quick never proposed changes to files I marked as off-limits. It used the correct file paths and conventions. It formatted output exactly how I asked. It asked for confirmation before touching anything sensitive.

The difference between "here's an AI, good luck" and "here's an AI that knows your project structure, your conventions, and your boundaries" is the difference between generic advice and actionable fixes.

Regular Audits Are Now Feasible for Small Teams

My old security review cycle:

Know I should do an audit
Keep putting it off because it's time-consuming
Eventually something bad happens
Panic

My new cycle:

Open Quick, it already has access to the project folder
Run the audit (~15 minutes)
Review findings and fix (1–2 hours)
Deploy
Repeat monthly

That's a cadence I'll actually stick to.

Try This Yourself

If you want to run a similar audit on your own project:

1. Install Amazon Quick and grant folder access. It's a desktop app - once installed, go to Settings → My Computer → Local Folders and add your project directory. Quick can now read, search, and write files in that folder directly.

2. Write project instructions. Set custom instructions that describe your tech stack, file structure conventions, security concerns specific to your architecture, what Quick shouldn't touch without asking, your desired output format, and escalation triggers. Don't skip this step - the quality of the audit is directly proportional to the quality of context you provide.

3. Make sure the folder covers your full project. Config files, serverless functions, frontend code, utility libraries - it should all be under the allowed folder. The more Quick can see, the better it can trace dependencies and find issues that span multiple files.

4. Ask for a security review. Be specific: "Check all serverless functions for authentication, input validation, and access control issues. Check for secrets exposure, SSRF risks, and unsafe data handling patterns."

5. Review, fix, verify, deploy. Read each finding. Ask follow-up questions. Quick can edit the files directly and run verification scripts - no copy-pasting needed. Ship it.

The whole process - from granting folder access to deploying fixes - took me one focused evening. Your mileage will vary depending on codebase size, but the point is: this is hours, not weeks.

Final Thoughts

I shipped security vulnerabilities to production. That's embarrassing to admit publicly, but I know I'm not the only solo developer who's done it. When you're building fast, security reviews feel like a luxury - something big companies with dedicated security teams do.

Amazon Quick changed that for me. What used to be a "someday" task is now part of my regular workflow. The 11 vulnerabilities it found were real, the fixes it implemented were correct, and my users' data is safer because I finally stopped procrastinating.

If you've been putting off a security review of your own project - stop putting it off. Grant Quick access to your project folder. Ask it to review. See what it finds.

You might not like what comes back. But you'll sleep better after fixing it.

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.

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 EVI : An AI-Powered Economic Vitality Analysis Platform with Kiro

Asad marcus — Wed, 06 Aug 2025 09:47:56 +0000

How I leveraged Kiro's autonomous development capabilities to build a comprehensive economic analysis EVI tool that processes real-world data from multiple countries and generates actionable business insights

The Challenge: Making Economic Data Accessible

As a developer who recently joined the Kiro organization, I wanted to showcase how Kiro's AI-powered development environment can accelerate complex project development. I decided to build EVI (Economic Vitality Index) - a platform that analyzes the economic health of any location worldwide using real-time data and AI insights.

The challenge was ambitious: create a system that could:

Process economic data from multiple countries (EU, USA, UK, Pakistan)
Integrate with Google Maps and Places APIs for real-time business data
Generate comprehensive economic vitality scores (0-100 scale)
Provide actionable insights for businesses and investors
Handle complex data analysis and visualization
Support global coverage with fallback mechanisms
Implement secure API usage to avoid expensive charges

The Reality Check: Building this manually would have required weeks of:

Setting up Flask blueprints and database schemas
Implementing complex data processing pipelines
Managing multiple API integrations with proper error handling
Creating authentication and session management
Building data visualization and export features

Enter Kiro: My AI Development Partner

Working with Kiro transformed how I approached this complex project. Instead of spending weeks setting up boilerplate code and debugging API integrations, Kiro helped me focus on the core business logic while handling the heavy lifting.

What Kiro Brought to the Table

Autonomous Code Generation: Kiro generated complete Flask blueprints with 15+ API endpoints, comprehensive database models, and complex data processing pipelines. What would have taken days of manual coding was completed in hours with proper error handling and validation built-in.

Intelligent Architecture Decisions: When I described needing to process economic data from multiple countries, Kiro automatically structured a modular service architecture with separate handlers for EU (Eurostat), USA (Census/BEA), UK (ONS), and Pakistan (PBS) data sources.

Smart Error Handling: Kiro implemented sophisticated fallback mechanisms I hadn't considered - when Google Places API fails, it generates realistic synthetic data based on location demographics. When external APIs hit rate limits, it gracefully degrades to cached data.

Database Design: Kiro designed a comprehensive SQLAlchemy schema with 8 interconnected models for analysis history, user sessions, invite codes, and cached results - including proper indexing and relationship management.

The EVI Architecture

Here's what we built together:

Core Components

# EVI Analysis Engine - Generated with Kiro's help
@dataclass
class LocationMetrics:
    latitude: float
    longitude: float
    radius_meters: int
    business_count: int
    business_density: float
    average_rating: float
    total_reviews: int
    business_type_distribution: Dict[str, int]
    foot_traffic_index: float
    economic_activity_score: float
    infrastructure_quality: float
    accessibility_score: float
    competition_index: float
    growth_trend: float
    last_updated: datetime

@dataclass
class BusinessData:
    id: str
    name: str
    business_type: str
    latitude: float
    longitude: float
    rating: float
    review_count: int
    price_level: int
    address: str
    foot_traffic_score: float
    digital_presence_score: float
    last_updated: datetime

Multi-Source Data Integration

EVI pulls data from multiple sources with intelligent processing:

class EnhancedDataService:
    def __init__(self):
        self.eu_data = {}      # Eurostat regional data
        self.usa_data = {}     # Census & BEA data
        self.pakistan_data = {} # Pakistan Bureau of Statistics
        self.uk_data = {}      # ONS (Office for National Statistics)
        self.load_all_data()

    def get_enhanced_analysis(self, city_name: str, country_code: str):
        """Combine multiple data sources for comprehensive analysis"""
        # GDP per capita, unemployment rates, business demographics
        regional_data = self.get_regional_economic_data(city_name, country_code)
        # Population, age distribution, education levels
        demographic_data = self.get_demographic_data(city_name, country_code)
        # Business formation rates, industry composition
        business_data = self.get_business_ecosystem_data(city_name, country_code)

Data Sources Include:

Google Places API: Real-time business data, ratings, and foot traffic estimates
World Bank API: Economic indicators, development metrics, and country comparisons
Eurostat: EU regional GDP, unemployment rates, and business demographics
National Statistics: Country-specific datasets (Census, ONS, PBS)
Enhanced Processing: PDF parsing, Excel integration, and data normalization

Smart Analysis Pipeline

@evi_bp.route('/analyze', methods=['POST'])
def analyze_city():
    """Analyze a city's economic vitality with comprehensive data integration"""
    try:
        data = request.get_json()
        city_name = data.get('city')
        radius = data.get('radius', 500)

        # Multi-step analysis process
        analysis = evi_engine.calculate_evi_analysis(city_name, radius)

        # Enhanced with real economic data
        enhanced_data = enhanced_data_service.get_enhanced_analysis(
            city_name, 
            analysis.country_code
        )

        # Auto-save comprehensive history
        history_record = AnalysisHistory(
            city_name=city_name,
            evi_score=analysis.evi_score,
            business_vitality=analysis.business_vitality,
            economic_stability=analysis.economic_stability,
            growth_potential=analysis.growth_potential,
            risk_level=analysis.risk_level.value,
            investment_grade=analysis.investment_grade,
            business_density=analysis.location_metrics.business_density,
            foot_traffic_index=analysis.location_metrics.foot_traffic_index,
            competition_index=analysis.location_metrics.competition_index,
            # ESG scoring integration
            esg_overall=enhanced_data.get('esg_score', {}).get('overall', 0),
            confidence_level=analysis.confidence_level
        )

        return jsonify({'success': True, 'data': result})
    except Exception as e:
        return jsonify({'error': str(e)}), 500

Key Features We Built

Economic Vitality Scoring Algorithm

EVI generates a comprehensive 0-100 score by analyzing:

Business Vitality (25%): Density, diversity, and health of local businesses
Economic Stability (25%): Employment rates, income levels, economic resilience
Growth Potential (25%): Demographic trends, infrastructure development, investment flow
Risk Assessment (25%): Market volatility, regulatory environment, competition intensity

def calculate_evi_score(self, location_metrics, enhanced_data):
    """Calculate comprehensive EVI score with weighted components"""
    business_vitality = self._calculate_business_vitality(location_metrics)
    economic_stability = self._calculate_economic_stability(enhanced_data)
    growth_potential = self._calculate_growth_potential(enhanced_data)
    risk_factors = self._calculate_risk_factors(location_metrics, enhanced_data)

    evi_score = (
        business_vitality * 0.25 +
        economic_stability * 0.25 +
        growth_potential * 0.25 +
        (100 - risk_factors) * 0.25
    )

    return min(100, max(0, evi_score))

Multi-Dimensional Analysis Engine

Business Ecosystem Mapping: 12+ business categories with density analysis
Demographic Integration: Age distribution, education levels, income brackets
Infrastructure Assessment: Transportation, utilities, digital connectivity
Competition Analysis: Market saturation, pricing trends, opportunity gaps
ESG Scoring: Environmental, Social, and Governance factors

Global Coverage with Smart Localization

200+ Major Cities: Pre-configured with local economic data
Fallback Generation: AI-powered synthetic data when APIs are unavailable
Multi-Language Support: Handles international city names and addresses
Currency Normalization: Converts all economic indicators to USD equivalents

📈 Advanced Analytics & Reporting

Trend Analysis: 12-month historical tracking with seasonal adjustments
Comparative Analysis: Side-by-side city comparisons with benchmarking
Export Capabilities: PDF reports, Excel dashboards, API data feeds
Real-time Updates: Live data refresh with change notifications

Enterprise-Grade Features

Kiro helped implement production-ready features:

Authentication System: Multi-tier access (admin, invite-based, public)
Rate Limiting: API usage controls to prevent abuse
Caching Layer: Redis integration for performance optimization
Email Integration: Automated reports and notifications
Admin Dashboard: Real-time system monitoring and user management

The Kiro Advantage in Action

Before Kiro:

Manual API integration and error handling
Hours spent on boilerplate Flask setup
Complex data processing logic written from scratch
Debugging authentication and session management

With Kiro:

Automated blueprint generation with proper error handling
Intelligent fallback mechanisms for API failures
Pre-built authentication and session management
Smart data processing pipelines

Real Example: API Integration

When I needed to integrate the Google Places API safely (avoiding expensive charges), I simply described my requirements to Kiro:

"I need to fetch business data using Google Places API but only use free fields to avoid charges"

Kiro generated:

def fetch_real_business_data(self, lat: float, lng: float, radius: int = 500):
    """
    Fetch real business data using Google Places API with STRICT controls 
    to avoid expensive SKUs. ONLY uses the most basic free fields.
    """
    try:
        places_result = gmaps.places_nearby(
            location=(lat, lng),
            radius=radius,
            type='establishment'
        )

        # Process only free fields to avoid charges
        for place in places_result.get('results', []):
            # Only access confirmed free fields
            geometry = place.get('geometry', {})
            name = place.get('name', f'Business {i+1}')
            rating = place.get('rating', 0.0)
            # ... safe field processing

Performance & Scalability

EVI handles:

Real-time analysis of any global location
Multi-source data integration from 4+ different APIs
Intelligent caching to optimize API usage
Fallback mechanisms when external services are unavailable

What's Next?

The EVI platform demonstrates how Kiro can accelerate complex, data-driven application development. Future enhancements include:

Machine learning models for predictive analysis
Enhanced ESG (Environmental, Social, Governance) scoring
Real-time market sentiment analysis
Mobile app development

Try It Yourself

The beauty of working with Kiro is that complex projects become manageable. Whether you're building:

Data analysis platforms
API-heavy applications
Multi-service integrations
Complex business logic

Kiro's autonomous development capabilities can help you focus on what matters: solving real problems with code.

Want to see EVI in action? The platform analyzes economic vitality for any location worldwide, providing insights that help businesses make informed decisions about expansion, investment, and market entry.

Interested in Kiro? Join the organization and experience AI-powered development that actually accelerates your workflow instead of getting in the way.

What complex project would you build with an AI development partner? Share your ideas in the comments!

NOTE : This blog is made with Kiro IDE.

kiro #ai #programming #flask #python #economic-analysis #api-integration #data-science #startup #development

Forem: Asad marcus

How I Used Amazon Quick to Run a Full Security Audit on My SaaS — and Fixed 11 Vulnerabilities in One Session

The Problem: You Can't Secure What You Can't See

What Is Amazon Quick?

Step 1: Setting Up the Project Context

Step 2: The Audit - Watching Quick Think Through My Code

Phase 1: Reconnaissance

Phase 2: Critical File Deep Dive

Phase 3: Pattern Scanning

Phase 4: Call Chain Tracing

Phase 5: Report

Step 3: The Findings - 11 Security Issues

🔴 Critical: Fix Immediately

🟠 High: Fix Soon

🔵 Medium and Lower

Step 4: The Fix - 94 Patches Across 24 Files

The Strategy

The Vulnerable Pattern

The Server-Side Fix

The Client-Side Fix (94 Call Sites)

The Batch Patching Process

Full Scope

Step 5: Deployment

What This Experience Taught Me

Serverless Doesn't Mean Secure by Default

The "It Only Works Internally" Assumption Is Dangerous

AI-Assisted Security Reviews Are a Legitimate Workflow

Good Agent Instructions Are an Investment

Regular Audits Are Now Feasible for Small Teams

Try This Yourself

Final Thoughts

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

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 EVI : An AI-Powered Economic Vitality Analysis Platform with Kiro

The Challenge: Making Economic Data Accessible

Enter Kiro: My AI Development Partner

What Kiro Brought to the Table

The EVI Architecture

Core Components

Multi-Source Data Integration

Smart Analysis Pipeline

Key Features We Built

Economic Vitality Scoring Algorithm