Building Mirmer AI: How Kiro Transformed Solo Development into AI-Powered Collaboration

Published: (December 3, 2025 at 10:52 AM EST)
5 min read
Source: Dev.to

Source: Dev.to

The Challenge: Resurrecting 400 Years of Peer Review

When I set out to build Mirmer AI, I wanted to revive the centuries‑old peer‑review process and run it at machine speed with AI models. The concept was simple but the execution was complex:

  1. Stage 1 – Multiple AI models respond independently
  2. Stage 2 – Models anonymously peer‑review each other’s responses
  3. Stage 3 – A chairman model synthesizes consensus

I was a solo developer, so the stack I needed to assemble included:

  • FastAPI backend with async orchestration
  • React frontend with real‑time streaming
  • PostgreSQL database with dual‑mode storage
  • Python SDK with sync/async clients
  • CLI tool with browser‑based authentication
  • Payment integration (Razorpay)
  • Firebase authentication
  • Deployment on Railway and Vercel

That workload would normally take 2–3 months; I only had weeks.

Enter Kiro

Mirmer AI's 3‑stage council interface – where AI models debate and synthesize answers

The Kiro Advantage: Not Just Code Generation, But Architecture

Most AI coding assistants help you write individual functions. Kiro helped me architect an entire system.

1. Steering Rules: Teaching Kiro My Codebase

I created three steering documents in .kiro/steering/.

tech.md – Tech‑stack overview

Backend: FastAPI, Python 3.10+, uv package manager
Frontend: React 18, Vite, Tailwind CSS
Database: PostgreSQL (production), JSON (dev)
Key Pattern: Dual‑mode storage with factory pattern
Critical: Always use "uv run" not "python" directly

structure.md – Project architecture

backend/
  main.py          # API routes
  council.py       # 3‑stage orchestration
  storage.py       # Factory pattern (auto‑selects backend)
  storage_postgres.py  # Production storage
  storage_json.py      # Dev storage
frontend/
  src/components/ # React components
  src/pages/      # Route pages
sdk/
  mirmer/          # Python SDK package

product.md – Business & feature rationale

Core: 3‑stage council process (parallel queries → peer review → synthesis)
Business: Free (10/day), Pro (100/day), Enterprise (unlimited)
Key Feature: Real‑time streaming via SSE

Steering rules – the secret to persistent context across all Kiro conversations

Impact – After the steering rules were in place, every Kiro conversation started with the correct conventions (e.g., use uv run, import from storage.py, follow the 3‑stage pattern), eliminating a whole class of architectural errors.

2. Spec‑Driven Development: From Idea to Implementation Plan

For complex features I used Kiro’s spec system. Below is the workflow for the Python SDK.

Phase 1 – Requirements (requirements.md)

I asked Kiro to “Create a spec for a Python SDK”. It produced:

  • 12 user stories with acceptance criteria
  • Glossary of technical terms
  • 60+ testable requirements in EARS format

Example requirement:

User Story: As a developer, I want to stream council updates in real‑time

Acceptance Criteria:
1. WHEN a developer calls the stream method THEN the system SHALL yield updates as each stage progresses
2. WHEN Stage 1 completes THEN the system SHALL yield an event containing all individual model responses
3. WHEN streaming encounters an error THEN the system SHALL yield an error event with details

Auto‑generated requirements document with user stories and acceptance criteria

Phase 2 – Design (design.md)

Kiro generated:

  • Full architecture with data‑flow diagrams
  • Component interfaces with method signatures
  • 20 correctness properties for property‑based testing
  • Error‑handling strategies
  • Testing approach (unit, property‑based, integration)

Correctness properties example:

  • “For any API request, x-user-id header must contain the API key”
  • “For any subscription payment, tier should update to pro
  • “For any streaming request, events must arrive in order: stage1_start → stage1_complete → stage2_start …

These became Hypothesis property‑based tests running 100+ iterations each.

Phase 3 – Tasks (tasks.md)

Kiro broke the work into granular tickets:

- [ ] 1. Set up project structure and packaging
- [ ] 2. Implement core data models
  - [ ] 2.1 Create Pydantic models for all data structures
  - [ ]* 2.2 Write property test for response structure validation
- [ ] 3. Implement synchronous Client class
  - [ ] 3.1 Create Client with initialization and configuration
  - [ ]* 3.2 Write property test for API key security

* marks optional test tasks, allowing focus on core functionality first.

Implementation tasks with progress tracking – each task references specific requirements

Result – The SDK spec caught three bugs before production. Tasks turned a three‑day feature into one‑hour chunks, and the preserved spec files let me pause and resume weeks later without losing context.

3. Agent Hooks: The Self‑Improving Codebase

I defined six agent hooks that automated routine development tasks.

API Function Generator – Triggered on backend file edits

When I write a new API function, Kiro automatically generates:
- FastAPI route decorator
- Pydantic validation schema
- Error‑handling boilerplate
- Example request body

Auto‑Document Code – Triggered on any code file edit

Kiro adds docstrings/JSDoc to every function automatically.
No more “I’ll document this later” – it happens in real‑time.

Auto‑Generate Tests – Triggered alongside function creation

For each new function, Kiro creates:
- Unit test skeleton
- Property‑based test template (if a correctness property exists)
- Mock data fixtures

Dependency Updater – Runs on requirements.txt changes

Kiro checks for newer package versions, runs the test suite, and creates a pull request if all checks pass.

CI/CD Optimizer – Runs after each push

Kiro analyses test coverage, suggests flaky‑test mitigations, and updates the GitHub Actions workflow accordingly.

Documentation Publisher – Runs on release tags

Kiro builds the MkDocs site, uploads it to the hosting provider, and posts a release note with changelog highlights.

These hooks turned the codebase into a self‑maintaining system, dramatically reducing manual overhead.

Takeaways

  • Steering rules give AI assistants persistent context, eliminating repeated explanations.
  • Spec‑driven development bridges the gap between high‑level ideas and concrete implementation, catching defects early.
  • Agent hooks automate repetitive tasks, allowing a solo developer to scale a production‑grade multi‑LLM platform in weeks rather than months.
Back to Blog

Related posts

Read more »