AI adoption in companies: who's in charge, engineering or leadership?

A developer who uses Claude daily opened a thread on Hacker News this week with a question that has been circulating in many organizations: who is really in charge of AI adoption, engineering teams or executives reading headlines? The framing is direct and, perhaps because of that, resonant: imposing an AI tool from the top feels as absurd as having someone without technical knowledge dictate which compiler the team should use.

The thread is recent, posted on June 13, 2026, and still hasn't accumulated many responses, but the question itself deserves analysis. The tension it describes isn't new, though it has intensified over the last eighteen months as pressure to "do something with AI" has cascaded down from boardrooms.

Two speeds, two logics

What the author calls the pray and spray approach, deploying AI tools across the board and hoping something sticks, makes sense from an executive perspective: visibility to investors, a signal of modernization, fear of falling behind. The problem is that it directly conflicts with how tools actually get adopted in engineering.

When a technical team adopts Claude Code, an MCP server, or a set of custom skills, it's because it solves a concrete problem: automating code reviews, integrating internal data sources, delegating repetitive tasks to sub-agents. There's a chain of reasoning: problem → tool → metric. When adoption comes from above, that chain is usually inverted or missing entirely.

This isn't a principled criticism of leadership. There are organizations where executive push has worked: they establish a common platform, allocate resources, and then let teams build on top of it. The key is whether leadership understands that its role is to enable, not prescribe.

What typically fails with top-down approaches

Based on what we see in organizations that have gone through forced AI tool implementations in the past year, the most common friction points are:

• No clear use case: the tool is adopted before anyone identifies what problem it solves in that specific context.
• Shallow training: teams are given access to Claude or an equivalent platform without investing in teaching them to write useful prompts, configure MCP servers, or integrate hooks into their workflows.
• Vanity metrics: what gets measured is the number of activated licenses, not actual impact on productivity or quality.
• Passive resistance: engineers who don't see value keep using their old workflows in parallel, creating duplication and frustration.

The case for bottom-up adoption

Engineering-led adoption tends to produce sturdier integrations precisely because it starts with real problems. A team that has spent weeks using Claude with MCP servers connected to their internal database, or that has built sub-agents to automate part of their CI/CD pipeline, understands the tool's limits, its strengths, and what shouldn't be automated yet.

That practical knowledge is hard to transfer through an executive mandate. And it's the same knowledge that later enables sensible scaling: documenting what works, building reusable plugins, sharing skills across teams.

The problem with pure bottom-up is that it can fragment: multiple teams adopting different tools, no interoperability, no common standards. That's where leadership should step in, but to coordinate, not to impose.

A question that needs better data

The Hacker News thread is a good informal thermometer, but the debate needs more empirical rigor. What percentage of AI implementations in European companies in 2025-2026 have been top-down versus bottom-up? Which has higher real adoption rates at the six-month mark? These are measurable questions, but published studies so far mix sectors and company sizes in ways that make comparison difficult.

Meanwhile, the thread's question remains open. And any developer who uses Claude daily and also has to deal with a digital transformation PowerPoint at their company probably already knows their answer.

---

Editor's note: AI adoption has a better chance of creating value when technical teams have real agency over how and when they integrate tools. Leadership's role should be to remove obstacles, not choose the hammer.