Coming at this from a design perspective, but wow—this entire thread is giving me chills because we’re seeing the exact same patterns with AI design tools. And it’s making me rethink everything about craft, learning, and what it means to actually understand your work.
The design parallel
I lead design systems, and about 8 months ago our team started using AI tools heavily—Figma AI, Midjourney for explorations, ChatGPT for component documentation, AI-assisted accessibility checks. Productivity went through the roof. Leadership was thrilled.
Then I asked a junior designer to explain why they chose a specific accessibility pattern for a form component. They couldn’t. The AI had suggested it, they’d implemented it, it passed automated checks, so they shipped it.
Turns out the pattern worked for screen readers but created a nightmare for keyboard navigation—something the AI didn’t catch and the designer didn’t understand deeply enough to spot.
Sound familiar? It’s Luis’s “Alex freezing during the production incident” but for design.
Speed without understanding is dangerous
That 23.7% increase in security vulnerabilities Michelle mentioned? In design, we’re seeing similar issues with accessibility, information architecture, and user experience patterns.
What I’m seeing:
- Designers who can generate beautiful components quickly but can’t explain the design decisions
- Perfect visual execution with no understanding of the underlying UX principles
- AI-generated solutions that work in common cases but break in edge cases
- Massive productivity on familiar design patterns, paralysis on novel UX challenges
The research about AI coding tools is basically describing what’s happening in design too: fast output, shallow thinking, skill erosion.
The craft vs speed trade-off
Here’s what really scares me: I founded a startup that failed. The hardest lesson I learned was that understanding why things work matters more than making things that work.
AI tools let you skip the “why” and jump straight to “what.” And when you do that consistently, you never build the judgment needed for complex decisions.
My startup failed because:
- We shipped features users asked for without understanding the underlying problems
- We optimized for velocity without understanding product-market fit
- We looked productive based on output metrics while missing fundamental strategic issues
Sound familiar? It’s exactly what David is describing with roadmap planning based on AI-augmented velocity that doesn’t reflect true capability.
The learning gap
When I learned design, I spent hours studying why certain patterns work, analyzing competitors, understanding cognitive load and visual hierarchy. It was slow, sometimes frustrating, but it built deep understanding.
Today’s junior designers can prompt an AI and get a component in minutes. They skip the learning process entirely. And when they face a novel UX challenge—something AI hasn’t been trained on—they’re lost.
Luis’s point about mentorship breakdown hits hard. I can’t mentor effectively when I don’t see the thought process. Code reviews become “does this look right?” instead of “do you understand the principles?”
Our “manual design hours” experiment
Similar to Luis’s “AI-Free Fridays,” we implemented “manual design hours”:
Requirements:
- 4 hours per week, junior designers work without AI assistance
- Focus on fundamentals: typography, layout, accessibility principles, user research
- Senior designers available for mentoring and critiques
- They must explain their design decisions, not just produce artifacts
Results (painfully honest):
- About 40% of our “high performers” struggle with basic design principles
- Many can’t articulate why a design works beyond “the AI suggested it”
- Some have never done proper user research—they just iterate on AI suggestions
- Gap between AI-assisted output quality and fundamental understanding is shocking
Management pushback was intense: “Why slow them down?” But after one major redesign failed user testing because nobody understood the actual user needs, they got it.
Questions for the engineers
Reading this thread, I have questions for the engineering side:
1. How do you maintain code craftsmanship when AI makes it easy to skip steps?
In design, we talk a lot about “craft”—the care and understanding that goes into good work. How do you preserve that when AI tools optimize for speed over understanding?
2. Is there an engineering equivalent of “manual design hours”?
Would something like dedicated time for fundamentals work in engineering, or does the business pressure make it impossible?
3. How do you balance tool adoption with skill development?
We want juniors to learn modern tools (including AI), but not at the expense of fundamentals. How do you navigate this?
The uncomfortable truth about productivity
David’s ROI question is the right one: if AI gives 30% faster coding but only 8% faster delivery, and creates planning uncertainty and skill gaps—what’s the real value?
I’d add: if AI creates a generation of practitioners who are incredibly productive within the AI’s comfort zone but fragile outside it, are we actually building valuable teams or creating systemic risk?
From my failed startup experience: short-term productivity gains that sacrifice long-term capability are a trap. We scaled fast, shipped features quickly, and went out of business because we didn’t understand our market deeply enough.
The craft perspective
Here’s my maybe-controversial take: real craft is understanding the principles so deeply that you know when to break the rules.
AI tools are amazing at following rules. They’re terrible at knowing when to break them. If we train a generation of designers and engineers who can follow AI suggestions but can’t think independently, we’re creating teams that can execute the predictable but fail at innovation.
Michelle mentioned engineers who “can ship features fast but crumble under pressure when the AI can’t help.” In design, I’d describe it as: designers who can make things look good but can’t solve hard UX problems.
What I’m trying to preserve
I require every designer on my team to be able to:
- Explain their decisions - if you can’t articulate why, you don’t merge/ship it
- Work without AI periodically - maintain baseline capability
- Handle novel challenges - prove you can think independently when patterns don’t exist
- Understand accessibility deeply - not just “it passes automated checks”
- Do actual user research - AI can’t tell you what your specific users need
It’s slower. It’s harder to defend to leadership. But Keisha’s question about capacity planning resonates: I need to know my team’s actual capabilities, not their AI-augmented performance.
My questions for this community
For anyone managing creative/technical teams:
-
How do you preserve craft and deep understanding in an AI-augmented workflow?
-
What does “AI literacy” actually mean - is it prompting skills or knowing when NOT to use AI?
-
How do you assess growth potential when current output is AI-augmented?
For Luis specifically, since you mentioned diversity and inclusion: I’m worried AI tools are creating a false sense of capability for early-career folks from non-traditional backgrounds. They look productive initially, but hit a ceiling when fundamentals matter. How do we support them without setting them up for future failure?
The long game (from someone who learned the hard way)
My startup failed because we optimized for speed over understanding. We shipped fast, looked productive, and missed the fundamental strategic insights that would have saved us.
This AI capability gap discussion feels eerily similar. We’re optimizing for velocity metrics while potentially missing fundamental capability building that matters for long-term success.
I’d rather have a designer (or engineer) who understands principles deeply and uses AI to accelerate than one who relies on AI to compensate for missing fundamentals. The former can handle anything. The latter is fragile.
Luis is right: we’re choosing between long-term capability and short-term velocity. And from painful experience, I know which one actually matters when things get hard.