Warum liefern wir trotz KI nicht schneller?
Why aren't we shipping faster now?
Jensen Huang versprach 2023, dank KI könne nun jeder programmieren. Doch eine wachsende Zahl von Studien zeigt: Code zu schreiben ist nicht dasselbe wie Code auszuliefern. Die zitierte Forschung – darunter eine NBER-Arbeitsarbeit zu Produktivitätseffekten verschiedener KI-Coding-Generationen und eine Untersuchung zu den Grenzen von KI-Autonomie bei Entwicklern – deutet auf eine Lücke zwischen Aktivität und Ergebnis hin. Mehr Output beim Schreiben führt offenbar nicht automatisch zu schnelleren Releases.
- swatcoder
Leider ist das eine dieser HN-Einreichungen, bei denen die Leute einfach reflexartig auf den Titel reagieren, ohne überhaupt zu prüfen, worum es in der Einreichung geht. Natürlich hilft es auch nicht, dass es sich um eine lange Videokonferenz-Präsentation mit einem „Handout“ handelt, das wunderschön, aber für sich genommen etwas schwer zu lesen ist.
Für diejenigen, die tatsächlich neugierig sind: Die Einreichung ist selbst keine zynische oder abweisende Betrachtung. Die Frage im Titel ist interrogativ und kontextbezogen, nicht rhetorisch und universell, und die Präsentation versucht, einige der Engpässe und Herausforderungen aufzuschlüsseln, die dazu führen, dass die KI-Integration einen anderen Einfluss auf die Software-Engineering-Produktion hat, als manche vielleicht erwarten.
Anstatt zu suggerieren, dass diese Engpässe/Herausforderungen universell oder unlösbar sind, zählt sie nur einige davon auf und präsentiert einige Umfrageanalysen dazu, wie verbreitet sie sind.
Es ist tatsächlich ziemlich interessant und genau die Art von Sache, über die Ingenieure und diejenigen, die mit ihnen arbeiten, nachdenken sollten, damit sie ihre Nutzung und Prozesse besser um die KI selbst herum gestalten können.
- rbehrends
Das ist etwas, worüber Brooks bereits in „The Mythical Man Month“ nachgedacht hat:
„Gelegentlich liest man Zeitungsberichte darüber, wie zwei Programmierer in einer umgebauten Garage ein wichtiges Programm gebaut haben, das die besten Bemühungen großer Teams übertrifft. Und jeder Programmierer ist bereit, solche Geschichten zu glauben, denn er weiß, dass er jedes Programm viel schneller bauen könnte als die 1000 Anweisungen/Jahr, die für industrielle Teams gemeldet werden. Warum wurden dann nicht alle industriellen Programmiererteams durch engagierte Garagen-Duos ersetzt? Man muss sich ansehen, was produziert wird.“
Brooks argumentiert, dass das Programmieren in der Garage nur ein Bruchteil dessen ist, was man für das Endprodukt braucht:
„Es kostet neunmal so viel. Aber es ist das wirklich nützliche Objekt, das beabsichtigte Produkt der meisten Systemprogrammierungsbemühungen.“
Was wir gerade sehen, fühlt sich nicht viel anders an. Man kann einen ersten Entwurf, ein Greenfield-Projekt, ein Experiment oder zumindest die erste Iteration davon stark beschleunigen. Ein laufendes Produktionssystem oder eine weit verbreitete Bibliothek zu ändern, ist eine ganz andere Sache.
- 9cb14c1ec0
Ich liefere so viel mehr aus, aber ich weiß nicht, ob unsere Kunden das unbedingt merken würden. Komplette Rewrites, die nötig waren, aber wegen des Umfangs aufgeschoben wurden, werden jetzt erledigt. Sicherheitsprobleme werden gepatcht. Die Zeit von der Eröffnung eines Support-Tickets bis zur Lösung sinkt. Also ja, wir liefern viel schneller aus, um ein viel besseres Projekt zu schaffen, anstatt uns nur auf Features zu konzentrieren.
- degreesoffun
Eine Dynamik, die das KI-Coding eingeführt hat, ist, dass Features nach ihrer ersten Entwicklungsiteration im Vergleich zum Coding vor KI wachsen und „vollständiger“ oder „komplexer“ sind. Ein Beispiel dafür ist, dass ich kürzlich einen Web-Crawler für eine interne Dokumentationsseite in meinem Unternehmen gebaut habe. Mein Design zum Scrapen, Parsen, Vektorisieren und Indexieren der Daten war weitaus komplexer/vollständiger, als wenn ich keine KI verwendet hätte. Das liegt vor allem an meinem mangelnden Wissen in diesem Bereich und den allgemeinen Zeitbeschränkungen für das Projekt.
Diese erhöhte Komplexität, obwohl kostengünstiger als zuvor, fügte dem Projekt dennoch Zeit/Kosten in Form von kognitiver Belastung und Tests hinzu, die es sonst nicht gegeben hätte, wäre das Design „dümmer“ gewesen. Diese Vorstellung von erhöhter Designkomplexität könnte man als eine Form von Parkinsons Gesetz betrachten, bei der die Komplexität des Designs wächst, um die verfügbare Zeit auszufüllen.
Ich denke, KI macht uns sicherlich schneller beim Schreiben von Code, aber wie viel Zeit wird wirklich frei, jetzt wo das Schreiben von Code billiger ist? Ich habe den Eindruck, dass wir oft einfach andere Dinge finden, um diese freigewordene Zeit zu füllen, wobei erhöhte Designkomplexität eines davon ist.
- throwitaway222
Mehr Tickets und größere Tickets, vollständige Migrationen, die früher 4 Wochen in Abstimmung mit 3 Teams dauerten, sind jetzt ein einzelner PR, der an einem Tag erledigt wird.
Edit: Wenn du eine Verlangsamung bei PRs siehst, liegt es eher daran, dass 10 deiner 10x'ler während ihrer Schicht bei 8 Startups nebenbei in 3-4 plus Accounts in Codex Code schmeißen.
- choult
Die Begeisterung für LLMs drehte sich um die Produktivität der Ingenieure, nicht um die Qualität der Projekte. Traditionell haben wir Engpässe in den Review- und QA-Phasen für neue Arbeit, und viele Organisationen drehen den Wasserhahn für neuen Code auf, ohne diese Engpässe zu beheben.
Wenn du mit hoher Geschwindigkeit fahren willst, musst du zuerst eine Autobahn bauen.
- MisterPea
Ich habe das Gefühl, verrückt zu werden, bei all den Leuten, die die Auswirkungen von KI in der Softwareentwicklung infrage stellen.
Ich glaube, die Leute haben schon vergessen, wie lang und mühsam Softwareentwicklung noch vor ein paar Jahren war.
Der größte Engpass ist jetzt CI/CD/Experimentierung in Bezug auf das Engineering und die Produktausrichtung in Bezug auf das Geschäft.
- 0xb0565e486
Sind wir. Ein Monat Arbeit wurde zu einem Tag.