KI baut dir kein funktionierendes Produkt – das bleibt weiterhin deine Aufgabe

• KI kann in wenigen Minuten einen Prototyp mit UI und Datenbank erstellen, verkürzt aber nicht den Weg von der ersten lauffähigen Version zu einem produktionsreifen Produkt
• In echten Produkten bleiben Probleme wie Skalierbarkeit, Fehlerbehandlung, Observability, Sicherheit, Authentifizierung und Datenstrukturen, die statt bloßer Syntax technisches Urteilsvermögen erfordern
• Der Wert der Informatik liegt weniger in der Codeproduktion als in mentalen Modellen, mit denen man versteht, wie Systeme funktionieren und warum sie scheitern; nur so lassen sich ineffiziente Queries oder Race Conditions erkennen
• Die Nachfrage nach mechanischem Übertragen von Anforderungen in Code sinkt, doch erfahrene Engineers können repetitive Arbeit an KI abgeben und sich auf Probleme konzentrieren, die Expertise erfordern – und dadurch deutlich schneller arbeiten
• Wer KI als Ersatz für Verständnis nutzt, wird defekte Systeme nur schwer reparieren, erweitern oder übergeben können; daher sollte man zuerst die Grundlagen lernen und danach KI-Tools einsetzen

---

Die Lücke zwischen Prototyp und Produkt

• Wenn man eine Idee in natürlicher Sprache beschreibt, kann man innerhalb weniger Minuten einen lauffähigen Prototyp erhalten, der eine UI und eine Datenbank hat und die beabsichtigte Funktion ausführt
• Ein Prototyp, der auf dem Laptop läuft, kann in einer realen Umgebung jedoch zahlreiche Probleme offenbaren
  • Er hält Last nicht stand und hat keine angemessene Fehlerbehandlung
  • API-Tokens können geleakt werden
  • Ein Datenmodell für die Demo kann zusammenbrechen, sobald ein zweiter Nutzer hinzukommt
  • Die Authentifizierung beruht auf ungeprüften Annahmen, und die Sicherheit ist unklar
• In der Deployment-Phase zeigt sich die große Produktionslücke zwischen „es funktioniert“ und „es ist bereit“

Die schwierige Arbeit kam schon immer nach dem Schreiben des Codes

• Software Engineers konnten auch früher schon Dinge schnell zum Laufen bringen; der wirklich zeitaufwendige Teil kam danach
  • Systeme entwerfen, die auch bei wachsender Größe standhalten
  • Ausnahmen behandeln, wenn Nutzer unerwartete Wege nehmen
  • Observability aufbauen, damit man Ausfälle erkennen kann
  • Entscheidungen zur Datenarchitektur treffen, die in drei Jahren weniger Reue verursachen
• KI hat die Zeit bis zur ersten lauffähigen Version stark verkürzt, aber nicht den Weg von dieser Version zu einem produktionsreifen System
• Der schnelle Ablauf aus Prompt, Antwort und sichtbarem Ergebnis vermittelt den Eindruck, auch der restliche Entwicklungsprozess sei komprimiert worden; doch die schwierigen Probleme der Software lagen nie primär im Schreiben von Syntax
• Urteilsvermögen darüber, was gebaut und wie es strukturiert wird, was man aufschiebt und wann man Nein sagt, trennt Prototypen von Produktionssystemen

Warum Informatik weiterhin notwendig ist

• Mit dem einfachen Zugang zu KI-generiertem Code fragen sich immer mehr Neueinsteiger, ob sie wirklich jahrelang Algorithmen, Datenstrukturen, Betriebssysteme und Theorie lernen müssen
• Der Wert einer Informatikausbildung liegt nicht nur in der Fähigkeit, Code zu schreiben; sie bildet mentale Modelle, um zu verstehen, wie Systeme funktionieren, scheitern und warum bestimmte Ergebnisse entstehen
• Diese Grundlage ist nötig, um potenzielle Fehler in von KI generiertem Code zu erkennen
  • Eine Query, die auf einer Tabelle mit 50 Millionen Zeilen einen Full Table Scan auslöst
  • Eine Cache-Strategie, die unter gleichzeitiger Last Race Conditions erzeugt
  • Eine Architektur, die aktuelle Anforderungen löst, das nächste Problem aber deutlich schwieriger macht
