Right now, it seems like almost every tech company is changing its developer tooling stack, which is a big shift from eighteen months ago (in 2025) when the answer to “what to use for AI-assisted coding ?” was simple : buy a GitHub Copilot license and boot up ChatGPT. In the Pragmatic Engineer newsletter AI tooling survey in 2024, those two tools racked up more mentions than all the others combined.

But no more. Today (2026), a plethora of tools outpace Copilot in various ways, like Cursor, Claude Code, Codex, and Gemini CLI, and there’s also AI code review tools like CodeRabbit, Graphite, and Greptile, not to mention all the MCP integrations which plug into agentic tools.

So, for this deepdive the Pragmatic Engineer newsletter ask some tech companies which tools their engineers use and, crucially, how they made their choices from among all the options. These businesses range from a 5-person seed-stage startup, to one that employs 1,500 people and is publicly listed. All are anonymous.

The goal of this article is to showcase what tech companies of different sizes are doing, and to offer a few pointers on measuring and comparing the AI tools.

Globally, here are some criateria which permit tech companies to select their AI tools :

1) How small teams select tools : At places with fewer than ~60 engineers, tooling decisions are fast and informal : developers try them for a couple of weeks and those which “stick” win.

2) How mid-to-large companies choose : bureaucracy, security, and vendor lock-ins. At companies with ~150 engineers, adoption is considerably slowed down by security reviews, compliance requirements, and executive-level budgetary considerations.

3) Measurement problem : metrics are needed but none work. Every workplace struggles to prove its AI tools work, and common metrics like lines-of-code-generated are distrusted by engineers.

For example, let us take a look to this job done by the Pragmatic Engineer newsletter :

A) Seed-stage logistics startup (20 people, 5 engineers)

The head of engineering at this startup describes their approach as high-trust and developer-led :

“We agreed to try new tools for 2 weeks and see how everyone felt. We didn’t use any hard-and-fast measurement. TLDR : I trust our devs and their opinion is a big part of this”.

Developers there suggest which tools to try and decide whether to keep using them or to seek alternatives. For AI code reviews, the team first tried Korbit for around a week but the tool felt “off”, so they roadtested CodeRabbit which “stuck” within a few days :

“Within a few days of using CodeRabbit I could tell the devs just liked it and were embracing the suggestions, unlike with Korbit which they ignored when they’d lost trust [in it].”

And that was that : decision made. As a small team, it’s easy to switch to something better and it only takes a single engineer to suggest it.

The broader tooling stack of this startup has evolved quickly over the last year :

Figma for designs, which works nicely with Linear. The company has 5 devs and one UX designer.

Linear for ticketing and collaborating across UX and development. The UX person creates Linear tickets alongside her Figma designs.

Claude Code and Cursor for development, connected to Linear via MCP.

Claude Code writes tickets : a recent change which is working nicely with CodeRabbit, as more context is passed downstream for AI code review.

“Show and tells” – where team members show colleagues their tooling setups during weekly team meetings and demos – are used by this startup to identify which tools do or don’t work :

“Our show-and-tell process greatly helps. There are so many new tools, skills, IDEs, etc, that it can be overwhelming. We all learn from seeing what others in our team are doing.”

The team makes a clear distinction between company-wide tools like Claude and CodeRabbit that everyone is expected to use, and devs’ personal environments (IDE choice, terminal setup), over which individuals have full autonomy.

By now, almost everyone has migrated to Claude Code, but six months ago the team was evenly split between Cursor and Claude Code. The head of engineering said :

“We had a dev for a while who wouldn’t use Cursor or Claude. We didn’t force him to, but it became clear that everyone else seemed to ship more code, whereas his quality wasn’t there”.

B) Public travel company (1,500 people, 800 engineers)

A staff engineer at this business highlighted vendor lock-in as a primary concern :

“Our main concern is avoiding vendor lock-in with a single solution. With this in mind, I expect to continue evaluating AI tooling this year as things keep evolving rapidly”.

They rolled out GitHub Copilot last year and are now evaluating Claude Code as a replacement. They remain cautious, given that the per-engineer cost is steep with Claude.

C) Public tech company (2,000 people, 700 engineers, productivity space)

The engineering leader in charge of dev productivity at this business calls security the biggest challenge :

“The biggest hurdle for us is security. We are looking for some amount of compliance, and I’ve found dev tools startups aren’t prioritizing that until they are late Series A/Series B. This helps focus us and ensure that what we are evaluating has passed some muster in the industry, without us feeling like we’re late to the game”.

Unsurprisingly, the tooling selection process is more in-depth at companies of this size, with many vendors as options. Here’s how they go about things :

“There’s an amount of instinct involved in knowing how to prioritize vendors. Our process is this :

What we’ve heard from friends and colleagues at other places.

- Chatter on Twitter/Reddit/Hacker

- News

- Knowing how to cut through hype

Evaluation is more organized and beta trials are common, he says :

“Every tool has to move a metric. Those that directly impact a metric which we already care about get approved faster. The tools that could theoretically impact metrics, but don’t have directly-measurable impact, take more work. The weaker the metric story, the stronger the narrative has to be.

We like to capture at least two weeks of beta usage on a tool before making a call on expanding or ending it.”

D) Cloud infrastructure company (900 people, 300 engineers)

A principal engineer responsible for AI tooling at this company describes the constant push-pull between developer enthusiasm and executive scrutiny :

“We started with Copilot because it was easy to procure, since we were a Microsoft customer for M365. Then switching to Cursor took forever. Pricing keeps shifting. Meanwhile, execs read a doc and keep asking “why aren’t we on Claude Code ?”

The answer to this also came from the exec team : pricing. Execs simply did not want to invest in the tools, and pricing remains a persistent headache. Claude’s team plan is ~$150/month, Cursor’s is ~$65, and this company’s C-level was not comfortable with going from Copilot’s $40/month to Cursor’s $65/month. The principal engineer also worries that costs will keep mounting, even with approval to move to Claude Code’s $150/month :

“Claude Code and Codex are definitely eating the costs right now… we all know that won’t last. If my execs push me on this, I will need to say — ‘okay, our developers got much slower in 6 months, but now we need to pay $250/month, per developer, to get higher limits’”.

In conclusion, choose and AI tool in a tech company is based mostly on the principle of « Speed, trust, & show-and-tell »