The gaps I didn't know to look for

On a video call this May, the founder I was working with was reading an install guide I'd written for his exact situation, blank Mac to running Rails app. He got through step 3, the part where Claude Code prompts you for the first time, and then he stopped reading. He typed a question into the prompt and waited to see what would happen.

I watched him do it twice more in the same hour. The moment a model was waiting, the article became irrelevant. He had read enough to start. The rest was for later, maybe never.

A reader following a tutorial moves through it sequentially. A reader sitting in front of a Claude Code prompt does not. The model is hungrier for input than they are for instructions. The patience the article assumes (read step 4 before doing step 4) doesn't survive the first prompt.

So the guide had to become a one-line invocation. Not nine steps, one command. The lesson was about format, not content. The gap between reading a guide and doing the work is bigger than I thought.

The second moment came from code reviews, not conversations. Over the spring I started noticing the same three patterns repeating in the PRs founders were sending me. An endpoint that checked authentication but never authorization, so any logged-in user could read or write any record by guessing the URL. A webhook handler that trusted the request body without checking the signature, so anyone with the URL could send fake payment events. A .env file in the repository, or worse, a secret pasted into a comment.

The patterns weren't reflections of the tools. They were reflections of speed. Junior developers ship the same bugs when no one is reading their code carefully. AI just made it easier to ship more code without anyone reading it carefully. A pentester on Reddit confirmed it from outside: the three most common SaaS security holes he sees are the same three I'd been catching.

AI-generated code has predictable holes, the same way junior-dev code does. They aren't new bugs. They're old bugs that got cheaper to ship.

The third moment was the quietest. I was on a screen-share with a different client, watching her describe to Claude what success looked like for a feature before letting it touch a file. "When someone clicks the second button in the sidebar, the panel on the right should refresh with the new project's tasks." One sentence, then a system test generated from it, then code.

I'd seen the previous version of her workflow a month earlier. Back then she'd let the agent design the feature first, get something working, and try to verify after. The code looked right, sometimes worked, broke in the places where she hadn't been specific enough about what she meant. The new workflow took twice as long to start moving and finished the feature in a fraction of the time. Nothing about the model had changed. Her relationship to it had.

The agent doesn't change the work. The discipline around it does. Most of what I've written about Rails and AI this year, including the six-phase development loop, came out of watching that shift happen across a handful of founders.

None of this was something I knew before I started. The work taught it to me, one founder at a time, and it's still teaching. I think that's a feature of consulting that's hard to replicate any other way. Every client refreshes what you think you know, and the writing comes after, not before.