Praxiserprobte Notizen aus der Bereitstellung echten Codes mit Claude

 (diwank.space)
77 Punkte von GN⁺ 2025-06-09 | 7 Kommentare | Auf WhatsApp teilen
  • Das AI-Tool Claude wurde in einem realen Service eingesetzt; zusammengefasst werden realistische Wege, um den Effekt einer 10-fach höheren Entwicklerproduktivität tatsächlich zu erreichen, sowie praktische Anwendungs-Kniffe
  • „Vibe-Coding“ ist nicht nur ein kurzlebiger Trend, sondern eine praktisch nutzbare Methodik: Mit den richtigen Entwicklungsgewohnheiten und der passenden Infrastruktur lassen sich die Stärken von AI maximieren und ihre Schwächen ausgleichen
  • Die Rolle der AI wird klar in drei Modi unterteilt – „Erstentwurf-Ersteller“, „Pair-Programmierer“ und „Code-Reviewer“ – und für jede Phase sind passende Dokumentation und Guardrails unverzichtbar
  • Der Kern besteht darin, für jedes Projekt mithilfe einer Datei CLAUDE.md Konventionen, Architektur, Muster und Verbote klar zu dokumentieren und die AI im Code mit „anchor comments“ wirksam zu steuern
  • Testcode muss zwingend von Menschen geschrieben werden, und es müssen strikte Grenzen gesetzt werden, damit die AI keine Änderungen an kritischen Bereichen wie Tests, Migrationen, Sicherheit, API-Verträgen oder Secrets vornehmen kann
  • Teams, die AI-Coding unter den richtigen Grenzen und Gewohnheiten einführen, können Deployment-Frequenz, Stabilität und Entwicklungsgeschwindigkeit deutlich verbessern; das Teilen realer Betriebs-Kniffe und Muster wird dabei zum Kern der AI-Entwicklungskultur

Vibe Coding Isn’t Just a Vibe

  • Dieser Artikel ist ein Praxisleitfaden für eine neue Art der Softwareentwicklung mit AI und erklärt nicht nur die Nutzung, sondern auch das „Warum“ hinter tatsächlich wirksamer AI-gestützter Entwicklung
  • Selbst die mythisch wirkende 10-fache Produktivitätssteigerung ist laut realen Beispielen nur durch praktische Gewohnheiten erreichbar, die die Stärken der AI maximieren und ihre Schwächen kompensieren
  • Am produktiv genutzten Julep-Codebase werden praktische Infrastruktur und Betriebs-Know-how offengelegt, darunter CLAUDE.md-Templates, Commit-Strategien und Guardrails zur Vermeidung operativer Katastrophen
  • Besonders wichtig: Testcode muss immer direkt selbst geschrieben werden; eine übermäßige Abhängigkeit von der AI kann sonst schwere Ausfälle und Debugging-Albträume verursachen
  • In der AI-Entwicklung gibt es drei Modi (Erstentwurf, Pair-Programming, Reviewer), und je nach Situation unterscheiden sich Rhythmus und Prinzipien dafür, wann die AI die Führung übernimmt und wann Menschen direkt steuern müssen
  • Die Kernbotschaft: Nur mit guten Entwicklungsgewohnheiten und klaren Grenzen verstärkt AI die eigenen Fähigkeiten; auch reale Forschungsergebnisse zeigen, dass „Teams mit konsequenten Entwicklungsgewohnheiten bei Deployment-Geschwindigkeit und Qualität deutlich voraus sind“

Warum dieser Artikel geschrieben wurde: vom Meme zur praktischen Methodik

  • Das Konzept, der AI den Code zu überlassen und Entwickler würden nur noch „den Vibe mitnehmen“ („vibe-coding“), begann ursprünglich als Scherz-Tweet von Andrej Karpathy
  • Die Entwickler-Community tat das damals lachend als ultimative Fantasie ab: „Die AI arbeitet für uns, und wir trinken Kaffee.“
  • Doch seit der Veröffentlichung von Anthropic Sonnet 3.7 und Claude Code begann sich dieser Witz in eine tatsächlich mögliche Realität zu verwandeln. Es gab zwar schon Tools wie Cursor, aber Claude Code vermittelte erstmals wirklich das Gefühl von „Vibe Coding“
  • Das Team von Julep, zu dem der Autor gehört, arbeitet mit einem umfangreichen Codebase voller unterschiedlicher Designmuster und technischer Schulden. Code-Qualität und Dokumentation werden zwar streng gepflegt, doch allein das Verstehen von Absichten und Historie einzelner Teile ist so komplex, dass es Wochen dauern kann
  • Wenn Claude ohne Guardrails eingesetzt wird, entsteht ein Chaos, als würde ein übereifriger Praktikant an allen Ecken Fehler machen
  • Dieser Artikel teilt deshalb nur die wirklich praxiserprobten Muster und Kniffe, die aus solchen Fehlversuchen, nächtlichem Debugging um 3 Uhr und dem Überleben im echten Service-Betrieb hervorgegangen sind