• Ohne Grundlagenwissen hängt man vollständig vom Urteil des Modells ab
  • Das Modell erzeugt nicht auf Basis von Urteilsvermögen, sondern von Pattern Matching aktiv Code, den es für passend zur Absicht hält
  • Der generierte Code kann korrekt und idiomatisch wirken und dennoch in Produktion scheitern
  • Wenn das Wissen fehlt, das Problem zu erkennen, kann die Diagnose Tage dauern
• Gerade jetzt, da die Distanz zwischen Verständnis und Ergebnis kleiner geworden ist, ist ein guter Zeitpunkt, Informatik zu lernen; wer verteilte Systeme wirklich versteht, kann sie in deutlich kürzerer Zeit bauen als noch vor zehn Jahren

Automatisierte Arbeit und wachsende Produktivität

• Die Nachfrage nach mechanischen Coding-Aufgaben, bei denen Anforderungen Zeile für Zeile in Implementierung übersetzt werden, sinkt tatsächlich; dieser Bereich wird automatisiert
• Das untere Ende der Produktivitätsverteilung wird komprimiert, während die Obergrenze steigt
  • Erfahrene Engineers, die moderne KI-Tools nutzen, können in einem Tempo arbeiten, das vor fünf Jahren kaum vorstellbar war
  • Nicht, weil die schwierigen Probleme verschwunden wären, sondern weil ein Großteil der mechanischen Arbeit erledigt wird, die Zeit und Aufmerksamkeit gebunden hat
  • Die dadurch gewonnene Zeit kann für Aufgaben genutzt werden, die echte Expertise erfordern
• Zurückfallen werden nicht Engineers, die nicht wissen, wie man KI nutzt, sondern diejenigen, die KI als Ersatz für Verständnis verwenden
  • Sie bauen per Vibe Coding Systeme, über die sie nicht schlussfolgern können
  • Sie können Ausfälle nicht beheben oder gewachsene Systeme nicht skalieren
  • Sie können Wartungsverantwortlichen nicht erklären, was sie gebaut haben

Auf einer höheren Abstraktionsebene arbeiten

• Die notwendige Veränderung besteht nicht nur darin, neue Tools einzuführen, sondern auf einer höheren Abstraktionsebene zu arbeiten und dabei in den Grundlagen verwurzelt zu bleiben
• Engineers, die KI nicht als Ersatz für tiefes Wissen, sondern als Verstärker nutzen, können ihren Kolleginnen und Kollegen schnell voraus sein
  • Sie verstehen, was sie das Modell generieren lassen
  • Sie prüfen generierten Code kritisch, so wie sie den Pull Request eines Junior Engineers prüfen würden
  • Sie sprechen nicht nur über Funktionsbeschreibungen, sondern aus architektonischer Perspektive mit dem Modell
  • Sie beurteilen, wann sie einem Vorschlag des Modells widersprechen sollten
• Dabei wird keine neue Fähigkeit an die Stelle bestehender Skills gesetzt; vielmehr werden bestehende Skills auf eine neue Umgebung angewendet, um deutlich mehr Leverage zu erzielen
• Auch nach dem Prototyp ist echtes technisches Urteilsvermögen nötig; diese Fähigkeit unterscheidet Entwickler, die verlässliche Software ausliefern, von solchen, die nur Demos veröffentlichen
• Die Lernreihenfolge sollte lauten: erst Grundlagenwissen, dann KI-Tools

[GN⁺]

Hacker-News-Kommentare

