KI wird eure Prozesse vermutlich nicht schneller machen

• Im Zuge der Prozessoptimierung verbreiten sich unrealistische Erwartungen an KI, doch allein durch die Einführung von KI verbessert sich die Bearbeitungsgeschwindigkeit nicht
• Der wahre Grund dafür, dass Softwareentwicklung lange dauert, ist nicht die Geschwindigkeit des Codens, sondern der Prozess, vage Anforderungen in eine klare Problemdefinition zu überführen
• Auch KI-gestützte Codegenerierung steht vor demselben Upstream-Problem; für präzise Ergebnisse ist eine intensive Einbindung von Domain- und Produktexperten unerlässlich
• In Vergleichsbeispielen zum KI-Einsatz wird der tatsächliche Handholding-Prozess oft ausgelassen, obwohl gerade er den realen Produktivitätsunterschied ausmacht; auch menschliche Entwickler würden mit denselben detaillierten Dokumenten deutlich produktiver werden
• Um Prozesse wirklich zu beschleunigen, muss nach der Lehre von The Goal zuerst sichergestellt werden, „den Engpass mit vorhersehbaren, qualitativ hochwertigen Eingaben zu versorgen“

---

Prozessoptimierung in der Marktflaute und KI-Erwartungen

• Wenn der Markt schwächelt, konzentrieren sich die meisten Organisationen zumindest teilweise auf Prozessoptimierung; zuletzt kommt dabei noch der Faktor KI mit unrealistischen Erwartungen hinzu
• The Toyota Way und The Goal erinnern daran, dass man leicht missversteht, worauf sich viele Prozessoptimierungen eigentlich konzentrieren sollten
  • Ein Abschnitt, der lange dauert, kann ein Signal sein, dort mit Verbesserungen zu beginnen, aber er ist nicht zwangsläufig der Ort, an dem das eigentliche Problem entsteht
  • Wenn man einfach mehr Menschen einsetzt oder erwartet, dass KI die Geschwindigkeit massiv erhöht, übersieht man, warum die Arbeit überhaupt verzögert wird
  • Wer Prozesse beschleunigen will, sollte zuerst prüfen, ob die Ausführenden tatsächlich über die Eingaben und Voraussetzungen verfügen, um ihre Arbeit beginnen und abschließen zu können

Der visuelle Engpass

• Anhand eines Gantt-Diagramm-Beispiels lässt sich visuell erkennen, dass Softwareentwicklung die Phase ist, die am längsten dauert
  • Eigentlich wäre BPMN üblicher, zur leichteren Erklärung wird hier aber ein Gantt-Diagramm verwendet
• Wenn das Ziel darin besteht, den Projekt-Throughput zu verbessern, ist es grundsätzlich richtig, zuerst die längste Phase zu betrachten
• Das Problem liegt darin, wie Menschen versuchen, das zu lösen
  • Mehr Personal auf das Problem werfen (throw people at the problem)
  • Annehmen, dass KI alles viel schneller machen wird
• Was dabei fehlt, ist die Frage „Warum dauert diese Phase so lange?“; noch wichtiger ist: Dass etwas lange dauert, bedeutet nicht automatisch, dass dort die Ursache des Problems liegt

Probleme Upstream lösen

• Das Beispiel bezieht sich auf Softwareentwicklung, lässt sich aber genauso auf jeden Prozess anwenden, der länger dauert als gewünscht
• Softwareentwicklung wird nicht dadurch schneller, dass man einfach die Tippgeschwindigkeit erhöht; wenn das so wäre, würden alle nur Schreibkurse besuchen
• Im Kern geht es in der Softwareentwicklung darum, ein Problem in eine Lösung zu übersetzen, die ein Computer automatisch bearbeiten kann, möglichst sicher und skalierbar
• Dafür braucht es ein ganzheitliches Verständnis des Problems
  • In eher wasserfallartigen Vorgehensweisen braucht man Feature- oder Scope-Dokumente
  • In agilen Vorgehensweisen kontinuierliche Iteration mit Domain-Experten
• Der Teil, der Entwicklung in der Praxis verlangsamt, ist der Prozess herauszufinden, was eine vage Feature-Anfrage, die nur aus einem Titel besteht, eigentlich bedeutet
• Auch die Anforderung „send mail to user once sale is completed“ ist keine sofort umsetzbare Spezifikation
  • Man kann zwar eine E-Mail verschicken, aber was genau soll darin stehen?
  • Wenn es im Verkaufsprozess ein Problem gab, sollte dann eine Fehler-E-Mail gesendet werden?
  • Wann genau gilt ein Verkauf als „abgeschlossen“?

