Prompt → Code ≠ Product

The default narrative right now is that AI makes building easy. Prompt a model, get code, ship it. And that's true in the most literal sense. You can go from idea to running code in an afternoon. What you can't go from is idea to product, because product requires something prompts don't carry: domain expertise, operational knowledge, and the scar tissue from doing the work by hand.

I've been building a project called LineupSnap. It generates fair, competitive lineups for youth sports coaches. Soccer, softball, large rosters, position rotations, sitting equity. The kind of thing every rec coach solves with a notebook, a spreadsheet, or a prayer.

It's about 100,000 lines of TypeScript now. Auth, payments, a proprietary fairness algorithm, hundreds of tests, end-to-end coverage. I use it every week this season for the teams I coach. But here's the thing that matters for this conversation: LineupSnap didn't start with a prompt. It started with years of coaching.

I coached my way through Apple Notes lineups, manual rotation tracking, and spreadsheets that collapsed under their own weight. Then I wrote a thousand lines of Google Apps Script to automate the parts that were killing me. That script ran for a full season before I decided to build the real thing. Each layer taught me something the next layer needed.

That progression is the part the "build a SaaS in a weekend" crowd skips.

The Default: Prompt → Code → Demo

The viral posts follow a pattern. Someone prompts a model, generates a UI, maybe wires up a database, and ships a landing page. It looks like a product. The code runs. The demo is convincing.

But a demo is a surface. It shows the happy path. It doesn't show what happens when a player shows up late and the entire rotation has to recalculate across four quarters. It doesn't show the edge case where two kids have the same sit-out count and the algorithm has to decide who sits again based on positional exposure over the last six games. It doesn't show the parent who sees their kid sitting out and wants to know why, which means you need a fairness dashboard, not just a lineup.

That complexity doesn't come from a prompt. It comes from coaching 15 eight-year-olds in the rain and realizing your "simple" rotation system just put the same kid in goal for the third straight game.

Where the Value Actually Lives

The hardest 5,000 lines in LineupSnap are the fairness algorithms. They track normalized exposure across positions, balance sit-out equity over an entire season, enforce configurable constraints like goalkeeper rotation caps, and maintain state across games so that fairness compounds instead of resetting.

None of that logic exists in any training dataset. No model could generate it from a prompt because the requirements came from exceptions I tracked by hand over years. The "what if a kid misses two games and comes back" scenario. The "what if a coach adds a player mid-season" scenario. The "what if the other team only has 8 players so we adjust to match" scenario.

This is the distinction that matters: AI is extraordinary at turning clear requirements into code. It falls apart when the requirements don't exist yet because nobody has lived the problem long enough to know what they are.

The Compounding Loop

Here's the progression I'd encourage anyone building with AI to think about:

Document manual process → Log Exceptions → Automation → Production

Each layer feeds the next. Manual process teaches you the happy path. The exceptions log captures what breaks. Automation encodes both. Production pressure reveals the next set of exceptions you didn't know existed.

Skip the manual layer and you're building on assumptions. You'll ship something that works for the demo and breaks in week three.

Think about your own daily workflows. The copy-paste routines. The spreadsheet you manually update every Monday. The approval chain you run from memory because the documented process doesn't match reality. Those manual reps aren't wasted time. They're requirements gathering. They're the domain knowledge that makes automation actually work.

This applies well beyond side projects. Enterprise teams trying to deploy agentic AI are hitting the same wall. You can't automate a process you don't truly understand. The tribal knowledge, the workarounds, the "ask Steve" steps that never got documented. AI doesn't solve that gap. It exposes it.

What AI Actually Does Well Here

I want to be clear: AI is what made LineupSnap possible. I'm not a professional developer. Claude Code, Cursor, and the broader ecosystem of AI tools turned me from "person with a very detailed spreadsheet" into "person who ships production software." That's a real and significant shift.

But AI amplified what I already knew. When I had clarity on what a feature should do, AI accelerated me dramatically. When I was confused about the requirements, AI reflected that confusion right back as buggy, half-baked code. The bottleneck quickly shifts to documentation and decision quality.