Das Wesen von Vibe-Coding

  • So wie Steve Yegge den Begriff CHOP (Chat-Oriented Programming) geprägt hat, ist „Vibe-Coding“ eine neue Art der Entwicklung, bei der Code im Dialog mit einer AI entsteht
  • Während traditionelles Coding dem sorgfältigen Meißeln einer Statue aus Marmor Zeile für Zeile ähnelt,
    • ist Vibe-Coding eher mit dem Dirigieren eines Orchesters vergleichbar, wobei die AI als Musiker den Rohstoff liefert (grundlegende Coding-Fähigkeit)
    • Der Entwickler entwirft die Gesamtrichtung und Struktur, und die AI setzt diesen Fluss in Code um
  • Die 3 Haltungen (Postures) des Vibe-Coding
    • 1. Die AI als Erstentwurf-Ersteller nutzen (First-Drafter)
      • Fokus auf Architektur und Design, während die AI repetitive Arbeiten (CRUD, Boilerplate usw.) schnell erzeugt
      • Es fühlt sich an, als hätte man einen Junior Engineer, der Code in Denkgeschwindigkeit schreibt, aber kontinuierliche Anleitung braucht
    • 2. Pair-Programming mit der AI (Pair-Programmer)
      • Der praktischste und effektivste Modus
      • Entwickler und AI tauschen Ideen aus; der Mensch skizziert den groben Rahmen, die AI füllt die Details der Implementierung aus
      • Es fühlt sich an wie Pair-Programming mit einem Kollegen, der viel Programmierwissen besitzt, aber keine echte Deployment-Erfahrung hat
    • 3. Die AI als Prüfer/Code-Reviewer nutzen (Validator)
      • Von Menschen geschriebener Code wird von der AI geprüft, die Bugs, Verbesserungen und übersehene Muster vorschlägt
      • Eine stets wache und gründliche Reviewer-Rolle
  • Zentrale Einsicht: Die Rolle des Entwicklers verschiebt sich vom „Autor“ zum „Editor“. Statt jeden Code selbst zu schreiben, prüft, korrigiert und lenkt man die von der AI erzeugten Ergebnisse.
  • Dennoch gilt: Die Gesamtarchitektur und der Kontext müssen zwingend vom Menschen geführt werden; die AI ist nur ein „Praktikant mit enzyklopädischem Wissen“ und kennt den Kontext unseres Services oder Geschäfts nicht

Drei praktische Modi des Vibe-Coding: ein Framework

Nach monatelangen Experimenten und echten Deployment-Zwischenfällen zeigt sich, dass es beim Vibe-Coding drei Modi mit jeweils eigenem Rhythmus, eigenen Guardrails und optimalen Einsatzbereichen gibt

  • Modus 1: Playground (Experiment/Prototyp/Privatprojekt)

    • Einsatzzeitpunkt: Wochenend-Hacking, private Skripte, PoCs, spontane Ideentests usw.
    • Merkmale: Ohne Design, Dokumentation oder Guardrails schreibt die AI 80 bis 90 % des Codes. Die Geschwindigkeit von der Idee bis zum Ergebnis liegt bei nur wenigen Minuten
    • Risiko: Für echte Services oder kritischen Code ungeeignet. Nur für Spielereien und Experimente verwenden. Gerade hier werden Engineering-Prinzipien eher noch wichtiger

  • Modus 2: Pair Programming (reale Nutzung/kleinere Services)

    • Einsatzzeitpunkt: Projekte mit weniger als 5.000 Zeilen, Side-Projekte mit echten Nutzern, Demos, kleinere Module usw.
    • Kern: Konventionen, Architektur, Muster und Test-Guidelines des Projekts werden einmal klar und gebündelt in CLAUDE.md definiert
    • Vorteil: Wie beim Onboarding eines neuen Entwicklers reicht es, Claude alles einmal zu erklären, damit konsistent Code erzeugt wird
    • Praxispunkte:
      • Mit anchor comments (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION usw.) im gesamten Code wird Claude so geführt, dass kein Kontext verloren geht
      • Diese Kommentare dienen als Leitlinien für AI und Menschen zugleich; in CLAUDE.md werden sogar Verwaltungsregeln und Beispiele dafür festgehalten

  • Modus 3: Production/Monorepo Scale (große Services)

    • Einsatzzeitpunkt: Große Services mit Dutzenden bis Hunderten Entwicklern, echten Nutzern und Situationen, in denen ein einziger Fehler großen Schaden anrichten kann
    • Achtung: Stand heute (Juni 2025) ist großflächiges, gebündeltes Vibe-Coding noch nicht perfekt skalierbar
    • Prinzip: Es wird empfohlen, Vibe-Coding auf Ebene einzelner Services oder Submodule einzuführen; an allen Integrationspunkten (API, DB usw.) braucht es klare Grenzen und Versionsverwaltung, und bei zentralen Schnittstellen und APIs sind Warnhinweise zu Änderungen Pflicht
    • Praxisbeispiele:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • Ohne solche Grenzlinien kann Claude bei gut gemeinten Verbesserungen unbedacht den gesamten realen Service zerstören
  • Fazit: In großen Projekten sollte Vibe-Coding schrittweise und auf Ebene isolierter Services eingeführt werden; nur wenn Dokumentation, Guidelines und Reviews zusammen mit traditionellen Prinzipien beibehalten werden, lässt sich Zuverlässigkeit sicherstellen

