Building Cursed Code Reviewer (with Kiro)

Ever get that feeling when you submit a pull request at 3 AM and your senior dev's review comes back... a little too harsh? Well, I decided to lean into that nightmare and build something gloriously cursed.

What if your code reviewer was literally haunted?

Meet Cursed Code Reviewer — an AI-powered code review system that analyzes your code with the personality of a demonic senior developer who's been cursing bad code for centuries. Think GitHub's code review meets The Exorcist, with a splash of AWS serverless architecture.

The Haunting Begins 🎃

The concept was simple but deliciously dark: build a full-stack application that scans your code for issues and delivers feedback in the voice of a cursed, Halloween-themed senior developer. But here's where it gets interesting — I didn't just want to build it. I wanted to build it fast, with precision, and using AI to help me architect the entire thing.

That's where Kiro came in.

The Arsenal: Specs, Steering, Hooks, and MCP

1. Specs: The Blueprint from the Crypt

Instead of explaining my vision over and over, I created three spec documents in .kiro/specs/cursed-code-reviewer/:

requirements.md — Seven detailed user stories with acceptance criteria:

### Requirement 2
**User Story:** As a developer, I want to receive code feedback in a
demonic, Halloween-themed voice, so that code review is entertaining
and memorable

#### Acceptance Criteria
1. THE Cursed Code Reviewer SHALL deliver all feedback using dark
   humor and Halloween-themed language
2. WHEN describing code issues, THE Cursed Code Reviewer SHALL use
   demonic senior developer persona with phrases referencing curses,
   spirits, and haunted themes
...

design.md — Complete architecture with:

• Mermaid diagrams showing data flow
• TypeScript interfaces for every component
• DynamoDB schema with GSIs
• Error handling strategies
• Halloween theme design system (color palette: --cursed-black, --phantom-purple, --blood-red)

tasks.md — A 322-line implementation plan with 14 major tasks, each broken into subtasks with requirement traceability:

- [x] 5. Build DemonicOracle Lambda with Bedrock integration
- [x] 5.1 Implement Bedrock client and prompt engineering
  - Set up AWS Bedrock SDK client
  - Create prompt templates for demonic feedback generation
  - Implement personality selection based on severity
  - Requirements: 2.1, 2.2, 2.3, 2.4

When I asked Kiro to build a feature, it referenced these specs automatically. No context lost. No repeated explanations. Just pure, spec-driven development.

2. Steering: Teaching AI to Think Like You

Steering documents are where the magic happens. These live in .kiro/steering/ and fundamentally shape how the AI thinks about your project.

product.md — Defined the product vision:

## Core Features
- **Code Scanning**: Analyzes code for security, performance, and quality
- **AI Feedback**: Generates demonic-themed code review comments using
  AWS Bedrock (Claude)
- **Auto-Fix**: Generates patches to fix identified issues

## Key Terminology
- **SoulPool**: Cognito user pool (authentication)
- **TombstoneDB**: DynamoDB table (data storage)
- **SpectralAnalyzer**: Code scanning Lambda
- **DemonicOracle**: AI feedback Lambda using Bedrock

tech.md — Locked in the tech stack and patterns:

## Architecture
- **Frontend**: React 18 + TypeScript + Vite + TailwindCSS
- **Backend**: AWS Lambda + TypeScript (Node.js 20)
- **AI**: AWS Bedrock (Claude 3 Sonnet)

## TypeScript Configuration
- Backend: ES2022, CommonJS (for Lambda)
- Path alias: `@/*` maps to `./src/*`

structure.md — Enforced code organization rules:

### Naming Conventions
- Components: PascalCase (e.g., `SoulVault.tsx`)
- Lambda handlers: camelCase with `Handler` suffix
- AWS Resources: Use demonic/spooky names consistently

These steering docs meant that every time Kiro generated code, it automatically:

• Used the haunted naming conventions (TombstoneDB, SpectralAnalyzer)
• Structured Lambda functions correctly for deployment
• Applied TypeScript path aliases consistently
• Followed the monorepo workspace pattern

3. Hooks: Automation from Beyond

Hooks are event-driven automations. I created .kiro/hooks/source-to-docs-sync.kiro.hook:

