Building Mirmer AI: How Kiro Transformed Solo Development into AI-Powered Collaboration
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:
- Stage 1 – Multiple AI models respond independently
- Stage 2 – Models anonymously peer‑review each other’s responses
- 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

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

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

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-idheader 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.

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.