I’ve been analyzing AI productivity impact across our engineering team for the past 6 months, categorizing tasks by complexity. The pattern is stark and troubling: we’re automating what’s already easy, not solving what’s hard.\n\n## The Data from Our Teams\n\nI broke down our work into categories and tracked AI assist impact:\n\nHigh AI Speedup (70-90% faster):\n- Boilerplate code generation\n- Unit test creation\n- API endpoint scaffolding\n- Documentation\n- Code formatting and style fixes\n\nModerate AI Speedup (20-40% faster):\n- Feature implementation with clear requirements\n- Refactoring well-understood code\n- Bug fixes with clear reproduction steps\n\nMinimal AI Speedup (0-10% faster):\n- Distributed systems debugging\n- Architecture design decisions\n- Performance optimization\n- Complex business logic implementation\n- Cross-system integration problems\n\nNotice the pattern? AI excels at tasks junior engineers traditionally handle. It struggles with senior-level work.\n\n## The Wrong Problem Optimization\n\nHere’s what bothers me: the tasks where AI provides 90% speedup are tasks that:\n1. Were already relatively fast\n2. Were already well-understood\n3. Weren’t the bottleneck in our delivery\n\nMeanwhile, the tasks where we desperately need help—debugging a race condition, designing a scalable architecture, optimizing a complex query—AI barely moves the needle.\n\n## A Real Example\n\nLast month, we had two parallel efforts:\n\nTask A: Build a CRUD API for a new data model\n- Estimated: 2 days\n- With AI: Completed in 4 hours\n- 90% speedup\n\nTask B: Debug why our distributed cache was causing intermittent timeouts\n- Estimated: 3-5 days\n- With AI: Took 6 days\n- Actually slower because AI suggestions were red herrings\n\nGuess which task was more valuable to the business? Guess which one AI helped with?\n\n## The Fundamental Limitation\n\nI think the issue is fundamental to current AI capabilities:\n\nCurrent AI = Pattern Matching + Statistical Prediction\n\nIt’s phenomenal at recognizing patterns it’s seen before and generating similar output. But complex engineering work requires:\n- Deep contextual understanding\n- Multi-system reasoning\n- Architectural tradeoff analysis\n- Novel problem-solving\n\nThose aren’t pattern matching problems.\n\n## The Strategic Implications\n\nIf AI primarily helps with simple tasks, the ROI question becomes very different.\n\nSimple tasks might represent:\n- 60% of development time\n- But only 20% of business value\n\nComplex tasks might represent:\n- 40% of development time\n- But 80% of business value\n\nIf AI speeds up the low-value work but not the high-value work… what’s the actual business impact?\n\n## The Question I’m Wrestling With\n\nIs this a current limitation of AI that will improve, or a fundamental limitation of the approach?\n\nWill the next generation of AI (reasoning models, better context, etc.) actually help with complex work? Or is AI fundamentally suited to be a "junior engineer assistant" rather than a "senior engineer collaborator"?\n\nI genuinely don’t know. But it matters enormously for how we should be thinking about AI investment and team composition going forward.
This resonates so much with the design side. Same exact pattern.
AI as “Junior Designer”
AI is amazing at:
- Generating icon variations
- Creating color palettes
- Producing layout options
- Writing copy variations
AI is terrible at:
- Understanding user needs
- Making strategic UX decisions
- Designing information architecture
- Solving novel interaction problems
Just like you said—it’''s great at what juniors do, useless for what seniors do.
The Startup Lesson
At my failed startup, we leaned hard into AI for design work. We churned out so many assets, so many variations, so many options.
But we still couldn’‘‘t figure out what users actually needed. We still couldn’’'t design a coherent product experience. We still made terrible strategic decisions about what to build.
The AI helped us fail faster, I guess?
Maybe That’''s Okay?
Here’‘‘s a contrarian thought: maybe it’’'s fine that AI is good at junior-level work.
If AI can handle the boilerplate, the repetitive stuff, the grunt work—that frees up senior people to focus on the complex problems. In theory.
The problem is what you identified: if senior people are buried in reviewing AI output, they’''re not actually freed up.
The Learning Curve Question
But here’''s what worries me: how do junior designers/engineers develop into senior ones if AI is doing all the junior work?
I learned design by doing all that “simple” stuff. Making icons taught me about visual hierarchy. Creating layouts taught me about composition. Writing copy taught me about user communication.
If AI does all that… what foundation are you building on?
Luis, this framework is super helpful for thinking about AI ROI.
The 80/20 Rule, Inverted
Your observation about value distribution is crucial:
- Simple tasks = 60% of time, 20% of value
- Complex tasks = 40% of time, 80% of value
If AI only accelerates simple tasks, it’''s optimizing the wrong 60%.
From a product strategy perspective, this changes the conversation entirely.
Where AI Actually Helps Product
Interestingly, I’‘‘ve found AI extremely valuable for product work—but not where you’’'d expect.
Huge AI value:
- Rapid prototyping and exploration
- Generating test variations for experiments
- Creating demo/proof-of-concept quickly
- Market research synthesis
Minimal AI value:
- Understanding customer needs
- Making strategic roadmap decisions
- Defining what to build
- Prioritizing features
Notice the pattern? AI helps with exploration and discovery, not decision-making and strategy.
A Different Framework
Maybe we should think about AI differently:
Time-to-Learning vs. Time-to-Shipping
AI dramatically improves time-to-learning. Want to explore 10 different approaches? AI makes that feasible.
But it doesn’‘‘t necessarily improve time-to-shipping, because shipping requires all the complex work (integration, testing, review, deployment) that AI doesn’’'t accelerate.
The Role Question
You asked if AI is fundamentally a “junior engineer assistant” vs “senior engineer collaborator.”
Based on how I’‘‘m using AI in product work, I’’'d frame it as: AI is best suited for divergent exploration, not convergent decision-making.
It helps you generate options, explore possibilities, prototype ideas. It doesn’''t help you decide which option is right for your specific context, users, and constraints.
Maybe that’''s actually the right role for AI?
This discussion is hitting on something critical: we need to match AI capabilities to the right use cases rather than expecting AI to solve all problems.
Current AI = Pattern Matching
Luis, your characterization is exactly right. Current AI systems are fundamentally pattern matching engines. They’''re trained on vast amounts of existing code and can generate similar patterns.
That’''s why they excel at:
- Code that follows common patterns
- Problems that have been solved many times before
- Tasks with clear, well-defined structure
And struggle with:
- Novel problems
- Complex system interactions
- Architectural decisions with subtle tradeoffs
The Next Generation Question
You asked if this is a current limitation or fundamental limitation. I think it’''s both.
Current models are limited by:
- Context window constraints
- Training data biases
- Inability to truly “understand” vs pattern match
But emerging capabilities are interesting:
- Reasoning models (like o1) showing improvement on complex problems
- Better context handling
- Multi-step problem decomposition
I’‘‘m cautiously optimistic that we’’‘ll see improvement on complex tasks. But I don’''t expect AI to fully match senior engineer judgment on architectural decisions anytime soon.
Strategic Team Composition
This has huge implications for hiring and team structure.
If AI handles junior-level work well:
- Do we need fewer junior engineers?
- Do we need more senior engineers to review and architect?
- How do we develop the next generation of senior engineers if juniors aren’''t doing junior work?
These aren’‘‘t hypothetical questions. I’’'m actively rethinking our hiring strategy based on this reality.
Build for Current Capabilities, Design for Future
My approach:
- Today: Use AI for what it’''s good at now (boilerplate, tests, documentation)
- Process: Design workflows that can absorb better AI as it improves
- Team: Maintain senior engineering capacity for complex work
- Investment: Watch reasoning models and be ready to adapt
We’‘‘re probably 12-18 months away from knowing if next-gen AI can truly help with complex engineering. Until then, I’’'m optimizing for current reality while building adaptable systems.
Maya’''s question about junior engineer development is keeping me up at night.
The Learning Paradox
Here’''s the problem: Junior engineers learn by doing the work that AI now does.
When I was coming up as an engineer:
- I learned architecture by writing boilerplate and seeing patterns
- I learned debugging by making mistakes and fixing them
- I learned good code by writing bad code and getting feedback
- I learned system design by implementing features end-to-end
If AI generates the boilerplate, writes the tests, scaffolds the features… what are junior engineers actually learning?
The Skill Development Gap
I’''m seeing this play out on my teams. Junior engineers using AI heavily:
Pros:
- Ship features faster initially
- Feel more productive and capable
- Contribute earlier in their career
Cons:
- Struggle to debug their own code
- Don’''t develop deep understanding of systems
- Have gaps in fundamental skills
- Can’''t function well without AI assistance
It’''s creating a dependency that worries me.
Mentoring in the AI Era
We’''re having to completely rethink our mentoring and onboarding approaches.
Old approach: Give junior engineer a starter task → let them struggle → provide feedback → they learn
New approach: ???
Do we:
- Encourage AI use and accept different learning paths?
- Restrict AI use for juniors until they have fundamentals?
- Create new types of learning experiences?
Honestly, we’''re still figuring it out.
The Workforce Development Concern
Here’‘‘s my bigger worry: if this generation of junior engineers doesn’’'t develop deep technical skills because AI is doing that work…
Who will be the senior engineers in 5-10 years?
You can’''t skip fundamentals and jump straight to architecture. The senior engineers of tomorrow need to build foundational skills today.
But if AI is doing that work, how do they build those skills?
What We’''re Trying
Some experiments we’''re running:
- AI-free zones: Certain projects require manual implementation for learning
- Explain-to-mentor sessions: Junior engineers must explain AI code to seniors
- Fundamentals curriculum: Required learning independent of AI tools
- Deliberate practice: Coding exercises without AI assistance
But I’‘‘ll be honest: I don’’'t know if this is enough. This is genuinely unprecedented territory.