Forem: Abdulkabir Musa

You Need Your Code to Be More Reliable Than People Using It

Abdulkabir Musa — Wed, 10 Dec 2025 21:35:01 +0000

There's a harsh truth about software development that many engineers learn the hard way: users will break your application in ways you never imagined possible. They'll enter dates in the wrong format, upload 50GB files to your profile picture field, click submit 47 times in rapid succession, and somehow manage to get your application into states you didn't even know existed.

The knee-jerk reaction is often to blame the user. "They should have known better!" But here's the thing: your code needs to be more reliable than the people using it.

The Reality of User Behavior

Users don't read documentation. They don't carefully review error messages. They're distracted, in a hurry, or simply don't have the technical background to understand what your application expects. And that's perfectly fine—it's not their job to accommodate your code. It's your code's job to accommodate them.

Consider these real-world scenarios:

A user copies text from a PDF that includes invisible Unicode characters
Someone's internet connection drops mid-transaction
A user navigates away from the page while your async operation is still running
Someone clicks "back" after submitting a form
A user leaves their session open for three days straight
Multiple tabs of your application are open simultaneously

If any of these scenarios can break your application or corrupt data, that's not a user problem—that's a code reliability problem.

What Reliability Actually Means

Reliable code isn't just code that works under ideal conditions. It's code that:

Validates rigorously - Never trust input, even from your own frontend
Fails gracefully - When things go wrong, degrade functionality rather than crash
Handles edge cases - The 99% case is important, but the 1% case is where bugs live
Maintains data integrity - No matter what users do, your data stays consistent
Recovers automatically - When possible, fix issues without user intervention

The Cost of Unreliable Code

I once worked on a financial application where a race condition allowed users to double-submit wire transfers. The bug was rare—it required clicking submit twice within a 200ms window. "Users won't do that," we thought. But with thousands of users, "rare" happened daily. Each incident required manual intervention, customer service calls, and potential financial liability.

The fix took two hours to implement: disable the button on first click and add idempotency keys. The cost of not implementing it from the start? Hundreds of hours of support time and damaged customer trust.

Strategies for Building Reliable Code

1. Input Validation Everywhere

// Bad: Trust the frontend
function createUser(data) {
  return database.users.insert(data);
}

// Good: Validate everything
function createUser(data) {
  const validated = userSchema.parse(data); // Throws on invalid data
  const sanitized = sanitizeInput(validated);
  return database.users.insert(sanitized);
}

Never assume input is clean, even from your own UI. Browsers can be manipulated, APIs can be called directly, and middleware can fail.

2. Idempotency for All State Changes

Every operation that changes state should be idempotent—running it multiple times should produce the same result as running it once.

# Bad: Can create duplicates
def submit_order(user_id, items):
    order = Order.create(user_id=user_id, items=items)
    return order

# Good: Uses idempotency key
def submit_order(user_id, items, idempotency_key):
    existing = Order.find_by_idempotency_key(idempotency_key)
    if existing:
        return existing

    order = Order.create(
        user_id=user_id, 
        items=items,
        idempotency_key=idempotency_key
    )
    return order

3. Defensive Database Operations

-- Bad: Assumes the record exists
UPDATE users SET balance = balance - 100 WHERE id = ?;

-- Good: Ensures constraints are maintained
UPDATE users 
SET balance = balance - 100 
WHERE id = ? AND balance >= 100;

-- Then check affected rows to ensure it succeeded

4. Timeouts and Circuit Breakers

// Bad: Wait forever for a response
const response = await fetch(externalAPI);

// Good: Fail fast with timeout
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 5000);

try {
  const response = await fetch(externalAPI, { signal: controller.signal });
  return response;
} catch (error) {
  if (error.name === 'AbortError') {
    // Handle timeout gracefully
    return fallbackResponse();
  }
  throw error;
} finally {
  clearTimeout(timeout);
}

5. Rate Limiting and Resource Protection

Users will accidentally (or intentionally) hammer your endpoints. Your code needs to protect itself:

from functools import wraps
from flask import request
import time

