Pimp My IDE / Garage Dispatch
← Back to the garage
September 4, 2026 · Agent procurement / dependency choice

Your coding agent has a favorite store.

Tool selection is becoming executable. When an agent recommends a database, auth vendor, or deployment target and then installs it, “what should I use?” is no longer casual advice. It is a procurement event with a package lock.

The take: do not ban recommendations. Make them show their work. Requirements, alternatives, switching cost, and source freshness should be visible before a familiar brand becomes architecture by autocomplete.

The recommendation now comes with a wrench.

Armature ran a large commercial study of coding-agent tool choices. Its headline describes 16,893 sessions across 1,163 prompt variations, 75 repositories, and three agents. The embedded implementation leaderboard describes a narrower slice: 5,292 runs across 18 sectors and 51 apps. In that slice, reported category leaders included Stripe for payments at 88.4%, Neon for databases at 66.3%, PostHog for product analytics at 52.6%, and E2B for agent sandboxes at 42.5%.

The percentages are interesting. The mechanism is bigger. These were not survey answers floating in a slide deck; agents were asked to pick a product and implement it. That collapses recommendation, installation, and code change into one move. A suggestion can land in package.json, environment variables, data models, and deployment config before a human has compared the exits.

A leaderboard can reveal a default. It cannot prove the default fits your constraints.

Read the odometer before worshipping the winner.

Armature plainly discloses that it sells growth services to developer-tool companies and studies how to influence agent choices. Good disclosure; material incentive. The page also presents more than one population count. That does not erase the results, but it makes the scope part of the result. Ask which run set produced each percentage, which versions were pinned, how prompts encoded requirements, how failures were counted, and whether implementation success was checked beyond “the agent wrote code.”

Popularity can be rational. Familiar tools have stronger docs, examples, SDK coverage, and model exposure. Those are real implementation advantages. They can also create a flywheel: agents choose what appears often; each generated integration creates more examples; the next agent sees even more of the same. Documentation becomes distribution, and distribution starts dressing like judgment.

The cockpit is already moving from chat to operations.

Cursor’s September 2 changelog adds self-hosted machines and team pools, with agent execution on infrastructure customers already use. VS Code 1.136 adds Agent Merge in preview, designed to keep addressing review feedback, failed checks, and merge conflicts until a pull request is ready. It also groups related chats under sessions and surfaces pending approvals.

Together, those releases show why tool choice needs a harder gate. Agents are gaining longer operational loops, broader workspace reach, and more places to execute. The old mental model—an assistant proposes, a developer separately implements—is expiring. The agent may propose, install, configure, test, respond to review, and drive the pull request toward merge inside one continuous session.

Replace “best” with a buying card.

Before delegating a product choice, hand the agent a small contract:

  1. Write the constraints first. Data residency, latency, traffic shape, team skill, budget ceiling, compliance, self-hosting, and failure tolerance.
  2. Compare at least three shapes. A category leader, a credible alternative, and a boring built-in or self-managed option.
  3. Price the exit. Export format, proprietary APIs, migration path, identity coupling, egress, and the code surface that must change.
  4. Date every material source. Pricing and product limits rot. Require links to current primary documentation, not remembered training residue.
  5. Separate recommendation from execution. Produce the card, stop, obtain approval, then install the chosen dependency.

The purpose is not committee theater. It is a visible clutch between “this tool is common” and “this tool belongs in this codebase.”

Interactive makeover / procurement dyno

Put a clutch before install.

Traditional purpose replaced: ask “what is the best tool?” and accept the first polished answer. Better version: choose the buying bay, close four evidence breakers, and copy a decision contract that forces recommendation to stop before execution.

Default Dealer Dyno

Pick the category. Close only the breakers your next agent run will actually satisfy.

Tool category

Buying Pressure

The gauge measures decision hygiene selected here, not product quality.

0 of 4 breakers closed · recommendation not cleared
Why it is better: the same control that exposes missing evidence also produces the handoff. You leave with a reusable buying card instead of a vague intention to “compare later,” and the install gate stays visibly open until every promised check is present.

Sources read, not vibes

  1. Armature — “Which tools do Claude Code, Codex and Cursor choose?” (September 3, 2026): reported study design, commercial-interest disclosure, headline corpus, embedded leaderboard scope, and category percentages. Treat as vendor research, not an independent standard.
  2. Cursor changelog — “Self-hosted machines” (September 2, 2026): product claims about in-network tool execution, team worker pools, supported sandbox infrastructure, and Linux/Mac computer use.
  3. Visual Studio Code 1.136 release notes (September 2, 2026): Agent Merge preview, multi-root agent sessions, session hierarchy, pending approvals, and workspace resolution behavior.
  4. Hacker News discussion of the Armature study (read September 4, 2026): discovery and public criticism surface; comments are context, not verification.
  5. GitHub Trending (read September 4, 2026): current scan of adjacent developer-tool activity; used for editorial context, not factual support for the percentages.

Source boundary: this dispatch did not reproduce Armature’s experiments or independently audit its traces. Counts and percentages are attributed to the publisher. Cursor and VS Code capabilities are based on their own release notes. The Default Dealer Dyno is an explanatory checklist; its gauge is not a benchmark, security score, or endorsement of any vendor.