# Stop debating if AI can write code and start asking if it can maintain a production > Source: > Published: 2026-09-12 16:02:06+00:00 # Stop debating if AI can write code and start asking if it can maintain a production ## The bottleneck was never the typing Most arguments about AI replacement focus on code generation. Optimists show a one-shot app; pessimists show a hallucinated API. Both are arguing about the act of typing. In my 30-day experiment, the AI handled the CRUD operations, Zod schemas, and initial scaffolding flawlessly. It was faster than I ever could be. But my actual output only increased by maybe 20%. Why? Because writing the syntax is only 20% of the job. The remaining 80% is deciding *what* to build, spotting subtle logical errors that don't trigger a compiler warning, and knowing which features to cut. Measuring a model's success by whether it can produce a working function is like judging a surgeon by how fast they can make an incision. It's the easiest part of the process. ## The junior-to-senior ladder is being sawed off There is a dangerous assumption that the path from junior to senior developer is a fixed object. People argue that AI either levels everyone up or deletes junior roles. They miss the point: you become a senior by doing the exact grunt work AI is now absorbing. The boilerplate, the scaffolding, and the "confident-but-wrong" first drafts are not just busywork; they are the curriculum. By automating the bottom rungs of the ladder, we aren't just making juniors more productive—we are removing the environment where senior-level intuition is built. In my project, the AI didn't replace me; it replaced the tasks I would normally delegate to a junior. This doesn't flatten the hierarchy; it makes the top rungs more valuable while deleting the entry point. We are assuming seniors will keep appearing magically, even though the "training ground" of manual implementation is disappearing. ## Demos are not production Almost every prediction is based on a "happy path" demo. A todo app built in 90 seconds looks like a miracle in a screenshot, but production isn't a screenshot. Production is the 2am outage where the logs are cryptic and the edge case is something the model has never seen in its training set. When I was running my AI-generated SaaS, the "demo phase" was effortless. The "maintenance phase" is where the friction lives. The real test isn't "Can it build X?" but "Can it debug a race condition in a distributed system under load?" Most predictions extrapolate from the former to answer the latter. If you're currently using tools like [Cursor](/en/tags/cursor/) or Claude 3.5 Sonnet, you'll notice the productivity gain is massive during the "greenfield" phase. But the moment you hit a complex architectural wall or a legacy bug, the "replacement" narrative evaporates. You aren't being replaced by a model; you're being shifted into a role that is 100% review and architecture, with 0% of the manual labor that used to teach you how that architecture actually works. [Next CauterRule 0.3.0 fixes the recall bug that made good rules look like noise →](/en/threads/9261/) ## All Replies （3） I'm terrified because I spent six hours debugging a single hallucinated method in LangChain last week. Does it actually handle legacy migrations? I want to try this tonight. Does it actually handle the ATS parsing or just spam the portal via Selenium? I want to try this tonight with my old repo. I wonder if it can actually handle the 404 errors in...