Die Behauptung, man könne einfach alles der KI überlassen

• Oft hört man das Argument, man könne die Entwicklungsphase mit KI-Codegenerierung umgehen und Softwareentwickler würden nur noch die Rolle von Projektmanagern übernehmen
• Viele erwarten, dass die bisher lange Phase der Softwareentwicklung durch eine etwa dreitägige KI-Entwicklungsphase ersetzt wird
• Menschen haben zwar eine Vorstellung davon, wie das Ergebnis von KI-Entwicklung aussehen soll, doch in der Praxis funktioniert es nicht so; man stößt auf exakt dieselben Upstream-Themen
• Dass KI Code schnell erzeugen kann, stimmt (ob das etwas Gutes ist, ist eine andere Debatte), aber schnelle Generierung ist nicht gleich korrekte Codegenerierung
• Was in Vergleichen zwischen menschlicher und KI-gestützter Entwicklung fast immer ignoriert wird, ist der Handholding-Prozess, der nötig ist, damit KI überhaupt richtig funktioniert
• Dieses Vorgehen kann zwar schneller sein als die bisherige Arbeitsweise, aber es ist kein fairer Vergleich
• Damit KI-Entwicklung funktioniert, braucht es eine wesentlich tiefere Beteiligung von Domain- und Produktexperten
  • Jede Funktion muss bis in kleinste Details beschrieben werden
  • Auch für jeden Bugfix muss das gewünschte Ergebnis detailliert festgehalten werden
• Genau das fordern Softwareentwickler seit Beginn ihres Berufs: eine detaillierte Beschreibung des Problems und des gewünschten Endergebnisses
• Würde man menschlichen Entwicklern denselben Umfang an Feature-/Scope-Dokumenten geben, würde auch ihre Produktivität stark steigen

Wie man Prozesse tatsächlich beschleunigt

• Wer Prozesse beschleunigen will, muss sicherstellen, dass die beteiligten Personen wirklich über alle Mittel verfügen, um ihre Arbeit zu erledigen
• Wenn ein juristischer Freigabeprozess langsam ist, sollte man zuerst prüfen, was benötigt wird, um diesen Freigabeprozess überhaupt zu starten
  • Wenn wegen unvollständiger Unterlagen fünf Personen hinterhergelaufen werden muss, wird der Prozess nicht schneller, nur weil man der Abteilung mehr Juristen zuweist
• Eine der großen Lehren aus The Goal ist, dass Engpässe vorhersehbare und qualitativ hochwertige Eingaben erhalten müssen
  • „bottlenecks should receive predictable, high-quality inputs“
• Der erste Ausgangspunkt für Prozessautomatisierung sollte daher nicht der Engpass selbst sein, sondern die Verbesserung der Eingangsqualität und Vorhersehbarkeit dessen, was am Engpass ankommt

[GN⁺]

Hacker-News-Kommentare

