Photo by Alex Knight on Unsplash
Last week, I watched a junior developer ship a feature in two hours that would have taken me a full day five years ago. They didn't write most of the code — Claude did. They reviewed it, tweaked a few things, and pushed it to production.
I felt two things simultaneously: impressed and uneasy.
The New Reality
Let's be honest about where we are. AI isn't coming for white-collar jobs — it's already here, sitting in our IDEs, our design tools, our spreadsheets. The question isn't whether AI will change how we work. It's whether we'll still understand what we're doing.
In coding, I can now describe a feature in plain English and watch working code materialise. In design, tools generate layouts, suggest colour palettes, and even create entire brand identities. In analysis, AI summarises reports, identifies patterns, and drafts recommendations.
The productivity gains are real. But so is the quiet erosion of something harder to measure.
The Grey Areas No One Talks About
Enterprise leaders are understandably excited. AI promises faster delivery, reduced costs, and competitive advantage. The dashboards show impressive metrics: PRs merged, designs shipped, reports generated.
But here's what the dashboards don't show:
The knowledge gap is widening. When a senior engineer reviews AI-generated code, they catch the subtle issues — the edge cases, the security implications, the architectural debt. But they built that intuition over years of writing code themselves. What happens when the next generation of seniors never had that foundation?
Debugging is becoming archaeology. Understanding code you didn't write is always harder than understanding code you did. When AI writes most of the code, and something breaks at 2 AM in production, how deep does your understanding go?
Design intuition is being outsourced. A designer who's spent years understanding typography, colour theory, and user psychology can guide AI tools effectively. But if you learn design through AI, do you develop that same intuition? Or do you become skilled at prompting without understanding why certain designs work?
Critical thinking is atrophying. When AI drafts your analysis, suggests your conclusions, and even anticipates your objections — how much are you actually thinking? The effort of wrestling with a problem is often where real understanding emerges.
The Uncomfortable Enterprise Dynamic
Here's what I see in organisations pushing hard on AI adoption:
The pressure to adopt is immense. If your competitor ships features twice as fast, you can't afford philosophical debates about skill development. The short-term incentives all point toward maximum AI leverage.
But there's a growing tension between throughput and understanding. Teams are shipping faster while comprehending less. The codebase grows, but institutional knowledge shrinks. The designs look polished, but fewer people can explain the principles behind them.
Middle management is caught in an impossible position. They're measured on delivery speed, but they're also responsible for team development. How do you justify spending time on fundamentals when AI can skip straight to the answer?
And here's the uncomfortable truth: the employees who resist AI adoption are often labelled as dinosaurs, while those who embrace it fully might be hollowing out their own expertise without realising it.
Learning and Unlearning
So what do we actually do about this?
Unlearn the expectation of complete solutions. AI is remarkably good at generating plausible outputs. It's less good at generating correct outputs for your specific context. The skill isn't in accepting what AI produces — it's in knowing what to question.
Relearn the fundamentals, deliberately. This feels counterintuitive when AI can handle the basics. But understanding fundamentals is what allows you to evaluate AI output, catch errors, and know when the AI is confidently wrong. Schedule time for it. Protect it.
Learn to be a skilled collaborator, not just a prompter. The best results come from iterative dialogue with AI — pushing back, asking for alternatives, understanding trade-offs. This requires domain knowledge. You can't effectively challenge what you don't understand.
Accept that some skills will atrophy — and choose which ones. We don't do mental arithmetic like previous generations. That's probably fine. But we should be intentional about which skills we let go and which ones we protect.
The Path Forward
I don't think we're doomed to become execution engines. But I also don't think the current trajectory is sustainable.
The developers, designers, and analysts who thrive won't be the ones who use AI most aggressively or the ones who resist it most stubbornly. They'll be the ones who maintain enough depth to know when AI is helping and when it's leading them astray.
For enterprises, this means rethinking metrics. Shipping speed matters, but so does the team's ability to debug, maintain, and evolve what they've shipped. These are harder to measure, but they're not less important.
For individuals, it means being honest about your own understanding. When you ship something, could you explain it without referring to the AI conversation? Could you build it again from scratch? If not, you might be accumulating output without accumulating knowledge.
The irony isn't lost on me that I'm writing this with AI assistance. The difference — I hope — is that I'm wrestling with these ideas, pushing back on suggestions, and maintaining ownership of the thinking. The AI is a tool in this conversation, not a replacement for it.
But I'll admit: some days, the line feels blurrier than I'd like.