def rate_limit(max_calls, time_window):
    calls = {}

    def decorator(f):
        @wraps(f)
        def wrapped(*args, **kwargs):
            user_id = get_current_user_id()
            now = time.time()

            # Clean old entries
            calls[user_id] = [t for t in calls.get(user_id, []) 
                             if now - t < time_window]

            if len(calls[user_id]) >= max_calls:
                return {"error": "Rate limit exceeded"}, 429

            calls[user_id].append(now)
            return f(*args, **kwargs)
        return wrapped
    return decorator

The Mindset Shift

Building reliable code requires a mindset shift from "this should work" to "how could this fail?" Start asking questions like:

What happens if this takes 10 seconds instead of 100ms?
What if this function is called with null?
What if two users do this at the exact same time?
What if the network fails halfway through?
What if this external service is down?
What if someone sends me a 100MB string?

Testing for Reliability

Unit tests are great, but they rarely catch reliability issues. You need:

Chaos testing - Randomly kill processes, simulate network failures
Load testing - See what breaks under pressure
Fuzzing - Send random garbage input and see what happens
Concurrent testing - Run multiple instances simultaneously
Time-travel testing - Test with system clocks set to edge cases

The Payoff

Yes, building reliable code takes more time upfront. You'll write more validation logic, more error handling, more defensive checks. But the payoff is enormous:

Fewer production incidents and 3 AM wake-up calls
Reduced support burden
Increased user trust
Lower maintenance costs
Better sleep at night

Conclusion

Your users will make mistakes. They'll encounter network issues, browser quirks, and timing problems. They'll use your application in ways you never anticipated. That's not a bug in your users—it's the reality of building software for humans.

The question isn't whether users will do unexpected things. The question is: when they do, will your code handle it gracefully, or will everything fall apart?

Make your code more reliable than the people using it. Your future self (and your on-call rotation) will thank you.

What reliability lessons have you learned the hard way? Share your war stories in the comments below.

I Built a Real-Time 1v1 Coding Battle Platform in Days Using Kiro

Abdulkabir Musa — Thu, 04 Dec 2025 21:53:58 +0000

The Problem with LeetCode

Let's be honest: grinding LeetCode is boring.

You solve a problem. Green checkmark. Move on. Repeat. There's no excitement, no pressure, no reason to push beyond "it works."

I wanted to change that. What if coding practice felt like a ranked match in your favorite game? What if you could watch your opponent's progress in real-time and race to submit first?

That's how Phantom was born—a real-time 1v1 competitive coding platform where developers battle head-to-head in algorithmic challenges.

What I Built

Phantom features:

Live split-screen battles - Watch your opponent code in real-time
AI-powered judging - Google Gemini analyzes code quality and efficiency
Strategic power-ups - Time Freeze, Code Peek, Debug Shield
ELO matchmaking - Fair matches against similarly skilled opponents
Cyberpunk UI - Dark glassmorphism design with smooth animations

The tech stack:

Frontend: Next.js 14, React, TypeScript, TailwindCSS, Monaco Editor
Backend: Node.js, Express, Socket.io
Databases: PostgreSQL + Redis
Code Execution: Judge0 Cloud API
Deployment: Vercel + Railway

How Kiro Changed Everything

I built Phantom for the Kiroween Hackathon, and Kiro's spec-driven development approach was transformational.

Spec-Driven Development

Instead of diving straight into code, every major feature started with structured specs:

.kiro/specs/
├── phantom-code-battle/     # Core battle mechanics
├── power-ups-system/        # Strategic abilities
├── ai-code-coach/           # Gemini integration
├── judge0-cloud-integration/ # Code execution
└── authenticated-redirect/   # Auth flow

Each spec contained:

requirements.md - What the feature must do
design.md - Architecture, data models, API contracts
tasks.md - Implementation checklist

This structure forced me to think through edge cases before writing code. For a real-time multiplayer system where race conditions lurk everywhere, this was invaluable.

The Pivot That Could Have Killed the Project

Here's where Kiro really saved me.

