Reflections on Developing GoodBot with Kiro

YoungLee — Mon, 01 Dec 2025 12:02:52 +0000

Preface

Completing a full Telegram Bot management system in 48 hours was once unimaginable. But with Kiro, I made it happen. This article documents my real experience and thoughts using Kiro to develop the GoodBot project.

From Zero to One: How Kiro Changed My Development Process

No More "Writing Code"—It's "Conversational Development"

Traditional development flow: Clarify → Check docs → Write code → Debug → Repeat.

With Kiro, it became: Describe requirements → Kiro generates → Fine-tune → Done.

This isn’t laziness—it shifts focus from “how to write” to “what to write.” I can now concentrate on product logic and user experience instead of getting bogged down by syntax details and API call methods.

A Real Example: Message Forwarding System

The core feature of GoodBot is bidirectional message forwarding—users send messages to the bot, which forwards them to admins; when admins reply, the response is automatically routed back to the original user.

This involves:

Webhook handling using the grammY framework
Database transactions and message ID mapping
Reply thread tracking
Error handling and edge cases

I simply described the business needs, and Kiro generated a complete implementation—including the design of the messageMaps table. It worked right away upon first run, requiring only minor adjustments.

Steering: Making AI Truly Understand Your Project

Kiro’s Steering feature is one of the most valuable aspects I’ve found.

My Steering Configuration

.kiro/steering/
├── Rules.md      # Basic rules: use Chinese
├── tech.md       # Tech stack: Next.js 16, pnpm, Drizzle
├── structure.md  # Project structure and coding conventions
└── product.md    # Product background and business logic

Before vs After Steering

Without Steering:

Kiro might use npm instead of pnpm
Generate English comments and UI text
Place files in non-conforming locations
Require repeated corrections

With Steering:

Always uses pnpm
Outputs in Chinese
Follows project structure
Gets it right the first time

I estimate that Steering reduced over 70% of “not like this, should be like that” correction conversations.

Spec-Driven vs Vibe Coding: Finding the Balance

The Charm of Vibe Coding

For simple tasks, direct conversation with Kiro suffices:

"Help me add a loading state"
"Change this button to blue"
"Fix this TypeScript error"

Fast, direct, efficient.

Value of Spec-Driven Development

But for complex features like a lottery system, I chose Spec-driven:

Requirements: Define acceptance criteria
- Admins can create lotteries
- Users participate by sending keywords
- Automatic draw at scheduled time
Design: Technical solutions
- Database schema design
- Fisher-Yates shuffling algorithm
- Scheduled task solution in serverless environment
Tasks: Breakdown and execution
- Create lotteries table
- Implement lottery creation API
- Implement participation logic
- Implement drawing logic

My Strategy

Scenario	Approach
UI adjustments, bug fixes	Vibe Coding
New simple features	Vibe Coding
Core business logic	Spec-Driven
Database design	Spec-Driven
Multi-file refactoring	Spec-Driven

Pitfalls Encountered and Solutions

1. Scheduled Tasks in Serverless Environment

Problem: Vercel’s serverless functions are stateless—the setTimeout will lose its context after cold start.

Kiro’s Suggestion: Adopt a hybrid approach:

Primary: External Cron service polling every minute
Backup: In-memory timer (active sessions)
Fallback: Check during each bot interaction

This solution would have taken me hours to figure out myself—Kiro immediately provided a mature strategy.

2. BigInt Serialization

Problem: Telegram IDs are 64-bit integers, but JSON doesn't support BigInt.

Kiro’s Solution:

// Database storage
id: bigint("id", { mode: "number" })

// API response serialization
const serialized = { ...user, id: user.id.toString() };

3. React 19 New Patterns

Problem: ESLint reports useEffect as anti-pattern.

Kiro’s Help: Identified the issue and refactored code according to React 19 best practices.

Data Speaks

Task	Traditional Way	With Kiro
Project setup	4–6 hours	30 minutes
CRUD APIs	Each 2–3 hours	Each 15–20 minutes
Bug fixes	Uncertain	Minutes-level (with context)
Code review	Manual	Auto suggestions
Documentation	Often skipped	Generated alongside code

The entire project has 5,000+ lines of code, 12 API endpoints, 6 database tables, 20+ UI components, completed in 48 hours.

Deepest Insight

AI Is Not Replacement—It’s Amplification

Kiro won’t replace developer thinking—but it amplifies my capabilities. I still need to:

Understand business requirements
Make architectural decisions
Review generated code
Handle edge cases

But I no longer need to:

Remember parameter order for every API
Write boilerplate code manually
Set up project structure from scratch
Search Stack Overflow for common issues

Conversation Quality Determines Output Quality

The clearer and more specific your conversation with Kiro, the better the output.

❌ "Help me build a chat feature"
✅ "Implement a chat list component showing all user conversations sorted by last message time, click to enter detailed conversation"

Iteration Matters More Than Perfection

Don’t expect Kiro to generate perfect code in one go. Better approach:

Generate initial version
Test and find issues
Describe problems for Kiro to fix
Repeat until satisfied

This mirrors how human developers collaborate effectively.

Final Thoughts

These 48 hours developing GoodBot with Kiro were the most productive period of my programming career.

It made me rethink what “development” really means—not typing speed, but the ability to turn ideas into reality.

If you haven’t tried Kiro yet, strongly recommend giving it a shot—not because it writes code, but because it lets you focus on what truly matters: creating value.

DEV Community: YoungLee