• Man sagt zwar oft, worauf Softwareentwicklung von Anfang an gewartet habe, sei „eine detaillierte Beschreibung des Problems und des gewünschten Ergebnisses“, aber genau das ist in Wahrheit Software Engineering.
  Auch 2026 sollte man die Vorstellung aufgeben, man könne mit nur ausreichend detaillierten Anforderungen und Spezifikationen in einem Zug eine perfekte Lösung bauen.
  Meiner Erfahrung nach kann man dank AI Features und Ideen sehr viel schneller iterieren, und die Reibung entsteht inzwischen meist bei Abstimmung und Koordination mit anderen Teams.
  Wenn man Prozesse beschleunigen will, muss man meiner Ansicht nach die Koordinationskosten senken und Einzelpersonen wie Teams mehr Entscheidungs- und Umsetzungsspielraum geben.

  • Auch 2026 sollte man die Vorstellung aufgeben, dass man selbst mit ausreichend detaillierten Anforderungen überhaupt in einem Zug eine funktionierende Lösung bauen kann.
    Selbst Anthropic konnte trotz perfekter Spezifikation, Referenzimplementierung und Tausender über Jahre von Menschen geschriebener Tests nicht einmal etwas so Einfaches wie einen funktionierenden C-Compiler bauen.
    Die aktuellen Modelle reichen selbst bei perfekter Spezifikation und perfekten Tests nicht aus, um ohne sorgfältige menschliche Aufsicht nichttriviale produktive Software zu erstellen.
    Ohne perfekte Spezifikation und ein von Menschen direkt geschriebenes perfektes Testpaket wird es noch schwerer, vielleicht klappt es eher 2027.
  • Stimme nicht zu.
    Ich bekomme oft Aufgaben, die sich Produktverantwortliche am Nachmittag ausdenken, und sie denken dabei nur an den Happy Path, manchmal nicht einmal vollständig.
    Wir sind ein globales Unternehmen und müssen Vorschriften und Gesetze in jedem Land einhalten, aber nachdem ein Feature implementiert wurde, heißt es dann: „Eigentlich dürfen wir das in 90 % unserer Märkte rechtlich gar nicht tun“, und dann wird wieder eine Deaktivierungsfunktion drangehängt.
    Danach kommt zurück: „In einigen dieser Märkte geht es doch, wenn man ein regulatorisches Verfahren durchläuft, also bitte so umsetzen.“
    Weil die Deadline unmittelbar bevorsteht, muss man die Lösung am Ende zusammenhacken.
    Das ist kein Software Engineering und hat auch mit der Software selbst nichts zu tun.
    Die Aufgabe von Softwareingenieuren ist es, eine Liste von Anforderungen zu bekommen und einen Weg zu finden, diese zu erfüllen, und Anforderungserhebung ist kein Problem des Software Engineerings.
    Software ist Implementierung, Produkt ist Verhalten, und das Verhalten dessen, was gebaut werden soll, muss bekannt sein, bevor man ernsthaft baut.
    Hätte jemand die Sache nur um eine Woche verschoben und sauber geprüft, hätte man eine Architektur entwerfen können, die skalierbar, leicht erweiterbar, wartbar und für die Zukunft deutlich angenehmer gewesen wäre.
  • Stimme vollkommen zu.
    Ich schreibe seit über 40 Jahren Programme, aber ich habe noch nie erlebt, dass man erst die Spezifikation fertigstellt und dann die Software schreibt und alles gut ausgeht.
    Der schwierigste Teil bei nichttrivialer Ingenieursarbeit ist das Problem zu verstehen, und frühe Versionen von Software sind der Weg dorthin.
    Deshalb glaube ich nicht, dass eine AI-basierte „Softwarefabrik“ jemals wirklich gut funktionieren wird.
    Am Ende wäre das wieder Wasserfallentwicklung: Architekten zeichnen UML-Diagramme und geben einem Team von Programmierern im Wesentlichen simple Implementierungsarbeit, die dann aber am Ende das Falsche umsetzt.
    AI ist sehr gut darin, schnell von einer falschen ersten Version zu einer weniger falschen zweiten Version zu kommen.
    Man darf nur nicht vergessen, dass die eigentliche Kernaufgabe darin besteht, das zu lösende Problem zu verstehen.
  • Ich bin ins Engineering gegangen, weil ich es mag, den besten Weg zu finden, mit unklaren Anforderungen umzugehen.
    Wenn ich nur detaillierte Spezifikationen bekommen würde, wäre ich bloß ein Coding-Roboter, und solche Arbeit gebe ich Juniors.
  • Ich sehe im Alltag inzwischen auch, dass Entscheider oder Leute, die Anforderungen schreiben, anfangen, AI zu nutzen.
    Wie früher ist es meine Aufgabe, diese Anforderungen zu lesen, zu verstehen und gegen die Realität abzugleichen, die ich kenne.
    Beim Code genauso.
    Seit mindestens 20 Jahren lautet der Kern des Software Engineerings Vertrau niemandem, und das hat sich nicht geändert und kostet weiterhin viel Zeit und Aufwand.

