KI nutzen oder nicht?

 (antropia.studio)
5 Punkte von GN⁺ 2025-10-01 | 2 Kommentare | Auf WhatsApp teilen
  • Es wurde ein zweiwöchiges Experiment durchgeführt, bei dem eine App ausschließlich mit einem KI-gestützten Entwicklungs-Workflow gebaut werden sollte, das jedoch nicht so zufriedenstellend ausfiel wie erwartet
  • Mit einem Stack auf Basis von Claude Code und Remix wurde der Prozess Issue-Definition → Umsetzung durch die KI → Code-Review → Deployment wiederholt durchlaufen
  • Dabei nahmen jedoch fehlender Kontext, duplizierter, nicht wiederverwendbarer Code, unterbrochene Abläufe, Halluzinationen und das Pareto-Prinzip als Problem zunehmend frustrierende Ausmaße an
  • Nach zwei Wochen wurde die KI-zentrierte Entwicklung schließlich aufgegeben, man kehrte zur bisherigen Arbeitsweise zurück und war mit dem Aufräumen des Codes und der Qualitätsverbesserung zufriedener
  • Aktuell wird KI nur noch in begrenzten Einsatzbereichen wie Suche, Rubber-Ducking, Code-Snippets, Tests und sprachlicher Korrektur genutzt; eine Ausweitung ist erst bei grundlegenden technologischen Veränderungen geplant

Überblick über das Experiment

  • Es wurde ein zweiwöchiges App-Entwicklungsexperiment durchgeführt, bei dem ein aktuell stark beachteter Entwicklungs-Workflow mit LLMs (Large Language Models) direkt angewendet wurde
  • Auf Basis der komplexen UI-Erfahrung von Facebook-Ads-Konten wurde mit der Entwicklung eines Prototyps namens adbrew begonnen, einem vereinfachten Tool zur Anzeigenverwaltung, das ausschließlich die Facebook Ads API nutzt
  • Das Experiment wurde mit dem Ziel durchgeführt, das Potenzial von KI zu prüfen und zugleich die Hoffnung auf eine Lösung realer Probleme zu testen

Vorgehensweise

  • Verschiedene KI-bezogene Accounts wurden verfolgt, Workflows untersucht und Remix/React Router v7 als Tech-Stack ausgewählt
  • Nach dem Abschluss eines Claude Code-Abos wurde Zeit in das anfängliche Setup investiert, darunter Prompts, DX-Tools und die Definition von Issues
  • Tägliche Routine
    • Issue definieren
    • Die KI um eine Implementierung bitten
    • Anforderungen mit der KI abstimmen
    • Den erzeugten Code im Detail prüfen
    • Code committen/deployen
    • Prozess wiederholen
    • Richtlinien und automatische Prüffiles regelmäßig verbessern
  • Es wurde fortlaufend versucht, den Entwicklungsfluss an die Arbeitsweise der KI anzupassen

Wiederkehrende Probleme

  1. Es fehlt ständig an Kontext
    • Selbst bei viel bereitgestelltem Kontext forderte die KI kaum Rückmeldungen zu den Anforderungen an
    • Die KI arbeitete mit willkürlichen Annahmen weiter, was häufig zu fehlerhaften Implementierungen führte
  2. Code ist weder wiederverwendbar noch wartbar
    • Schwächen bei Abstraktion und der Erstellung wiederverwendbarer Komponenten
    • Bereits vorhandene Komponenten wurden wiederholt neu erzeugt, was die Review-Müdigkeit erhöhte
    • Die Wirkung zusätzlicher Richtlinien blieb gering
  3. Unterbrochener Arbeitsfluss
    • Während der KI-Arbeit war fortlaufendes Monitoring nötig
    • Es war schwer, pro Issue konzentrierte, effiziente Arbeitszeit zu sichern, was zu Produktivitätsverlusten führte
  4. Halluzinationen
    • In Kombination mit der komplexen Facebook-API, lückenhafter Dokumentation und fehlerhaft getyptem SDK verschärfte die falsche Sicherheit der KI die Verwirrung
    • Zu diversen Frameworks und Bibliotheken wurden wiederholt falsche Informationen erzeugt
  5. Verschärfung des Pareto-Effekts
    • Zwar konnte die KI 80 % der Gesamtarbeit schnell erledigen, doch für die verbleibenden 20 % der finalen Fertigstellung und Korrekturen waren 80 % des Aufwands nötig
    • Vor allem bei Edge Cases und Wechselwirkungen zwischen Funktionen traten viele wesentliche Defekte und Bugs auf

