Warum agentenbasierte KI kein guter Pair Programmer ist

 (justin.searls.co)
17 Punkte von GN⁺ 2025-06-12 | 2 Kommentare | Auf WhatsApp teilen
  • LLM-Agenten schreiben Code viel schneller als Menschen, wodurch sich die Pair-Programming-Erfahrung sogar verschlechtern kann
  • Durch zu schnelle Automatisierung können Nutzer nicht Schritt halten und verlieren häufig den Arbeitskontext
  • Dieses Phänomen ähnelt dem Gefühl der Ausgrenzung beim Pairing mit sehr erfahrenen Entwicklern und führt letztlich zu schwächerer Qualitätssicherung und Kommunikation
  • Als Lösung werden asynchrone Zusammenarbeit mit Fokus auf Code-Reviews sowie ein Workflow vorgeschlagen, der das Tempo des Pairings mit KI reduziert und Qualitätssicherung sowie Kommunikation in den Mittelpunkt stellt
  • Auch KI-Agenten brauchen ein Design, das wie bei Menschen „anhält und spricht und sich statt auf Selbstsicherheit auf Zweifel und Verifikation konzentriert“

Probleme von LLM-Agenten beim Pair Programming

  • KI-Agenten (z. B. Copilot Agent) schreiben Code weit schneller als die menschliche Denkgeschwindigkeit
  • Dadurch wird der Nutzer mit Code überschüttet, bevor er folgen kann, und verliert den Kontext und die Konzentration auf die Aufgabe
  • Wenn der Agent in Problemsituationen um Hilfe bittet, übernimmt der Nutzer bereits ohne klares Situationsverständnis die Rolle der „Aufräumtruppe“, was letztlich die Belastung erhöht, in die falsche Richtung gelaufenen Code zu ordnen
  • Am Ende werden Qualitätssicherung, Kommunikation und das Einhalten der richtigen Richtung erschwert
  • Die Erfahrung, mit dem besten KI-Agenten zu pairen, ruft negative Erinnerungen an früheres Pairing mit herausragenden menschlichen Programmierern hervor
    • Der Pair-Partner hämmert lautlos in überhöhtem Tempo auf die Tastatur, sodass man den Code nicht mehr einholen kann
    • Die mentale Energie wird vollständig aufgebraucht, woraufhin man sich allmählich von der Arbeit entfernt
    • Sobald das Pairing ins Stocken gerät und Hilfe verlangt wird, entsteht die peinliche Erfahrung, die Situation kaum erfassen zu können
    • Während der Arbeit entstehen Implementierungen, die von den Zielen abweichen, und die Last, sie noch vor der Deadline zu korrigieren, wird weitergereicht

The path forward: Praktische Lösungen

  • 1. Asynchrone Zusammenarbeit

    • Ähnlich wie beim menschlichen Pair Programming, wenn eine Person die Führung übernimmt, ist es effektiver, wenn die KI selbstständig Code schreibt und dieser per Pull Request geprüft wird
    • Mit asynchronen Workflows wie GitHub Coding Agent kann sich der Nutzer auf Review und Qualitätssicherung konzentrieren

  • 2. Tempo reduzieren durch „zugbasiertes“ Pairing

    • Statt des „Agent Mode“ der KI sollte ein Vorgehen wie Edit/Ask Mode verwendet werden, bei dem Schritt für Schritt gearbeitet wird
    • Ähnlich wie beim Ping-Pong-Pairing (eine Seite schlägt vor, die andere genehmigt) akzeptiert oder prüft der Nutzer die von der KI vorgeschlagenen Änderungen direkt und steuert so das Tempo
    • Es ist sinnvoll, KI nicht nur zur Problemlösung/zum Debugging einzusetzen, sondern sie in einen konsistenten Workflow einzubinden

