Warum diese Säule anders ist
Die ehrliche Beobachtung: Entwickler die KI ernsthaft nutzen, arbeiten 2026 anders als die, die sie als „bessere Autocomplete" behandeln.
Der Unterschied zeigt sich nicht in der Geschwindigkeit. Der zeigt sich in was du baust. Wer Claude Code oder Cursor nur für Boilerplate-Generierung nutzt, spart Zeit. Wer MCP-Server baut, eigene Workflows designt, und KI als orchestrierendes System versteht — der baut Dinge die vorher nicht möglich waren.
Diese Kategorie sammelt alles was wir zu diesem Thema schreiben. Tools-Vergleiche mit echten Benchmarks. Tagebücher aus realen Projekten. Deep-Dives zu MCP-Servern. Lokale LLM-Setups die auf Consumer-Hardware laufen. Kein Marketing. Keine „X wird Y für immer verändern"-Headlines.
Nur: Was funktioniert, was nicht, und warum.
Was du hier findest — und was nicht
Wenn du hier bist, weil du dich fragst ob Claude Code besser ist als Cursor — das wird beantwortet. Mit 50 identischen Aufgaben, dokumentierten Zeiten, und klaren Qualitätsbewertungen. Keine „es kommt darauf an"-Ausflüchte, sondern: Welches Tool hat welche Aufgabe wie gelöst.
Wenn du wissen willst wie du deinen ersten MCP-Server in 60 Minuten baust — auch das. Mit TypeScript-SDK, Error-Handling, und dem ersten produktiven Use-Case. Vom Hello-World-Beispiel bis zum Server der eine echte API abfragt.
Wenn du überlegst, ob ein lokales Modell auf deinem MacBook M3 ausreicht — du findest die gemessenen Token/Sekunde, dokumentierte Latenzen, und ehrliche Grenzen. Auf drei Hardware-Setups getestet: MacBook Pro M3, Desktop mit RTX 4090, MacBook Air M2.
Was du nicht findest: Theorie-Artikel ohne Code. „Best Practices" ohne konkrete Implementierung. Fremde Blogpost-Zusammenfassungen. KI-generierte Listicles. Alles hier ist selbst getestet, mit echten Projekten, auf dokumentierter Hardware.
Die drei Kern-Themen dieser Säule
Der Leitfaden unten gruppiert alle Artikel thematisch. Du musst nicht linear lesen — such dir raus was für deine aktuelle Frage passt.
Claude Code in der Praxis: Für alle die wissen wollen ob der Terminal-Ansatz wirklich funktioniert. Mit 90-Tage-Tagebuch, direktem Benchmark gegen Cursor/Codex, und ehrlichen Stärken/Schwächen-Analysen.
MCP-Server verstehen und bauen: Für alle die ihre KI-Tools erweitern wollen. Vom Protokoll-Verständnis bis zum ersten produktiven Server, der interne APIs anzapft.
Lokale Coding-Modelle: Für alle die nicht jeden Context in die Cloud schicken wollen. Mit gemessenen Performance-Daten und klaren Empfehlungen welches Modell für welches Setup.
Claude Code in der Praxis
Claude Code ist der Einstiegspunkt für viele, die KI-Assistenten über reine Autocomplete-Funktionen hinaus nutzen wollen. Der Terminal-basierte Ansatz klingt zunächst ungewohnt — aber genau diese Architekturentscheidung macht den Unterschied.
Wo Cursor und Copilot in deinem Editor sitzen und Vorschläge machen, sitzt Claude Code neben deinem Projekt. Es liest deine Files, bevor es schreibt. Es läuft Tests, bevor es committet. Es fragt nach, bevor es destruktive Operationen ausführt. Das klingt langsam — ist es in der Praxis nicht.
90 Tage Praxistest aus Einsteiger-Perspektive
Der Artikel 60 Tage mit Claude Code als Junior-Dev dokumentiert den Einstieg eines Junior-Entwicklers, der Claude Code als einziges Coding-Tool nutzte. Keine IDE-Integration, keine Cursor-Vergleiche — nur die pure Erfahrung: Was wurde gelernt, wo entstanden Reibungspunkte, welche Erwartungen wurden enttäuscht, welche übertroffen.
Das Tagebuch zeigt ehrlich was passiert, wenn du nicht nur Snippets generierst, sondern Refactorings, Tests und Git-Operationen an ein Terminal-LLM delegierst. Die interessantesten Erkenntnisse liegen oft in den Fehlschlägen: Wo Claude Code an Grenzen stieß, welche Aufgaben weiterhin manuelle Intervention brauchten, und — wichtig — welche Mental Models aus klassischer Programmierung sich als Hindernis entpuppten.
Für Einsteiger ist das der ehrlichste Einstiegspunkt. Keine idealisierten Workflows, sondern: So sieht es aus wenn jemand neu anfängt.
Direkter Benchmark gegen Cursor und GPT-5 Codex
Wer konkrete Zahlen braucht, findet sie im Benchmark Claude Code vs Cursor vs GPT-5 Codex. 50 identische Aufgaben, dieselben Codebases, dokumentierte Zeiten und Qualität. Keine subjektiven Eindrücke — nur: Welches Tool lieferte den annehmbaren Code am schnellsten, wo sind die blinden Flecken, welche Aufgabentypen dominiert welches System.
Die Benchmark-Aufgaben decken das reale Spektrum ab: Einfache CRUD-Endpoints, Multi-File-Refactorings, komplexe Algorithmen, Test-Suite-Erweiterungen, Bug-Fixes in fremdem Code. Jedes Tool bekam dieselbe initiale Prompt-Formulierung. Die Outputs wurden blind bewertet: funktioniert der Code ohne Änderung, wie viele Iterationen bis zur Akzeptanz, welche Qualitätsprobleme bleiben.
Inklusive CSV-Download der Rohdaten für eigene Analysen. Wer eine Tool-Entscheidung treffen muss, kann die eigenen Aufgaben-Patterns mit den Benchmark-Kategorien abgleichen.
Warum der Terminal-Ansatz funktioniert
Nach drei Monaten täglicher Nutzung zeigt sich der Kern im Artikel Claude Code auf Deutsch — was es wirklich anders macht. Claude Code sitzt neben deinem Projekt, nicht in deinem Editor. Es liest Files, bevor es schreibt. Es führt Tests aus, bevor es committet. Und — entscheidend — es fragt vorher.
Multi-File-Refactorings funktionieren ohne Context-Verlust. Tool-Integration kommt out-of-the-box (Bash, Git, Browser, MCP-Server, eigene Skills) ohne Extension-Chaos. DSGVO-Compliance ist machbar, weil nur die Anfragen in die Cloud gehen — nicht der komplette Repo-Inhalt wie bei Cursor/Copilot-Setups die ständig Files hochladen.
Der Artikel erklärt wo Claude Code glänzt (große Refactorings, Multi-File-Änderungen, reproduzierbare Workflows), wo Cursor noch vorne liegt (visuelle Aufgaben, pixelgenaues CSS, Preview-Panel), und wie deutsche Entwickler die gesamte Dokumentation auf Deutsch führen können ohne Qualitätsverlust.
Für alle die sich fragen „lohnt sich der Umstieg von Cursor" — das ist der Artikel mit den ehrlichen Tradeoffs.
MCP-Server verstehen und bauen
Das Model Context Protocol (MCP) ist Anthropics Ansatz, LLMs erweiterbare Tools zu geben. Die Idee: Statt jede Integration fest in den AI-Service zu kodieren, baut man kleine Server die spezifische Fähigkeiten exponieren. Slack-Nachrichten lesen, Datenbanken abfragen, APIs ansprechen — alles über ein standardisiertes Protokoll.
Der Vorteil gegenüber fest verdrahteten Plugins: Du kontrollierst was das LLM kann. Du deployest den Server wo du willst. Du entscheidest welche Daten durchgehen und welche gefiltert werden. MCP-Server sind einfache stdio-basierte Prozesse — keine komplexen Cloud-Funktionen, keine Vendor-Lock-ins.
Die 30-Minuten-Einführung
Der Artikel MCP-Server auf Deutsch — was es ist und warum du es brauchst erklärt das Protokoll ohne Marketing-Fluff. Was ist ein MCP-Server technisch, warum ist das besser als fest verdrahtete Plugins, und wie baust du den ersten funktionierenden Minimal-Server in 30 Minuten.
TypeScript-SDK, erste Tool-Definition, Hello-World-Beispiel. Der Artikel zeigt die Anatomie eines MCP-Servers: stdio-Transport, Tool-Schema-Definition, Handler-Funktion. Du brauchst kein Backend-Framework, keine Cloud-Deployment-Pipeline — nur Node.js und das SDK.
Der Einstieg für alle die bisher nur von MCP gehört haben, aber nicht wissen wo sie anfangen sollen. Nach 30 Minuten hast du einen lauffähigen Server, den Claude Code aufrufen kann.
Vom Hello-World zum produktiven Use-Case
Wer tiefer einsteigen will, folgt dem Tutorial Dein erster MCP-Server in 60 Minuten. Der Artikel nimmt dich von der SDK-Installation bis zum ersten echten Server, der eine interne API abfragt.
Error-Handling, Authentication, Parameter-Validation — alles was zwischen dem Minimal-Beispiel und einem Server liegt, den du tatsächlich produktiv einsetzen kannst. Das Tutorial zeigt einen realen Use-Case: Ein MCP-Server der eine interne Ticketsystem-API anzapft, Tickets nach Status filtert, und strukturierte Antworten zurückgibt.
Du lernst wie du Secrets sicher handhabst (keine API-Keys im Code), wie du Tool-Parameter validierst (zod-Schemas), und wie du Fehler so zurückgibst dass Claude Code sie verstehen kann. Das Tutorial geht davon aus, dass du TypeScript schreiben kannst und einmal eine REST-API gebaut hast. Mehr Vorwissen brauchst du nicht.
Wichtig: Der Server läuft lokal auf deinem Rechner. Keine Cloud-Deployments nötig. Claude Code startet den Server automatisch wenn du ihn in der Config einträgst.
Lokale Coding-Modelle
Nicht jeder will jeden Codebase-Kontext in die Cloud schicken. Lokale Modelle laufen auf deiner Hardware, ohne externe API-Calls, ohne Rate-Limits, ohne Daten die das Netzwerk verlassen. Die Frage ist: Reicht die Qualität 2026?
Die ehrliche Antwort: Für viele Aufgaben ja. Lokale Modelle sind keine Notlösung mehr. Aber du musst wissen welches Modell für welches Setup, und wo die harten Grenzen liegen.
Qwen Coder, DeepSeek, Llama im Direktvergleich
Der Artikel Lokale Coding-LLMs — Qwen Coder, DeepSeek, Llama testet die drei relevantesten lokalen Coding-Modelle auf drei Hardware-Setups: MacBook Pro M3, Desktop mit RTX 4090, MacBook Air M2.
Welches Modell für welche Coding-Aufgaben, welche Token/Sekunde in der Praxis, wo sind die Grenzen. Die Tests decken typische Entwickler-Workflows ab: Code-Completion, Refactoring-Vorschläge, Bug-Erklärungen, Test-Generierung, Dokumentation schreiben.
Der Vergleich zeigt: Lokale Modelle sind 2026 kein Kompromiss mehr — aber du musst wissen für welche Aufgaben sie funktionieren und für welche nicht. Qwen Coder dominiert bei Code-Completion, DeepSeek bei komplexen Algorithmen, Llama bei natürlichsprachlichen Erklärungen.
Die Tests laufen über Ollama (für alle Plattformen) und MLX (Apple Silicon optimiert). Installationsanleitungen, exakte Modell-Parameter, verwendete Prompts und gemessene Latenzen sind vollständig dokumentiert. Wer eine Entscheidung zwischen lokalem Modell und Cloud-API treffen muss, findet hier die Datenbasis.
Wichtig: Die Tests messen nicht synthetische Benchmarks, sondern reale Workflows. Wie lange dauert es bis das Modell einen verwendbaren Refactoring-Vorschlag liefert. Wie oft ist die erste Antwort direkt annehmbar. Wie viele Iterationen braucht es bis der Code kompiliert. Das sind die Metriken die im Alltag zählen.
Wie du diese Artikel nutzt
Diese Säule wächst kontinuierlich. Neue Benchmarks wenn relevante Tools erscheinen. Praxis-Tagebücher wenn echte Projekte neue Patterns zeigen. Deep-Dives zu Technologien die sich durchsetzen.
Der Ansatz bleibt gleich: Alles selbst getestet, mit echten Projekten, auf dokumentierter Hardware, mit reproduzierbaren Setups. Keine Theorie-Artikel ohne Code. Keine fremden Blogpost-Zusammenfassungen. Keine KI-generierten Listicles die du schon hundertmal gelesen hast.
Wenn du hier reinkommst und nicht weißt wo anfangen:
- Du willst Claude Code testen? Start mit Claude Code auf Deutsch — das gibt dir die Mental Models für den Terminal-Ansatz.
- Du brauchst harte Zahlen für eine Tool-Entscheidung? Der Benchmark liefert die Datenbasis.
- Du willst MCP-Server bauen? Start mit der 30-Minuten-Einführung, dann das 60-Minuten-Tutorial.
- Du überlegst lokale Modelle? Der Vergleich sagt dir welches Modell auf deiner Hardware läuft.
Alle Artikel sind geschrieben um direkt umsetzbar zu sein. Code-Snippets, Installations-Befehle, reproduzierbare Setups. Keine „das kommt darauf an"-Ausflüchte.
Wo diskutieren wir das
Coding mit KI ist kein abgeschlossenes Thema. Tools ändern sich, Modelle werden besser, neue Patterns entstehen. Die meisten sinnvollen Gespräche passieren wenn jemand konkret zeigt was er gebaut hat — nicht in theoretischen Diskussionen.
Die Zone "Coding & Projekte" im Discord ist der Ort dafür. Frag konkret, zeig Code, teil deine Benchmarks. Wir sind eine deutsche Community — viele Gespräche laufen auf Deutsch, technische Details oft in englischen Code-Snippets. Kein Gatekeeping, kein „du solltest schon wissen dass"-Gehabe.
Was gut funktioniert in diesem Channel:
- Konkrete Setup-Fragen: „Ich krieg MCP-Server X nicht zum Laufen, hier mein Config" — zeig was du probiert hast, du bekommst präzise Fixes statt allgemeiner Ratschläge.
- Benchmark-Erweiterungen: „Ich hab Claude Code und Cursor auf Aufgabe Y getestet, hier die Timings" — ergänzt unsere Daten, hilft anderen bei ähnlichen Workflows.
- Tool-Kombinationen: „Ich nutze lokales Qwen + MCP-Server für interne Datenbank-Queries" — zeig dein Setup, diskutier Tradeoffs.
Was nicht so gut funktioniert: Endlos-Debatten welches Tool „objektiv besser" ist ohne konkrete Aufgaben-Definitionen. Wir reden über Werkzeuge — die Qualität zeigt sich im was du baust, nicht in abstrakten Feature-Listen.
Falls du an einem dieser Themen arbeitest und Feedback brauchst: Das ist der richtige Kanal.