Why this layer is short
Most AI transformations start here. “We rolled out Copilot.” “We have Cursor licenses for everyone.” “We use ChatGPT Enterprise.”
That’s the fastest route to a failed transformation.
Tools are the easiest thing to talk about, the easiest to procure, and the easiest to justify on a budget. And they’re the least significant of the five layers. If the four above, culture, organization, skills, processes, haven’t moved, tools are irrelevant. You just get bad outputs faster.
That’s why this layer comes last. And that’s why this section is deliberately shorter than the others.
Tools are commoditized
It’s worth saying out loud: the differences between the big AI models are marginal in a product context. Claude, GPT, Gemini: they all deliver 90% of what most teams need. The differences matter most when you’re solving the last 10%.
The same goes for coding tools. Claude Code, Cursor, Copilot, Windsurf: they fundamentally do the same thing. They differ on UX, integration and price. Not on whether they work.
Which means choosing a tool is easy. That’s not where the differentiation lies.
Where the differentiation does lie:
- How well the team has learned to use the tool
- How well it’s integrated with the team’s data and context
- How disciplined the team is about evaluating the output
Those are the three things that separate an organization that gets a lot out of AI from one that gets little. Not whether they picked Cursor or Claude Code.
What a minimum stack looks like
For a product organization that wants to work AI-first, a working base setup looks roughly like this:
- A coding assistant with an agentic approach. Claude Code, Cursor, Windsurf or similar. Pick one, learn it deeply.
- A context layer. MCP is becoming the standard. It’s how AI gets access to your team’s data, documents, systems. Without a context layer, AI works on generic knowledge, and generic knowledge is rarely what differentiates.
- An eval tool. How do you know your AI features work? How do you test them? The field hasn’t consolidated yet, but it becomes critical within a short time.
- An observability layer. What is the AI actually doing in production? Where does it fail? Where is it slow? New territory for most teams.
- A governance layer. Who may use what, for what, with which data? Compliance and security can’t be afterthoughts.
Not an exhaustive list. But it’s the minimum that has to be in place before you can talk about being AI-first.
The classic enterprise mistake
The mistake repeated in every enterprise AI transformation I’ve seen is this: picking a tool and calling it transformation.
“We’ve rolled out Copilot to 500 developers” is not a transformation. It’s a licensing deal. What are those 500 developers doing differently now? Which decisions are made differently? Which processes have changed? Which skills have been strengthened?
If the answer is we measure velocity and it’s up a bit, that’s not transformation. That’s a productivity boost on an existing model.
Real transformation requires the four layers above to be in motion. The tool is just the instrument that makes the other layers possible. Not what drives them.
Choose tools you can replace
Because the field moves so fast, the most important principle in tool selection is not which tool is best right now, but how easy is it to switch.
That means:
- Avoid deep lock-in. Tools that bind you to one vendor’s format, prompts or integrations are dangerous. The models change, the vendors change.
- Build on open standards. MCP is the first real attempt at an open context layer. Use it. API-based integrations beat proprietary plugins.
- Keep the context on your side. Your data, your prompts, your evals should exist independently of the tool that executes them. If you switch from Claude to GPT tomorrow, you should be able to take the context with you.
They’re the same principles software architecture has used for 30 years: avoid tight coupling, build on interfaces, keep your data free. AI doesn’t change that. It amplifies the need.
What I use myself
To make it concrete: my own setup as of today is Claude Code as primary coding assistant, Cursor as backup, MCP for context integration with Notion and other data sources, Loops for email automation, and Cowork as a browser agent for the tasks that require clicking around websites.
It’s not a recommendation. It’s a snapshot. In six months, half of it has probably been swapped out. The point is precisely that this should be able to happen without the whole setup collapsing.
The principle for this layer
The principle is short:
Choose principles. Swap tools.
The principles, what you decide to automate, which context you share with AI, how you evaluate outputs, how you handle compliance, are what lasts. The tools are what gets swapped out every six months.
If you have the right principle, you can use any tool. If you don’t, it makes no difference which tool you picked.
If some of the terms in this layer are new to you, I’ve put together a short glossary here: /en/playbook/ordbog.