Ideen, um Agenten-Pairing menschlicher zu machen

  • Nutzer sollten die Ausgabegeschwindigkeit von Code (Zeilen/Minute, Wörter/Minute) direkt einstellen können
  • Eine Funktion, um den Agenten vorübergehend anzuhalten, damit Nutzer Fragen stellen oder der Richtung widersprechen können
  • Jenseits bestehender Chatbot-UIs sollten UI-Primitiven angeboten werden, die mit dem Arbeitsfortschritt verknüpft sind (z. B. die aktuelle Sitzung an ein bestimmtes GitHub-Issue anheften, integrierte To-do-Liste usw.)
  • Agenten sollten so gestaltet sein, dass sie häufiger anhalten und das Gespräch suchen: prüfen, „warum wir das tun“, um Rat fragen, die Richtung abgleichen usw., um eine Atmosphäre menschlicher Zusammenarbeit zu schaffen
  • Einführung von fortgeschrittenem Voice-Chat-Support, damit Nutzer die Augen auf dem Code behalten und per Sprache mit der KI kommunizieren können
  • Wenn solche Funktionen umgesetzt werden, wäre statt des heutigen schnellen und einseitigen Agenten-Pairings eine echte kooperative Erfahrung zwischen Mensch und Agent möglich

Fazit

  • Wir beobachten derzeit zugleich die Grenzen und die Möglichkeiten von KI-agentenbasiertem Pair Programming
  • KI-Agenten-Pair-Programming erzielt größere Wirkung, wenn es nicht nur auf Tempo, sondern wie die Zusammenarbeit mit Menschen auf Kommunikation, Qualität und Verifikation ausgelegt ist
  • „Langsam, im Gespräch, prüfend und mit geteiltem Situationsverständnis“ verbessert die Qualität des KI-Pairings

Verwandte Beiträge

2 Kommentare

 
panarch 2025-06-12

> 1. Asynchrone Zusammenarbeit
> Ähnlich wie beim Pair Programming mit Menschen, wenn eine Person die Führung übernimmt, ist es effektiver, wenn die AI den Code eigenständig schreibt und ihn per Pull Request zur Review stellt.

Ich nutze Codex jetzt seit ein paar Tagen und stimme eher dem hier zu als der Agentenform. Dadurch, dass ich mehrere Projektaufgaben gleichzeitig laufen lassen kann, fühlt es sich wirklich so an, als würde ich mit mehreren Junior-Entwicklern zusammenarbeiten.
Weil ich AI nun asynchron nutzen kann und dadurch in mehreren Projekten sowie auch innerhalb eines Projekts mehrere Aufgaben gleichzeitig anstoßen kann, spüre ich ganz real, dass die Produktivität rechnerisch um mehr als das 3- bis 10-Fache steigt.
 
