Vibe coding はデバッグ能力のない開発者を生み出している。私たちはその代償を払うことになる。

こんにちは、私は Tuan です。 最近、バックエンド職の技術面接を実施してきました。数回の面接におけるパターンは本当に驚くべきものでした——そして、私たちが業界全体としてそれを本音で話しているのかどうかは疑問です。 私が面接した候補者の多くは、デバッグできませんでした。 「デバッグに苦労した」あるいは「予想より長くかかった」ものではありません。「デバッグ不可能」という意味において、壊れたシステムの仮説を形成し、検証することができませんでした。何か物がらなくなると、同じ反射が働きます：エラーを Cursor に貼り付け、ファイルを貼り付け、待機し、再度貼り付ける。 私はこれをゲートキーピングのために書いていません。何かが私たちの職業において静かに壊れ始めており、それを指摘しているシニアエンジニアはほとんどそれを静かにしているだけで、口に出すのは「老人が雲に叫んでいる」ように聞こえるからです。 よし。私はその老人だ。 実績の良い履歴書、数年の実務経験。システム設計、Redis キャッシング、キューパターン、といったものには自信がある。 彼に小さな課題を与えました：特定の入力に対して 500 エラーを返す Node.js サービスです。ロギが含まれていました。どのツールでも使用でき、AI も含まれます。 彼は Cursor を開き、スタックトレース、ソースファイル、そして解決せず新しいエラー、さらに次のエラーを貼り付けました。 40 分後、彼は 4 つの AI 提案タブを開いており、実際に何が間違っているのかについての理論を持っていませんでした。 私が彼に問題を解くまで、そのバグは幻視されたメソッドでした。3 ヶ月前、彼の AI アシスタントは.non-existent(.findUserByEmailOrThrow()) メソッド——私たちが使用する ORM に存在しないメソッド——を提案しました。コードが出荷されたのは、テストがデータレイヤーをすべてモックして真偽値を返したからです。本番では、呼び出しが未定義に解決し、次の行がそれを参照分解しました。そして、まだ誰も遭遇したなかった特定の端 case でサービスがクラッシュしました。 彼はその行を読みません受け入れました。彼には ORM が実際に公開するコードのモデルを持っていませんでしたから、それがキャッチできるはずはありませんでした。 私は彼を揶揄するために这个故事を述べていません。彼は頭が良い、論理的で、おそらくこの年齢の私が持つよりも分散システムを理解していませんでした。 彼は、目の前にあるコードが実際にどのように実行されるのかについての内部モデルを持っていませんでした。 私がそれだと思いました。でもそうではありませんでした。 最近の面接で、同じパターンが繰り返し現れました： 多くの候補者は、自分自身で一度の仮説を形成する前にエラーを見て 1 分以内に AI ツールに手が差し伸べました。 大半は、自分のコミットしたコードがどのように動くのか、行ごとに、説明する際、私の前に歩こうとしませんでした。 数人は、自分たちが使用しているライブラリに存在しない関数やフィールドを含むコードを出荷していたことがあり、それはテストが彼らをまわってモックしたからでした。 いくつかの人は、私に促すことなく「実はもうデバッグしていません」と言いました。 彼らはブートキャンプの卒業生ではありません。彼らはあなたが聞いたことがある企業の中レベルのエンジニアたちです。 そしてそれは私の面接室だけのことではありません。METR の 2025 年の経験豊富なオープンソース開発者に関するランダム化された調査は、スタンドアップで誰も繰り返したくない発見をしたことを示しました：AI ツルを使用して開発者は 20％速いと感じました、そして 19％遅いと測定されました。GitClear の 2024 年のミリオンコミット分析では、Copilot が主流になった以来、「 churned code」——2 ヶ月に追加され削除されたコードの行——のレートは約 2 倍になりました。私たちは、すぐにまたそれを取り除くコードを出荷しています。 何かが変わりました。そしてそれを指摘するために最も位置づけられている人々——シニアエンジニア——はほとんどそうではありません、なぜなら同じツールは彼らを速くするために作るからです、そしてそれはあなたにとってのものを批評するのが難しいからです。 ここは、Twitter 上の誰も認めたくない部分です。 あなたが自分で問題をデバッグするとき——本気でデバッグする、つまり、印刷ステートメントと悪い仮定と死んだ先——あなたは単にバグを修正しているだけではありません。あなたはシステムの精神的モデルを構築しています。あなたの誤り仮説を排除するたびに、あなたは圧力の下でコードがどのように振る舞うのかについて何かを学びます。 そのモデルは、すべての仕事のものです。 これは民間の知恵ではありません。認知科学はそれを 40 年ぶりに名付けました：好ましい困難さ。Robert Bjork の研究は、学習があなたが経験する摩擦に比例して定着することを示しました。