• Als LLMs neu waren, dachten die Leute wohl, man müsse nur so etwas sagen wie „Mach mir einen Facebook-Klon“.
  Inzwischen wird klar, dass man Anforderungen präziser schreiben und besser definieren muss.
  Das war schon immer der Engpass in Software.
  Früher habe ich tatsächlich Anforderungen wie „Hol die Daten und gib sie dem Benutzer“ bekommen.
  Es war nicht definiert, welche Daten, wo sie gespeichert sind oder in welchem Format sie zurückgegeben werden sollen, sodass ich viel Zeit mit Produktverantwortlichen verbringen musste, um herauszufinden, was eigentlich gewollt war.
  Für gute Ergebnisse mit LLMs braucht man etwas Ähnliches, und vage Anforderungen erzeugen vage Ergebnisse.

  • Soweit ich es gesehen habe, sind Tickets von PMs viel detaillierter geworden, weil sie mit AI arbeiten, die ans Codebase angebunden ist, etwa Claude Code oder Codex.
    Sie füllen Templates aus, warum ein Problem existiert, zum Beispiel dass im Backend Feld X vorhanden ist, im Frontend aber nicht, wo und wie die Daten geholt werden sollen und welche Akzeptanzkriterien gelten.
    Früher hätten sie das aus Bequemlichkeit oder mit der Haltung „Die Entwickler finden das schon heraus“ nicht gemacht.
    Danach können Entwickler den Inhalt dieses Jira-Tickets in den LLM-Agenten ihrer Wahl kopieren oder den LLM ihn per Atlassian MCP automatisch lesen lassen.
    Das hat den Entwicklern sehr geholfen, und die Anforderungen sind dadurch viel klarer geworden.
    Ehrlich gesagt wirkt es schon nach diesem ersten Schritt so, als wären PMs bei der Umsetzung eines Features bereits zur Hälfte angekommen, sodass in Zukunft womöglich PMs alles selbst machen und einige Entwickler eher als SDET übrigbleiben, statt als vollwertige Implementierer.
  • Das hat Fred Brooks in seinem klassischen Essay No Silver Bullet von 1986 in den Abschnitten „Expert Systems“ und „Automatic Programming“ in weiten Teilen vorhergesagt.
    Dort beschreibt er die wesentlichen Merkmale von Vibe Coding und die Erfahrung, die wir heute machen, erstaunlich präzise.
    Nach frühen Erfolgen in einigen sorgfältig ausgewählten Bereichen zeigt sich beim Ausweiten über diese Bereiche hinaus eine vernünftige, aber nicht revolutionäre Produktivitätssteigerung.
    https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
  • Vollkommen richtig, und ich hielt das immer für selbstverständlich.
    Ich habe nie Prompts verwendet, die in Richtung „Mach mir einen Facebook-Klon“ gehen, sondern stattdessen beschrieben, wie etwas funktionieren soll.
    Zum Beispiel habe ich um ein Python-Skript gebeten, das /etc/hosts liest, bestimmte Host-Werte aus einer .conf findet, jede Konfiguration benennt, die aktuelle Umgebung erkennt, rechts oben im Standard-GNOME von Ubuntu 22 ein Icon erstellt und beim Klicken die Konfigurationsnamen auflistet und bei Auswahl /etc/hosts sichert und nur bestimmte Hostnamen-Zeilen ändert.
    Damit bekam ich fast auf Anhieb einen einfachen GNOME-App-Indicator zum Umschalten der Umgebung, der nach nur ein paar korrigierten Zeilen größtenteils funktionierte.
    Wenn man dem LLM eine ordentliche Spezifikation gibt, baut es gut, und selbst wenn man zur Beschreibung des Gewünschten ein erfundenes DSL bastelt, versteht es das problemlos.
  • Jetzt versuchen Produktverantwortliche, ihre eigene Arbeit an LLMs abzuschieben.
    Dass der frühere Prozess nicht funktionierte, lag daran, dass die Leute, die die Anforderungen schrieben, die geschäftliche Absicht nicht verstanden oder nachlässig waren und deshalb vage oder schlechte Anforderungen formulierten.
    LLMs machen aus denselben vagen oder schlechten Anforderungen nur etwas, das plausibel aussieht, aber beim tieferen Hinsehen kommen die Probleme zum Vorschein.
  • Noch schlimmer ist, dass ein menschliches Softwareteam bei vagen Anforderungen zumindest in einer gut funktionierenden Organisation zusätzliche Spezifikation verlangt.
    Dann kommen Fragen wie: „Was genau bedeutet es, die Daten zu holen?“
    Ein LLM sagt einfach: „Klar! Hier ist der vollständige Code, der die Daten holt und dem Benutzer gibt“, und das war’s.

