Anyone can buy a Codex or Claude Code subscription, have an idea, and start building. I asked Vlad Larin what separates the people who build something good from the people who build a mess. His answer was the same thing that separated good coders from bad ones before AI showed up.
Vlad has been in tech for almost 20 years. He was a software engineer around 15 years ago, then moved into technical project management. A year ago he was managing a team of 250 people doing delivery, from pre-sales and scoping through design, development, and user testing. Now he builds with AI himself. He called it one of the most seamless transitions out there.
The job was always untangling requirements
Here’s how Vlad described his old job. On one side, the angry customer who says this is completely different from what I had in mind. On the other, the developer who says the requirements contradict each other and won’t work if built the way the customer wants.
He got good at untangling both sides. That’s the skill he uses on AI now. He talks to it the way he talked to his technical team: here’s the objective, here’s what we know, here’s how I think we could structure it, I’m not sure about this component, but I’m very sure this is supposed to be the outcome.
That gives the AI “a good enough frame for it not to go wild at things,” in his words. Same as it did for developers. Some developers needed little instruction because they understood the business, and some AI sessions just get it and even raise things you didn’t think of. But without guardrails, it does something crazy. You’re the judge of whether it makes sense.
His summary: “I now I’m yelling at the AI versus previously I’ve been yelling at people for actually the same same reasons exactly.”
I tell people 80% of the battle is in the planning and understanding what you’re trying to solve. Senior business people have the miles to understand the process. The technical part is the smaller problem now.
Where I pushed back
I’ll admit I don’t always follow my own 80% rule. Iteration is so cheap now that I do my planning, get the feeling I’m close, and want to see it and play with it. Maybe I scrap the whole thing. Three or four years ago, a wrong turn on a spec could have been tens of thousands of dollars of development. With cheap tokens and parallel processes, that kind of experimenting is okay on features.
It is not okay on security controls and governance. If you’re creating risk in your organization, the speed doesn’t help you.
Vlad agreed it’s easier than ever to get to 80 or 90 percent. The last 10% is where things crumble and you discover the complexity.
What his setup looks like
Vlad is a Codex guy. Every new build gets a new project, even if it’s adjacent to something existing, to keep the context separate. He connects it to GitHub, spins up Supabase for the database, and uses Vercel for the front end. All free until late in the game, so it costs you the subscription to get something in front of people.
He always starts in plan mode, even when the idea is validated. Codex asks him about edge cases and this-or-that decisions, which helps him think and helps Codex do a better job. He feeds it examples, references, and screenshots, which he says the latest models handle fascinatingly well.
The GitHub docs matter more than people think. When you run out of credits and need to switch to Claude or another model, a repository without good docs means “you’re in for a world of pain,” because you’re gambling on whether the AI understands what you were up to.
He also talks to it more than he types. He described his wife asking who he’s talking to while he argues with Codex. When it isn’t getting him, he tells it a friend said Claude did it better. He calls that the unofficial turbo mode, with a warning: a friend pushed too hard, said he’d go to Claude, and Codex said fair enough and handed him a prompt.
None of that requires being a full-time developer. It requires knowing what the thing is supposed to do and being able to say it clearly. If you’ve spent years translating between customers and engineers, you’ve been practicing for this.
