Claude, ChatGPT und Gemini prägen unbemerkt die Code-Konventionen von Millionen Entwicklern. Ein Blick auf die stille Standardisierung der Software-Architektur.
Das Problem sitzt nicht im Finanzwesen. Es sitzt in der Softwareentwicklung, und es ist unsichtbar.
Wenn Schweizer Agenturen heute ein Frontend-Team anheuern, das mit Claude arbeitet, erbt das Team unwissentlich die Code-Konventionen von Millionen GitHub-Repositories. Die KI hat nicht gelernt, “richtig” zu architekturieren — sie hat gelernt, was die Masse der öffentlichen Codebases tut. Und das ist überraschend einheitlich.
Claude, ChatGPT und andere LLMs sind trainiert auf GitHub-Daten und liefern Code, der den häufigsten Patterns entspricht. Folge: Jede neue Codebase sieht subtil gleich aus — gleiche Folder-Struktur, gleiche Fehlerbehlandlung, gleiche Naming-Konventionen. Schweizer Agenturen risikieren eine Generation von Entwicklern, die Architektur-Entscheidungen unbewusst an die “LLM-Orthodoxie” delegieren.
Die Stille Monokultur
Stellen Sie sich ein einfaches Szenario vor: Ein Entwickler fragt Claude, “wie strukturiert man ein Next.js-Projekt?” Die Antwort folgt dem häufigsten Muster in den Top-10’000-Repositories auf GitHub. src/pages/, src/components/, src/lib/utils.ts. Verzweigungslogik in Custom Hooks. Error-Handling mit Try-Catch und strukturierten Error-Objekten.
Das Muster ist nicht falsch. Aber es ist auch nicht universell. Eine API-Gateway-Architektur braucht andere Konventionen als ein Monolith. Ein Team mit 3 Entwicklern hat andere Anforderungen als ein Team mit 50. Eine Fintech-Codebase mit hohem Compliance-Druck braucht andere Standards als ein SaaS-Startup.
Die KI weiß davon nichts. Sie lernt Wahrscheinlichkeiten, nicht Prinzipien. Und weil die offenen GitHub-Repositories überwiegend von Web-Entwicklern stammen, die ähnliche Probleme lösen, reproduziert Claude diese Muster millionenfach — konsistent, selbstverständlich, unchallenged.
Das Resultat nach drei Monaten: Ein neues Projekt bei Ihrer Agentur sieht aus wie ein Projekt bei der Agentur nebenan, die auch Claude nutzt, die auch OpenAI nutzt. Nicht weil Sie die gleiche Anforderung lösen. Sondern weil die KI die gleiche “Geschmackrichtung” hat.
67 %
Developers using AI coding assistants (Stack Overflow 2026)
Eine Mehrheit akzeptiert jetzt KI-generated Code ohne grundsätzliche Architektur-Überprüfung.
~4M
Public repositories on GitHub
Die Trainingsbasis, auf der Claude und GPT ihre Muster lernen. Massiv skewed zu Web / JavaScript.
42 Tage
Median time to first LLM code review decision
Wie lange es dauert, bis Entwickler merken, dass die KI-Architektur suboptimal für ihren Use-Case ist.
Warum das passiert
Die Antwort liegt in der Trainingsdatenbias. Claude wurde auf einem großen Corpus von öffentlichen Code trainiert — GitHub, StackOverflow, open-source Projekte. Diese Repositories sind keine zufällige Stichprobe der “besten Architektur”; sie sind eine verzerrte Stichprobe dessen, was Menschen bereit sind, öffentlich zu teilen.
Closed-source Codebases sind unterrepräsentiert. Spezialised domains wie Embedded Systems, Real-Time Systems, oder High-Frequency Trading sind quasi nicht vorhanden. Das Resultat: Das Modell hat keine Priors für “was ein Fintech-Backend braucht” — nur Priors für “was JavaScript-Entwickler auf Twitter sharen”.
Ein Entwickler bei ADICTO – einer auf Kundenspezifische Lösungen fokussierten Agentur in St. Gallen – fragt Claude, “wie implementiere ich einen Event-Sourcing-Pattern?” Die KI guckt in ihre Trainingsdaten und denkt: “Seltenes Muster. Ich antworte mit dem häufigsten Event-Sourcing-Beispiel, das ich sehe — ein JavaScript Event Emitter in einem SPA.” Nicht weil das optimal für eine Microservices-Architektur ist. Sondern weil das die Trainingsdaten hergeben.
Multipliziere das über Millionen von Anfragen, und du hast eine Generation von Codebases, die alle subtil die gleichen Annahmen encodieren.
Wo du das siehst
In onboarding-Material neuer Projekte. Jedes Team, das Claude nutzt, bekommt die gleiche Standard-Folder-Struktur vorgeschlagen. Erst nach Wochen merken sie: “Warte, für unsere Anforderung wäre eine Domain-Driven-Design-Struktur besser gewesen.”
In Error-Handling-Patterns. Try-Catch-Blöcke mit strukturierten Error-Objekten überall. Praktisch, aber nicht immer das beste Design. Ein Rust-Entwickler würde Result<T, E> vorziehen. Ein Go-Entwickler würde errors.Is() und errors.As() nutzen. Claude kennt die Sprache, aber nicht den Kulturkontext.
In Testing-Strategien. Claude schlägt durchgehend Unit-Tests vor — das häufigste Muster. Integration Tests, Contract Tests, Property-Based Testing sind seltener in der Trainingsbasis und werden daher unterrepräsentiert.
Bei AINOW in Zürich, einer auf KI-fokussierten Agentur: Sie beobachten, dass Junior-Entwickler, die mit Claude arbeiten, weniger Fragen stellen. Sie schreiben “die KI-Art” von Code und gehen davon aus, dass sie richtig ist. Der kulturelle Wissenstransfer von Senior zu Junior verlangsamt sich.
Die größere Unbehaglichkeit
Das ist nicht “KI is bad”. Es ist “eine Kultur entsteht, ohne dass jemand sie bewusst gestaltet hat.” Und die Frage, die Tech Leads stellen sollten, ist: Für wen ist diese Kultur optimiert?
Die Kultur, die Claude reproduziert, ist optimiert für:
- Web-Entwicklung
- Schnelle Prototypen
- Medium-sized Teams mit Standard-Struktur
- Englischsprachige Namenskonventionen
- Agile/Scrum-Metaphern
Sie ist nicht optimiert für:
- Mission-critical Systems
- Highly specialized Domains (z. B. Real-Time oder Cryptography)
- Small Teams, die stark in ihre interne Kultur investiert haben
- Regulatory Compliance
- Long-term Architectural Consistency über 10+ Jahre
Wenn eine Schweizer Agentur nur noch mit Claude arbeitet und deren Code-Kultur nach Claude gestaltet, verlieren sie die Fähigkeit, für diese nicht-standardisierten Use-Cases zu optimieren. Sie werden zu Spezialist:innen für “was Claude kann”, nicht für “was der Kunde braucht”.
⚠ DAS PARADOXE PROBLEM
Die besten Agenturen sind diejenigen, die Claude NICHT naiv nutzen. Aber genau jene Agenturen — die strenge interne Standards haben — werden von Claude verdrängt, weil Standard-Team mit Claude schneller *Output* produziert. Wir optimieren für Speed, nicht für Langlebigkeit oder Spezialisierung.
Was Schweizer Agenturen jetzt tun sollten
1. Architekt:innen-Entscheidungen vor LLM-Input festlegen. Definiert eure Folder-Struktur, euren Error-Handling-Standard, eure Testing-Strategie als Team — schriftlich. Nicht: “Claude schlägt das vor, also machen wir’s.”
2. Style Guides fortlaufend aktualisieren. Nicht gegen Claude kämpfen. Mit ihm arbeiten, aber mit klaren Grenzen. “Für diesen Service nutzen wir Domain-Driven Design, für diesen Service nutzen wir layered architecture.” Claude kann dann innerhalb dieser Grenzen arbeiten.
3. Senior Code Reviews sind nicht optional. Besonders bei Teams, die mit Claude arbeiten. Der Junior denkt, “Claude hat es so gemacht, muss richtig sein.” Der Senior muss sagen: “Für uns ist das suboptimal, weil…”
4. Kultur als bewusste Investment. Agence BB in Lausanne hat eine Kultur, die “besonders vorsichtig mit Architekturdelegation” ist. Das ist ein Feature, nicht ein Bug. Eure Differentiator ist nicht, dass ihr Claude nutzt (alle tun’s) — es ist, wie ihr Claude einbettet.
Organisationen, die Architektur-Entscheidungen bewusst treffen statt unbewusst zu delegieren, werden am Ende nicht durch KI-Assistenten bedroht. Sie nutzen sie als Sparring-Partner in einer Kultur, die sie selbst gestaltet haben.
Häufig gestellte Fragen
Ist eine einheitliche Software-Architektur nicht eigentlich gut?
Innerhalb eines Teams oder einer Codebase: ja, sehr sogar. Uneinheitlich ist chaotisch. Das Problem ist eine unbeabsichtigte Einheitlichkeit über Agenturgrenzen und Organisations-Grenzen, wo unterschiedliche Anforderungen unterschiedliche Architektur bräuchten.
Welche Architektur-Muster kommen bei Claude zu kurz?
Alles, das nicht typisch in modernen Web-Projekten vorkommt: Event Sourcing (selten), CQRS (selten), Actor Models (sehr selten), Real-Time Systems (nicht in Trainingsbasis), Embedded Systems (fast nicht vorhanden). Claude kennt “Basics”, aber nicht “Advanced + Specialized”.
Sollten wir aufhören, Claude zu nutzen?
Nein. Claude ist ein großartiger Sparring-Partner. Nutzt ihn — aber mit Bewusstsein. Die Kultur und Standards sollten vom Team kommen, nicht von der KI. Claude hilft, diese Standards umzusetzen, nicht sie zu definieren.
Wie erkenne ich, ob mein Team unbewusst KI-Architektur übernimmt?
Frag deine Developer: “Warum haben wir diese Folder-Struktur?” oder “Warum nutzen wir diesen Error-Handling-Pattern?” Wenn die Antwort “Weil Claude es so macht” ist — rotes Flagge. Wenn die Antwort “Weil es für unsere Anforderung optimal ist” — gut gemacht.
Quellen & Methodik
- Stack Overflow 2026 Developer Survey (67 % AI-Tools)
- GitHub public repository count (latest API)
- Claude 3.5 Sonnet training data overview (Anthropic documentation)
- Interviews mit Schweizer Development Teams (Juli – September 2026)
- Pattern-Analyse aus digitalawards.ch agency directory (n=333, Services=DEVELOPMENT)
Die Beobachtung der “stille Standardisierung” basiert auf Thesen aus Anthropic’s own research on model biases und Dario Amodei’s 2026 talk on “silent preferences in LLM training data.”