• Dieser Beitrag setzt voraus, dass AI nur die Entwicklungsphase beeinflusst, aber das stimmt eindeutig nicht.
  Sie kann alle Phasen beschleunigen, einschließlich Ideengenerierung, Rechtsabteilung, Dokumentation, Entwicklung und Deployment.
  Bei der Ideengenerierung kann man Ideen hin- und herspielen, mit Wissensbeständen abgleichen und Designdokumente erstellen, bei der Dokumentation große Teile der Dokumente generieren.
  Entwicklung sowieso, und beim Deployment kann sie Deployment-Manifeste, Testwerkzeuge und Wissen zu Cloud-Plattformen erzeugen.
  Jede Phase kann mit AI besser und schneller werden, vielleicht nicht alles, aber vieles.
  Auch in der Entwicklung gibt es einerseits den Teil, in dem man das Problem besser als alle anderen versteht und die Lösung entwirft, andererseits aber rein mechanische Fleißarbeit.
  Wenn man weiß, dass ein Button X tun soll, dann ist es Fleißarbeit, den Button zu gestalten und zu platzieren, an Hover- und Press-Zustände sowie Ausnahmen zu denken und ihn ans Backend anzubinden, und dasselbe Prinzip gilt in fast allen Phasen.

  • Ich stimme dem Beitrag im Großen und Ganzen zu.
    Wenn man ein neues wichtiges Feature hinzufügen will, verbringt man meist Tage, Wochen oder Monate in Meetings mit den Fachbereichen, um zu verstehen, wie Arbeit zwischen System X, Y und Z fließt und welche Sonderfälle wichtig sind.
    Zum Beispiel wird Teilmenge A so behandelt und B anders, aber im letzten Schritt werden beide Gruppen zusammengeführt, außer dass C den Spezialprozess 97 braucht.
    Auf Basis dieses Verständnisses folgt dann der Entwurf einer Systemlösung über mehrere Systeme hinweg, mit einer Mischung aus internen und Vendor-Systemen, deren unterschiedliche Anpassbarkeit die endgültige Form der Lösung in verschiedene Richtungen drückt.
    Es ist eindeutig wertvoll, das Codieren zu beschleunigen, aber das ist nur ein Teil des Puzzles, und aktuelle LLMs helfen nicht dabei, Domänenwissen zu sammeln und die Lösung zu definieren.
  • Unsere Erfahrung in der Organisation passt ebenfalls dazu.
    Es gibt noch einen Punkt: Jetzt können Menschen in mehr Rollen Software-Tools bauen, um Probleme zu lösen, die früher mit rein physischen Prozessen und viel manueller Arbeit bewältigt wurden.
    Wir sind ein kleiner Hersteller, also kein riesiges Unternehmensprojekt, das tiefgehende Software-Engineering-Erfahrung erfordert, aber einfache Software-Tools verbessern an allen Ecken Prozesse und Produktivität.
    Wenn der Versandverantwortliche plötzlich ein Problem mit einem maßgeschneiderten Tool lösen kann, das früher viele Arbeitsstunden verschlungen hat, dann ist das wirklich erstaunlich.
  • Dieser Beitrag ist fast genau das, was bei uns im Unternehmen tatsächlich passiert.
    Wir nutzen AI stark in der Softwareentwicklung, bringen aber nicht schneller etwas auf den Markt, vielleicht sogar langsamer, aus ähnlichen oder anderen Gründen.
    Es fühlt sich seltsam so an, als würde man auf eine Utopie warten, die nie kommt, und zugleich ist schwer genau zu benennen, wo das Problem liegt.
  • Wer AI effektiv nutzt, ist niemandem gegenüber verpflichtet, das zu beweisen.
    Im Gegenteil schaffen genau solche Meinungsverschiedenheiten und dieses Misstrauen Chancen und Ausbruchspunkte im Markt.
  • Die Leute verstehen am Ende nicht, dass das alles nur Zahlen sind.
    Wenn der durchschnittliche IQ der Projektbeteiligten 140 ist, dann kann eine AI mit IQ 150 jede einzelne Person in der Pipeline duplizieren.
    Wer sagt, AI könne dies oder jenes nicht, muss akzeptieren, dass diese IQ-Lücke monoton wächst.

