What I lose first when the AI goes down
Every so often one of the AI tools I use goes down for a few hours, and I get a small preview of what I’m like without it. The most recent big one was in early September, when ChatGPT, Claude and Grok all had outages within a couple of hours of each other, so there wasn’t even anything to switch to. I get slower when this happens, obviously. I expect that. What I didn’t expect, the first time I noticed it, was how shaky I felt about decisions I’d normally just make. I sat there staring at the screen like someone had unplugged part of my brain.
Slower is fine
If the tools vanished tomorrow, I’d still write code. I’d just be slower and crankier, with more caffeine. That doesn’t worry me much, because the speed comes back the minute the tool does. Or I just go to sleep until the tools are back and give my body the break it deserves.
The part that worries me is my own judgment. At some point I’d started checking every decision with the model before I acted on it, even small ones like what to name a function. I’d know how I wanted to structure something and I’d still ask first. So when it went away I still knew how to do the work. I just didn’t trust myself to do it. I think that’s the order it goes in. You lose confidence before you lose productivity, and you can’t really see it happening while the tool is up. Nothing breaks and you ship as much as before. The only sign is that you’ve stopped making a call without asking first.
Where I handed it over
The first React app I shipped was mostly written by a model. I’d describe a feature and get back a 300-line component, and I didn’t know enough to question it, so if it ran, I shipped it. It did run, which is why I never looked any closer. A few weeks later, once I had a better handle on component architecture and state management, I went back through it and didn’t like what I found. It was full of packages I didn’t need and state being passed around in ways I couldn’t follow, and cleaning it up took forever. The annoying part is that the same tool was also a good teacher. I had no idea about small accessibility details, like managing focus traps or announcing dynamic state changes, until the model pointed them out, and that opened up a corner of frontend I’d been skipping.
So what was different? The first time, I asked it to do the work and took what came back. The second time, it told me about something and I had to go and understand it myself. It was the same model and the same me. One of those left me better at the job, and the other left me with a codebase I couldn’t explain (btw: models as of November 2026 are more scarier since the code quality is much better. Tbh, I don’t know how relevant code quality is anymore).
Anthropic published a study in January 2026 that looks a lot like this. They had 52 engineers, mostly junior, build something with a Python library none of them had used, half with an AI assistant and half without, and then gave everyone a quiz on the library. The AI group averaged 50% and the group who wrote the code by hand averaged 67%, with the biggest gap on debugging questions. The AI group also only finished about two minutes sooner, which the study says isn’t a statistically significant difference. So they didn’t really buy any speed, and they gave up a fair bit of understanding.
The bit I found interesting is inside the AI group, because it didn’t all go one way.
People who leaned on the model to write or debug the code all landed under 40%. People who asked it to explain things, or only asked concept questions and wrote the code themselves, landed around the no-AI average or above it. The fastest people in the whole study were the ones who handed everything over, and they scored 39%. It’s a small study, and the authors say they can’t show that one causes the other. It still matches what happened to me almost exactly.
That’s also why I wouldn’t go back to typing everything by hand. Because the model writes most of my code, I have time I wouldn’t otherwise have, and I spend a lot of it on systems design and architecture. That started with React apps, and now it includes how mobile apps work and how they differ between operating systems. I wouldn’t have got to any of that this early without it. So I’m happy to hand over the typing. The React mess was what happened when I handed over the understanding as well.
It’s getting harder to notice
We used to joke about hallucinations. A model would invent an API and you could usually spot the cracks. Now the code compiles and the explanation sounds right, which is a much harder kind of wrong to catch. In Stack Overflow’s 2025 survey, the biggest frustration, picked by 66% of developers, was AI answers that are “almost right, but not quite”. In the 2026 one, the most common answer on trust, at 48%, was “I trust it when I can easily verify the output”.
I’d have ticked that box too. The trouble is that those two answers pull against each other. If the output is almost right, it’s the kind of thing I can’t easily verify, and that’s when I’m most likely to nod along. An answer that’s obviously wrong makes me think. One that’s almost right doesn’t, and every time I nod along without checking, that’s one more call I’ve handed over.
What I do about it
I don’t have a system, and honestly I often just go with the vibes. The habit I’d recommend is deciding first and asking second. I draft my own plan or the API shape before I prompt. Then the model is checking my answer instead of giving me one, and when it goes down I still have somewhere to start. It’s also the cheapest way I know to find out whether I still have an opinion. If I sit down to write the plan and nothing comes out, that’s worth knowing before the next outage.
The other one is treating its output like a PR from someone else. I read the diff and look hard at any dependency it added, because that’s where my frontend mess came from. I skip both more often than I’d like. An outage is a decent reminder to check how much I’ve let slide.