Ergebnis und Rückblick

  • Nach zwei Wochen war der Code zunehmend chaotisch und kaum noch kontrollierbar
  • Wegen des Verlusts an Freude am Entwickeln und anhaltender Qualitätsprobleme wurde zum bisherigen Workflow zurückgekehrt
  • Beim erneuten manuellen Aufräumen des Codes wurden Punkte entdeckt, die die KI im Review übersehen hatte; dadurch entstand letztlich eine bessere Codebasis

Aktuelle Nutzung von KI

  • Leistungsstarke Suchmaschine: effizient für die Recherche komplexer Informationen und kontextbezogene Antworten; bei Fehlschlägen ist ein schneller Wechsel zur bisherigen Methode möglich
  • Rubber Ducking (Ideen-Brainstorming): besonders effektiv für Alternativvorschläge, breitere Exploration und die Suche nach relevanten Keywords
  • Code-Snippet-Assistent: reduziert Entwicklungsaufwand durch die Automatisierung repetitiver Utility-Funktionen
  • Unterstützung bei Testcode: KI wird genutzt, um neue testbezogene Szenarien zu finden
  • Sprachbezogene Aufgaben: nützlich für die Bearbeitung von Commit-Messages, Issues, PRs und anderen Texten
    • In letzter Zeit hat sich die Struktur sogar umgekehrt: Statt dass die KI schreibt, prüft sie nun verfasste Texte der Entwickler

Fazit und Ausblick

  • Für die Unterstützung im Tagesgeschäft wird KI weiter genutzt, einer Ausweitung zur Delegation des gesamten Entwicklungsprozesses steht man derzeit jedoch skeptisch gegenüber
  • Es wird versucht, lokale LLMs bevorzugt zu nutzen und die Datenkontrolle zu behalten
  • Künftige technologische Veränderungen werden weiter beobachtet; vorerst soll der Einsatz von KI jedoch bewusst begrenzt bleiben

Verwandte Beiträge

2 Kommentare

 
shakespeares 2025-10-06

Das ist ein Nachteil, den ich bei komplexen Aufgaben sehr oft spüre.
Der Spaß geht verloren + der Code wird chaotisch..
Oft wirkt es wirklich so, als wäre es außer für Code-Refactoring und zum Sammeln von Ideen nicht besonders geeignet.
 
