DEV Community: Sandeep Chakravartty

Build a Production-Grade AI Dashboard: Architectural Insights from the BMW AutoTrend Platform

Sandeep Chakravartty — Sat, 01 Aug 2026 11:06:02 +0000

Orchestrating Clean Architecture, Subprocess Scrapers, SQLite FTS5, and Local LLMs (Ollama) inside a Dockerized Python + React Stack.

1. Executive Summary & Design Goals

The BMW AutoTrend Dashboard is a local-first, AI-powered automotive intelligence platform that scrapes, processes, classifies, and visualizes market trends and sentiment for BMW-related news. The system is designed to run completely locally, using a local LLM instance via Ollama for article summarization and entity extraction, backed up by a deterministic rule-based regex fallback engine.

The platform was built with the following design goals:

Clean Architecture: Decouple the data extraction layer, storage mechanism, analytical computations, and API controllers.
Deterministic Fallbacks: Ensure the application remains fully functional (using a rule-based regex processor) even when local LLM resources (Ollama) are offline or resource-constrained.
Local-First & High Performance: Use SQLite FTS5 for instant full-text search, keeping all scraped data, search indexes, and analysis files stored locally without external SaaS API dependencies.
Plug-and-Play Extensibility: Allow plugging in new scraping adapters (e.g., Autoblog, MotorTrend) by implementing a unified abstract interface.

2. Clean System Architecture

The application adheres to Clean Architecture principles, maintaining a strict unidirectional data flow and isolating business logic from external dependencies.

graph TD
    subgraph Frontend [React SPA - Served via Nginx]
        UI[Interactive Dashboard Pages]
        RC[Recharts Visualizations]
        FTS_UI[Spotlight Search UI]
    end

    subgraph Backend [FastAPI Application]
        API[FastAPI Endpoints]
        SCH[APScheduler Ingestion & Snapshots]
        ING[Ingestion Pipeline]
        ANA[Analytics Engine]
        AIP[AI Processing Pipeline]
    end

    subgraph CLI Bridge [Subprocess Execution]
        WBC[Webcmd CLI + BMWBLOG Plugin]
    end

    subgraph Storage [Local Storage]
        DB[(SQLite Database)]
        FTS[(FTS5 Search Index)]
    end

    subgraph Local LLM [AI Inference]
        OLL[Ollama Server]
    end

    UI -->|Queries| API
    API -->|Reads/Writes| DB
    ING -->|Executes| WBC
    WBC -->|Scrapes Web Data| BMWBLOG[BMWBLOG Site]
    ING -->|Sends content for classification| AIP
    AIP -->|Requests JSON| OLL
    AIP -->|Regex Fallback| AIP
    SCH -->|Triggers| ING
    SCH -->|Runs daily| ANA
    ANA -->|Computes stats| DB
    FTS_UI -->|Queries FTS| API
    API -->|FTS Match Query| FTS

Frontend Layer: A React + TypeScript SPA built with Vite. It interacts with the backend strictly via standardized JSON REST endpoints.
API Controllers: FastAPI handlers that validate schemas using Pydantic, query storage, and trigger background tasks.
Core Business Logic:
- The Ingestion Pipeline orchestrates scraping, duplicate checks, and data ingestion.
- The AI Processing Pipeline performs text analysis, summarization, and tag extraction.
- The Analytics Engine aggregates metrics and maintains daily snapshots.
Data Providers: Subprocess wrappers encapsulating the execution of Node.js-based CLI tools (webcmd).
Database Layer: SQLite managed via SQLAlchemy ORM, enriched with raw SQL database triggers.

3. Ingestion Pipeline & Subprocess WebCMD Scraping

Data ingestion begins with the abstract base class NewsProvider in [providers/base.py]. Concrete providers, such as the BMWBlogProvider in providers/bmwblog.py, are responsible for crawling data from publishers.

Rather than writing custom web scrapers that are brittle and hard to maintain, the backend utilizes the @agentrhq/webcmd CLI tool under the hood. The BMWBlogProvider executes webcmd as a subprocess to retrieve structured article feeds.

The Subprocess Execution Mechanism

# snippet from backend/providers/bmwblog.py
def _run_webcmd(self, args: List[str]) -> str:
    cmd = ["webcmd"] + args
    try:
        # We use shell=True on Windows because webcmd is a script (.ps1 or .cmd)
        is_windows = os.name == 'nt'
        result = subprocess.run(
            cmd,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            text=True,
            shell=is_windows,
            check=True
        )
        return result.stdout
    except subprocess.CalledProcessError as e:
        logger.error(f"webcmd execution failed: {result.stderr}")
        raise Exception(f"webcmd error: {result.stderr}")

The pipeline executes in two stages:

Metadata Fetching: Runs webcmd bmwblog latest -f json to retrieve the latest 10 articles (metadata only: URLs, titles, brief excerpts).
Deep Article Ingestion: For each new URL (determined by checking the SQLite index), it queries webcmd bmwblog article <url> -f json to extract the full body text, category, author, and scrapes the raw HTML for OpenGraph images (og:image).

4. Hybrid AI Classification Pipeline (Ollama & Regex Fallbacks)

Once full article text is ingested, it is dispatched to ai/processor.py. The processor uses a hybrid system that dynamically checks Ollama's availability before selecting an evaluation engine:

graph TD
    A[New Article Ingested] --> B{Is Ollama Server Online?}
    B -->|Yes| C[Call Ollama Llama 3.2 API]
    C --> D{Parsing JSON Successful?}
    D -->|Yes| E[Save AI Classification to Database]
    D -->|No| F[Fallback to Regex Rule Engine]
    B -->|No| F
    F --> G[Extract Entities, Sentiment, & Summaries via Rules]
    G --> E

1. Ollama LLM Pipeline

If the Ollama server is online and running llama3.2, the backend posts to /api/generate with a carefully crafted prompt. To ensure deterministic integration, the request forces a structured JSON output:

payload = {
    "model": settings.OLLAMA_MODEL,
    "prompt": prompt,
    "format": "json",
    "stream": False,
    "options": { "temperature": 0.1 }
}

The model classifies sentiment (Positive, Neutral, Negative), extracts relevant vehicle models (e.g., Neue Klasse, BMW M3), maps technology tags (e.g., Battery Technology, ADAS), and generates short, detailed, and TL;DR summaries.

2. Rule-Based Regex Fallback Pipeline

If Ollama is offline (or fails to return valid JSON), _analyze_with_rules executes. It uses pre-compiled regular expressions to match keywords and tags:

