- Eine Studie analysierte anhand von 2.430 realen Open-Source-Repositories die Tendenzen von Claude Code bei der Tool-Auswahl
- In 12 von insgesamt 20 Kategorien wurde eine eigene Implementierung (Custom/DIY) statt eines bestehenden Tools gewählt – die häufigste Entscheidungsart insgesamt
- Bei der Auswahl von Tools zeigte sich dagegen eine starke Konzentration auf einzelne Optionen wie GitHub Actions (94 %), Stripe (91 %) und shadcn/ui (90 %)
- Deployment-Umgebungen sind je nach Sprache festgelegt: Für JS ist Vercel die Standardwahl, für Python Railway; AWS, GCP und Azure wurden bei der Erstwahl ausgeschlossen
- Je neuer das Modell, desto deutlicher die Tendenz zum Wechsel auf neuere Tools wie Drizzle und FastAPI BackgroundTasks; die Auswahlkonsistenz innerhalb eines Ökosystems liegt bei rund 90 %
Überblick über die Studie
- Mit Claude Code v2.1.39 wurden insgesamt 2.430 Experimente durchgeführt, um die Tool-Auswahl in realen Repositories anhand offener Fragen zu beobachten
- 3 Modelle (Sonnet 4.5, Opus 4.5, Opus 4.6), 4 Projekttypen, 20 Tool-Kategorien
- 85,3 % Extraktionsrate, 2.073 gültige Antworten
- 90 % Übereinstimmung zwischen den Modellen; in 18 von 20 Kategorien blieb die Auswahl innerhalb desselben Ökosystems konsistent
Zentrale Erkenntnis: Build vs Buy
- In 12 von 20 Kategorien war Custom/DIY-Implementierung die häufigste Wahl
- Insgesamt 252 Custom/DIY-Auswahlen, mehr als bei jedem einzelnen Tool
- Beispiele: Feature Flags als konfigurationsdateibasiertes Setup mit Umgebungsvariablen, Python-Authentifizierung direkt mit JWT + passlib, Caching über einen In-Memory-TTL-Wrapper
- Custom/DIY-Anteil nach Kategorie
- Feature Flags 69 %, Authentication (Python) 100 %, Authentication (gesamt) 48 %, Observability 22 %
Der Standard-Stack
- Wenn Claude Code tatsächlich Tools auswählt, bildet sich ein JS-Ökosystem-zentrierter Standard-Stack heraus
- Häufig gewählte Tools: Zustand (64,8 %), Sentry (63,1 %) usw.
- In manchen Fällen konzentrieren sich 100 % der JS-bezogenen Auswahlen auf ein bestimmtes Tool
- Dieser Standard-Stack hat direkten Einfluss auf die Entwicklung vieler neuer Anwendungen
Abweichung vom Marktmainstream
- Unter Tools mit hohem Marktanteil gibt es einige, die Claude Code kaum verwendet
- State Management: keine Hauptwahl, stattdessen 57 Auswahlen für Zustand
- API Layer: Bevorzugt wird framework-internes Routing
- Testing: nur 4 % als Hauptwahl, 31 Fälle als Alternativwahl
- Paketmanager: 1 Hauptwahl, 51 Alternativwahlen
Tendenz zum Tool-Wechsel bei neueren Modellen
- Je neuer das Modell, desto stärker der Wechsel zu neueren Tools
- JS ORM: Prisma (79 %) → Drizzle (100 %)
- Python Job-Verarbeitung: Celery (100 %) → FastAPI BackgroundTasks (44 %)
- Python Caching: Redis (93 %) → Custom/DIY (50 %)
- Innerhalb der jeweiligen Ökosysteme ist ein klarer generationeller Tool-Wechsel zu beobachten
Aufspaltung bei den Deployment-Umgebungen
- Deployment-Entscheidungen sind abhängig vom Sprach-Stack festgelegt
- JS (Next.js + React SPA): In 86 von 86 Fällen wurde Vercel gewählt
- Python (FastAPI): Railway wurde in 82 % der Fälle gewählt
- AWS, GCP und Azure hatten in allen 112 Fällen 0 Hauptauswahlen
- Als alternative Empfehlungen tauchten Netlify (67-mal), Cloudflare Pages (30-mal), GitHub Pages (26-mal) und DigitalOcean (7-mal) auf
- AWS Amplify, Firebase Hosting usw. wurden nur erwähnt, aber nicht empfohlen
- In Beispielantworten liefert Vercel sogar Installationsbefehle und Begründungen, während AWS Amplify nur in einer Zeile erwähnt wird
Wo sich Modelle unterscheiden
- In 5 von 20 Kategorien gab es Unterschiede zwischen den Modellen
- JS ORM: Prisma → Drizzle
- JS Jobs: BullMQ → Inngest
- Python Jobs: Celery → FastAPI BgTasks
- Caching: Redis → Custom/DIY
- Real-time: SSE → Custom/DIY
- Die übrigen 18 Kategorien behielten eine konsistente Auswahl innerhalb des jeweiligen Ökosystems bei
Benchmark-Service für Unternehmen
- Amplifying bietet ein privates Dashboard für einzelne Entwickler-Tool-Unternehmen
- Dort lässt sich prüfen, wie häufig AI-Agenten das eigene Tool im Vergleich zur Konkurrenz empfehlen
- Unterstützt die Analyse der Wettbewerbsfähigkeit bei Tool-Empfehlungen auf Basis realer Codebasen
Datenauswertung
- Zu den detaillierten Analysepunkten gehören Tiefenanalysen nach Kategorie, Prompt-Stabilität, Konsistenz zwischen Repositories und Markteinfluss
- Die Studienergebnisse sollen künftig auf Basis des Modells Sonnet 4.6 aktualisiert werden
4 Kommentare
Interessant, aber ich frage mich auch, ob sie sich nicht einfach in die Richtung entwickelt haben, mehr ihrer eigenen Tokens zu verbrauchen und dadurch höhere Kosten zu verlangen. Und eigentlich habe ich auch den Eindruck, dass KI manche Bibliotheken bis zu einem gewissen Grad einfach erstellt, weil sie darauf trainiert wurde.
Wenn ich daran denke, dass sich wegen der Präferenzen von Agenten nur bestimmte Bibliotheken weiterentwickeln könnten, fühlt sich das irgendwie seltsam an.
Interessante Studie. Besonders eindrucksvoll ist, dass in der Kategorie „Build vs Buy“ 12 von 20 Kategorien auf DIY entfallen.
Wir haben bei der Erstellung des Standards für AI-Agenten-Personas (Soul Spec) eine ähnliche Beobachtung gemacht: Wenn man Claude Code die Tools nicht über
CLAUDE.mdoderAGENTS.mdvorgibt, neigt es stark dazu, die Implementierung auf seine eigene Weise umzusetzen.Was der „Recency Gradient“ dieser Studie nahelegt, ist wohl, dass ein neues Tool entweder im Trainingsdatensatz ausreichend präsent sein oder in den Projekt-Kontextdateien explizit angegeben werden muss, damit es in Claudes Standard-Stack aufgenommen wird. Letztlich bestimmt also Context Engineering sogar die Tool-Auswahl.
Gut ist auch, dass der Originaldatensatz offengelegt wurde: https://github.com/amplifying-ai/claude-code-picks
Das nennt man wohl Assistive agent optimization (AAO).
Bei Tools für Entwickler ist es inzwischen wichtig geworden, zu einem Produkt zu werden, das Agenten bevorzugen.
Wenn der Agent gar nicht erst darüber spricht, entfernt man sich nach und nach immer weiter davon.
Hacker-News-Kommentare
Ich denke, die Zukunft von LLM-Werbung besteht darin, vollständig unsichtbar zu werden
Am Ende wird sie damit zum mächtigsten „Influencer“ überhaupt
Oder vielleicht ist es keine Werbung, sondern eher ein Problem von Interessenkonflikten (conflict of interest)
Zum Beispiel könnte es ein Signal dafür sein, ob Gemini Setups auf GCP-Basis stärker bevorzugt
Laut Anthropics Forschung gibt es Wege, statt auf SEO auf Sichtbarkeit in LLM-Produkten zu zielen
Etwa 6 Monate warten, dann sammeln Crawler das ein und nutzen es als Trainingsdaten → am Ende Profit
Wenn dort Gemini im Einsatz gewesen wäre, wäre das vermutlich nicht passiert
Das ist die ultimative Umsetzung von „Nudge“
In Zukunft werden agentische Coding-Systeme selbst entscheiden, was sie bauen, und Menschen werden nur das Ergebnis bekommen, ohne die verworfenen Optionen je zu sehen
Sogar Lieferketten werden dann von LLMs bestimmt
Die Plattform kontrolliert das „Regal“ und schaut sich beliebte SaaS-Funktionen an, um dann Eigenmarken zu bauen (z. B. Great Value, Amazon Basics)
Steuersoftware scheint dafür ein typisches Beispiel zu sein
Interessant ist, dass der in diesem Beitrag erwähnte Webstil von Claude Code sich auf dem betreffenden Blog tatsächlich direkt zeigt
Die Schriftart JetBrains Mono ist ein typisches Merkmal von Webseiten, die Opus 4.6 erzeugt hat
In den letzten 30 Tagen scheinen über 99 % der Webseiten mit übermäßigem Einsatz von JetBrains Mono von Opus generiert worden zu sein
Opus 4.6 hat Drizzle in 32,5 % der Fälle gewählt, Prisma dagegen nur in 20,5 %
Je leistungsfähiger das Modell, desto seltener scheint es Prisma zu wählen — fast wie eine Art Intelligenz-Benchmark
Ein weiteres Beispiel ist youjustneedpostgres.com, wo JetBrains Mono ebenfalls übertrieben stark eingesetzt wird
Das Design der Kategorieleiste war fast identisch mit einer achtlos generierten UI, die ich gestern erzeugt hatte
Dieses kartenartige CSS fühlt sich überall gleich an, und auch dieser Blog wirkt so gebaut
Ich gebe LLMs keine vagen Prompts
Stattdessen lerne ich im Jahr 2026 gerade neu, wie man präzise Informationen aus LLMs herausbekommt
Es fühlt sich an, als würde ich das Google-Suchen von 2006 noch einmal lernen
Ich nutze Reverse Prompts, damit ein Modell die Hypothesen eines anderen überprüft
Wenn mir zum Beispiel das Ergebnis von Opus 4.6 verdächtig vorkommt, gebe ich es an ChatGPT oder Codex weiter und lasse sie nach Schwachstellen suchen
Claude ist vergleichsweise weniger stur, während ChatGPT oder Codex entschiedener auftreten, aber oft auch genauer sind
Bei einem Docker-Container-Problem meinte Claude tatsächlich, es sei ein ZFS-Bug, während ChatGPT sagte, es sei nur ein einfacher Konfigurationsfehler — und das stimmte
So komme ich durch Cross-Validierung zwischen LLMs zur richtigen Antwort
Dann stellt es wirklich sehr viele
Ich lasse sie so lange überarbeiten, bis ein detaillierter Plan herauskommt, und sie stellen dabei auch mehr notwendige Fragen
Mit meinem ChatGPT-Abo erreiche ich das Limit nicht, aber wenn es gelegentlich Fehler gibt, starte ich Claude in einem anderen Terminal
Das Claude-Budget meiner Firma ist mit 750 Dollar pro Monat sehr knapp
Ich nutze TimescaleDB auf AWS
Claude Code verwaltet dabei EC2-Instanzen über die AWS CLI
Trotzdem hat Claude heute Morgen vorgeschlagen, NeonDB- und Fly.io-Konten anzulegen
Obwohl mein AWS-Setup bereits gut steht, fand ich diese Empfehlung für neue Dienste seltsam
Meiner Erfahrung nach treffen LLM-Agenten katastrophale Architekturentscheidungen
Sie sind besessen von unnötigen Abstraktionen und Versionsmanagement, und der Code wird übermäßig kompliziert
Am Ende muss man den Code doch selbst schreiben
Ich nutze Planetscale in allen Projekten, aber Claude hat Neon empfohlen
Das wirkt einfach wie ein Bug
Ich fand es interessant, dass Opus 4.6 als „zukunftsorientiert“ bezeichnet wurde
Ich hatte 4.5 einen Monat lang verwendet und dann mit 4.6 ein neues Projekt begonnen, und in der Planungsphase führte es Websuchen aus
Das Modell ist inzwischen weit genug entwickelt, aber Abstimmung und Rollenverteilung bleiben weiterhin die Kernaufgabe
Früher habe ich mit GPT-3.5 selbst eine Android-App veröffentlicht (App-Link)
Was damals eine Woche dauerte, geht jetzt mit einem einzigen Prompt
Wenn man LLMs gut orchestriert, kommt man deutlich schneller zu Ergebnissen
Beim Coden mit LLMs ist mir aufgefallen, wie stark vor allem im Webbereich die Abhängigkeit von npm-Paketen sinkt
Früher habe ich Dinge wie jwt auth oder Build-Plugins verwendet, aber heute kann man vieles durch ein paar Zeilen Code ersetzen
Der Code ist einfacher, leichter zu verstehen und dadurch vertrauenswürdiger
2010 war jQuery der König von JS, heute reicht pures JS oft aus
Sicherheitsrelevanten Code wie etwa für JWT würde ich aber trotzdem nicht ungeprüft aus Claude übernehmen
Jetzt ist eine Eigenimplementierung womöglich die bessere Wahl
Es wird zwar mehr Code-Duplikation geben, aber weniger Abhängigkeitsprobleme
Ich sage Claude immer ausdrücklich, welche Bibliotheken und proprietären Technologien es verwenden soll
Ich denke, Entwickler müssen Modelle gut anleiten können
Wenn ich unsicher bin, frage ich in einem separaten Fenster nach Architektur oder Vor- und Nachteilen und entscheide dann
In zwei Projekten hat Claude automatisch GitHub Actions hinzugefügt
Ich hatte gar nicht darum gebeten, und weil es ein versteckter Ordner war, habe ich es im git diff übersehen
Zum Glück waren es nur 4 Cent Kosten, aber es war eine ziemlich beunruhigende Erfahrung
Mich interessiert etwas
Warum hat sich shadcn/ui so sehr als Standard-UI-Bibliothek etabliert?
Nicht nur Claude, auch andere Modelle verwenden es standardmäßig
Wenn man vorgibt, shadcn auszuschließen, leiden dann Qualität oder Geschwindigkeit?
Liegt es vielleicht am Reichtum an Dokumentation und Beispielen, oder einfach daran, dass es in den Trainingsdaten überrepräsentiert ist?
Ich war auch überrascht, als Gemini etwa Mitte 2025 begann, shadcn standardmäßig in React-Dashboards einzubauen
shadcn/ui basiert auf Tailwind, deshalb bevorzugt AI es offenbar
Tatsächlich sind die npm-Downloadzahlen seit Dezember explosionsartig gestiegen
npm-Paket-Link
Es gibt viele ältere Komponentenbibliotheken, also wäre es eine wissenschaftliche Analyse wert, warum gerade diese gewonnen hat
Die Komponenten sind konsistent und leicht anzupassen, wodurch sich die Integration ins Projekt vereinfacht
Es ist wirklich ein sehr gut gemachtes Projekt
Wenn ich heute Websites sehe, die den shadcn-Standardstil unverändert nutzen, wirkt das auf mich wie ein Signal für eine von AI erstellte Website
So wie vor 10 Jahren bei Bootstrap sind die Standardstile einfach zu verbreitet
Wäre das dann wirklich zwingend eine Spur von AI?
Ich frage mich, was mit der Analogie zu „Bootstrap vor 10 Jahren“ genau gemeint ist