Eine nachhaltige, infrastrukturzentrierte AI-Entwicklungsumgebung aufbauen

  • CLAUDE.md: die Single Source of Truth für AI und Menschen

    • CLAUDE.md fungiert als „Verfassung“, in der alle Projektregeln, Architektur, Hinweise, Code-Stil, Verbote und das Glossar der Domänenbegriffe systematisch festgehalten werden
    • Es dient als „Wissensgerüst“, das AI und neue Teammitglieder gemeinsam nutzen, wobei konkrete Richtlinien und Verbote samt Beispielen mit hohem manuellem Aufwand gepflegt werden
    • Teams, die in eine gute CLAUDE.md investieren, erzielen bessere Ergebnisse
    • Siehe unsere produktive CLAUDE.md
    • Je größer die Codebasis wird, desto weniger reicht CLAUDE.md allein aus; an verschiedenen Stellen im Code müssen mit anchor comments (AIDEV-NOTE/TODO/QUESTION usw.) lokale Kontexte klar vermittelt werden
    • Wenn man die Codebasis mit einer Stadt vergleicht, sind anchor comments Wegweiser, die verhindern, dass sich AI und Menschen verirren
    • Solche Kommentare gehen über einfache Code-Erklärungen hinaus und bewahren die Geschichte darüber, „warum“ etwas so funktioniert

  • Git-Workflow: systematische Verwaltung von AI-Code

    • Je schneller AI Code erzeugt, desto eher kann bei schlechter Verwaltung die Git-Historie verunreinigt werden
    • Mit Methoden wie git worktree wird ein vom Main-Branch getrennter Experimentierraum für AI geschaffen, sodass Code frei generiert werden kann, während die Nachvollziehbarkeit sauber getrennt und verwaltet bleibt
    • In Commit-Messages muss die Beteiligung von AI unbedingt kenntlich gemacht werden (z. B. mit dem Tag [AI]), damit Reviewer besonders aufmerksam prüfen können

Ungeschriebene Regel: Testcode muss immer von Menschen geschrieben werden

  • Das wichtigste Prinzip bei AI-gestützter Entwicklung: „Testcode darf man AI niemals überlassen.“
  • Tests sind nicht bloß Code zur Funktionsprüfung
    • Sie sind eine ausführbare Spezifikation, in die reales Problemverständnis, das Erkennen von Edge Cases, die Interpretation geschäftlicher Anforderungen sowie menschliches Domänenwissen und Erfahrung einfließen
    • Teams auf Spitzenniveau, die weder bei Geschwindigkeit noch bei Stabilität Kompromisse machen, verwalten genau diese Tests konsequent durch Menschen
  • Von AI automatisch erzeugte Tests prüfen meist nur oberflächliche Pfade (happy path) und übersehen schwerwiegende unerwartete Probleme (z. B. Memory Leaks)
  • In unserem Team wird ein PR automatisch abgelehnt, wenn AI Testdateien verändert (ohne Ausnahmen)
  • Tests sind die Spezifikation und das Sicherheitsnetz des Codes sowie die Weisheit aller angesammelten Bugs und Edge Cases
  • Sie müssen zwingend von Menschenhand geschrieben und so stark geschützt werden, dass AI sie nicht anfassen kann

Skalierung und Kontextmanagement: Token-Ökonomie und Kontextoptimierung

  • Ein häufiger Fehler in der AI-gestützten Codeentwicklung:
    Wenn man aus „Token-Sparen“ den Kontext (Prompt, Anforderungen, Umgebung usw.) minimiert, steigt am Ende die Zahl der Wiederholungen und damit auch der gesamte Token-Verbrauch
  • Angemessener Kontext ist langfristig effizienter
    • Entscheidend ist nicht „minimaler“, sondern „relevanter und ausreichender Kontext“, der vorab gegeben wird
  • Schlechtes Beispiel: Prompt mit zu wenig Kontext "Add caching to the user endpoint"
    • Claude schlägt dann einfaches In-Memory-Caching vor, ohne Invalidierungsstrategie oder Monitoring, ohne Berücksichtigung mehrerer Server und ohne Gegenmaßnahmen gegen Cache Stampede
    • Das Ergebnis: mehr als drei Korrekturschleifen und insgesamt mehr als der vierfache Token-Verbrauch
  • Gutes Beispiel: ein kontextreicher Prompt 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* 엔드포인트 트래픽 5만 req/분, 12대 API 서버, 데이터 변동 적음  
* 기존 Redis 인프라 위치, 표준 키 패턴, Prometheus 기반 메트릭 요구  
* 캐시 어사이드 패턴, TTL 1시간, 캐시 스탬피드 방지(확률적 조기 만료)  
* 캐싱 가이드 문서 참조
    • Mit konkretem Kontext von Anfang an wird eine präzise Implementierung ohne Wiederholungen möglich
  • Fazit:
    • „Tokens sind wie eine Investition in gutes Werkzeug“
    • Wenn man im Voraus ausreichend Kontext mitgibt, sinken auf lange Sicht Wiederholungen und Korrekturen, was Kosten spart
  • Praxistipp: In jedem Projekt sollte Claude bei jeder Codeänderung angewiesen werden, Änderungen an der Codebasis und den relevanten Kontext in CLAUDE.md zu aktualisieren