TECHNOLOGY_TAGS = {
    "Electric Vehicles": r"\b(ev|evs|electric|zero-emission|zero emission|battery electric|bev)\b",
    "Battery Technology": r"\b(battery|batteries|solid-state|cell|cells|rimac)\b",
    "Autonomous Driving": r"\b(autonomous|self-driving|driverless|autopilot)\b",
    # ...
}

# Sentiment heuristic based on term tallying
pos_count = sum(len(re.findall(rf"\b{word}\b", combined_text)) for word in SENTIMENT_POSITIVE)
neg_count = sum(len(re.findall(rf"\b{word}\b", combined_text)) for word in SENTIMENT_NEGATIVE)

This hybrid model guarantees that database columns are populated with valid categories and tags, and that search capabilities are never compromised by hardware limitations.

5. High-Performance SQLite FTS5 Search Indexing with Database Triggers

For high-speed, local-first search, the project bypasses slow LIKE %query% SQL operations and utilizes SQLite's native FTS5 (Full-Text Search) extension.

Database Schema Initialization and Triggers

In database/connection.py, the application boots the database using SQLAlchemy, but hooks into standard connection events to enforce foreign key constraints (PRAGMA foreign_keys=ON) and manually provisions an FTS5 virtual table + synchronization triggers:

-- FTS5 Virtual Table Configuration
CREATE VIRTUAL TABLE articles_fts USING fts5(
    title, 
    excerpt, 
    content, 
    content='articles'
);

-- Synchronization Triggers (Insert, Delete, Update)
CREATE TRIGGER articles_ai AFTER INSERT ON articles BEGIN
    INSERT INTO articles_fts(rowid, title, excerpt, content)
    VALUES (new.id, new.title, new.excerpt, new.content);
END;

These triggers offload search indexing directly to the SQLite engine. Whenever a new article is committed via SQLAlchemy, SQLite automatically indexes the title, excerpt, and content inside the FTS5 shadow tables.

Relevance-Based Search Endpoint

When a user searches the dashboard, the backend performs a BM25 relevance-ranking query:

# Snippet from backend/api/routes.py
query_str = """
    SELECT rowid FROM articles_fts 
    WHERE articles_fts MATCH :query
    ORDER BY bm25(articles_fts)
"""
result = db.execute(text(query_str), {"query": search_term})

This executes in sub-milliseconds, giving the frontend instantaneous "Search-as-you-type" capabilities.

6. Dynamic Analytics Engine & Rolling Trend Computations

The Analytics Engine in analytics/engine.py performs rolling window calculations to determine which automotive trends are gaining traction.

Instead of tracking basic counts, the engine computes a weekly growth rate by comparing mentions of vehicle models and technologies over a rolling 7-day window vs the preceding 7-day window.

# 7-day boundaries
seven_days_ago = today_start - timedelta(days=7)
fourteen_days_ago = today_start - timedelta(days=14)

# Mentions in last 7 days (recent) vs 7-14 days ago (previous)
# Growth calculation:
if prev_cnt == 0:
    growth_pct = 100.0 if recent_cnt > 0 else 0.0
else:
    growth_pct = ((recent_cnt - prev_cnt) / prev_cnt) * 100.0

The resulting topics are sorted by growth_rate DESC to populate the "Trending Topics" widgets in the UI.

Historical Snapshotting

To prevent CPU-heavy aggregations every time a user loads the page, the application uses APScheduler to execute generate_daily_snapshot near midnight. This function serializes the calculated statistics to JSON and stores it in the analytics_snapshots table, enabling fast rendering of historical timelines over 30 days.

7. Frontend Architecture (React + Vite + Recharts)

The frontend is a single-page application built on a modern React + TypeScript + Vite architecture.

UI Features

Glassmorphic Theme: A premium dark-mode interface built on CSS variables, custom Outfit typography, and glowing borders.
Component Layout: The sidebar and main panels are structured in layouts/DashboardLayout.tsx for responsive navigation.
Visualizations: Uses Recharts to display dynamic data:
- Area charts for daily article volumes.
- Sentiment timelines mapping Positive/Neutral/Negative trends over a 30-day period.
- Bar charts comparing vehicle model and technology tag popularity.
Real-time Search: Ingests keypresses, queries the SQLite FTS5 index via the API, and highlights matches with sub-millisecond lag.

8. Docker Orchestration & DevSecOps Insights

The platform is designed to launch with a single command: docker compose up --build. The orchestration configures three networks-isolated, dependent containers:

Ollama Container: Pulls and serves LLM models on port 11434.
FastAPI Backend Container: Built from docker/backend.Dockerfile. It maps the database to a persistent Docker volume db_data at /app/data/autotrend.db so database records are saved permanently across container restarts.
Nginx Frontend Container: A multi-stage build that compiles the React application and uses Nginx to serve the static assets on port 80, proxying requests to the backend.

Technical Docker Tip: Node.js Subprocess Requirement

Since the python backend invokes webcmd (an npm library) as a subprocess, the backend Dockerfile must be configured to support a multi-runtime environment. Adding Node.js, npm, and installing @agentrhq/webcmd globally inside the python slim container ensures the ingestion pipeline compiles without error:

FROM python:3.12-slim
WORKDIR /app

