The Impossible Ask: Work at AI Speed, But Understand the System Like You Built It

A tech lead on Reddit described engineers using AI to ship 5,000+ line pull requests daily, producing code that is "complete garbage and incredibly fragile and full of bugs," while management blames reviewers for "slowing down growth." The paradox of demanding both AI-speed development and deep system understanding is impossible, and AI-assisted coding without a pre-existing mental model creates technical debt on steroids, according to the author. Anthropic's randomized controlled trial found AI-assisted developers scored 17% lower on mastery, equivalent to nearly two letter grades, with the largest gap in debugging skills.

A few weeks ago, my CTO pulled me aside and said, “I want you to work at AI speed. Vibe code everything, let the agent do it, just review the output. But I also need you to understand the system deeply enough to anticipate what will break two weeks from now.” I told her that’s impossible. She didn’t believe me. That paradox, demanding velocity and deep understanding at the same time, is the core lie our industry is swallowing right now. You cannot maximize both. Either you hold the full mental model yourself, as if you’d built every component by hand — or you delegate to AI and end up with shallow, review-level knowledge. There is no shortcut that gives you both. And the people who promise otherwise are selling something. AI-assisted coding without a pre-existing deep mental model of the system is technical debt on steroids. The middle ground exists, but it requires understanding the system as if you had coded it yourself from scratch, and then using AI only for surgical, controlled execution of things you already know exactly how to do. That’s slower. That’s what a lot of people call “unproductive.” But it’s the only way to not wake up six months later with a codebase nobody understands and bugs nobody can fix. We’ve been sold a lie that more code faster means more software faster. It doesn’t, and it never did. Look at what’s happening on real teams. A tech lead on r/ExperiencedDevs described a few engineers with “no constraints” who are “shipping 5000+ diff PR per day, with full feature sets built out. The results are obviously great for demos, and powerpoint decks, but code is complete garbage and incredibly fragile and full of bugs,” according to a recent post https://old.reddit.com/r/ExperiencedDevs/comments/1rwzfra/how to manage vibe coders backed be leadership/ . When he holds their PRs and asks for fixes, management blames him for “slowing down growth.” This is not a one-off. It’s the new normal. The same pattern existed a decade ago, just slower. One developer on r/webdev put it crassly: “A decade ago those customers would have ended up hiring someone on Fiverr to create a buggy, unmaintainable mess of copy-pasted code. Today, they can instead hire someone on Fiverr to have an AI create a buggy, unmaintainable mess of copy-pasted code,” as noted in a discussion on r/webdev https://old.reddit.com/r/webdev/comments/1qughoj/so when will people realize vibe coding is just/ . Same garbage, just faster. And when it breaks, there’s no vibe to lean on. As one exasperated developer wrote, “I can’t vibe my way through debugging, I can’t ship anything that actually matters, and then I’m back to square one pulling out my wallet for someone who actually knows what they’re doing,” per a post on r/vibecoding https://old.reddit.com/r/vibecoding/comments/1mu6t8z/whats the point of vibe coding if i still have to/ . The telemetry backs this up. AI-enabled developers merge 98% more pull requests, but PR review times inflate by 91%, according to a MeaningfulTech analysis https://meaningfultech.com/p/the-vibe-coding-illusion-why-faster . The code lands, but the bottleneck just shifts downstream. And the maintenance phase hasn’t even hit yet. Most vibe-coded apps never reach real maintenance. We’re still in the honeymoon. When all these AI-sloshed codebases need integration, refactoring, and real debugging, the dumpster fires will be spectacular. 98% more pull requests, but 91% longer review times and a bump in bugs. Speed doesn’t mean progress. This isn’t just about bad code. It’s about what happens to your mind when you stop thinking. Anthropic ran a randomized controlled trial with 52 developers learning a new library. The AI group scored 17% lower on mastery, the equivalent of nearly two letter grades. The largest gap was on debugging questions. Their summary is blunt: “the ability to understand when code is incorrect and why it fails may be a particular area of concern if AI impedes coding development,” Anthropic’s study reports https://www.anthropic.com/research/AI-assistance-coding-skills . You are trading long-term comprehension for short-term output. And developers are feeling it. One admitted, “I do review the code, but being honest, a lot of the time I’m skimming. I feel more like a tester than a developer,” as shared on r/webdev https://old.reddit.com/r/webdev/comments/1sjhkhj/do you feel like youre losing your actual coding/ . Skimming is the new coding, but you can’t own a system you only skimmed. There’s a sewing-machine analogy that lands hard. If you don’t know how to sew by hand, using a sewing machine will just let you make mistakes faster. The hard part of sewing isn’t the actual sewing; it’s everything that puts you in a position to sew. AI amplifies skill. If you have none, it amplifies your incompetence. A sewing machine lets you make mistakes faster. Without deep understanding, AI is that machine. If you never struggle to write code, you never learn to debug it. If you never fix your own mistakes, you never build the intuition that tells a senior developer, “That’s the kind of bug that comes from a race condition,” before even opening the log. I think about the junior developer who posted on r/SaaS: “Built my MVP in 3 days with Claude. Felt like a god. Then I hit a weird auth bug. I spent 4 hours ‘prompting’ the AI to fix it, only for it to hallucinate and break everything else. I realized I didn’t even recognize my own architecture. Finally deleted the AI mess, looked at the logic, and fixed it manually in 20 minutes,” as recounted on r/SaaS https://old.reddit.com/r/SaaS/comments/1rwa2ox/vibe coding is making us 10x faster but 100x/ . That guilt, knowing you built something you don’t understand, is a signal that something is broken. Worse, the pipeline is cracking from the bottom. One senior engineer on r/cscareerquestions said, “I already see junior devs shipping AI-generated Terraform that works… and they have zero clue how to fix it because they never learned the fundamentals. Companies are in the ‘fuck around’ phase and the ‘find out’ phase is coming,” as shared on r/cscareerquestions https://old.reddit.com/r/cscareerquestions/comments/1rn8e3g/have we professional developers already lost the/ . Can you become an expert bug-finder by only reading AI output? No. The data shouts the same thing: AI adoption correlates with a 154% increase in average PR size and a 9% increase in bugs per developer https://www.faros.ai/blog/ai-software-engineering . We are raising a generation of prompt engineers who can’t debug a race condition, and the bill is coming. When AI churns out code, the ‘factory’ looks great in demos, but quality inspection can’t keep up. I don’t blame the CTOs for wanting speed. Startups need to find product-market fit or they die. Budgets are tight. A demo that works in a PowerPoint is better than a perfect architecture that never ships. I get it. But the cost of this thinking is invisible until it’s too late. The tech lead who insists on quality gets blamed for “slowing down growth.” The engineers who know every moving part well enough to predict what breaks are told to be more like the vibe coders. The culture shifts: velocity over everything, understanding be damned. The DORA data is the canary. The broader industry data paints an even grimmer picture: A SmartBear survey from March 2026 found that 70% of software leaders say application quality has already degraded as AI accelerates development. The 2024 DORA report found that a 25% increase in AI adoption correlated with a 7.2% decrease in delivery stability and a 1.5% decrease in throughput. We are not getting faster. We are getting faster at creating messes. Delivery stability drops as AI adoption rises. Incident response times degrade because debugging code you didn’t write, in patterns you don’t recognize, takes longer. More code, reviewed less thoroughly, tested less completely, and released more frequently produces more production incidents. Management sees the initial burst of speed and confuses it with productive output. They don’t see the seven hours per week teams lose to AI-related inefficiencies. They don’t see the codebase nobody will be able to maintain six months from now. You might think this is the same argument people used against IDEs and IntelliSense, but it’s not. Those tools still required you to know what you intended to write, they just auto-completed lines you already conceptualized. AI agents, by contrast, write code you never formed the intent to create in the first place. The difference is losing the mental model entirely, not just saving keystrokes. This isn’t a technology problem; it’s a cultural rot that rewards looking fast over being solid. Use AI like a scalpel, not a chainsaw. The difference is whether you know exactly what to operate on. I’m not saying don’t use AI. I use it every day. But there is a way to use it that doesn’t atrophy your brain or destroy your codebase. First, treat AI like a junior coworker. Review every line. Change most of it. Use it for cross-checking, not authority. One developer puts it nicely: “I use LLMs daily for coding but have absolutely always code-reviewed what it writes and change it most of the time. I treat it as a junior coworker,” as advised in an r/AI Agents discussion https://old.reddit.com/r/AI Agents/comments/1r68hpy/discussion honest question how are you preventing/ . Second, enforce the five-minute rule. Never let an AI agent run unattended for more than five minutes. Short, focused, constantly reviewed interactions produce far better results than massive spec-driven sessions. Long autonomous runs create code that looks polished but hides architectural drift you won’t catch until it’s too late. Third, turn off autocomplete. Write the first draft yourself. Then use AI to suggest improvements. This forces you to form your own mental model before the AI muddles it. There’s a hard truth in the saying, “If you’re nothing without AI, maybe you shouldn’t have it.” Fourth, when you must use AI on a system you don’t fully understand, build audit trails. One engineer described leaving over 100,000 lines of markdown organized by tasks, specifications, and guides, a trail that keeps you tethered to the system even when AI writes the code, according to an account on r/vibecoding https://old.reddit.com/r/vibecoding/comments/1mfgeex/vibe coding is not working and heres why/ . That’s not overhead; that’s ownership. The same trial found that developers who scored high used patterns like asking follow-up questions after generating code, combining generation with explanations, and using AI only for conceptual inquiries while coding independently. That’s the real middle ground: use AI as a tutor and a keystroke saver, never as a ghostwriter. It’s slower than vibe coding, but it’s the only pace that leaves you in control. I’m not a Luddite. I use AI tools daily, and they make me faster at things I already know how to do. But my rule is absolute: understand your system as if you coded it yourself from scratch. Then use AI for surgical, controlled execution of precisely the things you already know exactly how to build. That’s slower than vibe coding. That’s the honest trade-off. And it’s the only way to own what you ship. The industry is sleepwalking into a crisis where we have never shipped faster and understood less. When the maintenance phase finally hits, and it will, the companies that survive will be the ones that prioritized mental models over velocity. Everyone else will be cleaning up dumpster fires with a team of developers who can only prompt. If you’re nothing without AI, maybe you shouldn’t have it. The Impossible Ask: Work at AI Speed, But Understand the System Like You Built It https://pub.towardsai.net/the-impossible-ask-work-at-ai-speed-but-understand-the-system-like-you-built-it-80a2b1f844e0 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.