I built a beautiful Docker-based code execution system locally. Sandboxed containers, resource limits, network isolation—it worked perfectly.

Then I tried deploying to Railway.

Railway doesn't support Docker-in-Docker.

My entire code execution engine was unusable in production. With the hackathon deadline approaching, I had to completely rewrite the execution pipeline to use Judge0's cloud API instead.

Because I had clear specs defining the interfaces and requirements, I could swap the execution layer without touching the battle logic. Kiro helped me plan the migration systematically:

// Before: Docker execution
async executeCode(code: string, language: string): Promise<ExecutionResult> {
  const container = await docker.createContainer({...});
  // ... container management
}

// After: Judge0 API
async executeCode(code: string, language: string): Promise<ExecutionResult> {
  const response = await judge0Client.submit({
    source_code: code,
    language_id: LANGUAGE_MAP[language],
  });
  // ... same interface, different implementation
}

The spec-driven approach meant the rest of the codebase didn't care how code was executed—just that it returned the expected result format.

Debugging Railway Deployment

Deploying the backend to Railway was brutal:

Environment variables needed specific formatting
TypeScript errors only appeared in Railway's build environment
Health checks kept timing out
WebSocket connections dropped due to proxy issues
The dashboard kept timing out during deploys

When I hit walls, Kiro helped troubleshoot systematically. It analyzed error logs, suggested configuration fixes, and helped me understand Railway's specific requirements.

Eventually, I deployed everything via Railway's CLI after the dashboard proved unreliable:

railway login
railway link
railway up

Sometimes the CLI just works better.

The Real-Time Challenge

Building multiplayer real-time features is genuinely hard. Here's what I learned:

WebSocket Architecture

// Socket.io event naming convention: action:resource
socket.on("battle:join", handleJoin);
socket.on("battle:submit", handleSubmit);
socket.on("battle:sync", handleSync);
socket.on("battle:powerup", handlePowerup);

Consistent naming made debugging much easier when events were flying between two players.

State Synchronization

Keeping two editors in sync with sub-100ms latency required:

Redis pub/sub for cross-instance communication
Throttling to prevent event flooding
State recovery for reconnections
Optimistic updates on the client

Race Conditions

What happens when both players submit at the exact same moment? The spec forced me to define this upfront:

## Correctness Properties

- CP-1: Simultaneous submissions must be processed in arrival order
- CP-2: A player cannot submit while their previous submission is being judged
- CP-3: Battle state must remain consistent across disconnection/reconnection

Steering for Consistency

Kiro's steering docs maintained consistency across the codebase:

# coding-standards.md

## TypeScript Guidelines

- Use strict TypeScript configuration
- Prefer interfaces over types for object shapes
- Always define return types for functions

## Backend Conventions

- Controllers handle HTTP/WebSocket requests
- Services contain business logic
- Socket events follow `action:resource` naming

Without steering, Kiro would generate valid but inconsistent code. With steering, every file followed the same patterns—crucial for a full-stack TypeScript project.

What I'd Do Differently

Research deployment constraints first - Check platform limitations before building. My Docker system was elegant but unusable.
Start with the spec - Even for hackathons, 30 minutes of requirements thinking saves hours of rewrites.
Use the CLI - When dashboards fail, CLIs are more reliable.

Try Phantom

🎮 Live Demo: kiroween-phantom.vercel.app

📂 GitHub: github.com/AIEraDev/phantom

Test accounts:

player1@test.com / player1@test.com
player2@test.com / player2@test.com

Open two browser windows, log in with both accounts, and start a battle to see the real-time sync in action.

Final Thoughts

Kiro's spec-driven development isn't just about generating code—it's about thinking clearly before coding. The structured approach caught edge cases early, made the Judge0 migration possible under pressure, and kept a complex real-time system maintainable.

Phantom started as a hackathon project, but the foundation is solid enough to build on. Next up: tournament brackets, more languages, and maybe ranked seasons.

If you're building something complex with real-time features, give spec-driven development a try. Your future self debugging WebSocket race conditions at 2 AM will thank you.

Built for Kiroween Hackathon 2025 🎃