AI Didn't Make Software Easy. It Made It Possible for the Rest of Us.
The one-prompt dream is a myth. Production software is still hard. What is new is that a motivated non-coder, with the right mindset, system, and grit, can finally ship the real thing.
People talk about AI coding like there are two camps. Vibe coders who type a sentence and ship whatever comes back, and real engineers who do it the hard way. There are no camps. There is one line, and the only question that matters is how much structure, verification, and human judgment surround what the machine produces.
I walked that whole line in four months. And I cannot write a line of code.
I am not a developer. I am a coach. I spent two decades teaching teams how to build software well. Then I built ShipIt, a delivery forecasting tool with real users, with Claude Code as my hands: 174 work sessions, 97 tickets, 13,300 lines of code, around 1,900 tests, and not one line typed by me. Here is what the line looks like from inside.
The vibe end: fast, fun, fake
I thought I could vibe code an app over a weekend. And honestly, I almost did. By Sunday I had a working prototype that looked real, and I was hooked. I could not believe how fast I could build something that looked finished.
That feeling is the trap.
Then I did what I always coached other people to do. I tested it hard. And the wheels came off. The prototype that looked done was nowhere near done. Production software is not software that looks done. It is software that is still standing after a thousand people poke it. It handles the weird input. It does not lie when the data is ugly. It survives the second week.
At work I had replaced a Jira plugin costing $4,200 a year with a tool of my own, prototyped in days. ShipIt is the real rebuild, built on nights and weekends over a few months: Monte Carlo simulation over a team's actual delivery history, thousands of simulated futures, turning "when will it be done?" into an honest probability instead of a promised date everyone quietly knows is fiction.
At the end of the day we are all marching toward software factories. You put a prompt in, something shiny comes out, and you have no idea what is inside it, like a vending machine.
The middle: I ran the only playbook I had. Mine.
Here is the embarrassing part. Everything I needed, I already knew. Refine the work before you build it. Define what done looks like. Review the logic, not just the output. I got seduced by the speed of asking for something and having it appear before my eyes, without doing the due diligence.
So I stopped treating Claude Code like a vending machine and started treating it like a sharp new hire on day one. Brilliant and clueless at the same time. And what do you do with a new hire? You do not hope. You onboard. I ran every Agile event I spent my career teaching, on a team of two: refinement before building, a Kanban board with tickets so the work stays visible, deliberate working sessions, a golden definition of done, and a retrospective after every session. Fifty of them, written down.
Then I told Claude one thing that changed everything: the inside code has to be beautiful too, not just the screen. Claude did not argue. It flipped to hard rules on the spot. Test-driven development. Modules kept under 300 lines, small tidy building blocks instead of one giant tangle. We tracked tech debt and test coverage like a real team, because we were one.
Except demanding rigor is not the same as getting it. Claude Code will sometimes tell you it is done when it is not. It will say the tests pass when it never wrote them. It will nail the easy case and quietly skip the ugly one. A confident wrong answer looks exactly like a confident right one. So we built a pipeline that checks the work at every step instead of taking the machine's word for it.
The gates earned their keep fast. My first forecast told me every project was 100% on track. So I fed it a hopeless, doomed project, the kind that misses every date. Still green. Still a comfortable yes. I had nearly shipped a tool that tells everyone what they want to hear and means nothing. It ran. It was wrong. Catching that is the job.
The middle of the line is also where taste gets a system. My app first showed up wearing a purple so loud it looked like a grape. That is the default look every AI reaches for, and I wanted a different style for this software. So I built a design system, one place that holds our real colors. With the design system in place, I promptly asked Claude to change purple to cobalt blue. Then the scope of work came back in the tickets: two days. Two days to change a color? That is when tech debt and the word "hardcoded" finally clicked. I never knew there were this many ways to write a color into an app. Claude had used most of them building ShipIt, back before we had a design system. When a color is pasted by hand in three hundred places instead of named once, changing it is not an edit. It is a scavenger hunt.
And I understand something now that I did not before. When a stakeholder says "just make the button green instead of blue, it's a two minute job," and the developer's face falls, I get both of them. Sometimes it really is two minutes. Without a system underneath, it can be two days. For twenty years I was the guy asking for the green button. Now I know what I was actually asking for.
The engineering end: building the system that proves it
There is a step past checking the work. You stop asking the machine to behave and you make bad behavior impossible. A rule you write into a prompt is a hope. Claude Code can forget it, drift off it, or confidently override it. A wall is a guarantee. So I stopped telling Claude to stay away from the dangerous files and fenced them off in the settings, where it never gets the choice. The statistical core of the engine sat behind a deny list. And a strange thing happens when the machine cannot wander: it focuses. The fence is what creates the focus.
Then came the hardest problem for someone like me. One day the Monte Carlo fan lines did not look the way I expected. Was the simulation wrong, or was I? I cannot read the code to find out. So I engineered trust instead. We built verification exports so the math could be audited outside the tool, by anyone. And I handed the technical architecture to a second AI, Gemini, for an independent review. It passed with flying colors. When you cannot verify the work yourself, you build the system that verifies it for you.
Sometimes that system has to catch you. I once told Claude flat out that a forecast was broken. It was not. I was. So I wrote a new rule into the process: when it looks wrong, check the numbers before you change the code. The gates are not there because the machine is dumb. They are there because everyone in the room is fallible, including me.
One more bug deserves a mention, because the math was perfect and the answer was still wrong. The code read P95, the 95th percentile, our most conservative forecast, as the fastest outcome instead of the slowest. The numbers were flawless and the meaning was backwards. You only catch that if you know what the words mean to the person reading them, which is exactly the work I did as a coach.
By this end of the line, the relationship had changed too. Claude was not a tool I used or a hire I watched. It was a teammate I planned with, argued with, and got called out by.
What the far end of the line produces
Structure did not slow the product down. It is what let the product grow. Real beta testers used ShipIt, and I pivoted and added features based on what they hit. Every division ran Jira its own way, so the system had to understand different workflows and flex to each one. Even "done" was a living decision we kept making during the project: fully deployed for one group, ready to release for another. This was not a generic out-of-the-box tool. It worked the way we actually worked.
Then came the moment every agile coach knows. "We want Gantt charts." My heart sank. Delivery is not deterministic, and a classic Gantt chart is a promise nobody can keep. But you cannot stop people from wanting Gantt charts. So I stopped fighting the format and fixed what it says. ShipIt draws a probabilistic Gantt: every bar carries its own confidence, from Almost Certain down to Unlikely, in plain words a stakeholder can read.
Read the chart for a second. Everything scheduled before the target is green. The epic straddling the target line is a coin toss, and it says so. The work past the target reads 0%, in red. This chart cannot tell a comfortable lie. That is the point of everything above it: honest software, by construction.
Somewhere in those 174 sessions, something else happened. Every role on a software team stopped being an abstraction I coached and became a pair of shoes I had walked in. I wore the product manager's shoes when beta feedback changed the plan. The designer's when the grape had to go. The tester's every time a gate failed. And I manufactured my own technical debt, felt the drag, and dug out of it. I am humbled by how difficult each of those roles really is, and I appreciate the talented people I have worked with over the years in a way I never could from the outside. I build too, so I understand builders.
So what actually changed
The barrier moved. It used to be "can you write the code." Now it is "can you direct the thing that writes the code," and that is a door a lot of us can finally walk through. Walking through it takes three things. The mindset to treat a thing that runs as unproven until verified. The system of gates, walls, and ceremonies that turns a flashy prototype into a product. And the grit to argue, reject, and rebuild one stubborn export button eight times until it actually works, instead of shipping the broken thing and calling it done.
And this is not just me. In Anthropic's recent coding contests, the winners were a lawyer, a cardiologist, a music teacher, an electronics repair tech. The first place lawyer said it plainly: "It's crazy to me that I ended up winning this contest, and I didn't write a single line of code." The people winning are not the best typists. They are the best directors.
Easy, no. Possible, yes.
So no, AI did not make building software easy. Anyone who tells you that is selling something, and the wheels will fall off in front of your customers. What it did is quieter and far bigger. It made real software possible for people who were locked out of it their whole careers, as long as they bring the mindset, the system, and the grit to do it right.
I spent twenty years coaching teams to build well. Now I can build, and I can teach your people to do the same. If your organization is trying to turn AI into shipped product instead of demos that fall apart, that is the work I want. Let's talk.
The robot is brilliant. It still needs a director who refuses to ship the car with the wheels about to fall off.
Want forecasts instead of promises, or a coach who has walked in your team's shoes? Let's talk.
Email me →