Inside the same engineering team, sitting in the same office, two developers can have completely opposite experiences with AI coding tools. One is shipping features twice as fast. The other feels like their craft is being hollowed out.
Developer Jeremy Griffin calls this "K-shaped AI adoption" - borrowing the economic term for a recovery where some groups shoot upward while others decline. His observation: the divide isn't between companies that adopt AI and those that don't. It's happening within teams, across startups, large tech companies, and traditional enterprises alike.
Builders vs. Artisans
Griffin identifies two camps. Builders see code as a means to an end. They care about shipping outcomes, and AI agents that write boilerplate or scaffold entire features feel like a natural acceleration. For them, coding has always been about solving problems, not about the specific keystrokes used to get there.
Artisans have a fundamentally different relationship with code. Writing clean, elegant implementations is core to their professional identity. When an AI agent handles the detailed implementation work, it doesn't feel like help - it feels like the meaningful part of the job is being removed.
This isn't about skill level or seniority. Both camps include excellent engineers. The split is philosophical: do you view code as the product, or as the vehicle for the product?
The Uncomfortable Part
The practical result is increasing variance in productivity within teams. Two engineers with the same title and salary can have wildly different output, not because one is smarter, but because one has embraced AI-assisted workflows and the other hasn't.
Griffin acknowledges that artisan-camp concerns about code quality and environmental impact are legitimate. But he argues the core resistance is identity-based, not technical. And identity-based resistance is much harder to address with better tooling or training.
This maps to what I've seen across the AI tools space more broadly. The people getting the most value from tools like Cursor, Claude Code, or GitHub Copilot aren't necessarily the most technical users. They're the ones willing to change how they work, rather than trying to bolt AI onto their existing workflow.
The risk for teams and companies: if the productivity gap keeps widening, organizations will eventually have to decide whether AI fluency becomes an expectation rather than an option. That conversation is already happening at some companies, and it's not comfortable for anyone involved.