The Real Interests of Each Stakeholder in Enterprise AI Adoption
CEO, CTO, Developer, Manager, and Business User: What Each One Wants, Gains, and Stands to Lose
A standalone article from the series “AI in Business: Expectations vs. Reality”
When a company decides to adopt artificial intelligence, there’s a natural tendency to frame it as a rational, technical decision. People talk about efficiency, automation, cost reduction. Dashboards appear with ROI projections, and comparisons are drawn to what competitors are doing.
But behind that tidy narrative lies something far more complicated: a conflict of interests between people with different objectives, different pressures, and different definitions of success.
A CEO and a senior developer can be in the same meeting discussing “using AI in the project” and be understanding entirely different things — not because one is smarter or better informed, but because it affects them differently and their incentives aren’t aligned.
This article draws that map. Not to assign blame, but so each reader can identify the position they’re viewing the problem from — and understand the positions everyone else is viewing it from.
Note: this is an informed opinion piece. The values assigned here reflect my personal perspective, with my reasoning laid out so you have a starting point. Feel free to adjust them based on where your own view differs or where you’d add something.
The Five Key Stakeholders
In most technology companies, AI adoption involves five profiles with varying levels of power and influence:
Let’s look at each one.
1. The CEO / Executive: Between Competitive Pressure and Elusive ROI
What they say publicly: “We need to be a data-driven company. AI is critical to our competitiveness.”
What they’re actually worried about:
- Being left behind by the competition. Fear of obsolescence is, in many cases, the primary driver of adoption.
- Investments not translating into results. The gap between AI vendor promises and actual value delivered is a constant source of frustration.
- The board or investors asking “And what are you doing with AI?”
What they gain from a well-executed adoption:
- Real cost reduction in repetitive, low-value tasks.
- Competitive advantage in time-to-market.
- The ability to scale operations without scaling headcount proportionally.
What they lose or risk:
- Heavy investment with uncertain short-term ROI (more on this in the cost article).
- Reputational risk if AI produces visible errors or privacy incidents.
- Vendor dependency, where terms and pricing can change at any time.
- Internal resistance if adoption is perceived as a threat to jobs.
The most dangerous CEO isn’t the one who ignores AI, but the one who demands it at any cost without understanding its limits. The pressure to “use more AI” without a clear strategy produces exactly the opposite of what’s intended: cost without value.
2. The CTO / Architect: Between Technical Control and Cognitive Debt
What they say publicly: “We need to adopt AI responsibly and progressively.”
What they’re actually worried about:
- Cognitive debt: if the team stops understanding the code because AI generates it, the company becomes fragile. A production incident at 3 a.m. isn’t resolved by an AI — it’s resolved by someone who knows what they’re doing and why.
- Vendor lock-in: if the entire architecture is built assuming a specific AI provider will always exist on the same terms, any change in pricing or API can be catastrophic.
- Security: an AI that generates code at scale also generates security vulnerabilities at scale — with the added problem that they’re less visible, because nobody wrote them intentionally.
What they gain from a well-executed adoption:
- Less time on mechanical tasks (boilerplate generation, scripts, basic tests).
- The ability to do more with the same human resources.
- Rapid prototyping to validate ideas before committing development time.
What they lose or risk:
- The team’s critical knowledge. If architects stop practicing difficult technical decision-making, they lose precisely what makes them valuable.
- Control over the quality of code entering the repository.
- The ability to explain the system when something fails.
AI is “a gifted intern, but a terrible architect” AI today excels at executing specific, bounded technical tasks. But when asked to design complete systems or make strategic decisions, it produces “internet average” solutions: technically valid, but unaware of your company’s inherited technical debt, your budget constraints, your team culture, or the legal context of your industry.
3. The Developer: Between Productivity and the Fear of Atrophy
What they say publicly: “AI helps me be more productive. It’s just another tool.”
What they’re actually worried about:
- Employability. Will someone like me still be needed in three years? This question, though rarely voiced out loud, is on many people’s minds.
- Technical atrophy. If I delegate more and more to AI, will I still be capable of solving hard problems? A musician who doesn’t practice loses technique; a developer who only accepts suggestions without understanding them loses judgment.
- Meaningful work. The best developers don’t just want to close tickets — they want to understand systems, solve interesting problems, and grow. An environment where “AI does everything” can turn into a routine review job with little to offer intellectually.
What they gain from a well-executed adoption:
- Less time on mechanical and repetitive tasks (boilerplate, coverage tests, documentation).
- The ability to explore prototypes in hours instead of days.
- Immediate help with unfamiliar code or languages they’re not fluent in.
What they lose or risk:
- The junior-to-senior learning curve. If AI handles the basic tasks, where do you learn the fundamentals? (We’ll explore this further in the technical article.)
- Authorship and understanding of the code they maintain. “AI generated it” is not a valid answer when a production system is on fire.
- The appeal of the job, if the company turns the developer into a mechanical accept/reject button for AI suggestions.
4. The Manager / PM: Between Control and New Metrics
What they say publicly: “With AI, the team will be more agile and deliver faster.”
What they’re actually worried about:
- Visibility. If AI automatically generates code, how does the manager know what the team is doing and how much it’s worth? Traditional metrics (hours worked, tickets closed) become less reliable.
- Quality control. A team that delivers faster with AI may be accumulating invisible technical debt that explodes down the road.
- Their own role. If project management can be partially automated, what does a PM actually contribute in that context?
What they gain from a well-executed adoption:
- Teams with greater delivery capacity within the same timelines.
- Less team time spent on low-value tasks, more on design and decision-making.
- Tools to generate reports, summaries, and estimates faster.
What they lose or risk:
- The illusion of control. Delivery speed goes up, but so does the complexity of what’s delivered, making it harder to supervise real quality.
- Metrics that no longer function as reliable indicators of team performance.
5. The Business User: The Most Overlooked and the Most Decisive
What they say publicly: “If it saves me time, bring it on.”
What they’re actually worried about:
- Role change. If AI automates parts of their work, what do they do instead? The answer isn’t always “something more interesting.”
- Trust in the output. Can I rely on what the AI produces? Who’s responsible if it makes an error that affects a customer?
- The learning curve. Learning a new tool is not free — it costs time and energy.
What they gain:
- Less time on repetitive tasks (report generation, data classification, summarization).
- Fast access to structured information.
What they lose or risk:
- Visibility and understanding of their own work if they delegate too much to AI.
- Responsibility without control: if they sign off on an AI-generated report without reviewing it carefully, any errors are theirs.
The Conflict Map
Not all of these stakeholders share the same interests. The following diagram shows the main friction zones:
These tensions aren’t theoretical. They’re conversations that happen in meeting rooms every week. And what’s interesting is that nobody is wrong: each person is seeing the problem from their own legitimate point of view.
When Conflicts Materialize: The Tokenmaxxing Case
The conflicts in the diagram above are anything but theoretical. In May 2026, several specialist outlets documented what has been happening at Amazon — a phenomenon that’s been named tokenmaxxing.
Amazon set a target of having more than 80% of its developers use AI tools weekly, and began tracking token consumption through internal leaderboards. Although the company officially stated that the metrics would not influence performance reviews, employees reported that managers were monitoring them, creating real pressure.
Part of the team responded rationally given the incentive system: they used MeshClaw (an internal AI agent tool) to automate unnecessary tasks and inflate token consumption, without that representing any real productivity gain. More tokens consumed = better leaderboard position = less pressure from the manager.
“There’s a lot of pressure to use these tools. Some people are just maximizing their token usage.” — Amazon employee, quoted in The Decoder and TechSpot
The phenomenon isn’t unique to Amazon: similar behavior has been documented at Meta.
What this case illustrates in the context of the stakeholder map:
- The CEO wants high AI adoption metrics.
- The manager monitors them because they’re receiving pressure from above.
- The developer optimizes for the metrics being measured, not for the real value they deliver.
- The result: the company has excellent adoption statistics and unchanged — or worse — actual productivity.
It’s the clearest possible example of what happens when you set an AI usage target without first defining what problem you’re solving and how you’ll measure real impact.
The Trade-offs Table by Stakeholder
| Stakeholder | Primary gain from well-executed AI adoption | Primary risk from poorly executed AI adoption |
|---|---|---|
| CEO | Competitiveness, scale, efficiency | Investment without ROI, vendor dependency, privacy scandals |
| CTO / Architect | Team productivity, rapid prototyping | Cognitive debt, incomprehensible code, vendor lock-in |
| Developer | Automation of repetitive work, fast exploration | Technical atrophy, loss of meaningful work, obsolescence of the junior role |
| Manager / PM | Faster teams, quicker reports | Loss of visibility, broken metrics, hidden technical debt |
| Business user | Less time on mechanical tasks | Unmanaged role change, responsibility without control, loss of understanding of their own work |
The Radar: Comparing the Two Extremes
To visualize the real consequences of two extreme positions, we compare:
- 🔴 Ultra-AI Company: intensive, non-strategic adoption. AI throughout the entire cycle, top-down pressure to increase usage, no solid governance.
- 🔵 No-AI Company: complete resistance to adoption. Everything manual, no assistants, no automation.
The dimensions and their definitions:
The 8 Dimensions
1. Delivery speed (time-to-market): How quickly features or products reach the end user.
2. Output quality: Bugs, errors, consistency, and comprehensibility of the work produced.
3. Cost efficiency (medium term, 1–3 years): How much it costs to produce the same output. Includes salaries, tools, infrastructure, and the hidden cost of errors.
4. Resilience: Capacity to recover when something fails or when a key system, tool, or person becomes unavailable.
5. Internal know-how: How much of the critical knowledge about the company’s systems lives in people inside the company versus in external tools.
6. Capacity for disruptive innovation: Ability to generate paradigm shifts, not just optimize what already exists.
7. Talent attraction: How attractive the company is to the best professionals in the sector.
8. Legal and regulatory risk: Exposure to fines, privacy issues, non-compliance with the EU AI Act, or similar.
Note on the scale: for the “Cost efficiency” and “Legal risk” dimensions, a higher score is better (greater efficiency, lower risk). The scores are qualitative assessments of tendencies (estimated based on my judgment), not precise measurements.
Radar Data
Why Each Score
Delivery speed: Ultra-AI 9 / No-AI 3 The most obvious gap. With AI, supporting code (boilerplate), tests, documentation, and automation scripts are generated in minutes. Without AI, everything runs at human pace. The gap widens as competitors who do use AI keep building larger time advantages.
Output quality: Ultra-AI 4 / No-AI 7 Here’s the paradox. More speed does not equal more quality. AI generates code that looks correct but can contain subtle logic errors, weak security configurations, or solutions that don’t scale. Without rigorous human review — which speed pressure often eliminates — quality suffers. The no-AI company is slower, but the code it produces is more comprehensible to the people maintaining it.
Cost efficiency: Ultra-AI 5 / No-AI 7 Counterintuitive but real: in the short to medium term, intensive AI adoption can be more expensive than maintaining an equivalent human team. Licenses, API tokens, additional infrastructure, training time, and the cost of fixing AI-introduced errors add up to more than many executives initially estimate. The no-AI company has more predictable personnel costs. (This is developed in Article 3.)
Resilience: Ultra-AI 3 / No-AI 8 What happens when an AI provider changes its pricing, modifies its API, or simply goes down? A company that has built its development cycle around a specific external tool is fragile against those changes. And if nobody understands the code the AI generated, any production incident becomes a crisis with no clear solution.
Internal know-how: Ultra-AI 2 / No-AI 9 The most critical dimension and the most ignored. A company that delegates technical design and execution to AI accumulates what we might call “cognitive debt”: the code exists, it works (until it doesn’t), but nobody in the company truly understands why it does what it does. When something explodes, there’s nobody with the knowledge to fix it. Know-how is the company’s life insurance.
Disruptive innovation: Ultra-AI 6 / No-AI 3 AI is extraordinary at optimizing what already exists and exploring variations of the known. But disruptive innovation — changing the business model, inventing a new category, pivoting radically in response to a market shift — requires human judgment, intuition, and the ability to break patterns. The Ultra-AI company can launch faster, but not necessarily in the right direction. The No-AI company has more judgment but less execution capacity at speed.
Talent attraction: Ultra-AI 6 / No-AI 4 The best developers want to work with modern tools — the no-AI company is seen as outdated. But we don’t score Ultra-AI high either, because senior professionals flee environments with no real learning, where “AI does everything” and they’re mere mechanical validators. Quality talent seeks a balance: good tools, but meaningful work.
Legal and regulatory risk: Ultra-AI 4 / No-AI 9 The EU AI Act is now in force. GDPR applies to data sent to external models. The use of AI in decisions affecting people (hiring, credit, public services) has specific restrictions. A company using AI intensively without a governance policy is exposed. The no-AI company simply doesn’t have these risks. (Note: 9/10 for No-AI doesn’t mean there are no legal risks in general — only that those specifically associated with AI are practically zero.)
Two Readings the Extremes Don’t Show
The ideal Ultra-AI company doesn’t exist in pure form. Most companies that adopt AI aggressively have control elements that moderate the downsides. We’ve shown the worst-case extreme, not the average of enthusiastic adopters.
The No-AI company is losing ground every month. Although its profile above doesn’t look too bad, there’s a dimension that doesn’t appear: the rate of competitive degradation. A company that has adopted zero AI tools in 2026 is not in the same position as a company that hadn’t done so in 2022. The gap with competitors who do use it keeps growing.
The ideal point is in the middle, but not the average. This isn’t about using “some AI” to land in the middle of the chart. It’s about being selective: maximizing the advantages where AI genuinely contributes (speed on mechanical tasks, exploration, automation) while actively protecting the critical dimensions that mass usage erodes (know-how, quality, resilience).
The Competitive Gap Compounds Over Time
The radar chart above doesn’t show that the No-AI company isn’t standing still — it’s losing ground on a compounding basis every year that passes.
Top line: company with strategic AI adoption. Bottom line: company with no AI adoption. The growth of the first and the decline of the second are not linear — they accelerate, because AI enables building advantages that generate further advantages (better tools → more speed → more capacity to invest in better tools).
The Goal Isn’t the Middle: It’s Selective Adoption
A misreading of the radar chart would be to conclude that “the ideal position is the midpoint between the two extremes.” It isn’t. The average of Ultra-AI and No-AI produces a company that’s mediocre at everything.
The following chart compares the three profiles across four key dimensions.
What the chart shows: Ultra-AI 🔴 has the highest bar in speed but the lowest in know-how and resilience. No-AI 🔵 has the inverse pattern: strong in know-how and resilience, weak in speed. Selective adoption 🟢 achieves high scores across all four dimensions because it uses AI where it delivers speed (mechanical tasks) and maintains human oversight where know-how and quality are critical. It’s not a middle-ground position — it’s a different position altogether.
Conclusion: The Map Exists So Everyone Knows Where They Stand
The conversation about AI in business typically fails because each participant speaks from their own position without acknowledging that everyone else is in a different position with legitimately different interests.
The CEO demanding more AI isn’t wrong to want competitiveness. The developer warning about cognitive debt isn’t wrong to defend quality. The architect asking for governance isn’t being an obstacle — they’re protecting the resilience of the system. And the business user who distrusts AI outputs isn’t being obtuse — they’re exercising exactly the kind of human oversight that must exist.
The goal of this article isn’t to tell you who’s right. It’s to help you understand the perspective you’re looking from, and the perspective everyone else is looking from. With that on the table, the conversation can become far more productive.
The next articles in the series explore the technical reality behind all of this, the real cost figures, and a practical framework for making decisions.
Sources cited in this article:
- Tokenmaxxing at Amazon: The Decoder · TechSpot · Tom’s Hardware
- Tokenmaxxing at Amazon and Salesforce: PYMNTS
- Tokenmaxxing at Meta and Nvidia: The Conversation
- Goodhart’s Law applied to AI metrics: PYMNTS — Enterprises Look Beyond Token Counts
- EU AI Act (regulatory reference): EUR-Lex — Regulation (EU) 2024/1689
Next article: What AI Can and Cannot Do Today in Software Development
Previous article: Series Introduction
