Recently, I needed to convert an Excel-based tool into something more robust, and I decided to build a React.js application with the help of Claude Opus. Within less than four hours, I had a flawlessly working web application, just based on Claude’s analysis of the Excel structure and content. I was obviously super-happy, praising a tool that helped me do something that would have cost me at least $10,000 if I had hired an offshore developer to build it, not counting the numerous hours of back and forth during debugging I would have spent.<\/p>\n
The next two days, however, I spent coaching Claude Opus debugging the positioning of headers and footers in the PDF output of that new tool. I was frustrated and ready to throw in the towel. Had I done it myself or hired a freelancer, it would have taken half an hour at best.<\/p>\n
Since I started using AI to develop software, these ups and downs have become an essential part of my life.<\/p>\n
What I want to unpack here is why the experience swings so violently between miracle and misery – because the reasons are structural, not bad luck – and what actually changes once you stop expecting the tool to behave like a consistent colleague and start treating it like what it is.<\/p>\n
The miracle is real – and so is the misery<\/h2>\n
Let’s begin with the good half of my story, because dismissing it would be a mistake. The four-hour React build was not a fluke or a toy. AI genuinely collapses the cost of the work most developers find tedious: reading an unfamiliar data structure, scaffolding an application, wiring up boilerplate, translating intent into a first working draft. In that mode it is not a little faster than a human – it is faster by an order of magnitude, and often cheaper than you can quite believe.<\/p>\n
AI gets you 80% to an MVP; the last 20% requires patience, learning deeply or hiring engineers.<\/p>Addy Osmani, Director Google Cloud AI, 2026<\/cite><\/blockquote>\n
What the miracle of quick success quietly trains you to do: it teaches you to trust. And the tedious two-day stretch to fix something seemingly obvious (the size of a logo and its positioning) is not the worst flaw. I remember days where I was inattentive after a good moment and the AI model destroyed more than it fixed, by taking shortcuts, covering up mistakes, and creating bloated code with patches over patches. The effect: I reverted every change made that day and grudgingly accepted that a lot of work was wasted.<\/p>\n
In all these cases the results were presented with conviction, and only my scrutiny stopped this from bleeding into the codebase. “Now I have the full picture” is only one of the famous misleading sentences an AI model uses, suggesting confidence when there is none.<\/p>\n
Here’s the first thing to internalize: the high and the low are not separate experiences. The high creates<\/em> the conditions for the low. The smoother the early wins, the less you scrutinize – and the harder the eventual wall hits.<\/p>\n
The key issue: nothing about AI output is stable<\/h2>\n