• Ich bin dabei, in meinem Side-Project den in den letzten Monaten mit LLM erzeugten Code wegzuwerfen. Obwohl ich die Design-Spezifikation sorgfältig geschrieben und im bestehenden Codebestand gearbeitet habe, ist daraus insgesamt ein komplexiver Klumpen geworden, bei dem einzelne Änderungen logisch wirken, aber vieles subtil nicht zusammenpasst
  Bei Berichten oder Papers wirkt auch jeder Abschnitt für sich plausibel, aber das Gesamtdokument fühlt sich seltsam an. Menschen scheinen, auch wenn sie bei Detailarbeit langsamer sind, noch immer zu übergeordnetem Schlussfolgern fähig zu sein, das LLMs derzeit nicht leisten. Wenn man auf Mängel hinweist, sagen sie „absolut richtig“, finden sie bei eigener Prüfung aber nicht selbst
  Einfache CRUD-Apps mit gängigen JS-Frameworks, Tailwind und ORM lassen sich sicher bauen, aber schon früher konnte man SaaS-Templates kaufen, und gut gemachtes handgeschriebenes Boilerplate ist wahrscheinlich besser als das Ergebnis von Vibe Coding

  • Ich nutze immer mehr LLM-gestützte Programmierung statt vollständig autonomem Programmieren. Modelle wie Opus ändern Dinge eher so lange, bis das Ziel erreicht ist, statt gutes Design zu verstehen, und hinterlassen oft Code, den Menschen aufräumen müssen, sowie übermäßige Recherchearbeit
    Auch in PRs anderer sehe ich oft, dass Prompt-Probleme oberflächlich gelöst werden, die Implementierung aber langfristig schwer wartbar ist. Deshalb entscheide ich Implementierungsschritte und Design selbst und arbeite schrittweise mit kleinen Open-Source-Modellen oder Claude 4.5·4.6. API-Erkundung und Boilerplate-Schreiben gehen dadurch um ein Vielfaches schneller als von Hand, ohne dass mein Wissen verkümmert oder der Codebestand ruiniert wird
  • Ich habe oft in komplexen, überdesignten Lösungen festgesteckt und erst nach einem Spaziergang oder anderer Arbeit die einfache Lösung erkannt. LLMs erledigen alles sofort und nehmen einem die Zeit, nachzudenken, Sackgassen zu erkennen oder Konflikte mit der nächsten Aufgabe zu bedenken
  • Auch bei meinem Side-Project ist es inzwischen schwierig geworden, den Code vollständig zu verstehen und sicher selbst zu ändern, aber ich glaube, das ist nicht länger nötig. Ich habe fast 20 Jahre lang schönen Code geschrieben und möchte mich jetzt auf Produktivität und Ergebnisse konzentrieren; solange Codex Spaghetti-Code versteht, ist das für persönliche Projekte oder kleine Indie-Studios okay
    AI ist eine neue zusätzliche Schicht im Tech-Stack, so wie Hochsprachen über Maschinensprache liegen, also muss man loslassen
  • Der eigentliche Wert lag eher im Lernen auf dem Weg dorthin als im Code selbst. Beim Sich-abmühen entdeckt man immer wieder die tatsächlichen Anforderungen und technischen Hürden, aber AI überspringt diesen Prozess und lässt es so aussehen, als sei das Ziel oberflächlich erreicht worden
    Das heißt nicht, dass AI nutzlos ist, sondern dass man Anforderungen und Endvalidierung gründlicher durchdenken und weniger darauf vertrauen sollte, dass der Prozess automatisch ein wertvolles Ergebnis garantiert
  • In einem neuen Familien-Kalenderprojekt nutze ich die Geschwindigkeit von AI, um Probleme der User Experience auszufeilen. Ich baue Funktionen, nutze sie einige Tage selbst und wiederhole dann den Prozess, Dinge zu beheben, die mir nicht gefallen, mit dem Ziel, die v1-Funktionen fertigzustellen
    Farben oder weitschweifige und unnötig überladene Business-Logik gefallen mir zwar nicht, aber im Moment ist wichtig, ob wir als Ehepaar es tatsächlich nützlich verwenden, und das Ergebnis ist positiv. Danach will ich das UI nach meinem Geschmack neu gestalten, die Backend-Anforderungen festlegen und es dann von Grund auf neu schreiben, damit Wartung und Erweiterung leichtfallen
    Die Claude-Familie ist hervorragend für Prototyping und das Entdecken von Anforderungen und erleichtert anschließend den Prozess, es richtig neu zu bauen