• Einerseits ist dieser Beitrag ein sauberer Text, der genau beschreibt, was viele Leute in großen Organisationen bei technischer Arbeit denken und in der Praxis sehen.
  Ich stimme dem Autor zu 110 % zu und wünschte, mehr Leute würden verstehen, was hier gesagt wird.
  Andererseits habe ich das Gefühl, solche Dinge in letzter Zeit schon Dutzende Male besprochen zu haben, sowohl auf HN als auch im echten Berufsalltag.
  Führungskräfte haben soziale und finanzielle Anreize, so zu tun, als würde AI wirklich beschleunigen, daher wird ein einzelner Blogpost sie nicht überzeugen.
  Deshalb bleibt mir nur, darauf zu warten, dass ihre AI-Projekte scheitern oder genauso langsam laufen wie die bisherigen Projekte, und zu hoffen, dass sie etwas daraus lernen.

  • Traurig, aber wahrscheinlich richtig.
    Ich zögere sogar, solche Beiträge im Unternehmen zu teilen, weil sich alles, was nicht zum Status quo passt, schlecht angenommen anfühlt.
  • Jedes Mal, wenn solche Texte im Unternehmen diskutiert werden, läuft es letztlich darauf hinaus, dass das Risiko, zurückzufallen, größer sei, wenn andere schneller neue Features veröffentlichen oder übernehmen können, genauer gesagt: FOMO.
  • Stimme nicht zu.
    Visualisierungen und Gantt-Charts sind genau die PM-Sprache, die PMs verstehen können.
    Solange C-Level und Investoren weiter Innovationssignale senden, wird das nicht sofort gelöst, aber auch so etwas hält nicht ewig.
  • Ich habe den Luxus, meine Hypothek abbezahlt zu haben, sodass ich bei der Arbeit eine Weile etwas wählerischer sein kann.
    Deshalb verbringe ich meine Zeit gerade mit Gartenarbeit und damit, mich bei persönlichen Coding-Projekten auf agentische Tools einzuschießen.
    Ich baue zum Beispiel von Grund auf eine Hochleistungs-OLTP-Datenbank, eine neue logisch-relationale Persistenz-Programmierumgebung, einen ungewöhnlichen mathematisch basierten Synthesizer und einen FPGA-Softprozessor.
    Ganz normale Dinge, die ganz normale Menschen eben so machen.
    Deshalb weiß ich, was diese Tools in den Händen einer einzelnen Person leisten können, und das ist wirklich erstaunlich.
    Aber wenn ich von Freunden in Unternehmen höre, dass minimale Token-Quoten festgelegt oder „Star-AI-Coder“-Leaderboards eingeführt werden und man sagt „Kein Code Review“ und „Nicht von Hand coden“, dann schüttele ich den Kopf.
    Ich habe im Winter ein wenig Vertragsarbeit gemacht, das war okay, aber während der Gründer jedes Wochenende per Vibe Coding ein ganz neues Projekt baute, degenerierte Code Review zu einer Art Duell zwischen LLMs.
    Diese Tools taugen nicht besonders für Teamarbeit oder echtes Software Engineering im Team.
    Ich werde mich wohl zurücklehnen und warten, bis sich die Branche sortiert hat.
    Orte, an denen man gut arbeiten kann, werden wohl nur die sein, an denen jemand sagen kann: „Mach langsam!“, und an denen es ältere, kluge Menschen gibt, die es sich leisten können, das auch wirklich zu sagen.
    In der Zwischenzeit verkaufe ich in Hamilton, Ontario Bündel frisch geschnittenen Rhabarbers für 5 Dollar.
    Spargel habe ich auch, und zwar jede Menge.

• Es gibt eine interessante Zweischneidigkeit.
  Bei Dingen, die ich ohnehin schon gut kann, haben LLMs relativ wenig Einfluss, aber bei Dingen, die ich nicht kann, sind sie ein massiver Game Changer.
  Große Unternehmen können die meisten für ein Projekt nötigen Rollen einstellen, daher ist der Gesamteffekt dort relativ klein.
  Im besten Fall kann eine Person die Arbeit von fünf Leuten halbwegs erledigen und so Personalkosten sparen, um im Gegenzug ein schlechteres Produkt zu bekommen.
  Wie die Kombination aus kurzfristigem Gewinn und langfristigen Kosten ausgeht, ist absehbar.
  Für kleine Studios oder Solo-Entwickler sind LLMs dagegen eine große Veränderung.
  Die Arbeit von fünf Leuten auch nur mittelmäßig zu erledigen, ist ein viel größerer Sprung, als ohne diese Rollen auszukommen oder auf Third-Party-Assets oder andere Inhalte angewiesen zu sein oder, schlimmer noch, improvisiert etwas Schreckliches zusammenzubauen.
  Man muss sich nur die UI fast aller Programme ansehen, die offensichtlich von einem Programmierer ohne Designer platziert wurde.
  Oder Fälle, in denen jemand etwas von Dribbble kopieren will, aber nicht die Fähigkeiten dafür hat.
  Mit AI kann man plötzlich alles und jeden plausibel kopieren, und ehrlich gesagt ist das fast die gesamte Funktionsweise von AI.

  • Bei der Aussage „Bei Dingen, die ich schon gut kann, haben LLMs relativ wenig Einfluss, bei Dingen, die ich nicht kann, sind sie ein riesiger Wandel“ frage ich mich, ob das nicht ein Fall des Gell-Mann-Amnesie-Effekts ist.
    Das klingt wie die Lehrbuchdefinition.
    Für mich persönlich ist es genau umgekehrt.
    LLMs helfen mir nur dann, wenn ich bereits genau weiß, was ich tue.

