Was sind die Überlebensprinzipien in der Ära der KI-Programmierung? Andrew Ng: Handeln Sie schnell und übernehmen Sie Verantwortung.
In jüngster Zeit hielt Andrew Ng einen Keynote-Vortrag auf der ersten Buildathon. Der Inhalt drehte sich um AI-gestütztes Programmieren, schnelles Prototyping von Produkten und die Fähigkeitsanforderungen an AI-Engineer.
Andrew Ng ist ein international anerkannter Wissenschaftler auf dem Gebiet der künstlichen Intelligenz und des maschinellen Lernens. Er war einer der Gründer des Google Brain-Projekts und Mitbegründer der Online-Bildungsplattform Coursera. Im Jahr 2014 trat Andrew Ng bei Baidu als Chefwissenschaftler ein und 2024 trat er in den Vorstand von Amazon ein. In den letzten Jahren ist er im Bereich der AI-Investitionen und des Unternehmertums aktiv und gründete Projekte wie AI Fund und DeepLearning.AI.
Wichtige Punkte aus dem Vortrag:
1. Das neue Motto in Silicon Valley: "Bewege dich schnell und übernehme Verantwortung".
AI-gestütztes Programmieren beschleunigt die Entwicklung von unabhängigen Prototypen um das Zehnfache. Die drastische Reduzierung der Prototypkosten macht es zu einer machbaren Strategie, schnell und mehrfach Fehlversuche zu machen. Der wahre Wert liegt darin, in diesen Fehlversuchen Projekte zu finden, die sich für eine tiefgreifende Entwicklung lohnen.
Andrew Ng stellte fest, dass bei der Prototypentwicklung die Anforderungen an Sicherheit und Skalierbarkeit geringer sind und die AI die Schwelle für Fehlversuche weiter senkt. Er befürwortet das Prinzip "Bewege dich schnell und übernehme Verantwortung" (Move fast and be responsible) und empfiehlt, mutig in einer Sandbox-Umgebung zu experimentieren, bevor man sich für eine produktive Umsetzung entscheidet.
2. Der Wert von Code sinkt, Entwickler müssen sich zu Systemdesignern und AI-Führern wandeln.
Programmierwerkzeuge haben mehrere Generationen von Evolution durchlaufen: von GitHub Copilot über IDEs bis hin zu hochgradig agierenden Programmierassistenten. Die Geschwindigkeit der Werkzeugiteration schafft einen wesentlichen Effizienzunterschied. Ein Rückstand von nur einer halben Generation kann die Produktivität deutlich beeinträchtigen.
Der Wert des Codes selbst sinkt. Die AI kann Code automatisch generieren und Datenbankarchitekturen migrieren, was Architekturentscheidungen reversibler macht. Entwickler müssen sich von Code-Schreibern zu Systemdesignern und AI-Führern wandeln und sich auf die Kontrolle der Kernarchitektur und die Konstruktion von komplexen Systemen konzentrieren.
3. Die Revolution der Engineering-Effizienz bringt einen "neuen Engpass in der Produktverwaltung" hervor.
Nach der Steigerung der Engineering-Geschwindigkeit werden die Produktentscheidungen und die Benutzerrückmeldungen zum neuen Engpass. Andrew Ng erläuterte dies anhand eines eigenen Beispiels: Wenn die Engineering-Zeit von drei Wochen auf einen Tag reduziert wird, erscheint es extrem langsam, eine Woche für die Benutzerrückmeldung zu verbringen.
Er schlug ein neues Paradigma für die Datennutzung vor: Man sollte nicht einfach nur auf Daten für Entscheidungen verlassen (z.B. "Die Daten sagen, wähle Version drei"), sondern die Intuition mit Daten korrigieren ("Warum habe ich falsch eingeschätzt, dass die Benutzer Version eins wollen"). Durch Korridor-Tests, Kaffeeladen-Umfragen, schnelles Prototyping und andere Methoden kann man die Intuition für die Benutzer präzisieren und einen effizienten Entscheidungs-Zyklus aufbauen.
4. "In der AI-Zeit muss man nicht programmieren lernen" ist der schlechteste Berufsratgeber aller Zeiten.
Andrew Ng widersprach vehement der Meinung, dass man in der AI-Zeit nicht programmieren lernen muss. Er wies darauf hin, dass bei jedem Fortschritt der Programmierwerkzeuge in der Vergangenheit immer mehr Menschen die Fähigkeit zum Programmieren erlangten. In seinem Team konnten der CFO, der Rechtsanwalt und die Empfangsdame durch das Lernen des Programmierens ihre Arbeitsleistung steigern. Die zukünftige Kernkompetenz besteht darin, "dem Computer präzise zu sagen, was er tun soll", was das Verständnis von Computersprachen und Programmierlogik erfordert. Nicht-technische Personen können mit Hilfe der AI schnell die grundlegenden Programmierfähigkeiten erlernen und so die Effizienz in anderen Bereichen steigern.
5. Es fehlen dringend AI-Engineer, aber die Universitätskurse sind bereits stark anachronistisch.
Die Arbeitslosigkeit von Informatik-Absolventen ist auf 7 % gestiegen, aber Unternehmen haben dennoch ein Problem, genügend AI-Engineer zu finden. Der Kern des Problems liegt darin, dass die Universitätskurse nicht auf die aktuellen Schlüsselkompetenzen zugeschnitten sind: AI-gestütztes Programmieren, Aufruf von Large Language Models, Aufbau von RAG/Agentic-Workflows, standardisierter Fehleranalyseprozess usw. Aufkommende AI-Engineer müssen drei Schlüsselkompetenzen beherrschen: die Verwendung der neuesten AI-Programmierwerkzeuge, die Vertrautheit mit AI-Bausteinen (Prompting-Engineering/Evaluierungstechniken/MCP) und die Fähigkeit zum schnellen Prototyping und die grundlegende Intuition für Produkte. Andrew Ng forderte die Bildungssysteme auf, die Kurse schneller zu aktualisieren und ermutigte die Entwickler, sich diesen Veränderungen bewusst zu stellen.
Unten finden Sie den Originaltext des Vortrags:
Ich freue mich, Sie hier am Wochenende zu sehen. Was ich tun möchte, ist, Ihnen meine Ansichten über AI-gestütztes Software-Engineering zu teilen und zu erklären, warum wir diese Buildathon veranstaltet haben, eine schnelle Engineering-Wettbewerbsveranstaltung, bei der man in einem Tag von Null zu einem Produkt kommt.
Ich habe festgestellt, dass wenn man versucht, etwas Neues zu tun, sei es das Gründen eines Start-ups wie AI Fund oder die Innovation in einem größeren Unternehmensumfeld, eine der größten Faktoren, die vorhersagen, ob ein Projekt erfolgreich sein wird, die Geschwindigkeit ist. Einige Teams können durch eine schnelle Umsetzung mehr Iterationen durchführen, mehr Dinge ausprobieren und so die Chancen auf Erfolg deutlich erhöhen.
Ehrlich gesagt, wenn ich mit Ingenieuren oder CEOs von Portfolio-Unternehmen zusammenarbeite, schätze ich besonders diejenigen, die entschlossen und schnell handeln können. Übrigens, wenn ich über Geschwindigkeit spreche, denken manche Leute vielleicht: "Oh, will Andrew nur sagen, dass man härter arbeiten soll?" Das stimmt aber nicht. Natürlich hilft es, hart zu arbeiten. Ich weiß, dass es in einigen Teilen der Welt nicht immer richtig ist, über harte Arbeit zu sprechen, aber ehrlich gesagt, ich arbeite hart und ich schätze Leute, die hart arbeiten.
Aber neben der harten Arbeit braucht es auch Entscheidungsfähigkeit, um die Umsetzungskraft zu steigern, mehr Dinge auszuprobieren und mehr Arbeit zu erledigen. Einer der Gründe, warum ich mich für AI-gestütztes Programmieren begeistere, ist, dass es den Kern unserer Arbeit stark beschleunigt.
Wenn ich an meine bisherige Softwarearbeit zurückdenke, habe ich einige kleine unabhängige Produktprototypen entwickelt, und ein Teil meiner Arbeit und auch vieler von Ihnen besteht darin, produktives Software in großen Code-Bibliotheken zu entwickeln. Wenn wir die Auswirkungen von AI-gestütztem Programmieren untersuchen, ist es schwer, eine strenge Studie durchzuführen. Vielleicht kann die AI die Geschwindigkeit bei der Arbeit an großen traditionellen produktionsreifen Code-Bibliotheken um 50 % oder sogar mehr erhöhen, ich bin mir nicht sicher. Aber bei der Entwicklung von kleinen unabhängigen Produktprototypen ist es nicht eine 50-prozentige Beschleunigung, sondern eine zehnfache Beschleunigung.
Ich denke, viele von Ihnen haben Erfahrungen mit Projekten, die vor zwei Jahren drei Ingenieure sechs Monate lang benötigten. Jetzt können wir zusammen mit Freunden am Wochenende solche Projekte erledigen. Das bedeutet, dass wir neue Dinge ausprobieren können, 20 Prototypen entwickeln und sehen können, welche funktionieren. Eigentlich schreibe ich oft an Samstagen viel Code, weil es so zu meiner Zeitplanung passt. Jeden Samstag schreibe ich eine Menge Software und sage dann: "Oh je, das funktioniert überhaupt nicht!" Aber ich habe das niemandem erzählt und diese Prototypen sind nie veröffentlicht worden. Tatsächlich machen es manche Leute nervös, dass viele Proof-of-Concepts im Bereich der AI nie in die Produktion gehen. Dies wird als ein Problem angesehen, aber ich sehe es nicht so. Für mich ist die Lösung nicht, dass mehr Proof-of-Concepts in die Produktion gehen, sondern die Kosten für die Proof-of-Concepts so weit zu senken, dass es egal ist, wenn man 20 Prototypen entwickelt, von denen 18 scheitern und nie veröffentlicht werden. Dies ist der Preis, um die zwei wirklich wertvollen Prototypen zu finden, die man dann wirklich Zeit und Aufwand investieren muss, um sie robust, zuverlässig und skalierbar zu machen.
Tatsächlich gibt es Gründe, warum wir bei der Entwicklung von kleinen unabhängigen Produktprototypen besonders schnell skalierbare Lösungen entwickeln können. Ehrlich gesagt, wenn die Software, die ich schreibe, nur auf meinem Laptop läuft, sind die Anforderungen an Skalierbarkeit und sogar Sicherheit viel geringer, weil ich nicht vorhabe, meinen eigenen Laptop zu attackieren. Also ist es okay, wenn ich nicht so viele Firewalls habe, solange ich keine sensiblen Informationen preisgebe oder andere Schlimmes tue. Daher ist der Arbeitsaufwand für die Entwicklung von Prototypen viel geringer und die AI senkt diesen Kosten weiter und macht es auch sicherer.
Vor einigen Jahren hatte das Motto "Bewege dich schnell und breche Dinge" (Move fast and break things) in Silicon Valley einen schlechten Ruf, weil es tatsächlich einige Dinge kaputt gemacht hat. Ich denke, dass manche Leute daraus den Schluss gezogen haben, dass Silicon Valley zu schnell voranschreitet und man nicht so schnell entwickeln sollte, aber das ist falsch. Das Motto meines Teams lautet "Bewege dich schnell und übernehme Verantwortung" (Move fast and be responsible). Ich habe festgestellt, dass viele intelligente Teams Wege finden, eine Sandbox-Umgebung zu schaffen, so dass man nicht Software an Millionen von Menschen sendet, die sie möglicherweise irgendwie schädigen könnte. Aber man entwickelt einen Prototypen und testet ihn persönlich. Man geht davon aus, dass man sich nicht allzu sehr selbst schädigt. Wenn das Large Language Model einmal eine falsche Antwort gibt, kann man also schnell handeln, aber in einer sicheren Sandbox, um ein Prototypen zu entwickeln und dann zu entscheiden, ob man Sicherheitsmaßnahmen ergreifen muss und dann zu messen.
Eines der Merkmale von AI-gestütztem Programmieren ist, dass es in den letzten Jahren mehrere Wellen von Innovationen gegeben hat, mehrere Generationen von Innovationen. Ich denke, dass die automatische Codegenerierung von GitHub vor zwei Jahren eine riesige Innovation war, aber inzwischen haben wir weit darüber hinausgekommen. Dann kam es zu einer Welle von AI-unterstützten integrierten Entwicklungsumgebungen (IDE). Ich benutzte damals oft Windsurf oder Cursor. Gleichzeitig gab es auch Unternehmen wie Replit, Bolt, V0 und vielleicht auch Lovable. Und erst vor ein paar Monaten oder in den letzten Monaten kam es zu einer weiteren Welle von hochgradig agierenden Programmierassistenten wie Claude Code, Gemini CLI, Codex. Einige von Ihnen wissen, dass ich persönlich oft Claude Code benutze, oder? Aber in zwei Monaten werde ich vielleicht wieder etwas anderes sagen, was ich benutze.
Ich habe festgestellt, dass sich die Werkzeuge sehr schnell weiterentwickeln und dass dies tatsächlich erhebliche Veränderungen mit sich bringt. Der Unterschied zwischen der Nutzung der neuesten Generation von Werkzeugen und der Nichtnutzung ist sehr groß. Vielleicht sind die Large Language Models inzwischen ausgereift genug, dass es für viele kommerzielle Anwendungen mehrere Modelle gibt, die ausreichen. Aber das Gebiet des Programmierassistenz ist eines der Bereiche, in denen sich die Dinge sehr schnell entwickeln. Ein Rückstand von einer halben oder einer ganzen Generation macht bereits einen sehr wesentlichen Unterschied. Wenn man dagegen ein Large Language Model benutzt, das sechs Monate alt ist, ist das für viele Anwendungen vielleicht nicht so schlimm.
Eine andere aufregende Entwicklung, die ich beobachtet habe, ist, dass der Code einst ein sehr wertvolles Produkt war. Die Entwicklung von Code mit traditionellen Software war sehr schwierig und der Code musste gewartet und aktualisiert werden. Aber der Wert des Codes als Produkt sinkt, weil die AI ihn für uns schreiben kann. Selbst die Wahl einer Architektur ist jetzt eher eine "reversible Entscheidung", wie Jeff Bezos es nennt. Man kann eine Entscheidung treffen und wenn man sie nicht mag, kann man sie ändern.
Früher hat man eine Datenbankstruktur festgelegt und wollte sie nie wieder ändern. Aber jetzt ist es okay, wenn man die falsche Datenbankstruktur hat. Man kann die AI die Migration durchführen lassen, und das ist nicht so schmerzhaft. Also erkunde ich manchmal an einem Tag drei völlig verschiedene Architekturen und alles ist in Ordnung. Und vielleicht sage ich nächste Woche: "Wissen Sie was? Lassen Sie uns unser Code-Repository verwerfen und alles von Grund auf neu aufbauen." Dies wird dazu führen, dass die Menschen über Software auf eine ganz neue Art und Weise nachdenken.
Eines der aufregenden Dinge, über das ich später noch sprechen werde, ist, dass Silicon Valley, ich denke, alle hier im Raum und alle, die das Live-Streaming sehen, tatsächlich an der Spitze in diesem Bereich stehen. Ich werde später noch darauf eingehen.
Aber einer der größten Veränderungen, die ich im Softwarebereich beobachte, ist, dass wenn das Bauen von Software einfacher wird, die Entscheidung, was man bauen soll, zum größeren Engpass wird. Ich nenne dies immer den "Produktmanagement-Engpass" (Product Management Bottleneck).
Also im AI Fund, wenn wir Produkte entwickeln, versuchen wir, einen sehr schnellen Iterationszyklus zu etablieren. Wir schreiben Software, um einen Prototypen zu entwickeln, vielleicht einen schnellen und unpolierten Prototypen. Dann machen wir einige Produktmanagement-Aktivitäten, holen Benutzerrückmeldungen ein, formen unsere Vorstellung vom Produkt und aktualisieren so, was wir bauen möchten. Wir iterieren schnell um diesen Zyklus herum, um die Intuition für die Benutzer zu entwickeln und ein besseres Produkt zu erhalten. Für mich ist dies ein Kernzyklus, den viele meiner Teams im AI Fund und DeepLearning.AI nutzen, um die Softwareentwicklung voranzutreiben.
Wegen der AI-Programmierassistenz und der schnellen Engineering-Methoden können wir jetzt Software schneller entwickeln als je zuvor. Das bedeutet, dass die Benutzerrückmeldung und die Feinabstimmung unserer Intuition für das, was die Benutzer wirklich wollen, immer größer werdende Engpässe darstellen. Früher hat es mich drei Wochen gedauert, einen Prototypen zu entwickeln und eine Woche, um Designstudien oder andere Aktivitäten durchzuführen, und das war okay. Also drei Wochen für das Schreiben von Code und eine Woche für die Benutzerrückmeldung. Aber jetzt, wenn wir in einem Tag Software schreiben können, fühlt es sich wie eine Ewigkeit an, eine ganze Woche für die Benutzerrückmeldung zu verbringen.
Also eine interessante Tendenz, die ich beobachtet habe, ist, dass viele meiner Teams immer häufiger intuitiv Entscheidungen treffen, weil es ein sehr schneller Entscheidungsprozess ist. Ich bin ein Datenmensch, ich liebe Daten, ich forsche an AI-Daten und ich spreche über datenzentrier