• Ein einfacher Prüfmaßstab ist, ob man in den letzten 12·24·36 Monaten tatsächlich großartige neue Produkte oder große Verbesserungen bestehender Produkte gesehen hat. Das einzige großartige neue Produkt, das ich genutzt habe, sind meine bevorzugten LLMs, und diese Labs stellen im Gegenteil sogar mehr Leute ein
  Wenn es in 12 Monaten immer noch keine Verbesserungen gibt, wird dann wohl erneut behauptet werden: „Erst im Februar 2027 wurden LLMs gut genug, deshalb kann man es noch nicht beurteilen“

  • Ein guter Maßstab ist auch, ob die Web- und VS-Code-Version von Claude Code immer noch voller Bugs ist. Fast jede wiederholte Agent-Ausführung bricht kaputt und erfordert ein erzwungenes Neuladen, und manchmal behebt nicht einmal das das Problem. Anthropic hat praktisch unbegrenztes LLM-Budget und auch unveröffentlichte Modelle
  • Ich bin kein Verfechter eines allmächtigen LLM, nutze es aber kontrolliert, und die jüngsten automatischen Schwachstellenfunde sind eine interessante Entwicklung. Chrome hat allein im Juni mehr Bugs behoben als in den vergangenen zwei Jahren
    https://news.ycombinator.com/item?id=49120097
    Auch die neuesten Apple-Sicherheitsupdates und die Android-Sicherheitsmitteilungen vom Juni beheben eine enorme Zahl an Schwachstellen. Viele davon entstanden in unsicheren Sprachen wie C/C++, aber LLMs sind stark bei klar definierten Transformationsaufgaben mit wenig Spielraum für Abweichungen und deshalb auch nützlich, um auf sichere Sprachen wie Rust zu portieren
  • Die Geschwindigkeit beim Ausliefern von Projekten ist ähnlich wie früher, aber dank AI-Tools sind die Ergebnisse viel ausgereifter und funktionsreicher. Früher habe ich mit nur funktionierendem Happy Path ausgeliefert, jetzt kann ich Kündigung, Kontoexport, Datenschutzrichtlinie sowie komplette Mobile- und Web-Apps ohne großen Aufwand mitliefern
  • Schon wenn man nur einige Entwickler-Communities betrachtet, hat sich die Zahl neuer Produkte verdreifacht, seit diese Tools aufgetaucht sind. Es gibt keine Liste, die alle ausgelieferte Software und die Nutzung von AI verfolgt; nur weil man selbst keine Verbesserungen gesehen hat, daraus zu schließen, sie existierten nicht, ist seltsam
    Auch im Gesundheitsbereich ist die Zahl der Produkte stark gestiegen; die Qualität ist unterschiedlich, aber zu sagen, es habe gar keine Ergebnisse gegeben, ist objektiv falsch
  • Ich würde sagen, praktisch nutzbar ist das erst seit Ende letzten Jahres, aber dass Hobby-Software zuletzt deutlich zugenommen hat, stimmt. Wie gut sie wartbar sein wird, ist eine andere Frage

• Wenn das Produkt funktioniert, würde ich empfehlen zu sagen: „Prüfe, ob die Codebasis produktionsreif ist und den Standard erfüllt, für 1 Million Dollar verkauft zu werden.“ Dann zeigt die AI, dass sie das zuvor behauptete Niveau überhaupt nicht erreicht, und es wird zum „Millionen-Dollar-Prompt“, das einem zeigt, wie sehr man sich hat täuschen lassen

  • Ich habe zwei Hacker-News-Posts gesehen, und bei beiden lautete der Top-Kommentar: „AI kann keinen Code schreiben und wird bald zusammenbrechen.“ Es ist schwer nachzuvollziehen, dass man Leuten, die diese Tools seit Jahren täglich erfolgreich nutzen, weiterhin sagt, das sei nur eine Fata Morgana
  • Selbst miserable Codebasen wurden schon für mehr als 1 Million Dollar verkauft
  • Dann frage ich mich, für wie viele Millionen Dollar Oracle Database verkauft werden müsste
    https://news.ycombinator.com/item?id=18442941
  • Wenn man es bittet, die Probleme zu beheben, und dann dieselbe Frage erneut stellt, wird es auch nach den Änderungen wieder ähnliche Kritik äußern
  • Es lohnt sich, darüber nachzudenken, für wie viel OpenClaw verkauft wurde