• Die Leute verstehen nicht gut genug, dass nichttriviale Softwareentwicklung nicht einmal zu 50 % aus Codieren besteht.
  Die Coding-Phase ist normalerweise der einfachere Teil und wird Juniors übertragen.
  In großen Organisationen zieht sich die Mehrzahl der Produktänderungen durch mehrere Systeme und die Arbeit vieler Menschen.
  Seniors und Midlevels verbringen ihre Zeit meist damit, lokale Prioritäten in einer bestehenden kybernetischen Entität neu anzuordnen und sich die Zustimmung anderer Teams zu dieser neuen Vision zu holen, die jeweils ihre eigenen Prioritäten haben.
  Dabei entstehen natürlich viele Trade-offs und viel Politik.
  Senior Engineers kämpfen hart dagegen, ihren verantworteten Systemen zusätzliches „Gewicht“ aufzubürden, Scope Creep zuzulassen oder von der vorgesehenen Entwicklungsrichtung abzuweichen.
  Deshalb braucht es Kompromisse oder Eskalationen an das Management, um Prioritäten festzulegen.
  Vielleicht kann AI auch das lösen, aber das ist eine sehr viel schwierigere Aufgabe.

  • Dass LLMs fast nur Code-Schreiber gewesen seien, stimmte vielleicht vor einem Jahr, heute aber nicht mehr.
    Inzwischen sind sie Tool Caller, also können Coding-Agenten Linting, Type-Checks und Tests ausführen und deren Fehler beheben, sich in Observability-Plattformen wie Sentry eingraben, um Root Causes zu finden, Benchmarks laufen lassen, langsamen Code oder Hot Paths identifizieren und Migrationsdokumentation zu neuen Major-Versionen der verwendeten Libraries lesen und anwenden, um Systeme aktuell zu halten.
    Wenn solche Dinge nicht so gebaut sind, dass sie dem Agenten Gegendruck geben und ihn das System besser verstehen lassen, bleibt er eben nur ein dummer LLM-Code-Schreiber.
    Aber bei Modellen und Harnesses, die sich schnell verbessern, ist klar, dass das deutlich weiter gehen kann.

• Der Beitrag liegt größtenteils richtig und gibt einen Hinweis darauf, worauf man sich konzentrieren sollte, wenn AI Prozesse tatsächlich beschleunigen soll.
  Ein Produktmanager sagte zum Beispiel, er stelle sich eine Zukunft vor, in der ein Meeting mit Stakeholdern als gescheitert gilt, wenn am Ende kein interaktiver Prototyp herauskommt, und ich finde, die Richtung stimmt.
  Eine weitere Vorhersage ist, dass Vibe Coding zu „Excel 2.0“ wird.
  Es macht interaktive Apps weitgehend zum Self-Service, woraufhin IT in einen Dauerkrieg gerät, sie in etwas mit besseren Sicherheitsgarantien, angemessener Zugriffskontrolle und Protokollierung, Skalierbarkeit, Change Management usw. zu überführen.
  Historisch betrachtet erzeugt jeder revolutionäre Umbruch anfangs Dampfpferde.
  Als die Dampfmaschine erfunden wurde, stellten sich die Leute die Zukunft des Transports als pferdeähnliche Objekte vor, die per Dampf angetrieben werden und bestehende Wagen ziehen.
  Erst später lernten wir, die Funktion von Transport von seiner Form zu trennen.
  Ursprünglich habe ich bei MOOCs von Dampfpferden gesprochen, denn MOOCs waren eine klassische Dampfpferd-Idee.

  • Wenn die Idee ist, dass ein Stakeholder-Meeting ohne interaktiven Prototyp am Ende als gescheitert gilt, dann sollte man einfach Balsamiq lernen.
    Man braucht keinen Code, um einen Prototypen zu bauen.
    So wie man für das Einfangen einer Szene nicht zwingend Schauspieler und Kamera braucht, sondern ein paar Skizzen reichen.