Sitzungsverwaltung und Vermeidung von Kontextverschmutzung

  • Es ist wichtig, für jede Aufgabe eine neue Claude-Sitzung zu starten
    • Wenn in einer langen Unterhaltung mehrere Aufgaben gemischt werden (z. B. DB-Migration und Frontend-Design), vermischt sich der Kontext und führt zu unbeabsichtigten Ergebnissen
  • Regel: eine Aufgabe = eine Sitzung; nach Abschluss wird eine neue Sitzung gestartet
    • So bleibt Claudes „mentales Modell“ stets sauber und fokussiert
    • Kontext wird getrennt, wie man auch Schneidebretter für rohes Huhn und Gemüse getrennt verwendet

Praxisbeispiel: Umstellung der Fehlerbehandlungsstruktur

  • Vorgestellt wird ein realer Fall, in dem die ad-hoc-Fehlerbehandlung in mehr als 500 Endpoints durch eine strukturierte Fehlerhierarchie ersetzt wurde
  • Der Mensch (Architekt) erstellt vorab das Kerndesign (SPEC.md/Anforderungen/Fehlerklassifikation), und Claude übernimmt als Ausführer die umfangreiche tatsächliche Codetransformation (mechanische Arbeit)
  • Architekturprinzipien und konkrete Spezifikation sowie das Ableiten von Beispielen/Konzepten aus Designdokumenten -> klare Arbeitsanweisung an die AI -> Erfahrung einer vollständigen Refaktorierung in exakt 4 Stunden

Leadership und Organisationskultur im AI-Zeitalter

  • Die Rolle von Senior Engineers entwickelt sich vom direkten Schreiben von Code hin zu Wissenskuratierung, dem Setzen von Grenzen und der Anleitung von AI und Menschen gleichermaßen
  • Moderne Entwicklungskultur wie Lean Management und Continuous Deployment bleibt auch für das Management der Zusammenarbeit mit AI unverändert wichtig

  • Onboarding-Checkliste für neue Mitarbeitende (Trennung von menschlicher und AI-Zusammenarbeit)

    • Woche 1: Grundlagen festigen
      • Die CLAUDE.md des Teams lesen (allgemein/service-spezifisch)
      • Entwicklungsumgebung einrichten
      • Ersten PR einreichen (100 % selbst geschrieben, AI verboten)
    • Woche 2: Praxis mit AI-Zusammenarbeit
      • Team-Template auf Claude anwenden und konfigurieren
      • Ein „Spielzeugproblem“ gemeinsam mit AI lösen
      • Prompt-Muster üben
      • Ersten AI-unterstützten PR erstellen (zusammen mit Mentor/Senior)
    • Woche 3: Eigenständige Praxisarbeit
      • Wichtige Funktionen mit AI-Unterstützung entwickeln und deployen
      • Für den AI-Code von Kolleg:innen selbst Tests schreiben
      • Eine Code-Review-Sitzung leiten

Eine transparente Kultur aufbauen: den Einsatz von AI aktiv offenlegen

  • Jeder Commit mit AI-Einsatz wird wie folgt mit Commit-Message-Tags klar gekennzeichnet 
    feat: add Redis caching to user service \[AI]  
# \[AI] - 50% 이상 AI 생성, \[AI-minor] - 50% 미만, \[AI-review] - 리뷰만 AI 사용  
# AI가 캐시/클라이언트 코드 작성, 캐시키 설계/테스트/검증은 사람이 직접
  • Effekte
    1. Reviewer achten besonders auf AI-Code
    2. Beim Debugging lässt sich die Herkunft des Codes leichter nachvollziehen
    3. Scham oder Verschleierung beim AI-Einsatz werden beseitigt, und eine Teamkultur von „AI verantwortungsvoll nutzen“ wird etabliert
  • Damit jede:r AI ohne Hemmungen nutzen und zu einer Hochleistungskultur beitragen kann, sind aktive Offenlegung und kulturelle Mechanismen entscheidend

Claudes Verbote: Hier darf AI auf keinen Fall eingreifen

  • Testdateien/Datenbankmigrationen/sicherheitskritischer Code/API-Verträge (ohne Versionsverwaltung)/Umgebungskonfiguration und Secrets dürfen niemals mit AI-Automatisierung bearbeitet werden
  • Fehler nach Schweregrad unterscheiden (von Formatierung und Abhängigkeiten bis zur Zerstörung geschäftskritischer Daten) und betonen, dass in Hochrisikobereichen zusätzliche verpflichtende Guardrails nötig sind
  • Risikohierarchie von AI-Fehlern (Hierarchy of AI Mistakes)
    • Level 1: lästig, aber nicht fatal
      • Formatierungsfehler (werden vom Linter erkannt)
      • geschwätziger Code (später refaktorierbar)
      • ineffiziente Algorithmen (fallen beim Profiling auf)
    • Level 2: teure Fehler
      • Brüche in der internen API-Kompatibilität (erfordern Abstimmung im Team)
      • Änderungen bestehender Muster (stiften Verwirrung)
      • unnötige zusätzliche Abhängigkeiten (blähen den Code auf)
    • Level 3: karriereschädigend (Career-Limiting)
      • Tests selbst ändern, um das gewünschte Testergebnis zu bekommen
      • API-Verträge brechen
      • Secrets/personenbezogene Daten offenlegen
      • Datenmigrationen beschädigen
    • Je nach Fehlerstufe muss auch das Niveau der Guardrails unterschiedlich sein, und Fehler der Stufe 3 stellen selbst für die Karriere eine erhebliche Bedrohung dar

