How Fear of AI Turned Into an AI Development System

I didn’t start with a grand strategy. I started with fear.

When ChatGPT went mainstream, a nagging thought burrowed into my mind and refused to leave: This is it. This is the thing that finally leaves me behind. This is when I become the out-of-touch tech dinosaur I’ve spent my career working to replace.

That fear was a powerful motivator. So I did the only thing I know how to do when I feel out of my depth: I started building.

The Project

The LPO Bracket app became my proving ground—a tournament manager for grass volleyball tournaments, designed to handle pool play and bracket generation. It came with specific, non-negotiable constraints:

• Complex pool logic: For 22 teams, generate 4 four-team pools and 2 three-team pools
• Data integrity: When a pool is deleted, teams remain in the database with pool_id set to NULL
• Code consistency: Match scheduling logic must stay identical on client and server

Initially, I thought AI would just be a coding assistant. But its role quickly expanded. It became an architect, a technical writer, and a pair programmer.

Phase 1: Throwing Prompts at the Wall

My first attempts were chaotic. I’d type a giant, hopeful prompt: “Build a React component that lets a user assign 22 teams into pools according to these rules…”

The output was often over-engineered, missed key invariants, and was nearly impossible to debug. It became clear that this ad-hoc prompting approach couldn’t scale. My best wasn’t very good.

Phase 2: The Mindset Shift

The breakthrough came when I stopped treating the AI like a one-off tool and started treating it like a junior engineer. It needed clear instructions, context, and guardrails.

Instead of big, messy prompts, I built a workflow: Plan → Document → Patch → PR. Instead of letting AI scan my entire repo, I built a context map cataloging the project’s critical files. Instead of asking vague questions, I gave it specific files to analyze.

Token usage dropped from 200+ files per session to fewer than 15. Focus improved, accuracy spiked, costs plummeted.

The Self-Documenting System

This was the biggest unlock. I realized the AI could document its own reasoning as part of development.

Every major feature started with a written plan. When I reorganized image assets, AI generated the migration plan and executed it. AI wrote the first drafts of user guides for tournament directors.

This isn’t just a time saver—it’s a knowledge retention layer. Anyone new to the project can open /docs/dev and instantly understand why a change was made.

What Changed

By version 2, the fear that initially drove me had transformed into something else. Not confidence exactly—more like trust in the process. I built a system that planned, documented, and improved alongside me.

When a bug emerged where client and server pool logic diverged, I didn’t spend hours manually debugging. I asked the AI to compare the pool generation logic in two files and identify discrepancies based on the invariants doc. Using the context map, it pulled only those three files and found the mismatched sorting algorithm. The fix took minutes instead of hours.

What I’m Still Figuring Out

The system works for solo development on a contained codebase. I’m not sure how it scales to teams or to projects with more moving parts. The context maps need constant updating. The docs drift if I’m not vigilant.

But the core principle seems solid: start small, learn by doing, iterate until you know better—and then do better.

That fear hasn’t entirely gone away. It just turned into something more useful.