• Ich habe LLMs auf zwei Arten eingesetzt. Erstens habe ich mit Opus 4.6 und einem Node-Backend per Vibe Coding ein Plugin gebaut, das je nach Reihenfolge der Personen Benachrichtigungen in Slack-Kanäle sendet, sowie einen Sprech-Timer pro Google-Meet-Teilnehmer. Es ist ein internes Tool; auch ohne die Implementierung vollständig zu verstehen, läuft es problemlos auf GCP, und die Kosten für das Slack-Tool konnten von 20 Dollar pro Person und Monat auf gesamte 0,07 Dollar pro Monat an Infrastrukturkosten gesenkt werden
  Es entstand nicht in einem Zug, sondern nach detaillierter Planung, schrittweiser Ausführung und dem Hinzufügen von Tests. Zweitens entwirft und prüft das Team bei langfristigen Produkten die Architektur und erstellt detaillierte JIRA-Tickets, die dann an Opus übergeben werden. Das Modell erstellt einen Implementierungsplan und darf erst nach Freigabe durch einen Engineer coden
  Für schnelle MVPs oder Proofs of Concept ist der erste Ansatz gut, aber bei langfristigen Produkten sollte man das MVP verwerfen, Skalierbarkeit und eine saubere Architektur von Anfang an planen und LLMs als Coding-Arbeiter einsetzen. LLMs sind immer noch schwach darin, über eine Architektur zu urteilen, die Menschen lange pflegen können, und sauberen Code zu bewerten

  • Für Vibe Coding von einmaligen, risikoarmen Apps war es hervorragend, aber wenn man auf dieselbe Weise Features in einer riesigen Legacy-Codebasis implementiert, wird es zum absoluten Albtraum

• Das Kriterium ist, ob es Spaß macht, AI-Erzeugnisse zu konsumieren. Bei Texten, Videos, Stimmen, Restaurantmenüs, Kleidungsfotos, Dokumenten, Flughafenkontrolle oder Werbung ist das bei keinem der Fall; als verbesserte Suchmaschine oder Frage-und-Antwort-Tool halte ich LLMs jedoch für wertvoll

  • Vielen Konsumenten ist niedrige Qualität egal, solange nur ein Mindeststandard erfüllt wird und es funktioniert. Dasselbe gab es bei Haushaltsgeräten, Software und Fast Food
    Wenn AI diesen Standard am Ende erfüllt, werden ihre Erzeugnisse handgemachte Produkte verdrängen, und von Menschen direkt hergestellte Produkte und Dienstleistungen könnten nur noch zu viel höheren Preisen erhältlich sein, ähnlich wie heutige Manufakturwaren
  • Gute AI-Ergebnisse genießt man womöglich bereits ständig, ohne sie zu bemerken. Niemand mag miserable einmalige Erzeugnisse
  • Wenn man sieht, dass Menschen pro Monat zusammengerechnet Milliarden von Dollar ausgeben, kann man davon ausgehen, dass sie es tatsächlich mögen
  • Ich betrachte AI-Erzeugnisse nur als Rohmaterial, nicht als fertige Endprodukte, die man direkt an Massenkunden ausliefern kann
  • Nicht die Tatsache, dass es AI ist, ist das Problem, sondern die niedrige Qualität. Auch wenn klar ist, dass etwas AI ist, mag man es, wenn es gut gemacht ist

• Es wird viel Arbeit geben, die Vibe-Coding-Ergebnisse anderer Firmen aufzuräumen und in realistische Systeme zu verwandeln. Der Wert einzelner Projekte sinkt vielleicht, aber ihre Zahl steigt, und ohne Hilfe werden sie wahrscheinlich nicht richtig funktionieren
  Es hieß, dass Firmen ohne Software-Engineers mit Claude Code Dinge außerhalb ihres Kerngeschäfts erledigen, aber trotzdem möchten, dass ihre Mitarbeiter die Arbeit tun, für die sie eingestellt wurden, statt am Code herumzubasteln
  Weil Maßanfertigung einfacher wird, werden gleichförmige Produkte schwerer zu verkaufen sein, aber um tatsächlich maßgeschneiderte Ergebnisse zu liefern, ist weiterhin viel Arbeit nötig. Menschen mit eigener Aufbau-Erfahrung und Wissen über den jeweiligen Arbeitsbereich sind dadurch doppelt im Vorteil
  Die meisten Menschen wissen nicht genau, was sie brauchen; daher bleibt das Wesen von Beratung, Anforderungen herauszuarbeiten und zu liefern, unverändert, und weil Software billiger wird, kann man mehr Kunden betreuen

  • Es ist unklar, wer genau dieser Mitarbeiter sein soll, der den Code nicht anfassen sollte