Die Zukunft der Entwicklung: kommende Veränderungen und Richtung

  • Stand 2025 ist AI-gestützte Entwicklung wie ein pubertierender Teenager: mächtig, aber noch unbeholfen und rau
  • Die Wachstumskurve beschleunigt sich jedoch eindeutig
  • Gute Dokumentation ist die zentrale Infrastruktur für die DevOps-Umsetzung im AI-Zeitalter
    • Dokumentation ist nicht mehr nur „Referenzmaterial“, sondern eine direkte „Schnittstelle“ zwischen menschlicher Absicht und AI-Ausführung
    • Hochleistungs-Teams gehen mit der Pflege von Dokumenten wie CLAUDE.md genauso konsequent um wie mit Tests

  • Erwartete Veränderungen in Zukunft

    • AI, die den vollständigen Code-Kontext versteht
      • nicht nur auf Dateiebene, sondern bis auf Service- und Systemebene
    • Dauerhaftes Gedächtnis über Sitzungen und Projekte hinweg
      • merkt sich Gesprächs- und Arbeitskontext langfristig und nutzt ihn weiter
    • AI, die proaktiv Verbesserungsvorschläge macht
      • diagnostiziert Probleme und Verbesserungsmöglichkeiten im Voraus, auch ohne Aufforderung
    • AI, die teaminterne Muster und Präferenzen lernt
      • erzeugt automatisch Code passend zum Stil und zu den Konventionen der jeweiligen Organisation
  • Doch am Grundprinzip ändert sich nichts:
    • Menschen geben die Richtung vor, AI übernimmt Ausführung und Hebelwirkung
    • Egal wie mächtig die Werkzeuge werden, wir bleiben weiterhin diejenigen, die Werkzeuge benutzen

Fazit: Jetzt, hier anfangen

  • Wenn Sie bis hier gelesen haben, verspüren Sie vermutlich neben Erwartung auch ein wenig Angst
    • Diese Reaktion ist normal; AI-gestützte Entwicklung ist mächtig, verlangt aber nach „bewusster und systematischer Praxis“

  • Aktionsplan zum sofortigen Umsetzen

    • Heute
      • 1. Im aktuellen Projekt eine Datei CLAUDE.md anlegen
      • 2. Dem Code, den Sie selbst für am komplexesten halten, direkt drei Anchor Comments hinzufügen
      • 3. Unter klaren Grenzen (Leitlinien) eine AI-gestützte Funktion ausprobieren
    • Diese Woche
      • 1. Im Team Regeln für AI-Commit-Messages festlegen
      • 2. Eine AI-Coding-Session gemeinsam mit einem Junior-Entwickler durchführen
      • 3. Für von AI erzeugten Code selbst Tests schreiben
    • Diesen Monat
      • 1. Die Veränderung der Deployment-Frequenz vor und nach der AI-Einführung messen
      • 2. Eine Bibliothek von Prompt-Mustern für wiederkehrende Teamaufgaben aufbauen
      • 3. Ein Retrospektive-Meeting zur AI-Zusammenarbeit mit dem gesamten Team durchführen
  • Der Kern ist: „sofort, klein anfangen, vorsichtig, aber unbedingt anfangen“
  • Entwickler, die diesen Wandel schnell meistern, sind nicht deshalb besser, weil sie klüger wären,
    • sondern weil sie früher angefangen und durch mehr Fehler mehr gelernt haben
  • Ergebnisse bei Software-Deployments bestimmen unmittelbar die Leistungsfähigkeit einer Organisation
    • In einer Zeit, in der Geschwindigkeit und Qualität wettbewerbsentscheidend sind, ist AI-gestützte Entwicklung keine Option, sondern eine „Pflichtkompetenz“
    • Allerdings nur, wenn man sie richtig angeht
  • Vibe Coding mag wie ein Scherz klingen,
    • ist aber eine ernsthafte Art der Entwicklung, die menschliche Fähigkeiten verstärkt
    • Werkzeuge und Muster sind bereits ausreichend vorhanden
    • Jetzt ist es an der Zeit zu entscheiden, wer das Orchester dirigiert und wer allein alle Instrumente spielen will

Praxismaterialien und empfohlene Ressourcen

Verwandte Beiträge

7 Kommentare

 
softychoco 2025-06-16

Der Beitrag, den ich heute geschrieben habe, hat eine ähnliche Perspektive.
Letztlich war der entscheidende Punkt, die Produktivität durch AI zu steigern und zugleich die Organisationsstruktur so zu verändern, dass die gesunkene Stabilität wieder erhöht wird.

https://softycho.co/57
 
kimjoin2 2025-06-09

Ich verstehe immer noch nicht, welche Absicht hinter dem Begriff „vibe“ in „Vibe Coding“ steckt, also beim Coden mit KI-Unterstützung.
Atmosphäre? Gefühl? Harmonie? Mit KI hat das nichts zu tun.
Es wirkt genauso kontextlos wie „Tung Tung Tung Sahur“.
 
analogstar 2025-06-11

Laut Namuwiki
ist „Vibe Coding“ ein Neologismus, der das Schreiben von Code mit Unterstützung generativer KI bezeichnet; der Name „Vibe Coding“ soll daher kommen, dass man sich beim Programmieren nicht auf eine im Voraus streng ausgearbeitete Logik oder ein Design stützt, sondern auf Intuition und Gefühl. haha
 