GN⁺ 2025-10-01
Hacker-News-Meinung

  • Ich habe kürzlich über eine Stunde lang versucht, ChatGPT nach einem sehr einfachen rsync-Befehl zu fragen, aber es hat mir immer wieder Befehlsparameter gegeben, die mit der rsync-Version auf meinem Mac nicht funktionieren. Etwa die Hälfte der Fehlschläge bestand aus völlig unsinnigem Troubleshooting, und beim Rest behauptete es, seinen Fehler „erkannt“ zu haben, lieferte dann aber wieder die falsche Antwort für eine andere Version. Ich habe ausdrücklich angewiesen, die Parameter gegen meine vorhandene Version zu validieren, aber das wurde offensichtlich nicht richtig umgesetzt. Eigentlich wäre das allein in fünf Minuten erledigt gewesen, aber ich habe dieser faszinierenden Technologie dabei zugesehen, wie sie meine Zeit verschwendet. Ich bin kein professioneller Entwickler, frage mich aber, ob solche Erfahrungen unter Entwicklern ebenfalls häufig sind. Vermutlich tritt das Problem weniger auf, wenn man für Software-Versionen codiert, die gut zum Haupt-Trainingsdatensatz des LLM passen, und ich frage mich, ob es Prompts gibt, mit denen sich das vermeiden lässt. Im Moment fällt es mir schwer zu glauben, dass LLMs bei Programmierarbeit wirklich Zeit sparen — eher verschwenden sie durch ihre eigentümliche Art noch mehr davon.

    • Selbst wenn ich ein LLM bitte, die Parameter für meine Version zu validieren, macht es das nicht zuverlässig. Mich würde dazu die Einschätzung von AI-Experten interessieren. Ich erlebe das auch oft. Letztlich versteht ein LLM nicht wirklich, was ich sage; mathematisch lässt sich auch erklären, warum das so ist. Gleichzeitig scheint aber, als seien in Aufgaben, die nicht so peinlich scheitern wie das Zählen von Buchstaben, Techniken wie Transformer oder zusätzliche Tricks im Spiel. Ich frage mich, ob ich etwas übersehe.

    • Solche Erfahrungen sind auch unter Entwicklern sehr verbreitet. Vielleicht sagt jemand: „Mir ist das noch nie passiert“, aber das sind nur sehr seltene Ausnahmen, und die meisten Leute beschweren sich über Ähnliches. Du hast auch gefragt, ob man das per Prompt vermeiden kann — wenn es nicht in den Trainingsdaten enthalten ist, bringt das überhaupt nichts. In vielen Sprachen sind LLMs wirklich miserabel. Bei CLI-Tools ist es oft so, dass sie einem selbst dann weiter GNU-Flags geben, wenn man ihnen sagt, dass es sich um macOS oder eine BSD-Version handelt. Gerade bei macOS hat sich rsync kürzlich geändert, daher gibt es online auch nicht viele Informationen dazu. Siehe dazu Beitrag zum rsync-Austausch. Und schon die Annahme, LLMs würden beim Coden Zeit sparen, ist ein Best-Case-Szenario. Viel häufiger vertrauen Leute LLM-Code blind und committen ihn, wodurch Bugs oder Sicherheitslücken entstehen. Siehe auch ai-coding-slowdown Blog und arXiv-Paper

    • Ob man das per Prompt vermeiden kann, weiß ich nicht genau, aber in Claude Code kann man Befehle direkt ausführen. Statt das LLM also einfach irgendetwas halluzinieren zu lassen, kann man echte Ausgaben wie ! man rsync oder ! rsync --help als Kontext hinzufügen.

    • Ich frage mich, warum man überhaupt ein LLM benutzt, wenn man gezielt das Handbuch für ein bestimmtes Tool nachschlagen will.

    • Zu dem Punkt, dass du über eine Stunde lang versucht hast, mit ChatGPT einen einfachen rsync-Befehl zu bekommen: Ich würde es ein paar Mal versuchen und dabei ausreichend Umgebungsinformationen und Fehlermeldungen ergänzen. Wenn es dann immer noch nicht klappt, würde ich andere Modelle wie Claude oder Gemini ausprobieren. Wenn es nach einer vorher festgelegten Zahl von Versuchen nicht gelöst ist, dann wird das LLM wahrscheinlich nicht helfen, und es ist viel schneller, wieder auf klassische Wege wie Handbücher oder Foren zurückzugreifen. Realistisch sind meist 10–20 Minuten, bevor man weiterzieht. Es gibt Probleme, die ein LLM auch bei beliebig langer Beschäftigung nicht lösen kann; es dreht sich dann einfach nur im Kreis.

  • Ich habe solche Erfahrungen ebenfalls oft gemacht. Wirklich hilfreich ist AI für mich dann, wenn ich ihr Arbeiten gebe, die ich ohnehin schon selbst beherrsche. Wenn ich das Problem präzise genug beschreiben kann, damit das LLM es versteht, liefert es brauchbare Ergebnisse, und ich kann den ausgegebenen Code sofort prüfen und erkennen, ob er das Gewünschte tut. Wenn ich ihm etwas völlig Unbekanntes überlasse, wird es eher noch komplizierter.

    • Ich halte diesen Beitrag (abgesehen vom Titel) für ziemlich ausgewogen. „Überlass einfach alles dem LLM!“ ist voller Probleme, während „man kann ihm ruhig repetitive Boilerplate oder Teile von Testcode zur Zeitersparnis überlassen, aber AI funktioniert mal gut und mal nicht“ vernünftig klingt — nur würde so ein gewöhnlicher Titel natürlich niemals Klicks bekommen.

    • AI fühlt sich eher wie ein Praktikant an als wie ein externer Auftragnehmer.

  • Mit der Aussage „Kontextinformationen reichen nicht aus“ kann ich mich sehr identifizieren. Egal wie viel Kontext wir eingeben, AI fragt meistens nicht nach Feedback, sondern rät einfach drauflos und scheitert dann. Ich muss dabei an eine Szene aus einer TV-Show denken, in der jemand einem Dschinn einen Wunsch äußert und dann wie ein Anwalt jedes Detail absichert. Mit LLMs zu sprechen fühlt sich ganz ähnlich an.

    • AI ist wie dieser eine unglaublich kluge Kollege, der einem aber niemals sagt, was wirklich in seinem Kopf vorgeht. Es wirkt, als könnte er alles, aber Teamarbeit klappt nicht, und so etwas wie „Ich verstehe nicht, was du hier willst, erklär es bitte etwas genauer“ kommt von AI praktisch nie.

    • (Ich glaube, ich weiß, welche TV-Szene du meinst.) Dort wurde das Problem am Ende zwar gelöst, aber ich habe nicht den Eindruck, dass LLMs irgendein Bedürfnis verspüren, ihre „Versprechen“ einzuhalten. Ein Dschinn ist eher mit einer klassischen Sci-Fi-AI vergleichbar, die streng an Vorschriften und Regeln gebunden ist. LLMs sind völlig anders.

  • Ich mag vibe coding als Kommunikation mit AI weniger als tatsächliches Programmieren. Stattdessen habe ich vor allem meinen Entwicklungsprozess früher und stärker strukturiert. Ich schreibe zuerst eine Spezifikationsdatei und lasse das LLM auf Basis der Codebasis und von Online-Informationen die Anforderungen präzisieren und die Implementierungsschritte in eine schrittweise Checkliste zerlegen. Erst wenn ein Schritt abgeschlossen ist, gehe ich in die nächste Session und erhöhe so nach und nach den Fertigstellungsgrad. Wenn mich die Gespräche mit AI ermüden, kann ich oder jemand aus dem Team auch einfach direkt gemäß Spezifikation implementieren — das ist ein flexibler Einsatz.

  • In einem aktuellen Projekt habe ich AI Coding eingeführt. Ich weiß nicht genau, was mit vibe coding gemeint ist, aber mein Ansatz war eine entspannte, iterative Interaktion. Ich habe Gemini AI Studio verwendet und war mit dem Ergebnis sehr zufrieden, so sehr, dass ich den gesamten Prozess dokumentiert und als Open-Source-Projekt veröffentlicht habe. Für meine Produktivität war das ein spürbarer Boost. Mein einziger Kritikpunkt war, dass die AI übertrieben höflich formuliert. Meiner Ansicht nach ist der ROI von AI am höchsten, wenn klar ist, welches Ergebnis ich will, und wenn unterwegs Optionen gegeneinander abgewogen werden müssen. Ich habe sie für sämtliche Projektergebnisse eingesetzt — Kerncode, Testfälle, Build-Skripte, Dokumentation, Beispiel-App und Utilities. Das vollständige Entwicklungsprotokoll gibt es hier, den Projektquellcode hier.

  • Ich nutze AI auf ähnliche Weise. Von AI revolutionäre Abstraktionen zu erwarten, ist zu viel verlangt. Auf den völlig gewöhnlichen Pfaden, die schon Tausende Entwickler vor einem gegangen sind, funktioniert sie gut. In diesem Sinn ist sie einem sehr leistungsfähigen Suchsystem ziemlich ähnlich.

    • Ich finde, ChatGPT ist im Grunde die Suchmaschine, die Google eigentlich selbst hätte bauen sollen. Meiner Meinung nach hat Google das hinausgezögert, weil das dem bestehenden Geschäft geschadet hätte.

  • Meine bevorzugte Vorgehensweise ist, mir vom LLM kurz eine erste Lösung oder ein Codebeispiel geben zu lassen und danach ohne ständiges Nachschärfen der Prompts einfach selbst weiterzuarbeiten. Am Ende lasse ich bei Bedarf das LLM meinen Code noch einmal prüfen. Der größte Vorteil daran ist, dass man die Schleife des Prompt-Feintunings überspringt. Diese Schleife ist wirklich ermüdend, frisst enorm viel Zeit und kann langfristig die Arbeitseffizienz sogar verschlechtern.

  • Dass AI einfach weitermacht, ohne Feedback einzuholen oder klärende Fragen zu stellen, ist wirklich frustrierend.

  • Unser Team sagt: „Im aktuellen Zustand nutzen wir AI nur bis zu genau diesem Punkt; wenn sich die Technologie grundlegend verändert, bewerten wir die Lage neu.“ Ich frage mich, ob LLMs darüber hinaus überhaupt mehr leisten können. Schon jetzt halte ich sie bei richtiger Nutzung für sehr nützlich.

    • Ich verstehe die Zweifel nicht, ob LLMs noch mehr leisten können. Mir fallen jeden Tag mehrere neue Ideen ein, wie man LLM-basierte Tools verbessern könnte, und die meisten davon sind bloße Ingenieursarbeit, die ich theoretisch selbst umsetzen könnte. Selbst wenn Gott das weitere Training der eigentlichen LLM-Modelle verbieten würde, bin ich überzeugt, dass sich über Jahrzehnte hinweg noch Produktivitätssteigerungen um ein Vielfaches allein durch agentische Wrapper oder bessere Pipelines herausholen ließen — vorausgesetzt, sie werden mit soliden Softwareentwicklungs- und QA-Prozessen kombiniert.

  • AI zur Optimierung von Facebook Ads einzusetzen, ist wie die Breakers aus der Dark-Tower-Reihe.