Hello, I'm Tuan. I've been doing technical interviews for backend roles recently. The pattern across the last few rounds genuinely scared me — and I don't think we, as an industry, are talking about it honestly. Most of the candidates I sat with could not debug. Not "struggled to debug." Not "took longer than I expected." Could not, in any meaningful sense, form a hypothesis about a broken system and test it. The moment something didn't work, the same reflex kicked in: paste the error into Cursor, paste the file, wait, paste again. I'm not writing this to gatekeep. I'm writing this because something is breaking in our profession, quietly, and the seniors who notice it are mostly staying quiet because saying it out loud sounds like an old man yelling at clouds. Fine. I'll be the old man. Strong resume. A few years of experience. Confident on system design, fluent on Redis caching, queue patterns, the usual. I gave him a small task: a Node.js service throwing 500s on a specific input. Logs included. He could use any tool, including AI. He opened Cursor and pasted the stack trace. Then the source file. Then, when the suggestion didn't fix it, the new error. Then the next error. Forty minutes in, he had four open tabs of AI suggestions and no working theory of what was actually wrong. The bug, when I finally walked him through it, was a hallucinated method. Three weeks earlier, his AI assistant had suggested .findUserByEmailOrThrow() — a method that does not exist in our ORM. The code shipped because the test mocked the entire data layer and returned truthy. In production, the call resolved to undefined, the next line dereferenced it, and the service crashed on a specific edge case nobody had hit yet. He had accepted that line without reading it. He could not have caught it, because he had no model of what code his ORM actually exposed. I'm not telling this story to mock him. He was smart, articulate, and probably understood distributed systems better than I did at his age. He just had no internal model of how the code in front of him actually executed. I assumed it was. It wasn't. Across the recent interviews, the same patterns kept showing up: Most candidates reached for an AI tool within the first minute of seeing an error, before forming a single hypothesis of their own. A majority could not walk me through what their own committed code did, line by line, when asked. Several had shipped code containing functions or fields that don't exist in the libraries they claimed to use — hallucinations that survived because tests mocked around them. A non-trivial number told me, unprompted, that they "don't really debug anymore." These were not bootcamp graduates. These were mid-level engineers from companies you've heard of. And it isn't just my interview room. METR's 2025 randomized study on experienced open-source developers found something nobody wants to repeat at standup: developers using AI tools felt 20% faster, and were measured 19% slower. GitClear's 2024 analysis of millions of commits found that the rate of "churned code" — lines added and removed within two weeks — has roughly doubled since Copilot went mainstream. We are shipping more code that we then immediately rip back out. Something has shifted. And the people best positioned to call it out — senior engineers — are mostly not, because the same tool is making them faster, and it's hard to criticize what's working for you. Here's the part nobody on Twitter wants to admit. When you debug a problem yourself — really debug it, with print statements and bad guesses and dead ends — you're not just fixing a bug. You're building a mental model of the system. Every wrong hypothesis you eliminate teaches you something about how this code behaves under pressure. That model is the entire job. This isn't folk wisdom. Cognitive science has had a name for it for forty years: desirable difficulty. Robert Bjork's research showed that learning sticks in proportion to the friction you experience while doing the task — not in spite of it. Make the practice too easy and the skill never consolidates. The struggle isn't a tax on learning. It is the learning. Writing code is the easy part. AI is great at the easy part. But the model — the intuition for where the bug probably is, the smell that says this looks fine but it isn't — only forms when you struggle. When you outsource the struggle, you outsource the model. AI doesn't make you a worse developer. It makes you a developer who never becomes a better one. It's like learning chess by only playing with the engine's evaluation bar visible. You'll know which moves are good. You will never know why. The day the bar disappears, you are not a chess player. You are someone who used to be near a chess engine. There are two arguments against everything I just wrote that I take seriously. I want to deal with both, because if I don't, the comments will — and probably less charitably. Counter 1: "Juniors will learn faster, not slower. AI lets them ship more, hit more edge cases, see more of the system." I want to believe it. I genuinely do. I'm just not seeing it in the people walking into the interview room, and I'm not seeing it in the data either. Volume of code shipped is not the same as depth of understanding, and "shipping more" only teaches you something if you have the model to interpret what you shipped. Without the model, more output is just more noise — which is exactly what GitClear's churn numbers look like. Maybe I'm wrong. Maybe in three years the data flips and juniors reach senior-level intuition faster than ever. I'd love to write the apology post. Counter 2: "Calculators didn't kill math. Compilers didn't kill assembly devs. IDEs didn't kill C programmers. Every abstraction triggers this panic and the industry adapts. You're being a boomer." This is the argument I respect most, and it's also the one that's wrong in a specific, important way. Every previous abstraction in software was deterministic. A calculator that returns the wrong answer for 2 + 2 gets recalled. A compiler that miscompiles is a P0 bug that ships a patch the same week. An IDE that auto-completes a method that doesn't exist is broken software. The contract was: the abstraction is correct; you can trust the output and focus on the layer above. AI is the first abstraction in our field whose output can be confidently, plausibly wrong, by design, and we ship it anyway. There is no recall. There is no patch. The "bug" is the entire premise. That changes what skill is required of the user. With a compiler, you didn't need to verify its output line by line — that would defeat the point. With AI, verifying the output line by line is the only thing keeping you from shipping nonsense. And verification requires the exact skill — reading code, building a model, smelling wrongness — that vibe coding skips. Calculators didn't require a numeracy detector. AI requires a bullshit detector. You can only build that detector by being wrong, alone, many times, before you ever touch the tool. This is not the same transition. It looks the same from the outside. Underneath, the contract has flipped. The skill is not "writing code." The skill is forming a hypothesis about a system you don't fully understand and testing it cheaply. This is what senior engineers do all day. It's why we get paid. It's also the thing AI cannot teach you, because you can only learn it by being wrong in public, repeatedly, with consequences. Every time a junior pastes an error into Claude instead of reading it, a small skill atrophies. Compound that across two years of "productivity" and you get someone who can ship a CRUD app from scratch but freezes when production breaks at 2 AM. Stack Overflow, by the way, was not the same thing. It forced you to read an answer that was usually for a slightly different problem, then adapt it. That adaptation step — "this isn't quite my situation, but if I change X..." — was the learning. AI removes the adaptation step. It gives you something that looks like it should work, you accept it, you ship it, you learn nothing. Stack Overflow was a textbook. AI is the answer key. I've stopped saying "don't use AI." That's both unrealistic and condescending. What I tell them instead: Form your own guess before reaching for the tool. Even a wrong guess. Especially a wrong guess. The wrong guess is where the model gets built. Before you accept any AI suggestion, explain to yourself why it works. Out loud, if you have to. If you can't, don't paste it. Once a week, fix something the hard way. Pick a bug. Solve it without AI. It will feel slow. That's the point. This isn't anti-AI. It's anti-atrophy. The goal is not to never use the tool. The goal is to make sure that when the tool is wrong — and it will be wrong, on the day production is on fire and the stakes are real — you are not standing in front of the wreckage with no idea what to do. In five years, debugging legacy systems will be the highest-paid niche in software, because almost nobody under thirty will be able to do it. I am not joking and I am not exaggerating. The systems we are building today will still exist. The bugs in them will still exist. Someone will have to walk into a 200,000-line codebase, follow execution by hand, and figure out why a specific request is timing out on Tuesdays. That person will charge a fortune. There will not be many of them. If you are early in your career, this is genuinely good news — but only if you choose discomfort now. The friction of debugging without AI is not a bug. It is the skill being installed. Skip it now and the bill comes due later. It always does. If you're a junior reading this and you disagree — I genuinely want to hear why. Tell me what I'm getting wrong, in the comments. I'd rather be argued out of this than be right about it. I write about backend, production incidents, and the unglamorous parts of being a software engineer. Follow if that's your kind of thing.