The Deskilling Myth

I blanked on TypeScript generics last week. Not even anything fancy, just T extends Record<string, unknown>. I've written that a thousand times and I sat there like... is it extends? implements? Where do the angle brackets go again? I gave up and let the AI do it.

A year ago I could type that without thinking. Same with useCallback dependency arrays, WebSocket reconnection, CORS preflight headers. All stuff that used to be muscle memory. Now I have to look it up or just let the AI handle it.

If you want proof that AI is making us dumber, there you go. The take writes itself. We're getting dependent on tools, our skills are getting worse, and we're all going to be screwed when the tools stop working. I see some version of this on Twitter every single day.

I don't think that's the whole picture though.

What I Actually Do All Day

A few months ago I was building a system that syncs state across three services. Real-time updates, eventual consistency, all of it. Normally I would've had us start building right away. That's always been my move. Get something going, figure it out as you go, fix what breaks.

This time I just sat and thought about it before I wrote anything. I mapped out what happens when one service goes down while the others keep running. I thought through rollback strategies. I found edge cases that would've wrecked us in production later. By the time I started writing code, I actually knew what I was building.

I didn't do that because I suddenly got more disciplined. I did it because I knew the coding part would be fast. When writing the actual code takes hours instead of weeks, you don't feel the pressure to just start hacking. You can actually spend time thinking because you know you'll make it up on the other side.

That's not deskilling. That's the opposite. It just doesn't feel like the opposite because yeah, I'm definitely worse at the typing-code-from-memory part. If you tested me on writing a React hook with proper memoization or setting up WebSocket reconnection with exponential backoff, I'd do worse than I would have a year ago. For sure.

The Measurement Problem

All that time that used to go into implementation is going somewhere else now. And honestly, where it's going matters more than where it came from. We just don't have a good way to talk about it yet. We can measure typing speed and syntax recall and lines of code per day. We have no idea how to measure "makes better architecture decisions" or "picks the right technology" or "sees problems before they happen."

I'm juggling three projects right now where I used to handle one. Not because I'm working more hours. The bottleneck just moved. Implementation used to be what determined how much my team could take on. Now the constraint is figuring out what to build and whether it actually works. The building part goes fast enough that I can keep more stuff going at once.

I've also been trying stuff I never would've touched before. We needed an animation library for a project recently and instead of just grabbing Framer Motion like I always do, I actually built the same set of interactions with three different libraries to see which one felt right. Before AI, I'd never bother with that. I'd just go with the thing I already knew, even if it wasn't the best fit. Now I can actually try things because the cost of exploring is basically nothing.

My UI work got better too. When trying a different layout is fast, you actually try different layouts. You do three versions instead of shipping the first one that kinda works. I have real opinions about spacing and visual hierarchy now that I never had before, just because I've gotten way more reps in. You get better at design by iterating, and you can only iterate if it's fast.

The Skills Nobody Talks About

There's a bunch of stuff I've gotten better at that nobody would ever ask about in an interview. Like scope. When implementation is the bottleneck, it's easy to justify keeping your focus narrow. You're busy. Your team is busy. Everyone's heads down.

Now that the building is faster, I'm spending way more time on the bigger picture. What should we actually be working on. Which problems matter most. How do these three projects connect and where are they going to collide. Staying on top of all of that when everything is moving fast is its own skill, and it's one I'm developing way more than I used to.

Coordination is another one. When your team can execute faster, there's just more to keep in sync. More things in flight, more decisions happening at once, more places where stuff can go sideways if nobody's paying attention. That part of the job got bigger, not smaller.

The Junior Developer Question

OK there is a real concern here and I don't want to brush it off. What about people who never built the basics in the first place? If you lean on AI before you actually understand what it's doing, you might never learn. You'll be the person who can't debug when the model makes stuff up, can't design a system when the problem doesn't fit a neat template, can't tell when generated code is wrong in ways that won't blow up until production.

That's a real worry. I'm just not sure it's a new worry. Every round of new tools brings the exact same concern. IDEs with autocomplete were supposed to make us forget syntax. Stack Overflow was supposed to replace understanding with copy-pasting. High-level languages were supposed to produce engineers who have no idea what their code is actually doing under the hood.

And sometimes those worries were right. There are definitely developers who copy code without understanding it, who can't debug because they don't know what's going on underneath, who fall apart without their tools. Those same tools also let people work on harder problems than they could before. The engineer who doesn't know assembly isn't automatically worse than one who does. They're just working on different stuff at a different level.

I don't think the answer is to stop using the tools. It's more about knowing when to use them and when not to. Write code by hand sometimes so you remember what's actually happening. Build something from scratch every once in a while. Actually read what the AI gives you instead of just accepting it.

What doesn't help is acting like the specific skills your generation learned are the sacred ones. Syntax and boilerplate were never the point. Thinking through systems, spotting where things will break, making good tradeoffs, knowing when something is right. That stuff carries over no matter what tools you're using.

What Actually Matters

I still write code by hand sometimes. Not because I have to, more because it keeps me sharp. Like a pilot doing manual flying practice in a sim. You keep the skill up even if you're not using it every day, because eventually the autopilot's going to do something weird and you need to take over.

The exercise isn't the job though. The job is building stuff that works. Making architecture calls that don't fall apart under load. Shipping software that actually solves problems for people. Knowing when to let the AI rip and when to slow down and think.

By that measure, I'm doing fine. The important skills shifted and I shifted with them. My generic constraint syntax is rusty and I honestly don't care. My sense for when to use generics vs a union type vs just rethinking the whole approach? That's better than it's ever been.