The haves and have-nots.

Organizations have run unacknowledged reindeer games around software access for as long as I can remember. Photoshop licenses were expensive, and if you weren’t a designer, you had to go to great lengths to make the case for why on earth you would need one.

This meant that any small copy update or jpeg export required tapping in someone within a specialized discipline not because of their unique abilities but because of their unique access.

I’m seeing the same situation unfold with AI. Engineers are leveraging advanced tools like Claude Code that gets immediate context to their work directly from the tools they use to complete it. While product managers are left with Co-Pilot or Rovo — two AI tools that do not even seem to know how to integrate with the applications they are nested within. Ask Rovo a question about your product documented within Jira across thousands of stories, let me know how that goes. Ask Co-Pilot about information readily available in sharepoint, ‘new Clippy, who dis?’.

Something as logical as requesting access to Github to leverage automatic product context living in code raises immediate flags. This is earmarked as technical team software, why would a product team member need access? What exactly are you trying to do? How do we make sure you don’t mess anything up?

Product managers locked out of the most reliable and recent "Source of Truth" (the code), are forced to rely on "Proxy Truths" (Jira stories that may be out of date). This quickly becomes a productivity tax and kneecaps any product manager trying to keep up.

Some organizations are nimble enough to allow exceptions, but that introduces a whole set of politics over who warrants one and who does not. And at a certain point, the exceptions you begin managing bring the need for a system access control reconsideration to light. Nobody wants that, especially when it means the 10x gains in engineering speed require a 10x expenditure in licensing across the org to enable that pace.

I was not surprised to hear that the more junior and lower-paid employees within organizations are using AI much less than the higher ups in a recent episode of Platformer. The exact data they quote from the Financial Times is that within the top 10% of income, 60% of people are using AI most days, while the bottom 10% only 14% of people are using AI most days.

From there they breeze through some theories on why this divide exists, including the idea that the higher earners are simply more technical. They then note that the same study shows that 71% of people in a leadership position said AI makes them more productive, while only 54% who identified as individual contributors found it helped productivity.

The one thing they never consider is what exact ‘AI’ each of these groups has access to. An executive might have a high-limit pro with Claude, while a more junior employee might just have Co-pilot, or a limited free tier that frequently hits limits and requires constantly rebuilding context.

Like the early days of graphic design software, having access to a tool like Photoshop is quite different than trying to use Microsoft Paint. And if we are going to analyze these discrepancies in usage, it feels important to include that information as well.

If your organization is currently creating this digital divide, I foresee two outcomes — a robust shadow IT where lower-level employees skirt organization protocols and use personal accounts to empower themselves, or a business that has an AI-empowered engineering team capable of producing much more than the business is capable of supporting.

We’re at a juncture where the proliferation of tools is at wet mogwai level. It’s important to step back and stop saying ‘AI’ and instead talk about specifically which tool, capable of doing and accessing what, and by whom, is at play.