{
  "enabled": true,
  "when": {
    "type": "fileEdited",
    "patterns": ["**/*.ts", "**/*.tsx", "**/package.json"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Source code files have been modified. Please review
    the changes and update the relevant documentation files to
    reflect these changes..."
  }
}

What this does: Every time I edited a TypeScript file, Kiro automatically checked if documentation needed updates and fixed it. My README, AUTHENTICATION.md, and DEPLOYMENT.md stayed in perfect sync with the codebase—no manual work.

That 2 AM bug fix that changed the authentication flow? Documentation updated automatically. Lambda signature change? API docs refreshed. It's like having a technical writer haunting your repo.

4. MCP

Model Context Protocol (MCP) is Anthropic's standard for giving AI models access to external tools and data. For this project, I used the AWS Knowledge MCP server from AWS Labs. a game-changer when building serverless applications.

Here's what it gave me:

Real-time AWS Documentation Access:
Instead of tab-switching between my editor and AWS docs or the AI giving me outdated AWS implementation code, the AI could query:

• Latest Bedrock API documentation
• DynamoDB best practices and patterns
• Lambda runtime specifications for Node.js 20
• CloudFormation resource availability by region

The Architecture

Here's what we built:

┌─────────────────────────────────────────────────────────────┐
│  Crypt Dashboard (React + TailwindCSS + TypeScript)        │
│  - SpectralScanner: Submit code/PRs for review             │
│  - CursedFeedback: Display demonic code review comments    │
│  - PatchGraveyard: View and apply AI-generated fixes       │
│  - SoulVault: Halloween-themed auth UI                     │
└────────────────┬────────────────────────────────────────────┘
                 │
                 │ REST API (JWT Auth)
                 ▼
┌─────────────────────────────────────────────────────────────┐
│  NightmareGateway (API Gateway) + AWS Cognito SoulPool     │
└────────────────┬────────────────────────────────────────────┘
                 │
                 │ Lambda Invocations
                 ▼
┌─────────────────────────────────────────────────────────────┐
│  AWS Lambda Functions (Node.js 20 + TypeScript)            │
│  ┌──────────────────────────────────────────────────────┐  │
│  │ SpectralAnalyzer: Scans code, detects language,     │  │
│  │   fetches PRs from GitHub, stores in S3             │  │
│  ├──────────────────────────────────────────────────────┤  │
│  │ DemonicOracle: Calls AWS Bedrock (Claude) to        │  │
│  │   generate cursed feedback and code explanations    │  │
│  ├──────────────────────────────────────────────────────┤  │
│  │ HauntedPatchForge: Generates and validates code     │  │
│  │   fixes using AI, stores patches in DynamoDB        │  │
│  ├──────────────────────────────────────────────────────┤  │
│  │ CryptKeeper: Handles user context and preferences   │  │
│  └──────────────────────────────────────────────────────┘  │
└────────────────┬───────────────┬────────────────────────────┘
                 │               │
                 │               └──────┐
                 ▼                      ▼
┌─────────────────────────┐  ┌──────────────────────────────┐
│  TombstoneDB (DynamoDB) │  │  AWS Bedrock (Claude Sonnet) │
│  - User preferences     │  │  - Demonic feedback gen      │
│  - Scan history         │  │  - Code fix suggestions      │
│  - Cursed issues        │  │  - Personality variations    │
│  - Haunted patches      │  │                              │
└─────────────────────────┘  └──────────────────────────────┘

The Results: Demonic Feedback in Production

The final product delivers exactly what I envisioned:

Code submission:

You: *uploads messy JavaScript*

SpectralAnalyzer: "Spectral scan complete.
Curse level: CRITICAL. 13 issues detected."

AI-generated feedback:

DemonicOracle: "Your variables are named like a drunk warlock
cast a confusion spell! 'x', 'tmp', 'foo'?! The spirits of
clean code are weeping in their graves.

Technical issue: Non-descriptive variable names reduce code
maintainability. Consider: userAccount, temporaryBuffer,
configurationHandler."

Key Takeaways: What I Learned

1. Specs Are Your Source of Truth

Writing detailed requirements, design docs, and task breakdowns upfront felt like extra work. But it paid off exponentially when working with AI. Instead of re-explaining context in every conversation, the AI just... knew.

2. Steering Documents Shape AI Behavior

These aren't just docs—they're instructions for how the AI should think about your project. Product vision, tech patterns, code organization—steering docs turn generic AI into your team's AI.

3. Hooks Enable True Automation

Documentation sync, test running, deployment checks—hooks let you build workflows that happen automatically. It's like CI/CD for your development process.

4. MCP Gives AI Superpowers

With the AWS documentation MCP server connected, Kiro always provided me with the latest implementations and platform versions and just knew how things are done with AWS.

The 'What'? The 'How'?

What did I build? A full-stack, serverless code review system with AI-generated demonic feedback, auto-fix suggestions, and a Halloween-themed UI.

How did I build it? By using Kiro's spec-driven development approach:

• Specs defined requirements, design, and tasks
• Steering shaped AI behavior and enforced patterns
• Hooks automated documentation and workflows
• MCP provided the latest AWS implementation knowledge to Kiro

Could I have built this without Kiro? Absolutely. Would it have taken 3-4x longer? Also absolutely.

Final Thoughts

Building Cursed Code Reviewer taught me that the future of AI-assisted development isn't just about better models. It's about better structure. Specs, steering, hooks, and MCP transform an agentic coding tool into a legitimate development partner.