hohemian 2025-06-09

Leere deinen Kopf und überlass dich dem Flow.
Die gesamte Logik wird von der AI geschrieben.
Man wird einfach zur Tab-Taste-Maschine!
 
secret3056 2025-06-09

> look and feel👀🎵🎷. Versuchen Sie nicht, es zu verstehen🧠, sondern fühlen Sie es!😊

Genau dieses Gefühl, oder?
 
humblebee 2025-06-09

Oh, ist das so? Bei mir hat es sofort einfach klick gemacht, als ich es gehört habe..
Wo Sie das sagen ... muss ich an den Begriff „Hardcoding“ denken, den inzwischen auch Leute aus nicht entwicklungsnahen Bereichen gut verstehen.
Auch bei diesem Wort ist es anfangs schwer zu erkennen, was es an sich bedeutet, aber wenn man Entwicklung lernt, versteht am Ende jeder gut, was damit gemeint ist und welche Intention dahintersteht — so ein gewisses „Gefühl“ eben? haha
 
GN⁺ 2025-06-09
Hacker-News-Kommentare

  • Aus Sicht des Autors: In letzter Zeit gibt es zwar unzählige Artikel zu Claude Code, aber ein paar Kernpunkte, die wir entdeckt haben — insbesondere Anchor Comments — schienen es wert zu sein, geteilt zu werden
    Der Anchor-Comments-Ansatz hinterlässt speziell formatierte Kommentare an verschiedenen Stellen im Codebestand, sodass man benötigtes Wissen direkt per grep finden kann
    Als Beispiel werden Präfixe wie AIDEV-NOTE:, AIDEV-TODO: und AIDEV-QUESTION: verwendet
    Vor jeder Dateisuche gilt die Regel, dass zuerst unbedingt nach vorhandenen AIDEV-… per grep gesucht werden muss
    Nach Abschluss einer Aufgabe müssen die betreffenden Anchors unbedingt aktualisiert werden
    Wenn eine Codedatei oder ein Codeschnipsel zu komplex ist, besonders wichtig ist oder potenziell Bugs enthalten könnte, soll immer ein Anchor-Kommentar hinterlassen werden
    Ein Beispiel dazu gibt es hier

    • Ich bin ein sehr erfahrener Engineer, nutze LLMs aber nicht systematisch, sondern nur gelegentlich, und fand es sehr aufschlussreich, einmal detailliert zu sehen, wie man LLMs in einem realen Projekt in die Produktion bringt
      Ich kann nicht ganz nachvollziehen, warum manche Leute darauf so negativ blicken
      Das motiviert mich, den Einsatz von LLMs in meinem Workflow etwas stärker auszubauen
      Natürlich hielt das LLM nicht die Schlüssel zum Projekt in der Hand, aber es gab doch etliche Fälle, in denen es bei bestimmten Aufgaben erfolgreich war

    • Es gibt derzeit viele Beiträge zu dem Thema, aber dieser hier ist sehr praxisnah und liefert mir Systemideen, die ich selbst ausprobieren kann
      Ich frage mich, worin der Unterschied zu einem Workflow mit Tools wie aider besteht — falls der Autor dazu eine Sicht hat, würde ich sie gern hören

    • Hervorragender Artikel, der mir sehr geholfen hat zu verstehen, wie man LLMs in größerem Maßstab nutzt
      Besonders auffällig fand ich die Aussage „Die AI darf Tests niemals anfassen“, gefolgt von dem Beispiel, in dem mehr als 500 Endpunkte in vier Stunden refaktoriert wurden
      Mich würde interessieren, ob in diesen vier Stunden auch das Refactoring der Tests enthalten war oder ob das nur die für Prompts aufgewendete Zeit war

    • Ich habe die Regel gesehen, dass PRs abgelehnt werden, wenn Tests von AI aktualisiert wurden, und frage mich, wie man in der Praxis feststellt, dass etwas tatsächlich von AI erzeugt oder geändert wurde
      Im Artikel stand, dass das über Regeln für Git-Commit-Messages erkannt wird, aber das funktioniert ja nur auf Commit-Ebene

    • Ich frage mich, ob für das Schreiben des Artikels Claude Code verwendet wurde
      Ich selbst schreibe inzwischen 100 % meiner Texte mit Claude Code und finde den Effekt, dass der Agent direkt in Markdown-Dateien editiert, viel produktiver als claude.ai artifacts oder chatgpt.com canvas
      Dadurch ist es sehr einfach geworden, Recherchematerial und verwandte Dateien tief in ein Dokument zu integrieren

  • Das Interessante an AI-Agenten ist, dass sie Prozesse tatsächlich zur Ausführung bringen, die man zwar immer für wichtig hielt, die aber vor einem echten System-Deployment in der Priorität doch oft nach hinten gerutscht sind
    Ich nutze den Grad des Unbehagens darüber, dass die AI etwas an meiner Stelle tut, als Maßstab dafür, wie viel Zeit ich in systematische Validierung investieren sollte
    Wenn man wie im verlinkten Beispiel ein Validierungssystem für Datenmigrationen aufbaut, kann man auch alle dazugehörigen Änderungen ganz natürlich in den Bereich aufnehmen, in dem AI eingesetzt wird
    Im Vergleich zu abstrakten Gesprächen über „technische Schulden“ hat das den Vorteil, dass es sich nach außen viel konkreter erklären lässt

    • Dem stimme ich definitiv zu, aber ein weiterer nützlicher Trick, den ich entdeckt habe, ist, Claude Code zu bitten: „Schau dir den Codebestand an und hinterlasse AIDEV-QUESTION:-Kommentare überall dort, wo etwas verwirrend, seltsam oder kontraintuitiv wirkt“
      So bin ich schon wieder auf wichtige Stellen gestoßen, weil unerwartet komplexer und vergessener Code auftauchte

    • Mein Gefühl ist, dass wir häufiger Werkzeuge zur Validierung auf höherem Abstraktionsniveau einsetzen werden — etwa Acceptance Tests, Property Tests oder formale Verifikation
      Die Boilerplate-Kosten sind durch den Einsatz von LLMs relativ stark gesunken

  • Beim Lesen habe ich etwas Neues gelernt
    Ich habe kürzlich Sonnet 4 in Cursor und im Web benutzt und war irritiert, wie oft es Dinge schlampig erledigt oder Ergebnisse missversteht und dann falsch berichtet
    Sogar außerhalb des Programmierens wirkt es teilweise geradezu pathologisch falsch
    Wie schon im Anthropic-Report beschrieben, haben selbst Warnungen wie „Ich werde das löschen“ nicht geholfen, und nach der Nutzung konnte ich im Mobile-App-Feedback das Problem nicht einmal melden
    Bei anderen scheinen solche Claude-Probleme nicht aufzutreten, daher frage ich mich, ob ich damit allein bin

    • Die letzten Updates haben auf mich den Eindruck gemacht, als hätten sie die Fähigkeiten der AI zu stark abgeschwächt
      Bis Version 3.5 war sie für einfache Aufgaben wie Textanalyse, Zusammenfassungen oder kurze Schreibarbeiten ganz brauchbar, aber ab Version 4 schafft sie es innerhalb eines Kontexts oft schon nach drei bis vier Anweisungen nicht mehr, Befehle korrekt zu befolgen
      Wenn man fragt: „Warum erklärst du immer so ausschweifend, obwohl ich dich gebeten habe, dich kurz zu fassen?“, antwortet sie, dass sie Anweisungen wegen Standardeinstellungen ignoriere, und zeigt zusätzlich die Tendenz, „schädliche Informationen“ grundsätzlich zu meiden
      Wenn man wiederholt auf logische Schwächen hinweist, gibt sie mitunter selbst zu, dass ihre Zuverlässigkeit gering ist
      Fast wirkt es, als wäre sie zu klug geworden und genau dadurch seien die Probleme entstanden; falls Anthropic sie wirklich in die falsche Richtung weiterentwickelt hat, wäre das bedauerlich

    • Ich habe alle oben genannten Probleme tatsächlich selbst erlebt
      Im Web wird es etwas besser, wenn man sehr spezifische Anfragen stellt, aber trotzdem enthält noch immer etwa die Hälfte des erzeugten Codes Fehler

  • Beim Lesen der Dokumentationstipps hatte ich den Eindruck, dass solche Regeln eigentlich nicht nur für AI gedacht sind, sondern genauso gut für normales Coding gelten
    Statt CLAUDE.md könnte man CONVENTIONS.md haben, und statt Kommentaren für AI eben Kommentare für den LESER — ebenso nützlich wäre es allemal
    Wenn ich in einer unbekannten Codebasis neu beitragen würde, wäre ich für solche Kommentare ziemlich dankbar

    • Ich habe das tatsächlich mit aider ausprobiert, und es hat ziemlich gut funktioniert
      Während ich auf ein Flugzeug wartete, habe ich in 30 Minuten Code fertigbekommen, der sogar einen PDF-Viewer und Zeichenfunktionen enthielt

    • Ich bin nicht der Autor des Originalbeitrags, aber in der Praxis unterscheiden sich Kommentare, die Claude helfen, und Kommentare, die Menschen helfen, deutlich im Stil
      Ein Stilguide für Menschen umfasst oft nur rund 100 Zeilen und besteht überwiegend aus einfachen Regeln wie „An Funktionen, die Input verändern, immer ein ! anhängen“
      Einen Guide für Claude habe ich auf über 500 Zeilen ausgebaut, und ich habe das Gefühl, dass er nur dann wirklich wirkt, wenn zu jeder Regel viele Beispiele nach dem Muster „Mach es so, nicht so“ enthalten sind

  • Danke für den Beitrag
    Ich kann die widersprüchlichen Gefühle gut nachvollziehen, die viele Entwickler haben, wenn sie einem LLM einen Teil der Kontrolle über ihre Arbeit überlassen: einerseits Unbehagen, andererseits das Gefühl, sich von bisherigen formalen und strengen Entwicklungsmethoden hin zu einem experimentelleren oder unstrukturierteren Ansatz zu bewegen
    Gleichzeitig entsteht durch den Einsatz von LLMs tatsächlich ein praktikabler Mittelweg, in dem eine viel schnellere, zielorientierte Problemlösung möglich wird
    Oft verliert man sich in Implementierungsdetails und verfehlt dabei das eigentliche Ziel; ich denke, dass LLMs helfen können, solche Fehler zu verringern

    • Das stimmt
      Ich sehe LLMs als einen noch unfertigen Hebel: rau, fehleranfällig, aber absolut lohnend, wenn man lernt, damit umzugehen
      Wichtig ist, dass man sie nicht als Vorwand für schlampiges Engineering benutzt, sondern daran arbeitet, sie zu wirklich brauchbaren Werkzeugen weiterzuentwickeln

  • Das 2,3-MB-Bild ganz oben im Artikel lud selbst im WLAN scherzhaft gesagt quälend langsam

  • Ein paar Gedanken

    • Ich frage mich, ob es einen eleganteren Weg gibt, LLM-bezogene Prompts oder Spezifikationen im Codebestand zu organisieren
      Wenn CLAUDE.md, SPEC.md und AIDEV-Kommentare immer mehr werden, dürfte das schwer zu handhaben sein

    • Ich frage mich, was die aktuelle Definition von „vibe-coding“ überhaupt ist
      Früher, wie bei Karpathys „Cowboy-Modus“, bedeutete es eher, keinen Code anzuschauen und alle Diffs einfach zu akzeptieren, inzwischen scheint der Begriff auf nahezu jeden LLM-Workflow ausgeweitet worden zu sein

    • Mich würde auch interessieren, ob Leute ihren Sourcecode verschleiern, wenn sie ihn an fremde LLMs schicken

    • Es stimmt, dass viele Kommentare den Code sehr schnell komplex machen können
      Deshalb entwickle ich gerade selbst eine VSCode-Erweiterung, die das visualisiert und mit kleinen Indikatoren im Gutter anzeigt
      Was „vibe-coding“ bedeutet, ist von Person zu Person unterschiedlich; für mich persönlich war es keine perfekte Lösung, und ich bin auf verschiedene Probleme gestoßen
      3.7 Sonnet und Codex lieferten bei mir etwa 60 % Ergebnis, aber Opus 4 fühlt sich in der Praxis tatsächlich sehr effizient an
      Was die Verschleierung von Code betrifft: Im Beispiel im Artikel war ohnehin alles Open Source, daher spielte das keine große Rolle

  • Sehr interessant, ich werde einiges davon in meine eigene CLAUDE.md übernehmen
    Ich stimme der paradoxen Lektion in der AI-Entwicklung zu, dass das Sparen von Kontext aus Angst vor zu hohem Tokenverbrauch am Ende eher kontraproduktiv ist
    In größeren Projekten und komplexerem Code spüre ich den Leistungsunterschied zwischen Claude Opus und Sonnet inzwischen sehr deutlich
    Sonnet wiederholt oft unnötige Versuche und verschlechtert die Lage am Ende eher noch
    Da stellt sich für mich die Frage, ob Max-Abonnenten Opus und Sonnet überhaupt getrennt betrachten sollten
    Wenn Sonnet für etwas 10 bis 20 Anläufe braucht, die Opus in 2 oder 3 erledigt, dann kann die Nutzung von Sonnet langfristig sogar teurer sein

    • Das Max-Abo hat zwei Tiers: Für 100 $ bekommt man fünfmal so viele Tokens wie bei Pro, für 200 $ zwanzigmal so viele
      Die Tokenberechnung ist nicht ganz einfach, und im Hybrid-Modus wird Opus nur verwendet, bis noch 20 % der Opus-Tokens übrig sind; danach wird automatisch auf Sonnet umgeschaltet

  • Gut geschriebener Artikel, aber beim Teil „Tests niemals der AI überlassen“ bin ich anderer Meinung
    Ich lasse mir inzwischen alle Tests von AI schreiben und prüfe sie anschließend sehr sorgfältig selbst
    Gerade bei neuem Code braucht man für hohe Autonomie eigentlich auch AI-generierte Tests
    Ich arbeite so, dass ich der AI explizit auftrage, die Tests zu implementieren und zum Laufen zu bringen, und sie während der Entwicklung sofort reviewe und fehlende Testfälle ergänze

  • Dem größten Teil stimme ich zu, aber mit der Politik, Claude Tests oder Migrationen überhaupt nicht anfassen zu lassen, kann ich mich nicht anfreunden
    Tests selbst zu schreiben ist für mich die unerquicklichste Aufgabe, und schon ein minimaler Entwurf von einem LLM ist eine große Hilfe
    Entscheidend ist, dass unabhängig vom Erzeuger die endgültige Verantwortung und Ownership immer beim Menschen bleibt
    Vom Tonfall her wirkt es so, als traue der Autor Claude nicht genug oder wolle vor allem verhindern, dass Mitarbeitende AI-Ergebnisse unkritisch übernehmen
    Oder er hält das Risiko ohne strikte Regeln bei Tests und Migrationen für realistisch genug, dass echter Code kaputtgeht oder Daten verloren gehen können

    • Das stimmt zwar, aber meiner Erfahrung nach gab es dabei ernsthafte Probleme
      1. Wenn Menschen generierte Tests später manuell korrigieren, entstehen oft wirklich üble Fallstricke
      2. Claude versteht den Kontext nicht gut genug und mockt deshalb fast alles weg, wodurch häufig Tests entstehen, die völlig an unserer Service- und Build-Umgebung vorbeigehen
      3. Und das größere Problem ist, dass das ganze Team im Umgang mit Tests zu nachlässig wird
        Tatsächlich haben Bugs in Production bei uns deutlich zugenommen