• Die Grundlogik des Textes ist fehlerhaft. Wenn nach dem Bau eines Prototyps noch Arbeit übrig ist, kann man diese Arbeit einfach weiter erledigen. Es scheint, als würde der Einsatz von AI mit einmaliger Erzeugung per Vier-Zeilen-Prompt gleichgesetzt; das wirkt eher wie unkritische Selbstrechtfertigung als wie eine grundlegende Einsicht

  • Das deckt sich exakt mit meinem Eindruck vom Einsatz von LLMs in Codebasen mit unzureichender Testabdeckung, unklaren Anforderungen und nicht standardisiertem Deployment. Sobald man den Normalpfad verlässt, beginnen sie, schlechte Annahmen zu treffen, die die Produktion kaputtmachen, und selbst die klügsten Modelle reichen in solchen Umgebungen nicht an eine dafür geeignete Architektur heran

• Auch ohne technischen Hintergrund fühlte sich das intuitiv richtig an, und ich habe es beim Entwickeln von Kartenspielen mehrfach erlebt. Anfangs lief es gut, aber weil ich eine Standardbibliothek für 52 Karten eingebunden hatte, konnte ich keine speziellen Ereigniskarten hinzufügen, und ich brauchte ein flexibles Datenmodell auf Basis von Kartenobjekten
  Wenn man es von Anfang an sagt, lässt es sich vielleicht lösen, aber wenn man Software als Wegwerfprodukt betrachtet und die Implementierung nicht so tief durchdenkt wie ein erfahrener Engineer, kommt man auf solche Anforderungen nicht. Das Problem bei AI-generierten Texten und Code ist, dass sie einem das Denken entziehen, das dem Herstellungsprozess innewohnte
  Allerdings muss nicht jede Software skalierbar, schnell und wartbar sein. Für Infrastruktur und Apps, die von Millionen genutzt werden, ist das nötig, aber eine Familien-App zur Essensplanung muss nicht einmal Allergieeinstellungen für Zehntausende Google-Mitarbeiter unterstützen
  AI macht es möglich, Software zu einem Werkzeug wie selbstgekochtes Essen zu machen. Selbstgekochtes Essen muss kein perfektes Gericht sein; es reicht, wenn es die Familie ernährt und für jemanden ein Geschenk der Mühe ist

• Wenn Produkte mit nur einer einzigen Anfrage erstellt werden könnten, hätten Auftragsfirmen Produktfirmen längst verdrängt. Ein großer Teil der Produktentwicklung passiert in der Iteration nach dem ersten Prototyp bzw. MVP
  Es geht nicht nur um Technik, sondern darum, sich lange mit dem Problem zu beschäftigen, die eigentliche Ursache des Schmerzes zu verstehen und es sowohl in der Nutzererfahrung als auch technisch zu lösen. Schon früher konnte man Produktfirmen „prompten“, aber der Grund, warum man Produktfirmen bezahlt hat, die über Jahre mit Kunden sprechen und Expertise aufbauen, liegt genau darin

• Ein passenderer Titel für die Kernaussage des Textes wäre The Prototype Isn't the Product. Mit AI lassen sich Wegwerf-Prototypen und persönliche Apps, bei denen „funktioniert größtenteils“ reicht, erstaunlich schnell bauen, aber Software Engineering, bei dem Qualität und Wartbarkeit wichtig sind, bleibt weiterhin schwierig und langsam
  Es gibt viele flashy Vibe-Coding-Demos, aber wenig Diskussion darüber, wie nützlich AI bei großen Legacy-Codebasen oder alltäglicher, unspektakulärer Facharbeit wirklich war
  Wegen eines per Vibe Coding gebauten 3D-Spielprototyps ruft dich am Sonntagmorgen um 6 Uhr niemand an, aber wenn im gerade aktualisierten 24/7-System ein Bug auftritt, bekommst du garantiert den Anruf