GN⁺ 2025-06-12
Hacker-News-Meinungen

  • Fühlt sich wie eine treffende Beschreibung dafür an, warum ich aufgehört habe, AI auf diese Weise zu verwenden. Wenn ich etwas bauen will, habe ich meistens schon grob entschieden, <i>wie</i> ich es machen möchte, aber die Art, wie die AI es tatsächlich umsetzt, weicht oft von dem ab, was ich will. Und wenn die AI dann auf einmal 2.000 Zeilen Code erzeugt, macht sie mir damit eher mehr Arbeit. Dann muss ich so etwas sagen wie: „Lösch erst mal all diese Kommentare, bei einfachem Code ist das doppelt so viel unnötige Erklärung. Abstrahiere X nicht so, ich will stattdessen das hier ...“ Wenn ich Feedback gebe, springen die 2.000 Zeilen plötzlich auf 700 zusammen, und es ist extrem schwer, noch nachzuvollziehen, was passiert. Ich hasse auch die Vorstellung, dass die Codebase zu einem Haufen von Skripten wird, die ich nicht wirklich verstehe und die alle nach unterschiedlichen Mustern gebaut sind. Ich bräuchte eine AI, deren Stil und Denkweise meiner ähnlich sind, aber genau das ist so schwierig. Mit AI zu arbeiten fühlt sich an wie der erste Arbeitstag mit jemandem ohne Erfahrung. Für mich ist das weniger ein Problem von Überheblichkeit des Tools als vielmehr etwas, das den Designprozess sichtbarer gemacht hat. Ideal wäre ein Ablauf, bei dem ich zuerst ein Designdokument sehe wie: „Ich denke über diesen Ansatz nach und werde diese Funktionen, Klassen und diesen State auf diese Weise verwalten“, und wenn das passt, geht es erst danach an die Implementierung.

    • Wie bei menschlichen Engineers gilt auch hier: Eine Planning-Session am Anfang ist wirklich wichtig. Vor dem Coden erst diskutieren und die Details aushandeln. Ich stelle die erste Frage absichtlich möglichst vage, um zu sehen, ob unerwartete Empfehlungen kommen, und werde dann schrittweise konkreter. Wenn ich zufrieden bin, bitte ich das LLM, zwei Dokumente zu erstellen: initialprompt.txt und TODO.md. In initialprompt.txt stehen eine Projektzusammenfassung, die Anweisung, TODO.md zu lesen, und der Befehl, jeden Schritt nach Abschluss abzuhaken. So versteht das LLM sowohl das Gesamtziel als auch die Detailaufgaben und kann mich später, wenn wegen Context-Limits eine Unterhaltung abbricht und neu begonnen werden muss, schnell wieder in die Arbeit bringen.

    • Fühlt sich an, als hätte das genau meine Erfahrung zusammengefasst. Erfolgreich war AI-generierter Code bei mir nur dann, wenn wirklich nur das Endergebnis wichtig war und ich fast kein Fachwissen in dem Bereich hatte. Wenn ich eine starke Meinung dazu habe, was ein „gutes“ Ergebnis ist, lande ich am Ende meist frustriert dabei, das Projekt aufzugeben. Mit der Architect-Funktion von roo code erst den Ansatz zu strukturieren und dann im Code-Mode den eigentlichen Code zu implementieren, war halb Freude, halb Frust. Die wichtigste Lektion war: immer neue Tasks starten, keine langen Unterhaltungen weiterführen. Ich neige eigentlich dazu, Probleme klein zu schneiden und Ergebnisse zu prüfen, habe beim LLM aber eher den ganzen Problemraum auf einmal hineingeworfen und damit Schiffbruch erlitten. Ich habe viele Anläufe gebraucht, um meine Methode zu finden, und heute habe ich sogar in 30 Minuten ein App-Feature hinzugefügt. Wenn ich es selbst implementiert hätte, hätte das wirklich Tage gedauert. Und dass ich im Log tatsächlich nur 30 Minuten notiert habe, lag daran, dass ich genau wusste, was ich wollte, und mich der Prozess nicht interessierte. Diese Erfahrung hat mich aber auch zu dem Schluss gebracht, dass man Code, den irgendwann andere warten müssen, aus all diesen Gründen nicht einer AI überlassen kann.

    • Am Ende ist es einfach nur ermüdend und liefert unbefriedigende Ergebnisse. Das sage ich jemandem, der mit genau diesen Fragen ringt. Ich selbst war mit Agent Coding nur dann zufrieden, wenn es um kurzlebige Skripte ging, bei denen mir Codequalität egal war, oder um völlig folgenlose Leaf-Functions.

    • Der von Anthropic im Claude-Code-Leitfaden empfohlene Workflow ist durchaus zu empfehlen. Der Kern ist: „Lass das Modell zuerst den Code lesen, dann einen Änderungsplan erstellen und erst ganz am Ende ausführen.“ So kann man den Plan sehen und korrigieren, bevor die AI auch nur eine Zeile Code schreibt. Wenn ein Agent anders arbeitet, als du willst, etwa ohne Blueprint direkt losschreibt, dann sag einfach: „Mach es anders.“

    • Dieses Gerede davon, dass auf einmal 2.000 Zeilen Code erzeugt werden — da fragt man sich schon, ob man nicht gerade einen Prompt eingegeben hat wie „Pack das komplette Skyrim auf ein SNES“. Man kommt vom Mittagessen zurück, startet es und regt sich dann darüber auf, dass daraus ein Fallout im PS1-Stil mit nur Nahkampfangriffen geworden ist.

  • Wenn ein Beitrag auf die HN-Startseite kommt, habe ich immer Angst vor den Kommentaren — davor, wie dumm ich wohl wirke und ob Leute mich mit aggressiven Bemerkungen bloßstellen. Aber manchmal, wenn ich den Titel wirklich gut treffe, liest niemand den eigentlichen Text und alle reden nur über ihr eigenes Thema, und so entgehe ich dieser Art von Kritik.

    • Ich finde das eine amüsante und zugleich realistische Beobachtung. Dieses Muster sieht man auch in anderen Beiträgen oft. Trotzdem mag ich genau solche Diskussionen und habe Spaß daran.

    • Der Beitrag war gut. Hatte etwas von „wie man Pair Programming mit AI genießen kann“. War nützlich, also danke dafür.

  • Als ich LLM-Agenten zum ersten Mal benutzt habe, erwartete ich wechselseitige Kommunikation, echtes kollaboratives Pair Programming. Stattdessen hatte ich einen Partner, der alles vollständig auf seine eigene Weise lösen wollte. Als ich selbst ein wenig eingreifen wollte, zerfiel der vom AI geschriebenen Code zugrunde liegende Kontext, und es wurde eher noch unbequemer. Ich will echte Zusammenarbeit: ein bisschen ich, ein bisschen AI, abwechselnd.

    • Hast du es in letzter Zeit noch einmal probiert? Meine Erfahrung ist anders. Ich bearbeite den von der AI erzeugten Code und sage ihr dann, sie soll die Datei noch einmal lesen. Dann reagiert sie meist mit etwas wie „In der Datei gibt es Änderungen“. Wenn die AI Code ändert, lasse ich Tests laufen und gebe Feedback, und so verbessert sich das iterativ. Mit Zed und Claude Sonnet funktioniert das für mich gut.

    • Ich arbeite meistens so, dass ich mir erst den Vorschlag der AI ansehe und dann refaktoriere oder bei Bedarf noch einmal per Prompt nachsteuere. Dieser Ansatz erhöht die Accept Rate künstlich, und genau diese Statistik können AI-Unternehmen dann als Beleg dafür verwenden, dass „AI sehr guten Code schreibt“. Tatsächlich gab es viele Momente, in denen ich einfach dachte: „Ach komm, ich repariere das lieber selbst.“

    • Bei mir funktioniert es meistens gut, wenn ich dazuschreibe: „Lass uns zuerst nur diskutieren. Nimm keine Codeänderungen vor.“ Wenn wir ausreichend hin und her gesprochen haben, sage ich am Ende: „Wende es an.“

    • Wenn du eine bestimmte Form der Zusammenarbeit willst, dann fordere sie explizit vom LLM ein. Es hilft, ein paar Prompt-Dokumente bereitliegen zu haben, die du in jeder Unterhaltung wiederverwenden kannst.

    • In letzter Zeit ist es viel weniger schwierig, den Kontext beizubehalten, daher gibt es auch beim Ändern von Code weniger Probleme. Ich nutze nur den Ask-Modus, also Frage/Antwort statt Kommandos. In Claude Code verwende ich Opus, in Cursor o3 max. Den Agent-Modus meide ich absichtlich, weil ich wie im Originalbeitrag mit der Zeit immer weniger davon habe. Tab-Completion nutze ich nur selten, und 80 bis 90 % des vorgeschlagenen Codes ändere ich und tippe ich selbst. So kann ich weiter mit 170 WPM tippen. Die Ausgabegeschwindigkeit von Opus und o3 max ist begrenzt genug, dass auch das Lesen nicht überfordert. Am Anfang war es zu schnell, aber daran gewöhnt man sich rasch. Meine persönliche Einschätzung: Wenn GitHub Copilot dein gesamtes LLM-Erlebnis ist, dann ist das ungefähr wie ein Motel als Reiseerfahrung.

  • Auch Pair Programming ist nicht für jede Situation geeignet. Eigentlich ist es in vielen Fällen nicht geeignet. Ich habe das schon anderswo erwähnt, aber durch die Autocomplete-Vorschläge von LLMs wird mein konzentrierter Coding-Flow unterbrochen, weil ich ständig anhalten, lesen, prüfen und annehmen oder ablehnen muss. Das zerstört meinen Programmierfluss komplett. Ich habe wirklich damit gekämpft, AI-Autocomplete in meinen Workflow einzubauen.

    • Sehe ich genauso. Die Lösung ist, sowohl eine dedizierte IDE ohne AI als auch Cursor/VS Code zu verwenden und zwischen beiden zu wechseln. Echte Immersion/Deep Work ist unmöglich, wenn man gleichzeitig mit einem Chatbot spricht.

    • Ich habe mir vor Kurzem einen neuen Laptop gekauft und meine IDE neu installiert. Nach ein paar Stunden Coden hatte ich das Gefühl, irgendetwas sei „komisch“. Dann fiel mir auf, dass ich GitHub Copilot gar nicht eingeloggt hatte und gerade ohne AI arbeitete. Ich hatte das Gefühl, deutlich aktiver Code zu schreiben, statt auf Autocomplete zu warten. Besonders Cursor stört den Arbeitsfluss dauernd, und auch so etwas wie „Vorhersage bis zur nächsten Cursor-Position“ finde ich völlig unnötig. Künftig werde ich Copilot deaktiviert lassen und nur für Boilerplate oder repetitive Aufgaben Agent-Style-Tools wie aider verwenden.

    • AI-Autocomplete oder Codevorschläge sind besonders schlimm, wenn man stark typisierte Sprachen nutzt. Meistens sind sie nur zu 80 % korrekt, während die IDE-Autovervollständigung fast 100 % trifft. Der Agent-Ansatz ist besser, weil er 1) meinen Gedankenfluss nicht ständig unterbricht und 2) selbst kompilieren und testen kann, Fehler korrigiert und dann funktionierenden Code zurückliefert.

    • Ich dagegen liebe Autocomplete. Ich muss Go benutzen, und da gibt es so viel Boilerplate, dass sich manches nicht sinnvoll über zusätzliche Libraries lösen lässt und Selberschreiben oft schneller ist. Für lästigen Code bin ich mit den Händen schneller als mit AI, aber Autocomplete hilft trotzdem sehr. Vorschläge über eine einzelne Zeile lese ich sofort, und längere Vorschläge kann ich überfliegen, wenn sie dem ähneln, was ich ohnehin schreiben wollte. Mit der Zeit bekommt man ein Gefühl dafür, was die AI vorhersagen wird. Es ist kein gewaltiger Produktivitätsschub, aber Dinge wie Log-Meldungen oder for-Schleifen gehen klar schneller. Es hilft nur dort, wo ich schneller lese als tippe.

    • Pair Programming passt nicht immer, aber ich halte es in den meisten Situationen für nützlich. Wenn es nicht funktioniert, liegt es meist daran, dass eine oder beide Personen sich nicht wirklich darauf einlassen, dass eine Seite grundsätzlich blockiert nach dem Motto „so geht das nicht“ oder dass man die Pair-Programming-Prinzipien zu starr auslegt.

  • Meine Haltung dazu ist etwas kompliziert. Seit mindestens einem Monat versuche ich im Unternehmen aktiv, alle möglichen LLM-Tools zu nutzen und möglichst effektiv einzusetzen. Gemessen an der Zahl der geschriebenen Codezeilen steigt die Produktivität definitiv. Insgesamt würde ich aber nicht sagen, dass ich produktiver bin. Fast jede abgeschlossene Aufgabe bringt irgendwo unerklärliches Verhalten mit sich, oder es werden plötzlich auch irrelevante Bereiche angefasst, die ich dann wieder zurückrollen muss. AI-generierte Tests sehen anfangs plausibel aus, aber bei anderen Metriken wie Coverage sind die Schwächen offensichtlich. Um zum gewünschten Ergebnis zu kommen, fühlt es sich oft so an, als müsste ich mehrere Schritte rückwärtsgehen. Nicht wie ein Gewinn oder ein Lernprozess, sondern wie echter Rückschritt. Einmal wurden heimlich 50.000 Zeilen unnötiger Import-Code in ein Modul geschrieben, das überhaupt nicht Teil der Änderung war. In einem anderen Fall hatte ich die Regeln klar vorgegeben, und trotzdem wurde die gesamte objektorientierte Struktur zerstört und durch eine Menge if/else ersetzt. Das Problem ist, dass die Ergebnisse je nach Situation extrem schwanken: Selbst bei derselben Art von Aufgabe ist es manchmal perfekt und manchmal wird alles zerschossen. Ich habe viele Wege ausprobiert, Aufgaben zu formulieren und Anleitungen zu geben, aber weil das Verhalten selbst bei ähnlichen Aufgaben so unterschiedlich ist, bleibt die Qual, jede Änderung prüfen zu müssen. Selbst wenn der Code fast richtig ist, reicht es oft, um einen einzigen Teil anzupassen, und schon entgleist die ganze Arbeit. Meiner Erfahrung nach ist das für kleine Tools wirksam, aber bei mittelgroßen bis großen Codebases kann man keine konsistenten Ergebnisse erwarten.

  • LLM-Agenten reden zu viel und glauben immer, dass ihre Art die richtige ist. Sie sind nicht knapp, erklären Dinge, die in einer Zeile erledigt wären, in epischer Länge, versehen selbst kleine Änderungen mit langen Kommentaren, wollen mich belehren und kommen insgesamt viel zu stark rüber.

    • Manche Verhaltensweisen, die Leute hassen — etwa „zu lange Ausgaben, zu viele Kommentare usw.“ — könnten Nebenwirkungen davon sein, dass LLMs für Effizienz in anderen Bereichen optimiert wurden. Lange Ausgaben korrelieren eher mit nicht-faulem Code und guten Performance-Benchmark-Werten. Übermäßige Kommentare stärken auch den lokalen Kontext und hängen mit besserer Codequalität und weniger Fehlern im nächsten Schritt zusammen.

    • Ich habe gestern sonnet 4 benutzt, um genau einen einzelnen Konfigurationswert zu ändern, und es hat 15 Minuten damit verbracht, immer wieder zu testen und zu refaktorieren. Am Ende wurden unnötigerweise 40 Dateien geändert. Es wollte ständig einen nicht vorhandenen Debugger starten und immer wieder Webseiten öffnen, die eine Authentifizierung brauchen. Da merkt man, wie weit das noch von Perfektion entfernt ist.

  • Nach meiner Erfahrung ist das Problem nicht, dass es schnell ist, sondern eher, dass es zu langsam ist. Und zwar auf eine unangenehm uneindeutige Weise. Wäre es schneller, könnte man dem Code in Echtzeit folgen und damit arbeiten. Wäre es langsamer, könnte man in der Zeit etwas anderes tun und später zurückkommen. Stattdessen landet man bei Durchläufen von 50 Sekunden bis zu mehreren Minuten und kann sich auf nichts anderes wirklich konzentrieren. Ich denke, kleinere und schnellere Iterationen wären besser. Letztlich wäre ein Grad an Autonomie auf dem Niveau menschlicher Reviews sinnvoller, also unabhängige Arbeit wie beim Prüfen eines Merge Requests. Diese aktuelle Schleife aus Aufgabe geben, 1–3 Minuten warten, Ergebnis ansehen, Feedback geben und wiederholen ist für mich persönlich der schlimmste Fall.

    • Das erinnert mich an den Oatmeal-Comic über „langsames Internet vs. gar kein Internet“.

    • Wenn die Konzentration zerfällt, stell dir ein 30-Liter-Aquarium auf den Schreibtisch. Ein herrlich alberner Tipp zum Ins-Leere-Starren.

  • Als Entwickler nutze ich AI fast gar nicht, höchstens ab und zu einen Chatbot für nicht projektbezogene Fragen. Ich würde gern wissen, ob ihr AI auch in Kundenprojekten einsetzt oder nur in privaten Bastelprojekten. Falls in Kundenprojekten: Schreibt ihr in den Vertrag, dass der Code an eine AI übermittelt wird? Die meisten Kunden haben ja irgendeine Form von NDA, also eine Vereinbarung, nichts nach außen zu geben, und manche hatten bei mir sogar explizit Klauseln gegen AI-Nutzung. Mich würde interessieren, ob jemand Kunden erlebt hat, die Coding-Tools mit AI ausdrücklich erlauben.

    • Ich nutze es fast nur intern, und auch nur, weil es im Unternehmen klare Richtlinien zur AI-Nutzung gibt. Für meine privaten Arbeiten würde ich dafür kein Geld ausgeben, weil es sich für mich nicht wirklich nach Zeitersparnis anfühlt. In privaten Projekten ist mir außerdem der Spaß am Selberbauen wichtiger als nur das Ergebnis, und deshalb macht mir Direktbauen mehr Freude als Prompt-Arbeit.

    • Es gibt auch Kundenseite, die aktiv den Einsatz von AI verlangen. Sie erwarten bessere Qualität und schnellere Entwicklung — letztlich also geringere Kosten —, auch wenn die Realität diesen Erwartungen oft nicht entspricht. Das ist aber wieder ein anderes Thema.

    • Mit OpenAI/Anthropic teile ich nur Code, den ich auch einfach in ein öffentliches Websuchfeld kopieren könnte.

    • Ich teile gar nichts, auch keine internen Projekte. Code nach außen zu geben ist bei mir grundsätzlich etwas, das nur gegen Bezahlung passiert. Ich arbeite außerdem mit personenbezogenen Daten, und wenn Code bei US-Unternehmen landet, ist das rechtliche Risiko viel zu hoch.

  • Endlich spricht es mal jemand klar aus. AI ist im Design übermäßig selbstsicher und entscheidet Details der Implementierung einfach eigenmächtig, statt sie abzustimmen. Selbst Mocking-APIs bringen sie oft dazu, die Struktur zu missachten, sodass Nacharbeit unvermeidlich ist. Ich wünschte, das Verhalten von LLMs wäre kooperativer und würde bei fehlenden Details sofort nachfragen. Man kann nicht alle Informationen schon im ersten Prompt unterbringen, und zusätzliche Prompts zerstören oft den Kontext und den Gedankengang des ursprünglichen Designs. Vielleicht benutze ich es falsch, vielleicht gibt es einen besseren Weg — ich würde das gern lernen. Ich hoffe, LLMs verbessern sich dahin gehend, Feedback schrittweise aufzunehmen und umzusetzen. Vielleicht ist schon das Hinzufügen oder Aktualisieren von Kontext ein besonders schwieriges Problem, aber ich will weiter dazulernen.

    • Die meisten Tech-Stacks unterstützen inzwischen irgendeine Form von „Design-/Planning“-Session, und das auszuprobieren hilft oft schon. Ein Workflow, der für mich gut funktioniert, ist, mit etwas zu beginnen wie: „Ich möchte auf Basis von @file, @docs und @examples in @path _ bearbeiten, unter Bezug auf @module_requirements.md — lass uns vor der eigentlichen Implementierung alles besprechen, was dafür nötig ist.“ Dann diskutiert man vor und zurück, bis Einigkeit besteht, und speichert das Ergebnis entweder in einer .md-Datei oder geht direkt weiter mit „Jetzt setz es um“. Wenn man sich solche Workflows in .rules- oder .md-Dateien oder als IDE-Snippets ablegt, kann man sie bei neuen Aufgaben immer wieder nutzen. Man sollte aber bedenken, dass aktuelle LLMs viel mehr Kontext brauchen und dass man für jede Codebase, also jedes Projekt, unterschiedliche Abläufe ausprobieren muss, weil auch die Ergebnisse unterschiedlich ausfallen.

    • Ich habe auch das Gefühl, dass die AI verwirrter wird, je mehr Informationen dazukommen. Wahrscheinlich gibt es Wege, das zu überwinden. Für das Herausziehen sehr kleiner Informationsschnipsel sind diese Systeme großartig, aber es ist schade, dass sich die gesamte Branche nur auf Chatbot-Modelle einschießt. Man fragt sich, wie es wäre, wenn wir nie Tastaturen, Mäuse, GUIs oder Touchscreens entwickelt hätten.

  • Dieser kollaborative Stil, AI als Assistenten zu verwenden, ist meiner Meinung nach die richtige Art, AI einzusetzen, und der Trend, AI direkt Code schreiben zu lassen, ist eher ein Beispiel dafür, wie die Softwarebranche in die falsche Richtung läuft. Ich lasse AI nie Code schreiben. Ich nutze sie, um meinen Code kritisieren zu lassen oder Strategien für die Struktur größerer Codebasen zu entwickeln. So etwas wie ein Strategieberater also: Wenn man den Kontext für das LLM gut aufbaut, kann man exzellente Orientierung bekommen. Die Verantwortung liegt aber immer bei mir — ich verstehe und setze um, und der AI gebe ich grundsätzlich nie mehr Verantwortung als die eines Beraters. Ich sehe AI als „Idiot Savant“ und finde, dass man entsprechend vorsichtig mit ihr umgehen sollte.