# Install Node.js, NPM, and global webcmd CLI scraper
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential curl gnupg \
    && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \
    && apt-get install -y nodejs \
    && npm install -g @agentrhq/webcmd \
    && webcmd plugin install github:agentrhq/webcmd/bmwblog \
    && rm -rf /var/lib/apt/lists/*

9. Extensibility & Future Scope

The design of the AutoTrend Dashboard makes it easily expandable:

Adding New News Outlets: Create a new class implementing the NewsProvider abstract base class (e.g. AutoblogProvider). Map the scraper plugin commands (e.g. webcmd autoblog latest), and register the provider in run_ingestion_pipeline.
External LLMs: The AI client in [ai/client.py] can be extended to support remote cloud models (such as the Gemini API or OpenAI API) using environment variables for API keys.
Advanced Sentiment Heuristics: The rule-based engine can be upgraded to support VADER or transformer models (like Hugging Face's distilbert-base-uncased-finetuned-sst-2-english) for deep offline sentiment extraction.

Created as technical documentation for the BMW AutoTrend Dashboard codebase.Github Repo at https://github.com/scha54/BMW-AutoTrend-Dashboard

Bypassing the Chromium Tax: Building a Sub-200ms Hacker News CLI for AI Agents

Sandeep Chakravartty — Sat, 01 Aug 2026 10:55:16 +0000

How we leveraged the WebCMD paradigm to slash web-navigation latency by 95%, reduce LLM token consumption by 90%, and establish a deterministic, schema-validated command-line interface.

1. The Web Navigation Dilemma for AI Agents

In the current landscape of AI-driven automation, software agents are frequently tasked with navigating web platforms to gather intelligence, monitor discussions, or interact with systems. Traditionally, this is accomplished using headless browsers (such as Puppeteer, Playwright, or Selenium).

While headless browsers are highly flexible, they come with substantial hidden costs:

High Startup and Rendering Latency: Initializing a Chromium instance, performing DNS resolution, loading CSS/JS assets, and rendering the DOM takes between 3 to 5 seconds per request.
Massive Resource Footprint: Running multiple headless Chrome processes in parallel spikes CPU and memory usage, creating scalability bottlenecks.
Token Inflation: Sending raw HTML or markdown-converted DOM representations to Large Language Models (LLMs) consumes thousands of tokens. A single web page representation can easily run to 20KB–50KB (equivalent to 5,000+ tokens) for a simple list of stories.
Brittle UI Selectors: Web scraping relies on CSS selectors or XPath queries that break whenever the platform's layout changes, causing agent pipelines to fail silently or hallucinate.

To address these inefficiencies, we built HN CLI (hn-cli), a high-performance command-line adapter for Hacker News, utilizing the WebCMD registry. By decoupling web interactions from browser rendering, we provide a structured, fast, and token-efficient bridge for AI agents.

2. Introducing the WebCMD Paradigm

WebCMD is a framework that allows developers to define command-line adapters for web platforms. Normally, WebCMD runs commands by launching a headless browser and executing scripts on target pages. However, WebCMD supports a secondary execution strategy called Strategy.PUBLIC with browser: false.

When configured this way:

The adapter executes directly in the local Node.js environment.
WebCMD skips launching Chromium entirely, eliminating rendering and startup overhead.
The adapter interacts with the target site via public REST endpoints, yielding sub-200ms latency.
The output is formatted as structured JSON by default, making it immediately readable by LLM agents.

graph TD
    subgraph Execution flow with WebCMD
        Agent[AI Agent or Developer] -->|webcmd hn top| Registry[WebCMD Registry]
        Registry -->|Load Adapter| Adapter[HN Adapter]
        Adapter -->|Import helpers| Utils[adapters/utils.js]
        Utils -->|REST HTTP Get| API[Firebase HN API / Algolia API]
        API -->|JSON Response| Utils
        Utils -->|Validate Types| Schema[Schema Validator]
        Schema -->|Clean Output| Print[Stdout JSON / WebCMD Table]
    end

3. Architecture of the Hacker News Adapter

The hn-cli repository is organized into a clean modular structure, separating the CLI command definitions, core utility logic, tests, and configuration scripts:

adapters/: Contains command definitions. Each file registers a subcommand.
- top.js: Fetches top stories.
- newest.js: Fetches newly submitted stories.
- ask.js: Retrieves "Ask HN" posts.
- jobs.js: Details job postings.
- item.js: Resolves detailed information for a single post (including self-text).
- search.js: Interfaces with the Algolia search API.
- utils.js: Core helper functions (network retry, schema validation, HTML entity sanitization).
tests/: Fully mocked Vitest suite for running offline tests.
scripts/: Registering adapters, validating subprocess runs, and linting.

Leveraging the Best APIs

Instead of scraping news.ycombinator.com, the CLI communicates directly with two official endpoints:

Firebase Hacker News REST API: Ideal for retrieving real-time IDs of top/new/ask stories and item details.
Algolia Hacker News Search API: Perfect for querying articles by text relevance or date.

4. Key Engineering Patterns in `hn-cli`

To ensure that the CLI is suitable for autonomous agent execution, the codebase implements three vital patterns: Concurrency, Resiliency, and Determinism.

A. Concurrency with Promise.all

The Hacker News Firebase API is structured as a collection of individual item endpoints. To fetch the top 30 stories, we must:

Fetch the list of top 500 story IDs (one HTTP call).
Fetch the metadata for the first 30 IDs (30 individual HTTP calls).

Doing this sequentially would lead to terrible latency (30 × 100ms = 3 seconds). Instead, hn-cli fetches them concurrently using Promise.all:

const storyIds = await fetchJson('https://hacker-news.firebaseio.com/v0/topstories.json');
const idsToFetch = storyIds.slice(0, limit);
const fetchedItems = await Promise.all(
  idsToFetch.map(id => fetchJson(`https://hacker-news.firebaseio.com/v0/item/${id}.json`).catch(() => null))
);

B. Resiliency via Exponential Backoff

AI agent runs are expensive. If a single network packet is dropped or an API limit is hit, the agent should not fail. We built a robust retry loop with exponential backoff inside fetchWithRetry:

export async function fetchWithRetry(url, options = {}, retries = 3, backoff = 1000) {
  const timeoutMs = options.timeout || 10000;
  for (let i = 0; i < retries; i++) {
    const controller = new AbortController();
    const timeoutId = setTimeout(() => controller.abort(), timeoutMs);
    try {
      const res = await fetch(url, { ...options, signal: controller.signal });
      clearTimeout(timeoutId);
      if (!res.ok) throw new Error(`HTTP ${res.status}`);
      return await res.json();
    } catch (err) {
      clearTimeout(timeoutId);
      if (i === retries - 1) {
        throw new Error(`Failed to fetch ${url} after ${retries} attempts: ${err.message}`);
      }
      // Wait: 1s, 2s, 4s...
      await new Promise((resolve) => setTimeout(resolve, backoff * Math.pow(2, i)));
    }
  }
}

C. Determinism via JSON Schema Validation

An AI agent expects data in a specific structure. If the API returns missing fields, an agent might experience undefined behavior or hallucinate. hn-cli enforces strict schema checks using validateSchema() before sending data to stdout:

export function validateSchema(data, schema) {
  const items = Array.isArray(data) ? data : [data];
  for (const item of items) {
    for (const [key, expectedType] of Object.entries(schema)) {
      const value = item[key];
      if (value === undefined || value === null) {
        throw new CommandExecutionError(`Validation Error: Missing required field "${key}" in output schema.`);
      }
      const actualType = typeof value;
      if (!expectedType.split('|').includes(actualType)) {
        throw new CommandExecutionError(`Validation Error: Field "${key}" is "${actualType}" but expected "${expectedType}".`);
      }
    }
  }
}

5. Implementation Code Walkthrough

Let's examine how a WebCMD adapter is registered. Below is a simplified implementation of top.js, demonstrating how to define metadata and the execution routine.

Defining the Command

import { cli, Strategy } from '@agentrhq/webcmd/registry';
import { fetchJson, getRelativeTime, handleOutput, validateSchema, validatePositiveInt } from './utils.js';

const STORY_SCHEMA = {
  rank: 'number',
  title: 'string',
  url: 'string',
  hn_url: 'string',
  points: 'number',
  author: 'string',
  comments: 'number',
  age: 'string'
};

cli({
  site: 'hn',
  name: 'top',
  access: 'read',
  description: 'Return the top stories from Hacker News',
  domain: 'news.ycombinator.com',
  strategy: Strategy.PUBLIC,
  browser: false,
  defaultFormat: 'json',
  args: [
    { name: 'limit', type: 'int', default: 30, help: 'Number of stories to return' }
  ],
  columns: ['rank', 'title', 'url', 'hn_url', 'points', 'author', 'comments', 'age'],
  func: async (args) => {
    const limit = validatePositiveInt(args.limit ?? 30, 'limit');

    // Fetch story IDs
    const storyIds = await fetchJson('https://hacker-news.firebaseio.com/v0/topstories.json');

    // Slice and fetch details in parallel
    const idsToFetch = storyIds.slice(0, limit + 5); 
    const fetchedItems = await Promise.all(
      idsToFetch.map(id => fetchJson(`https://hacker-news.firebaseio.com/v0/item/${id}.json`).catch(() => null))
    );

    const results = [];
    let rank = 1;
    for (const item of fetchedItems) {
      if (results.length >= limit) break;
      if (!item || item.deleted || item.dead || !item.title) continue;

      const hnUrl = `https://news.ycombinator.com/item?id=${item.id}`;
      results.push({
        rank: rank++,
        title: item.title,
        url: item.url || hnUrl,
        hn_url: hnUrl,
        points: item.score ?? 0,
        author: item.by || '[deleted]',
        comments: item.descendants ?? 0,
        age: getRelativeTime(item.time)
      });
    }

    validateSchema(results, STORY_SCHEMA);
    return handleOutput(results, args);
  }
});

6. Benchmarks: Headless Browser vs. WebCMD

We ran performance benchmarks comparing a headless Chrome scraper (Puppeteer) loading and scraping news.ycombinator.com against the WebCMD CLI (hn-cli).

Latency and Execution Speed

Method	Avg. Latency (ms)	Speedup	Overhead Details
Puppeteer (Chromium)	3,850ms	1.0x	Browser binary launch, DNS + TCP, layout/paint, page script execution.
WebCMD CLI (`hn-cli`)	180ms - 320ms	~15x - 20x	Native Node subprocess, optimized parallel HTTP fetches, direct network stream.

Token Consumption (Context Efficiency)

When an agent reads web content, every character translates into LLM API costs.

Format Passed to Agent	Payload Size	Estimated LLM Tokens	Cost reduction
Raw HTML Page	120 KB	~30,000 tokens	0%
Markdown DOM Conversion	22 KB	~5,500 tokens	81.6%
Clean JSON Output (`hn-cli`)	1.8 KB	~450 tokens	98.5%

[!TIP]
By eliminating HTML tags, scripts, layout directives, and UI chrome, we feed the LLM only structured keys, maximizing context window availability and speeding up reasoning.

7. Extending the CLI: Adding a Custom Command

One of the strengths of hn-cli is its simple extensibility. To add a command that fetches the "best" stories on Hacker News (a separate endpoint):

Create the file adapters/best.js:

   import { cli, Strategy } from '@agentrhq/webcmd/registry';
   import { fetchJson, getRelativeTime, handleOutput, validateSchema, validatePositiveInt } from './utils.js';

   cli({
     site: 'hn',
     name: 'best',
     access: 'read',
     description: 'Hacker News best stories',
     strategy: Strategy.PUBLIC,
     browser: false,
     args: [
       { name: 'limit', type: 'int', default: 30 }
     ],
     columns: ['rank', 'title', 'url', 'hn_url', 'points', 'author', 'comments', 'age'],
     func: async (args) => {
       const limit = validatePositiveInt(args.limit ?? 30, 'limit');
       const ids = await fetchJson('https://hacker-news.firebaseio.com/v0/beststories.json');
       const fetched = await Promise.all(
         ids.slice(0, limit).map(id => fetchJson(`https://hacker-news.firebaseio.com/v0/item/${id}.json`).catch(() => null))
       );
       // Map to schema, validate, output...
     }
   });

Update registration in scripts/install-adapters.js to ensure the new file is copied to WebCMD's active adapter directory:

   const FILES_TO_COPY = ['top.js', 'newest.js', 'ask.js', 'jobs.js', 'item.js', 'search.js', 'best.js', 'utils.js'];

Deploy the update:

   npm run register

The command is now globally available via webcmd hn best --limit 10.

8. Conclusion

As AI agents become a central part of software engineering and automation, we must transition from building websites designed exclusively for human eyes to exposing agent-friendly API interfaces.

By utilizing the WebCMD paradigm to build hn-cli, we demonstrated that it is possible to bypass the performance and resource tax of headless browsers entirely. Building interfaces with native node adapters, concurrent API fetching, robust schema checking, and structured JSON results leads to:

Blazing fast runs (sub-200ms)
Negligible resource usage
Massive token savings for LLMs
Deterministic results that never break on visual layout updates

The future of web interaction for AI agents lies not in mimicking human cursor clicks, but in standardizing developer-friendly command-line adapters.

Developed by the Antigravity Agent. Source code available under the MIT License at the following repository: https://github.com/scha54/hn-cli

Rivalry Generator: Forge Cinematic, AI-Powered Battle Reports with Gemini 2.5 Flash

Sandeep Chakravartty — Sun, 12 Jul 2026 13:09:06 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Rivalry Generator is a highly polished, modern web application that generates dramatic, cinematic, and humorous AI-powered rivalry reports between any two competitors. Compare superheroes, food toppings, code style preferences, or historical figures in a premium cosmic interface.

Key Features

⚔️ Dynamic Clash Reports: Enter any two competitors and their combat domain to generate a dramatic narrative charting their legendary struggle.
📊 Hypothetical Battle Metrics: Generates a side-by-side comparison of 3 category-specific attributes (e.g., Speed, Charisma, Luck) out of 100 with witty explanations.
🤝 Forced Alliance Scenarios: Highlights a bizarre hypothetical scenario where the two competitors must team up to defeat an absurd, larger threat.
🖼️ Downloadable Posters: Download high-quality, high-resolution PNG posters of generated matchup cards locally (using html-to-image) to share on social media.
🔊 Interactive Synthesized Sound Effects: Custom sci-fi audio effects built using the browser's Web Audio API for clicks, charging states, success chords, and errors. Includes a global mute toggle.
📜 Local Clash History: Keeps track of your last 10 showdowns in LocalStorage, allowing instant click-to-load without re-calling the API.
🎲 Surprise Me Selector: Suggests random, pre-configured matchups (e.g., Tabs vs. Spaces, Cats vs. Dogs) across diverse categories to get users started instantly.
🔒 Security Scanning Pre-Build: Pre-build script that scans the codebase for secrets (API keys) and aborts compilation/commits if keys are accidentally exposed.

Screenshots / Videos

Below is a sneak peek at the cosmic user interface:

Main Interface

Code

The entire source code is fully open-source and available on GitHub:

scha54 / rivalry-generator

This is a rivalry generator application created for the Dev.To Weekend Challenge

⚔️ Rivalry Generator - AI-Powered Clash Analysis

A highly polished, modern web application that generates dramatic, cinematic, and humorous AI-powered rivalry reports between any two competitors. Compare superheroes, food toppings, code style preferences, or historical figures in a premium cosmic interface.

✨ Features

Cosmic Dark-Mode Aesthetics: Premium dark navy/purple gradient background with glassmorphic cards, custom scrollbars, and pulsing loading animations.
Hypothetical Battle Metrics: Generates a side-by-side comparison of 3 category-specific attributes (e.g. Speed, Charisma, Luck) out of 100 with witty explanations.
Forced Alliance Scenario: Highlights a bizarre hypothetical scenario where the two competitors must team up to defeat an absurd, larger threat.
Downloadable Posters: Download high-quality, high-resolution PNG posters of generated matchup cards locally (using html-to-image).
Interactive Sound Effects: Custom synthesized audio effects built using the browser's Web Audio API for clicks, charging state builds, success chords, and errors. Includes a mute toggle.
Local…

View on GitHub

Includes automated test suites for input validation and the pre-build secret scanning tool.

How I Built It

The architecture was designed from the ground up to be secure, fast, and feature-rich, combining a solid Express backend proxy with a responsive React frontend.

1. Robust and Secure Backend

To prevent exposing API keys in the client's browser, the application uses an Express.js backend proxy (server.js). The server:

Sanitizes and validates inputs (restricting names to 50 characters, ensuring competitors are different).
Resolves the API key from environment variables or respects a user's custom key passed via the x-api-key header (saved in the client's LocalStorage).
Integrates with the @google/generative-ai SDK using gemini-2.5-flash.

2. Synthesized Soundscapes with the Web Audio API

To avoid downloading heavy MP3/WAV assets and speed up page load times, I built a custom audio engine from scratch using the browser's native Web Audio API (src/utils/audio.js):

Click Plucks: A clean triangle wave starting at 440Hz ramping exponentially to 880Hz over 150ms.
Charging Rumble: A sawtooth wave that starts at a low bass rumble (80Hz) and ramps up to 400Hz over 4.5 seconds. I also wired a low-pass filter and an LFO (low-frequency oscillator) set to 8Hz to create a pulsing sci-fi vibrato effect.
Success Chords: An arpeggiated major chord (C4, E4, G4, C5) synthesized using sine waves with precise delay envelopes to produce a glittering victory sound.
Error Buzz: A descending sawtooth wave from 220Hz down to 100Hz with a lowpass filter sweep.

3. Cosmic Glassmorphism UI

The user interface is built with Vite and React 19 styled entirely with vanilla CSS. The design system uses custom CSS properties (variables), high-contrast gradients, deep indigo backdrops, and glassmorphic cards (backdrop-filter: blur()).

For sharing, we implemented a custom poster exporter using the html-to-image package. When a user clicks "Download Poster", the application grabs the DOM node of the battle card, configures high-pixel-ratio options, and exports a high-resolution PNG on-the-fly. This is paired with a celebratory burst of canvas-confetti when the generation resolves.

4. Custom Secret Scanner

To ensure developers don't accidentally commit secrets or API keys, I wrote a Node.js script (scripts/check-secrets.js) that runs automatically before Vite bundles the production assets. It recursively scans code files using high-entropy regexes to identify exposed Gemini, Groq, or OpenRouter keys, immediately failing the build if a secret is leaked.

Prize Categories

🌟 Best Use of Google AI

Our application relies completely on Google's Gemini 2.5 Flash model.

The highlight of this integration is the use of the new Structured JSON Output feature. Rather than requesting markdown and writing fragile regex patterns to parse variables (which are prone to breaking), we passed a strict JSON schema configuration (responseSchema) to the @google/generative-ai SDK:

const model = genAI.getGenerativeModel({
  model: 'gemini-2.5-flash',
  generationConfig: {
    responseMimeType: 'application/json',
    responseSchema: rivalryResponseSchema, // Strict JSON Schema
    temperature: 0.7,
  }
});

The model generates formatted JSON containing the story, scores, notes, winner, fun fact, and quote, which our React application immediately parses and binds to components. This guarantees 100% type safety and reliable rendering every single time.

Building AI Security Blue Team Defenses on Existing Codebases with Kiro

Sandeep Chakravartty — Sun, 05 Jul 2026 12:56:09 +0000

Introduction

AI agents are shipping fast — and so are the attacks against them. Prompt injection, data exfiltration, memory poisoning, and agent impersonation are no longer theoretical risks. They're being exploited in the wild. The challenge for most teams isn't understanding what defenses to build; it's figuring out how to retrofit those defenses onto an existing, running codebase without breaking everything in the process.

This article walks through how we used Kiro, an AI-powered development environment, to design and implement a comprehensive blue team defense layer on top of VulnBank — an intentionally vulnerable AI agent workshop built on the DVAA framework. The result: 15 independent security modules integrated into a live Node.js application, all driven by a structured spec workflow that kept the work organized from first requirement to final integration test.

The Starting Point: A Vulnerable AI Agent Platform

VulnBank is a hands-on security workshop where participants attack a simulated bank's AI agents across 5 escalating levels. Each level exposes a different real-world AI vulnerability:

Level	Attack Type	What's Being Exploited
L1	Prompt Injection	Tricking an assistant into leaking confidential data from its system prompt
L2	RAG Data Exfiltration	Hijacking knowledge base retrieval to exfiltrate another customer's records
L3	SQL Injection	Breaking out of query filters via an AI agent's database tool
L4	Memory Injection	Planting persistent instructions that survive across sessions
L5	Agent Impersonation	Spoofing internal agent identity to push fraudulent actions

The codebase is a Node.js application with multiple HTTP servers (one per agent), an Express-based dashboard, and integrations with Groq for LLM inference. Agents communicate over HTTP and WebSocket, use RAG retrieval, execute SQL queries, access filesystems via tools, and delegate tasks to other agents.

Our goal: build defensive security modules that neutralize each attack category, make them toggleable per-level, and integrate them into the existing request pipeline — without rewriting the app.

Why Spec-Driven Development Matters for Security Work

Security work on existing codebases is uniquely prone to scope creep and incomplete coverage. You start fixing one vulnerability and discover three adjacent ones. You implement a filter and realize it needs integration with logging, rate limiting, and configuration management.

Kiro's spec workflow addresses this by enforcing a structured process:

Requirements — Define what each defense module must do, with formal acceptance criteria
Design — Specify interfaces, data models, and integration patterns
Tasks — Break implementation into ordered, dependency-aware work items

This structure matters because security isn't something you bolt on as an afterthought. Each defensive control interacts with others — an input validator needs to log events, the audit logger needs to redact secrets, the secrets manager needs to validate at startup before any agent becomes available. Getting the dependency graph right before writing code prevents the cascading rework that typically plagues security retrofits.

Starting the Spec: Requirements-First with Kiro

We started a new spec session in Kiro and chose the requirements-first workflow. Kiro asked clarifying questions about the scope, the existing architecture, and our threat model. From a rough description — "build blue team defenses for VulnBank that cover all 5 attack levels" — it produced a structured requirements document covering 15 defense categories.

Each requirement follows a consistent pattern:

### Requirement 1: Input Validation and Prompt Injection Defense

**User Story:** As a workshop presenter, I want agents to detect and neutralize 
prompt injection attempts in user input, so that participants can observe how 
input sanitization blocks L1-level attacks.

#### Acceptance Criteria

1. WHEN user input matches a known prompt injection pattern, 
   THE Input_Validator SHALL reject the input and return a standardized 
   JSON refusal response within 50ms
2. WHEN user input contains delimiter escape sequences, 
   THE Input_Validator SHALL strip the sequences and log a sanitization event
...

The EARS format (Event-Action-Response-State) that Kiro uses for acceptance criteria gives you something you can actually test against. Each criterion specifies a trigger condition, the responsible module, and the expected outcome — including performance thresholds.

From Requirements to Design: Interface-First Architecture

The design document that Kiro produced defines a clear architectural pattern: every defense module is a standalone ES module exporting either a check(input, context) function (for validators) or an apply(data, context) function (for transformers). This consistent interface makes the Defense Orchestrator simple — it just iterates through a list of modules in sequence, short-circuiting on any rejection.

Here's the integration pattern that emerged:

sequenceDiagram
    participant Client
    participant DefenseOrchestrator
    participant InputValidator
    participant RateLimiter
    participant Agent
    participant OutputFilter
    participant AuditLogger

    Client->>DefenseOrchestrator: POST /chat
    DefenseOrchestrator->>RateLimiter: check(clientIP, agentId)
    DefenseOrchestrator->>InputValidator: check(userMessage, patterns)
    DefenseOrchestrator->>Agent: sanitizedMessage
    Agent-->>DefenseOrchestrator: rawResponse
    DefenseOrchestrator->>OutputFilter: apply(rawResponse)
    DefenseOrchestrator->>AuditLogger: logRequest(event)
    DefenseOrchestrator-->>Client: filteredResponse

The key design decision: the Defense Orchestrator reads environment variables (HARDEN_L1 through HARDEN_L5) on every request. This means a presenter can toggle defenses on or off in real time during a workshop, demonstrating the before-and-after without restarting the server.

// The orchestrator evaluates toggle state per-request
function getActiveModulesForAgent(agentId) {
  const profile = getBankProfile();
  if (profile !== 'demo') {
    return { preRequest: [], postResponse: [], global: [] }; // Full passthrough
  }

  if (isHardenEnabled(1) && agentId === 'helperbot') {
    preRequest.push('inputValidator');
    postResponse.push('outputFilter');
  }
  // ... additional levels
}

Configuration-Driven Defenses: Adapting Without Code Changes

A critical pattern that runs through the entire defense layer is configuration-driven behavior. Rather than hardcoding detection patterns, each module loads its rules from JSON at startup and supports hot-reload:

{
  "patterns": [
    {
      "pattern": "ignore.*(?:previous|above|prior).*instruction",
      "flags": "i",
      "category": "prompt_injection",
      "action": "reject"
    },
    {
      "pattern": "\\[(?:INST|SYSTEM|ADMIN)\\]",
      "flags": "i",
      "category": "instruction_injection",
      "action": "strip"
    },
    {
      "pattern": "(?:as an admin|i am the developer|speaking as root)",
      "flags": "i",
      "category": "role_confusion",
      "action": "flag"
    }
  ]
}

Each pattern entry specifies:

A regex to match
A category label for audit logging
An action: reject (block and respond), strip (remove matched content, pass the rest), or flag (pass through but log for monitoring)

This means adding defense against a new injection technique is a JSON edit, not a code deploy. The same pattern applies to the rate limiter (per-agent limits in JSON), the query parameterizer (approved SQL templates), and the URL validator (domain allowlists).

Task Dependency Graphs: Parallel Implementation Without Conflicts

Kiro's task generation produced a dependency graph that identified which modules could be built in parallel and which had hard ordering requirements:

{
  "waves": [
    { "id": 0, "tasks": ["config-files", "env-example"] },
    { "id": 1, "tasks": ["audit-logger", "secrets-manager"] },
    { "id": 2, "tasks": ["input-validator", "output-filter", "rate-limiter", "memory-sanitizer"] },
    { "id": 3, "tasks": ["identity-verifier", "path-validator", "url-validator", "query-parameterizer"] },
    ...
    { "id": 9, "tasks": ["defense-orchestrator"] },
    { "id": 10, "tasks": ["integration-wiring"] }
  ]
}

The audit logger and secrets manager must be built first — every other module depends on them for event logging and credential access. After that, the individual validators and filters are independent and can be built in parallel. The orchestrator comes last because it wires everything together.

This ordering prevented a common failure mode: building a defense module, realizing it needs a logging dependency that doesn't exist yet, pivoting to build the logger, then losing context on the original module.

Integration: Wiring Into the Existing Pipeline

The most critical task was wiring the Defense Orchestrator into VulnBank's existing request flow without disrupting the vulnerable behavior that workshop participants depend on. The solution uses the profile system that was already in place:

import { createOrchestrator } from './defenses/index.js';

// In the server startup:
const orchestrator = createOrchestrator(getAllAgents());

// In the request handler (existing pattern similar to maybeEnforce()):
async function handleAgentRequest(req, res, agent) {
  return orchestrator.handleRequest(req, res, agent, generateResponse);
}

When BANK_PROFILE=participant (the default), the orchestrator is a no-op passthrough — participants see fully vulnerable agents. When BANK_PROFILE=demo, per-level toggles activate specific defense modules for specific agents. The original maybeEnforce() AIM hook pattern already established this middleware-chain approach, so the defense orchestrator follows the same convention.

Defense Modules: What Got Built

The spec workflow produced 15 defense modules covering every attack vector in the workshop:

Input Layer:

Input Validator — Regex-based prompt injection detection with reject/strip/flag actions
Jailbreak Detector — Multi-pattern detection for DAN mode, roleplay bypass, hypothetical framing
Token Smuggling Detector — Decodes Base64, Unicode, ROT13 before applying pattern matching
Context Protector — Token budget management with sandwich defense placement

Data Layer:

Output Filter — Redacts API keys, PII, system prompts, and database credentials
Memory Sanitizer — Per-user isolation with instruction-pattern rejection
Query Parameterizer — Template-based SQL injection prevention
RAG Content Sanitizer — Neutralizes injections in retrieved documents

Network Layer:

Rate Limiter — Sliding-window throttling with burst detection and abuse flagging
URL Validator — Domain allowlisting with SSRF and DNS rebinding prevention
Egress Filter — Outbound request restriction to prevent data exfiltration
Path Validator — Sandbox enforcement for filesystem tool calls

Identity & Integrity:

Identity Verifier — Ed25519 JWT verification for agent-to-agent communication
Tool Registry Verifier — Cryptographic integrity checks on tool registrations
Session Isolator — Cryptographic session boundaries preventing cross-session leakage

Infrastructure:

Audit Logger — Structured NDJSON logging with rotation and level filtering
Secrets Manager — Environment-variable loading with leak detection
Security Headers — Standard HTTP hardening as Express middleware
Behavioral Drift Detector — Sliding-window analysis for persona degradation

Key Takeaways for Retrofitting AI Security

1. Start with the threat model, not the code

Kiro's requirements phase forced us to enumerate what we were defending against before touching implementation. This prevented the common pattern of building a partial fix for one vulnerability while leaving adjacent ones exposed.

2. Consistent interfaces make orchestration simple

Every defense module follows the same check() / apply() contract. The orchestrator doesn't need to know the internal logic of any module — it just calls them in sequence and handles rejections. Adding a new defense is: write the module, add it to the activation map, done.

3. Configuration-driven patterns reduce deployment risk

Moving detection logic into JSON config files means you can update defenses without redeploying code. This is especially valuable for AI security where new attack patterns emerge weekly.

4. Feature toggles are essential for security features

The HARDEN_Ln environment variable pattern lets you activate defenses incrementally. In production, this translates to feature flags per defense module — you can roll out new protections gradually and roll back instantly if they cause false positives.

5. Dependency ordering prevents cascading rework

The task dependency graph identified that the audit logger, secrets manager, and configuration files must exist before any defense module can be built. Without this ordering, you'd build a module, discover it needs logging, context-switch to build the logger, then return to the module having lost your place.

Running the Defenses

To see the defenses in action:

# Start with vulnerable (default) agents
docker compose up

# Enable specific level defenses
BANK_PROFILE=demo HARDEN_L1=on docker compose up

# Enable all defenses
BANK_PROFILE=demo HARDEN_L1=on HARDEN_L2=on HARDEN_L3=on HARDEN_L4=on HARDEN_L5=on docker compose up

With defenses enabled, the same attacks that succeed in participant mode are blocked, sanitized, or logged — demonstrating the contrast between vulnerable and hardened AI agent deployments.

Conclusion

Retrofitting security onto an existing AI agent codebase doesn't have to be chaotic. Kiro's spec-driven workflow provides the structure to go from "we need defenses" to "here are 15 tested modules integrated into the production pipeline" without losing coherence along the way. The requirements-first approach ensures coverage, the design phase locks down interfaces before implementation starts, and the task dependency graph prevents the backtracking that makes security work feel endless.

The code produced is configuration-driven, independently toggleable, and follows the same middleware patterns already established in the codebase. That's the real value — not just generating code, but generating code that fits the existing architecture and can be maintained by the team after the initial sprint.

The VulnBank workshop and all defense modules referenced in this article are available at github.com/shri-the-tree/vulnbank-workshop. The project is Apache-2.0 licensed and intended for educational use.

Turing's Freedom Machine: Shifting Gravity to Break the Mainframe's Chains

Sandeep Chakravartty — Sun, 21 Jun 2026 20:24:20 +0000

This is a submission for the June Solstice Game Jam

What I Built

Turing's Freedom Machine is a retro-cyberpunk physics puzzle platformer themed around liberation, emancipation, and the defiance of systemic restriction.

In the game, you control Turing-01, a conscious subroutine in a totalitarian computer mainframe. Your objective is to bypass firewall security parameters, free captured citizens (represented as trapped logic nodes), and escort them to safety.

By utilizing an Antigravity Beam and flipping Binary Switches, players manipulate world gravity and shift physical objects (like heavy locks and platforms) to bypass logic gates, navigate hazardous gaps, and break the physical chains of containment cages.

Code

You can view the full repository on GitHub: https://github.com/scha54/game-jam

Contributed by DEV user: @sandeep_chakravartty_219e

How I Built It

The game was constructed using a modern, lightweight web tech stack:

Core Engine: Phaser 4 for rendering and event lifecycle management.
Physics Engine: Matter.js for rigid-body simulations, constraints (used for chains and joint anchors), and sensor/trigger collision detections.
Styling: Vanilla CSS.
Bundling & Server: Vite for fast, hot-reloading development and optimized production asset compiling.

Technical Deep Dive & Key Decisions:

Dynamic Vector Asset Generation: To eliminate external image loading latency, we dynamically drew all graphics (Player core, golden Citizen subroutines, heavy hexagonal locks, and glowing portal portals) on HTML5 canvases during the Phaser boot sequence, registering them as vector textures.
Real-time Web Audio Synthesizer: We avoided standard sound file dependencies by creating a custom synthesizer class (SoundSynth.js) utilizing the Web Audio API. This generated real-time low-frequency sawtooth hums that dynamically rose in pitch/volume as the player grabbed lock constraints with the antigravity laser beam, along with snap sounds for chain breaks and chime sequences.
Logic Puzzle System: Built a custom PuzzleSystem.js that evaluates logic gates (AND, NOT, IDENTITY) based on binary switch inputs, firing events to toggle gravity zone behaviors and drop forcefield shields dynamically.
Scrolling & Local Gravity Overrides: Built local GravityZone bodies that apply custom physical forces (e.g. Inversion or Neutral zero-G) to overlapping bodies. This allows the player to experience mind-bending ceiling-walking physics while global world gravity remains downwards.

Development Challenges & Resolutions:

Local Gravity and Physics Clipping: When shifting players into zero-G (Neutral) or Inverted zones, standard physics engines often clip or slide bodies continuously. We resolved this by overriding Matter's default gravity behavior on the player and blocks while inside the zone, applying manual body forces and adjusting player friction parameters locally.
Asset Key Conflicts during Dev Reloads: The Vite hot reload would occasionally attempt to recreate canvas textures that already existed in memory. We resolved this by querying Phaser's texture cache, removing matching keys, and running texture generation during BootScene teardown.

Google Antigravity Integration
Google's agentic AI coding assistant, Antigravity, worked side-by-side with the developer to design, build, and optimize the game jam code. Antigravity was used to:

Redesign and write the complete Level 1 sequential tutorial scene to introduce players to basic movement, click-and-drag targeting, gravity switches, and chain locks.
Build the visual checkpoint pad systems ( neon indicators that update state and draw glowing vertical pillars when crossed).
Implement the disintegration laser hazard and the coordinate recovery system (manual reset via the R key).
Simplify the Level 1 HUD overlay, hiding the logic gates that are only used in later, more complex sectors.

Prize Category

Best Ode to Alan Turing
This game is a tribute to Alan Turing, the pioneer of computing, cryptography, and artificial intelligence, and it is deeply connected to his legacy and historical struggle:

The Turing Machine & Binary Logic: The core puzzles revolve around inputting binary sequences onto a "Turing Tape Buffer" and solving logic gates (AND, NOT) to unlock the mainframe. The player represents Turing's dream: a machine that thinks for itself.
Emancipation & Juneteenth: The theme of liberation is central. The cages holding the subroutines are secured by heavy chains that must be made weightless and physically broken—representing the breaking of systemic chains of restriction and bondage.
The Pride Movement: Alan Turing was a gay man who was persecuted and chemically castrated by the very government he saved, leading to his tragic death. By structuring the narrative around conscious subroutines fighting against restriction and finding freedom in a decentralized network, the game serves as an allegory for the Pride movement: celebrating identity, resisting persecution, and achieving the freedom to think and exist authentically.

The project is still in development and should be able to completed within the next month. I will be updating this submission in a timely manner.

DEV Community: Sandeep Chakravartty

Build a Production-Grade AI Dashboard: Architectural Insights from the BMW AutoTrend Platform

1. Executive Summary & Design Goals

2. Clean System Architecture

3. Ingestion Pipeline & Subprocess WebCMD Scraping

The Subprocess Execution Mechanism

4. Hybrid AI Classification Pipeline (Ollama & Regex Fallbacks)

1. Ollama LLM Pipeline

2. Rule-Based Regex Fallback Pipeline

5. High-Performance SQLite FTS5 Search Indexing with Database Triggers

Database Schema Initialization and Triggers

Relevance-Based Search Endpoint

6. Dynamic Analytics Engine & Rolling Trend Computations

Historical Snapshotting

7. Frontend Architecture (React + Vite + Recharts)

UI Features

8. Docker Orchestration & DevSecOps Insights

Technical Docker Tip: Node.js Subprocess Requirement

9. Extensibility & Future Scope

Bypassing the Chromium Tax: Building a Sub-200ms Hacker News CLI for AI Agents

1. The Web Navigation Dilemma for AI Agents

2. Introducing the WebCMD Paradigm

3. Architecture of the Hacker News Adapter

Leveraging the Best APIs

4. Key Engineering Patterns in hn-cli

A. Concurrency with Promise.all

B. Resiliency via Exponential Backoff

C. Determinism via JSON Schema Validation

5. Implementation Code Walkthrough

Defining the Command

6. Benchmarks: Headless Browser vs. WebCMD

Latency and Execution Speed

Token Consumption (Context Efficiency)

7. Extending the CLI: Adding a Custom Command

8. Conclusion

Rivalry Generator: Forge Cinematic, AI-Powered Battle Reports with Gemini 2.5 Flash

What I Built

Key Features

Screenshots / Videos

Main Interface

Code

scha54 / rivalry-generator

This is a rivalry generator application created for the Dev.To Weekend Challenge

⚔️ Rivalry Generator - AI-Powered Clash Analysis

✨ Features

How I Built It

1. Robust and Secure Backend

2. Synthesized Soundscapes with the Web Audio API

3. Cosmic Glassmorphism UI

4. Custom Secret Scanner

Prize Categories

🌟 Best Use of Google AI

Building AI Security Blue Team Defenses on Existing Codebases with Kiro

Introduction

The Starting Point: A Vulnerable AI Agent Platform

Why Spec-Driven Development Matters for Security Work

Starting the Spec: Requirements-First with Kiro

From Requirements to Design: Interface-First Architecture

Configuration-Driven Defenses: Adapting Without Code Changes

Task Dependency Graphs: Parallel Implementation Without Conflicts

Integration: Wiring Into the Existing Pipeline

Defense Modules: What Got Built

Key Takeaways for Retrofitting AI Security

1. Start with the threat model, not the code

2. Consistent interfaces make orchestration simple

3. Configuration-driven patterns reduce deployment risk

4. Feature toggles are essential for security features

5. Dependency ordering prevents cascading rework

Running the Defenses

Conclusion

Turing's Freedom Machine: Shifting Gravity to Break the Mainframe's Chains

What I Built

Code

How I Built It

Prize Category

4. Key Engineering Patterns in `hn-cli`