GitHub-CEO: Trotz AI-Boom bleibt manuelles Codieren zentral
(techinasia.com)- GitHub-CEO Thomas Dohmke betont, dass manuelle Coding-Fähigkeiten trotz der zunehmenden Verbreitung von AI-Tools wichtig bleiben
- Auch wenn AI Code generiert, ist es laut ihm effizienter, wenn Entwickler ihn selbst anpassen und prüfen
- Wer sich nur auf Automatisierung verlässt, riskiert reale Ineffizienz und Produktivitätsverluste; bei übermäßigem Einsatz von „Vibe coding“ steigen zudem Qualitäts- und Sicherheitsrisiken
- Anhand von Branchentrends und Beispielen erläutert er, dass ein hybrider Ansatz aus AI und menschlichen Entwicklern am effektivsten ist
- Die Rolle von Entwicklern verschwindet nicht, sondern entwickelt sich in Richtung Zusammenarbeit mit AI sowie strategischer Problemlösung und Architekturkompetenz weiter
GitHub-CEO betont die Bedeutung manuellen Codierens auch im AI-Zeitalter
GitHub-CEO Thomas Dohmke betont, dass es trotz der wachsenden Nutzung von AI-Tools in der Softwareentwicklung wichtig bleibt, manuelle Coding-Fähigkeiten zu erhalten.
- In „The MAD Podcast with Matt Turck“ erklärte er, Entwickler müssten in der Lage sein, von AI generierten Code selbst zu überarbeiten, um Produktivitätsverluste zu vermeiden
- Ein effektiver Workflow sei ein Ansatz, bei dem AI-Tools Code erzeugen und einen Pull Request einreichen, den Entwickler dann mit ihren Fähigkeiten direkt anpassen
- Wer sich ausschließlich auf Automatisierungsagenten verlässt, riskiert Ineffizienz, weil bereits einfache Änderungen in natürlicher Sprache zu beschreiben unnötig Zeit kosten kann
- Dohmke weist darauf hin, dass es „die ineffizienteste Wahl ist, etwas in natürlicher Sprache zu erklären, das man in einer Programmiersprache ohnehin direkt selbst erledigen kann“
- Der von OpenAI-Mitgründer Andrej Karpathy geprägte Begriff „vibe coding“ bezeichnet eine übermäßige Abhängigkeit von AI-generiertem Code, vor der Dohmke ebenfalls warnt
Einblicke und Branchentrends
1. Die beste Lösung für AI-Coding ist eine hybride Strategie
- Dohmkes Sichtweise deckt sich mit dem Branchenkonsens, dass die Kombination aus AI-Automatisierung und menschlichen Programmierfähigkeiten optimal ist
- Laut einer Deloitte-Studie nutzen Entwickler AI-Tools vor allem zum Schreiben von Boilerplate-Code, erzielen aber durch menschliche Endkontrolle einen Produktivitätsgewinn von 10 bis 20 Minuten
- Etwa die Hälfte des von AI erzeugten Codes enthält teilweise Fehler, weshalb sich eine „Vertrauen, aber verifizieren“-Strategie als Branchenstandard etabliert hat
- Google lässt mehr als 25 % des gesamten Codes durch AI erzeugen, hat aber zugleich die Erfahrung gemacht, dass aktive Reviews und Verbesserungen durch menschliche Entwickler weiterhin unverzichtbar sind
- Dieser ausgewogene Ansatz zeigt, dass die Branche reifer wird: Die Grenzen von AI werden anerkannt und die Expertise von Entwicklern wird nicht ersetzt, sondern erweitert
2. Die Rolle von Entwicklern verändert sich, verschwindet aber nicht
- Durch AI verschwindet der Programmierberuf nicht; vielmehr wandelt sich die Rolle des Entwicklers vom reinen Coder zum Manager AI-gestützter Entwicklungsprozesse
- Experten erwarten, dass sich Entwicklungsberufe in produktorientierte Engineers mit starkem AI-Einsatz und Architekten für fortgeschrittene Systemqualität und Sicherheit aufspalten werden
- Dieser Wandel bedeutet einen steigenden Bedarf an neuen Fähigkeiten wie effektiver AI-Nutzung, strategischer Problemlösung und High-Level-Designkompetenz
- Zusammen mit dem Mangel an Softwareingenieuren und der belegten Unterstützungswirkung von AI-Tools für Junior-Entwickler eröffnet dies auch erfahrenen Entwicklern neue Wachstumschancen
- Wie schon bei früheren Entwicklungswerkzeugen und Abstraktionstechniken deutet dies darauf hin, dass menschliche Kreativität weiterhin unverzichtbar bleibt
3. Das Produktivitäts-Qualitäts-Dilemma von „Vibe coding“
- Das Phänomen „vibe coding“ zeigt den Produktivitätsvorteil von AI-generiertem Code, aber auch dessen Grenzen bei Qualität und Sicherheit
- AI-Tools unterstützen schnelles Prototyping und iterative Entwicklung, erhöhen jedoch zugleich die Sorge vor sinkender Codequalität und Sicherheitsrisiken
- In realen Fällen kam es bereits zu Sicherheitslücken durch den ungeprüften Einsatz von AI-Code
- Gerade in Startups mit Gründern ohne technischen Hintergrund kann der übermäßige Einsatz von AI-Code technische Schulden aufbauen und so das langfristige Wachstum behindern
- Die Erfahrung großer IT-Unternehmen zeigt, dass das Gleichgewicht zwischen Automatisierung und strenger Qualitätssicherung entscheidend für die AI-Einführung ist – eine wichtige Lehre auch für Startups
1 Kommentare
Hacker-News-Kommentare
Ich frage mich ernsthaft, warum kaum noch jemand über die essenzielle Komplexität von Systemen spricht.
Fred Brooks weist in No Silver Bullet darauf hin, dass die eigentliche Schwierigkeit der Softwareentwicklung darin liegt, den zugrunde liegenden Problemraum zu verstehen, zu präzisieren und zu modellieren. Akzidentelle Komplexität wie Tool-Limitierungen ist zweitrangig.
In letzter Zeit hört man oft, dass AI-Agenten per Natural-Language-Prompt ganze Codebasen anstelle von Engineers erstellen würden. Diese Annahme beruht aber auf der Illusion, dass das Spezifikationsproblem bereits gelöst sei. Tatsächlich bleibt es die Kernaufgabe von Engineers, vage Ideen in detaillierte und robuste Systeme zu überführen.
Wenn jemand eine detaillierte Spezifikation liefert und iterativ mit AI zusammenarbeitet, um Software zu bauen, dann beseitigt AI im Grunde akzidentelle Komplexität. Das ähnelt dem Übergang von Assembly zu Hochsprachen für Entwickler. Es ersetzt Engineers nicht, sondern erhöht nur die Produktivität. Es senkt die Kosten repetitiver Arbeit und schafft die Möglichkeit, breiter Wirkung zu entfalten.
Wenn Agenten allein aus Prompts Produkte bauen, dann nur, weil jemand das System bereits klar definiert hat. Und wenn AI nur bestehende Produkte kopiert, geht es nicht um technische Problemlösung, sondern um Distribution oder Kostenwettbewerb — also nicht um Engineering-Innovation, sondern um Business-Innovation.
Ich frage mich, ob mir etwas entgeht.
Entscheidend ist, warum Spezifikationsarbeit schon lange vor dem Aufkommen von AI vernachlässigt wurde.
Stakeholder (Kunden, Manager) haben schon immer mit groben Intuitionen coden lassen. Man erklärt etwas vage, und dann liefert irgendjemand wie durch ein Wunder eine passende Lösung. Ob die Lösung wirklich vollständig funktioniert, weiß niemand. Oft heißt es einfach: scheint grob zu funktionieren, passt schon.
In den meisten Fällen konkretisieren Programmierer das auf Basis von Domänenwissen (zum Beispiel, weil sie instinktiv wissen, wie eine korrekte Formular-Absendeseite aussehen sollte).
Jetzt wurde nur das Gegenüber durch AI ersetzt; ob diese Arbeitsweise einfach so wiederholt werden kann, muss man abwarten.
Die Unterscheidung zwischen essenzieller/akzidenteller Komplexität ist eine sehr wichtige Einsicht, wenn man darüber nachdenkt, wie viel Softwareentwicklung AI tatsächlich übernehmen kann.
Viele Entwickler können nicht in Worte fassen, warum sie nicht durch AI ersetzt werden, aber genau das ist der Punkt, den sie intuitiv spüren.
Ich selbst habe tatsächlich versucht, mit Agenten wie Claude Probleme in einer riesigen Codebasis mit extrem komplexer, externer Business-Logik zu lösen. Aber AI hat kein echtes Gespür für Business-Anforderungen oder Kontext und kann deshalb keine geschäftslogischen Code-Änderungen umsetzen. Sie hilft eher bei einfachen Änderungen in eng begrenztem Kontext. Sie kann also nur akzidentelle Komplexität verarbeiten und stößt dort an Grenzen, wo die eigentliche Rolle eines echten Entwicklers beginnt: reale Anforderungen in Systeme zu übersetzen.
Ergänzend dazu gilt: Was viele Entwickler tatsächlich lösen, sind womöglich gar nicht technische Probleme, sondern Distributions-/Marktprobleme. AI einzusetzen, um Juniors zu ersetzen, fühlt sich noch unsicher an. Das größte Problem ist, dass AI sich nicht eigenständig selbst korrigieren kann. Trotzdem wird es weiterhin AI-basierte Unternehmen geben, die versuchen, die Kosten bestehender Geschäftsmodelle zu senken. Ob diese Veränderung gut oder schlecht ist, spielt für diejenigen, die dadurch aus Jobs verdrängt werden, keine Rolle.
Auf „Übersehe ich etwas?“ gibt es eine Antwort.
Es gibt tatsächlich extrem viele Entwickler, die Software nicht wirklich benutzen können. Diese werden leicht durch AI ersetzbar sein.
In einem früheren Karrierestadium habe ich mit JavaScript gearbeitet, und die wirklich beeindruckenden Leute waren ausschließlich solche, die aus Hobby entwickelt hatten. Im Unternehmen hatten die meisten schon Probleme damit, überhaupt Text auf dem Bildschirm anzuzeigen. Kein Witz.
Viele haben sich an riesigen Frameworks versucht, kamen aber am Ende nur auf Copy-Paste-Niveau, bis es irgendwie lief. Sie tun so, als hätten sie hohe Komplexität gelöst, aber fast alles davon ist unnötige Arbeit oder Code-Prahlerei.
Es fehlt fast vollständig an der Fähigkeit, originelle Apps zu bauen, Dokumentation zu schreiben oder echte Nutzbarkeit zu messen.
Wie löst man das? Mit hohen Standards wie etwa einem Staatsexamen für Juristen: Wer die Hürde nicht nimmt, sollte konsequent aussortiert und höchstens als Junior oder Auszubildender eingestellt werden, damit eine Entwicklergeneration überhaupt gesund heranwachsen kann.
Die einfache Antwort auf den „blinden Fleck“ ist, dass in der Branche offenbar niemand No Silver Bullet gelesen hat.
Leute, die über Technical Debt oder Systemarchitektur schreiben, sind in der Praxis oft nicht die Entscheidungsträger, die Teams oder Business steuern, und solche Bücher sind für Engineers optional.
Menschen, die die Erzählung vom Ersetzen des Codings durch AI vorantreiben, können oft nicht zwischen dem Bau eines MVP und der Pflege, Skalierung und Modernisierung einer Codebasis über zehn Jahre unterscheiden.
Zum Beispiel schlug ein Manager einmal ganz typisch vor, man könne drei Projekte an einem Tag mit je 33 % Zeitanteil parallel betreiben. Personaleinsatz und Zeitstrukturierung sollten eigentlich Managementkompetenzen sein, aber am Ende müssen Engineers das sauber auffangen.
Jetzt sind es dieselben Manager, die sagen: „Lassen wir AI einfach alle Technical-Debt-/Test-Probleme lösen“, und wenn das nicht klappt, müssen Engineers wieder erklären, warum.
Die Rede über Komplexität ist in Wirklichkeit nur eine Wiederholung von schlechtem Management. Die meisten erfahrenen Engineers glauben ohnehin nicht, dass ihre Arbeit durch einfache Prompts ersetzt wird.
Worüber wir wirklich sprechen sollten, ist: „Software Engineering hat ein massives Managementproblem, und AI macht es noch sichtbarer.“
Viele Nicht-Entwickler oder Studierende haben das Gefühl, dass man für Softwareentwicklung komplizierte Tools lernen müsse, und werden von dem Versprechen angezogen: „Wenn man nur gute Spezifikationen schreibt, kann jeder Software bauen“ (wobei unterschlagen wird, dass Spezifikationskompetenz selbst sehr schwierig ist und unterstützende Technologien braucht).
Früher war es mit No-Code genauso, und tatsächlich sind No-Code-Tools begrenzt; je mächtiger die Funktionalität, desto komplexer und spezialisierter wird auch das notwendige Lernen.
Die These, LLMs würden SWE ersetzen, ist letztlich nur die Version: „Statt das System zu lernen, gibst du Natural-Language-Prompts ein, und das Modell bedient die Tools für dich.“
Unter diesem Blickwinkel ist das heutige Vibe Coding im Grunde die Zuspitzung dieses Ziels (wenn auch mit realen Schwächen wie Wartbarkeit).
Ich denke, ein Grund, warum Manager SWE loswerden wollen, ist, dass sie nicht gut mit SWE kommunizieren können.
Mit LLMs glauben sie nun, mit Maschinen kommunizieren zu können, ganz ohne „Nerds (Entwickler)“, und sehen darin die Lösung dieses Problems.
Programmiersprachen sind ein geeignetes Medium für die präzise Spezifikation des gewünschten Programms. Natürliche Sprache erreicht niemals dieses Maß an Eindeutigkeit.
Deshalb ist es selbstverständlich, AI-generierte Ergebnisse zu reviewen und zu bearbeiten. Manchmal ist es sogar leichter, eine Änderung direkt selbst vorzunehmen, als sie zu erklären.
Ich frage mich, ob unabhängige Studien, nach denen Copilot die Fehlerrate erhöht, nicht ganz natürlich zu einer vorsichtigeren Haltung beigetragen haben.
Menschen, die AI verkaufen, behaupten oft, dass menschliche Autoren bald überflüssig würden.
Transformer lassen sich für automatisiertes Testing, Spezifikationserweiterung, Beschleunigung neuer Projekte, Erkundung unbekannter APIs, initialen Feature-Aufbau, Code-Review und vieles mehr einsetzen.
Selbst wenn Code tatsächlich das richtige Medium für Spezifikationen ist, fungieren Transformer als automatisierte Schnittstelle zwischen natürlicher Sprache und diesem Medium (Code).
Dank ihres enormen Wissensbestands haben Transformer derzeit kein grundsätzliches Problem mit Code-Generierung.
So wie Menschen in der Programmierung Automatisierung anstreben, sind Transformer ein gewaltiger Sprung.
Irgendwann in der Zukunft könnte die Verdrängung von Programmierern durch AI Realität werden (so wie früher automatische Webstühle, der Buchdruck oder elektronische Rechner menschliche Arbeit ersetzt haben).
Das muss aber nicht sofort oder innerhalb der nächsten zehn Jahre passieren; es bleiben Aufgaben wie Halluzinationen, Genauigkeit, Tooling und Infrastrukturaufbau.
Ob es Programmierjobs gibt, könnte je nach Domäne, Können und Vergütungserwartung unterschiedlich ausfallen.
Wichtig ist, AI-Tools ernst zu nehmen und sich anzupassen. Sonst droht man Veränderungen zu verpassen — ähnlich wie bei der Einführung von Personal Computing oder dem Internet.
Ich halte die Pseudo-Kreativität von AI für begrenzt.
Wenn alle Ergebnisse des LLM-Trainings wieder nur als LLM-Input zirkulieren, erweitert sich der Raum neuer Ideen niemals.
Menschen zeigen weiterhin Kreativität, die außerhalb dieses Bereichs liegt.
Vielleicht werden LLMs diese Wand in Zukunft überschreiten, aber momentan sind sie kaum mehr als „Affen an der Schreibmaschine“.
Meiner Erfahrung nach sind LLMs am effektivsten, wenn man sie als Scaffolding-Werkzeug nutzt.
Ich kippe gewissermaßen einen Brain-Dump der Funktion hinein, die ich bauen möchte, und bitte dann darum, das Modell plus den dafür nötigen Basis-Controller zu erzeugen.
Danach kann ich mich nur noch auf die View und die eigentliche Business-Logik konzentrieren; die Arbeitsteilung ist klar.
Als früher Hochsprachen erstmals aufkamen, gab es in der Frühphase meines Wissens ähnliche Kritiken wie heute an LLMs oder Natural-Language-Coding, etwa dass direkte Speicherkontrolle fehle und es daher an Präzision mangele.
Das Problem ist nicht, dass natürliche Sprache grundsätzlich keine Präzision leisten kann, sondern dass die meisten Menschen Anforderungen unpräzise beschreiben oder zwar genau wissen, was sie wollen, aber nicht präzise ausdrücken können, was der Computer tatsächlich tun soll.
Das führt dazu, dass Engineers beim Übersetzen von Business-Anforderungen massiv raten müssen — oder dass LLMs diese Rolle übernehmen, dabei aber noch weniger Kontext verstehen.
Der beste Einsatz von AI ist für mich, im Flow-Zustand zu bleiben und nicht an einer mir unbekannten API oder an Features hängen zu bleiben, auf die ich keine Lust habe.
AI kann gemeinsame Muster schnell und effizient auf Code anwenden, weiß aber im Kern selbst nicht, was sie da tut.
Ein aktuelles Beispiel aus meiner Erfahrung: Ich wollte ein LLM Code zum Berechnen und Platzieren der Größe eines Pop-ups refaktorieren lassen.
Ein Teil war mit
if, ein anderer mitswitchgeschrieben, aber das LLM konnte mit diesem Unterschied überhaupt nicht flexibel umgehen und vereinheitlichte trotz klarer Erklärung beide Stellen entweder aufifoder aufswitch.LLMs neigen dazu, das Muster vorheriger Tokens einfach fortzusetzen.
Hier war das kein großes Problem, aber in etwas komplexeren Situationen ignorieren sie Details und liefern Code, der oberflächlich plausibel wirkt.
Wenn man Aufgaben dagegen in kleine Schritte zerlegt und klar anweist, sind LLMs ziemlich effizient. Eine Anweisung wie „Größe in
m_StateStoragespeichern und im Render-Schritt anwenden“ führen sie problemlos aus.Gerade mit Modellen wie Cerebras, die auch ein paar Kilobyte Code schnell verarbeiten können, ist das viel schneller, als meine Gedanken selbst direkt in Code zu tippen.
Am Ende beziehen sich heutige Bewertungen nur auf die aktuelle Leistungsfähigkeit von Transformer-Modellen.
Diese Branche verändert sich so schnell, dass die Grenzen von heute in einem Monat bedeutungslos sein könnten.
Auch „LLM“ ist streng genommen ein unscharfer Begriff. Moderne Transformer-Modelle sind multimodal und verarbeiten nicht nur Text, sondern viele Arten von Daten.
Wenn man also kritisieren will, sollte man konkret benennen, welches Modell, welches Tool oder welches Paradigma gemeint ist, damit die Diskussion Substanz hat.
Zu Studien über „Mangel an Software Engineers“ und „AI hilft besonders Junior-Entwicklern“:
In meiner Realität ist der Tech-Arbeitsmarkt katastrophal, und AI wirkt für Juniors eher nachteilig, weil sie ihnen Erfahrungen dort nimmt, wo sie eigentlich wachsen müssten.
Ich hatte kürzlich ein interessantes Erlebnis mit Claude. In Zed habe ich gesagt: „Behebe den Fehler in Zeile 71“, und es hat stattdessen an Zeile 91 unnötiges Formatting geändert.
Es fühlte sich an wie Stille Post mit einem LLM.
Selbst so eine einfache Änderung ist direkt von Hand schneller erledigt. Diese Erfahrung hat mein Gefühl erneut bestätigt, dass „LLMs nicht wirklich denken“.
LLMs sind miserabel darin, Zeilennummern zu erkennen.
Daraus habe ich die Lektion gelernt: „LLMs können keine Zeilennummern zählen.“
Beim nächsten Mal wäre „Behebe den Fehler in Funktion XYZ“ besser, oder man fügt die relevante Zeile direkt ein.
Und natürlich: LLMs denken nicht. Sie sind einfach nur eine riesige Gleichung.
In diesem Thread scheinen viele Leute zum ersten Mal mit AI zu coden.
Vielleicht war es ein Bedienfehler.
Man muss dem LLM den richtigen Kontext geben. Zeilennummern sind dafür ungeeignet.
Für mich besteht die Rolle eines Software Engineers darin, Anforderungen in Software zu übersetzen.
Software ist nicht einfach nur Code, und Anforderungen kommen auch nicht bloß als natürliche Sprache.
Stand jetzt bin ich selbst mit AI nicht schneller als ohne (außer bei simplen Aufgaben oder kleiner Software).
Nach meinem Maßstab ist AI derzeit auf Junior-/Mid-Level-Niveau.
In den letzten zwei Jahren ist AI gefühlt nicht revolutionär besser geworden.
Die meisten Anforderungen sind nicht klar dokumentiert.
Kaum jemand weiß genau, was die Business-Logik eigentlich ist.
Deshalb müssen Software Engineers häufig selbst losgehen und nachfragen.
Erforderlich sind auch Erfahrung und Intuition, um darüber nachzudenken, in welche Richtung Software wachsen soll und wie man sie so entwirft, dass diese Erweiterbarkeit möglich bleibt.
Ich kann mir nicht vorstellen, dass LLMs auch nur einen Teil dieser Rolle übernehmen können.
Ich habe noch nie ein Softwareprojekt mit wirklich klaren Anforderungen gesehen.
Die Hälfte des Projekts besteht darin, überhaupt herauszufinden, was eigentlich gewollt ist.
LLMs erreichen noch nicht einmal wirklich Junior-Niveau.
Wenn bestehende AI bei euch tatsächlich auf dem Niveau eines Mid-Level-Entwicklers wäre, dann habt ihr ein Hiring-Problem.
Einer der größten Vorteile von Computern ist zuverlässige und reproduzierbare Automatisierung.
Formale Sprachen wie Programmiersprachen können gewünschte Automatisierungsanforderungen eindeutig und ohne Mehrdeutigkeit ausdrücken.
Natürliche Sprache ist nicht annähernd so präzise.
Der eigentliche Ground Truth eines Programms ist letztlich der Code.
Wenn Menschen das Verhalten eines Programms genau kontrollieren wollen, ist die Fähigkeit, Code zu verstehen und zu ändern, am wichtigsten.
Das Wort „manuell“ trägt einen negativen Beiklang.
Gemeint war in dem Artikel wohl eher: „Menschliches Coding bleibt zentral.“
Ich bin mir nicht sicher, ob der GitHub-CEO wirklich das Wort „manual“ benutzt hat. Es wäre gut, eine Artikelquelle mit neutralerer oder präziserer Wortwahl zu haben.
Human Coding als „manual“ abzuwerten ist nicht sinnvoll. Auch menschliche Entwickler verwenden neben AI viele verschiedene Automatisierungs-Toolkits.
Das könnte fast so negativ klingen wie „manuelles Denken“.
Dass „manual“ so negativ konnotiert ist, ist neu für mich.
Ich frage mich, ob man heutzutage wirklich so viel Abneigung gegen manuelle Arbeit hat.
Ich frage mich, worin eigentlich der Unterschied zwischen „manual coding“ und „human coding“ bestehen soll.
„Sich nur auf AI-Agenten zu verlassen, kann ineffizient sein.“
Zum Beispiel ist es bei einfachen Änderungen oft viel schneller, den Code direkt zu editieren, als ihn lang in natürlicher Sprache zu erklären.
Deshalb wird aktive Interaktion mit AI-Agenten wahrscheinlich der optimale Workflow sein.
Wenn ich Änderungen in natürlicher Sprache zu formulieren beginne, fällt mir oft schon vor dem Tippen die direkte Umsetzung im Code ein.
Je kontextreicher die Änderung, desto eher scheine ich sie selbst schneller zu beheben als ein Agent.
Ich frage mich, wie viel aktive Interaktion sinnvoll ist.
Ich bin kürzlich zu einem Startup für Agent-Tooling gestoßen, und intern diskutieren wir genau darüber viel.
Ich halte es für okay, dem Agenten laufend Feedback wie „ehrlich gesagt machst du das nicht gut!“ zu geben, aber manches davon könnte auch ermüdend werden.
Mich würde interessieren, was ihr darüber denkt und welche Vorstellungen oder welches Feedback ihr zu solchen Workflows habt.
AI ist noch nicht da, wo die Erwartungen sie sehen.
Ich plage mich zum Beispiel oft mit falschen Referenzen oder Spezifikationen herum. Das scheint daran zu liegen, dass AI auf veralteten Daten trainiert ist und nicht gut in Echtzeit aktualisiert wird.
Die heutigen LLM- und GI-Lösungen versuchen zu oft, alle n Schritte auf einmal zu lösen, und verlieren dadurch an Nutzen.
Es wäre für Menschen schon viel hilfreicher, wenn sie nur Schritt 1 bis Schritt i sauber erledigen würden.
Ich habe noch keine voll modular aufgebaute AI-Lösung gesehen, die ich mir wünsche (zum Beispiel: löse Problem x nur unter Bezug auf Ressourcen a, b, c und orientiere dich an meinem GitHub-Stil).
Außerdem hoffe ich auf Coding-AI, die Probleme schrittweise erkundet, unterwegs mehr Fragen stellt und wirklich dialogisch arbeitet.
Ich finde es bemerkenswert, dass ein CEO zu AI und Coding einmal eine etwas andere Richtung einschlägt.
Üblicherweise sagen CEOs oder Investoren Dinge wie „mehr als 30 % des gesamten Codes werden von AI geschrieben“ und prognostizieren damit eine Schrumpfung der Entwicklerrolle; hier lautet die Diagnose dagegen, dass dieselben Entwickler lediglich Tools nutzen, um schneller Code zu schreiben.
Dabei wird betont, dass das eigentliche Schreiben von Code nur ein Teil der Softwareentwicklung ist.