If You're Tired, You're Not Broken — You're Paying Attention

I have fifteen years of experience. I've shipped compilers, distributed systems, a database that didn't catch fire in production. Then, about eighteen months ago, I started noticing something: I couldn't debug things the way I used to.

Not because I forgot how. Because I'd reach for a problem and AI had already solved it before I got there. The answer was just… sitting there. I'd accept it, ship it, and move on. But I couldn't tell you why it worked. Not really.

The moment that broke me was in a code review. A junior asked me why a particular optimization was correct. I had no idea. I had approved it because it looked right and the tests passed. I'd become a pattern-matching stamp.

What saved me: I started doing one hour every Friday with zero AI assistance. Just me, a problem, and whatever I could figure out. First weeks were uncomfortable. Now it's the best part of my week.

I learned to code in a twelve-week bootcamp in 2023. I graduated into a market where every job listing said "experience with AI tools a plus." So I learned to code with Copilot running from day one.

Here's the problem nobody talks about: I never developed instincts. When something breaks in a way that's weird, I genuinely don't know if it's a simple typo or a systemic architectural problem. I can't tell when I'm looking at something I should know. I just… prompt.

I got to about nine months in and realized: I can build things, but I don't know what I know. That gap — between being able to produce code and actually understanding what you're producing — is the most unsettling feeling.

The quiz on this site was the first thing that made me feel like maybe it wasn't just me. The "Explanation Requirement" strategy helped. Making myself explain, out loud, how a piece of generated code actually works — that's uncomfortable and also the only thing that's actually building real understanding.

I managed a team of eight engineers at a mid-stage startup. We adopted AI coding tools company-wide in Q1 2024. Within three months, velocity metrics looked great. Within six months, I noticed my best performers were withdrawing.

The tell was code review. People who used to debate trade-offs would approve things with no comment. The conversations that used to happen — about why one approach was better than another — had gone silent. We'd achieved velocity at the cost of exactly the kind of thinking that made us a good engineering team.

What hurt most: I could see it happening and I didn't have the language for it. HR thought I was worried about nothing. The CEO pointed to the velocity numbers. I felt like I was watching my team slowly lose something and nobody else could see it.

What helped: I started running monthly "no-AI" retros where the team deliberately discussed what they'd figured out themselves that month. I changed our code review culture to require explanation of AI-generated sections. Eventually I had to leave — the company's velocity obsession was too deep. Found a team with healthier norms. Night and day difference.

I'm a remote engineer at a US company, working from Eastern Europe. The overlap window with my team is already small. AI tools made it easy to stay in that window — I could get answers to questions that would have required scheduling a meeting or waiting until tomorrow.

What I didn't notice happening: I stopped talking to my teammates. Not because I didn't like them. Because AI was a faster answer. And in a small overlap window, speed felt critical.

About eight months in, I realized I couldn't remember the last time I'd had a real conversation with a teammate about a hard problem. I'd become efficient in a way that was quietly removing something I actually loved about being an engineer: the shared wrestling with something difficult.

What helped: I set a rule — any question that takes me more than three back-and-forths with an AI tool, I ask a teammate. Even if the AI could eventually answer it. The first week was awkward. Now it's the thing that makes me feel like I'm actually on a team again.

I need to start by saying: I feel guilty even writing this. The discourse around AI tools is so positive that saying anything less than 'this has been transformative' feels like admitting I'm not trying hard enough.

I'm a mid-level engineer, about five years in. I work at a company that adopted AI coding tools about a year ago. Everyone around me seems to be using them effectively — shipping faster, producing more. And I keep feeling like I'm the only one who spends thirty minutes prompting, getting output that isn't quite right, revising, and then feeling vaguely dissatisfied with the result.

It's not that AI doesn't help. It does. But I keep noticing: I'm more tired than I was before. I'm less confident. And I feel guilty about not keeping up with everyone else, which is the worst part — guilt on top of fatigue is a bad combination.

What helped: actually taking the quiz on this site and reading the data. Sixty-three percent of engineers feeling like middlemen. Fifty-eight percent noticing skill drift. I'm not uniquely failing. This is just what's happening. That framing didn't fix the fatigue, but it made the guilt manageable.

What I'm doing now: I set a rule that I don't start a prompt unless I've already spent five minutes thinking about the problem myself. Not solving it — just thinking. It creates a tiny gap where I'm still the engineer, and then AI extends what I've already done. It's a small thing. It helps.

I've been programming since I was fourteen. Built my first website at sixteen. Was writing React in 2015, before it was obvious it would win. I loved the craft. I loved the feeling of a hard problem giving way to understanding.

About eighteen months into heavy AI tool use, I realized I couldn't sit with a problem anymore. I would literally reach for an AI tool before I'd finished reading a bug report. Not because I was lazy. Because the discomfort of not knowing had become unbearable in a way it never was before. The AI was a shortcut out of that discomfort — and in doing so, it had removed my tolerance for sitting in it.

The breaking point: I went on a two-week vacation to somewhere with very poor internet. I came back and opened a codebase I'd been working on. I couldn't read it. Not because it was complex — I'd written it. But I'd written it with AI assistance so heavily that my own code felt foreign. Like reading someone else's handwriting.

What helped: I took three weeks after that vacation with a strict no-AI rule for anything I was learning. New features only, without AI. Hard. Uncomfortable. But after about ten days, something shifted. The problems felt like mine again. The understanding came back slower, but it came back differently — more textured.

I'm a tech lead at a Series B startup. About a year ago, our CTO made AI tools mandatory for code generation on the team. Not optional — expected. The rationale was velocity. The metrics supported it.

Six months in, I noticed my technical instincts were dulling. In design discussions, I'd find myself deferring more often — waiting for AI to show me what was possible rather than reasoning through design myself. When things broke in production, my diagnostic instincts felt slower. I'd reach for AI-assisted debugging before trying the patterns I'd used for years.

The moment I knew something was wrong: I was reviewing a system I architected eighteen months earlier. AI had generated most of the implementation. I couldn't explain why a particular choice had been made. Not because it was wrong — it wasn't — but because I hadn't made it. The AI had. And I hadn't forced myself to understand it at the time because the pressure to ship was so high.

What helped: I built a no-AI Friday practice for myself. Every Friday, I work on something — a spike, a refactor, a hard problem — with zero AI assistance. Just me and the code. First few weeks felt slow and uncomfortable. Now it's the most valuable four hours of my week. I come in with clearer thinking on Monday.