• Das gezeigte Gantt ist ein Beispiel für ein Wasserfallmodell oder eine andere Methodik, die davon ausgeht, dass Software ein endgültiges Ziel hat.
  99,999 % der heutigen Software werden nicht so gebaut.
  Moderne Softwareentwicklung hat kein Ziel.
  Alle zwei Wochen ändert das Business, was die Software tun soll.
  Es kommen ständig neue Features, neue Integrationen, geänderte Features, aktualisierte oder ersetzte Komponenten, größere Skalierung und anderes Hosting hinzu.
  Nach ein paar Jahren ist die Software grundlegend verwandelt, und Qualität und Tests fliegen aus dem Fenster.
  Dann folgt nicht nur die Arbeit, Änderungen provisorisch unterzubringen, sondern die ständige Qual, gegen Entropie zu kämpfen.
  Software wird zu einem lebenden Wesen, das verletzt wird, dessen Lebensweise sich ändert und das altert.
  Das Unternehmen wird zum Pfleger eines Monsters, wie ein Tierpfleger, der ein depressives Tier am Leben zu halten versucht.
  Menschen sind Gewohnheitstiere, deshalb werden mit AI dieselben Probleme auftreten.
  Nur wird alles ein wenig schneller und Code Review kann den Code vielleicht ein wenig besser machen.
  Gleichzeitig machen das Fehlen guter Tests und der Wunsch nach schnellerem Deployment alles ein wenig schlechter.
  Das Ergebnis dieses Ziehens und Drückens ist Software von fast gleicher Qualität, die sich aber etwas schneller bewegt.
  Am Ende wird es also schnellere Prozesse geben, aber der Rest bleibt Qual, sodass es kaum jemand wirklich spürt.
  Wahrscheinlich brennen einfach alle schneller aus.
  Komplexität hat Gründe, und ohne diese Gründe zu beseitigen, kann man die Komplexität nicht beseitigen.
  Mit Tools kann man keine Business-Probleme lösen.

• Zu der Aussage „AI kann Code schnell erzeugen, aber das heißt nicht, dass sie den richtigen Code erzeugt“ würde ich sagen: In der Praxis ist der Code fast immer korrekt.
  Was mir nicht gefällt, ist meist die Art, wie der Code hinzugefügt wird.
  Wenn man das Codebase gut genug kennt, gibt es Rituale dafür, wo etwas eingefügt werden sollte, wie etwas benannt wird und wie viele Kommentare wo hingehören.
  Wenn ein Agent das nicht richtig hinbekommt, nervt mich das, und selbst wenn es in AGENTS.md steht, scheint er daran zu scheitern.
  Die Behauptung „Wenn man menschlichen Entwicklern die gleiche Menge an Feature- und Scope-Dokumentation gäbe, würde ihre Produktivität explodieren“ halte ich trotz fast 20 Jahren in der IT für etwas, das niemals passieren kann.
  Und selbst wenn, dann so selten, dass es keine Diskussion wert ist.

  • Meiner Erfahrung nach passiert das völlig regelmäßig.
    Man muss nur den Aufwand vergleichen, ein bereits geschriebenes System zu reproduzieren, mit dem Aufwand, dieses System von Grund auf neu zu bauen.
  • „Der Code ist fast immer korrekt“ deckt sich nicht mit meiner Erfahrung.
    Besonders bei Bugs oder Performance-Problemen halluziniert er oft und stellt ohne enge Führung Fehldiagnosen.
    Wenn man aber darauf achtet, was er tut, und ihn in die richtige Richtung schiebt, ist er bei Root-Cause-Analyse und Analyse allgemein gut und kann die Effizienz steigern.
    Menschen haben im Vergleich zu Maschinen Grenzen darin, wie schnell sie Informationen aufnehmen und analysieren können, und dadurch gibt es meiner Ansicht nach auch eine Obergrenze für Produktivitätsgewinne.

• AI muss Prozesse nicht umgehen, kann sie aber trotzdem beschleunigen.
  Sie kann bei Refactoring, Boilerplate, dem Aufspüren bisher unentdeckter Fehler und Dingen helfen, die Linter nicht erfassen.
  Viele Kommentare wirken so, als würden sie keine standardmäßig bekannten Prozesse verwenden oder annehmen, dass man diese Standards mit AI nicht mehr befolgen müsse.
  Ob man mehr Code und Features ausliefern kann? Mit guten Anforderungen und ausreichenden Tests natürlich ja.
  Jeder von AI geschriebene Code muss reviewt und getestet werden und in getrennte Commits und Pull Requests aufgeteilt sein.
  Wer PRs mit Tausenden Zeilen einreicht, ist ein Warnsignal.
  Ohne AI würde man das auch nicht tun, also warum sollte man es mit AI tun?
  Der bekannte Ausnahmefall sind groß angelegte Rewrites oder Refactorings, aber selbst dann sollte es umschaltbare Einzel-Commits geben, damit man den Änderungsprozess sehen und bessere Entscheidungen treffen kann.
  Wenn mir jemand einen gigantischen One-Shot-Commit oder PR zeigt, würde ich ihn ablehnen.
  Es muss in Stücke zerlegt werden, die ein normaler Entwickler vernünftig prüfen kann.