Der wahre Engpass: Warum schnelleres Coden mit KI Projekte nicht beschleunigt : dach

[–] HaraldvonBlauzahn@feddit.org 39 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

Das ist wirklich so, dass Softwareentwickler nur sehr wenig Zeit mit dem Eintippen von Code verbringen. Ich selber hatte zum Beispiel zwei Mal neue Projekte mit komplexen Anforderungen, wo ich jeweils in etwa 5 Jahren rund 50000 bis 60000 Zeilen Code geschrieben habe (und weit über 200 Seiten Dokumentation). Tatsächlich ist es extrem produktiv, in einem Jahr 10000 Zeilen gut funktionierenden, nahezu fehlerfreien, gut wartbaren, dokumentierten Code zu schreiben, und in einem größerem Projekt fast nicht möglich, da die Geschwindigkeit aufgrund der wachsenden Komplexität stark sinkt. Ein Projekt wie der Linux-Kernel mit vielen Millionen Zeilen komplexen Code repräsentiert einen unfassbar großen Wert an Arbeitszeit. (Schätzungen von 2018 geben 14 Milliarden Dollar Wert für "nur" 20 Millionen Zeilen Code an, d.h. die Erstellung und Pflege von einer Zeile Kernel-Code kostet aktuell rund 700 Dollar!).

Diese 10000 Zeilen sind, bei rund 250 Arbeitstagen im Jahr, 40 Zeilen Code pro Tag - deutlich weniger als eine Seite. Softwareentwickler tun halt zeitlich gesehen zu 90% (und bei Legacy Code zu 98%) andere Dinge, als Code zu schreiben - z.B. klären sie überhaupt erst mal, was der Code tun muss.

Eine gute Metrik für die Komplexität von Programmcode ist, die Zahl der darin enthaltenen Symbole zu vergleichen mit den Vokabular einer Fremdsprache. Einen fließenden Wortschatz von 5000 Worten wird man normalerweise erst nach Jahren steter Übung erwerben. Bei Programmcode ist es so, dass ein Programm von 50000 Zeilen Länge vielleicht so 5000 oder 6000 Symbole enthält - und deren Bedeutung muss man lernen, ganz wie eine Fremdsprache. Deswegen ist die Wartung von umfangreichem altem Code so zeitaufwendig und schwierig.

Deswegen könnte KI das auch selbst im besten Fall in Wirklichkeit nicht mehr als um ein paar Prozent beschleunigen - selbst wenn die Zeit für die Eingabe von Code auf Null sinken würde. Und eine Beschleunigung setzt ja noch voraus, dass die Beseitigung der Fehler (Debugging) nicht länger dauert als nach manueller Eingabe. Letzteres ist aber in der Praxis schon nicht der Fall.

[–] homoludens@feddit.org 11 points 2 weeks ago (1 children)

Den Vergleich mit einem Fremdsprachen-Vokabular finde ich spannend, das merke ich mir :)

[–] HaraldvonBlauzahn@feddit.org 5 points 2 weeks ago* (last edited 2 weeks ago)

Eine Konsequenz der Tatsache, dass man den Zusammenhang und die Bedeutung der Namen in einer größeren Codebasis regelrecht erlernen muss, ist dass es wegen der Menge an Details nur durch häufige Wiederholung geht. (Ins Kurzzeitgedächtnis passen bekanntlich nur ca. sieben Dinge rein ).

Und dass es bei Legacy Code extrem hilfreich ist, sich auf Geschriebenes zu stützen, denn das vereinfacht die Wiederholung .

[–] aard@kyu.de 3 points 2 weeks ago (4 children)

Ich sehe vor allem bei kleinen, klar abgegrenzten Projekten einen Vorteil - Dinge die man in 10-20k Code machen kann. Danach bekommt das LLM auch massiv Probleme, und macht zu viel Duplizierung von Code - ab der Schwelle etwas ist es fast immer schneller ein Problem selber zu beheben.

Auch um da hinzukommen braucht es recht viel Anleitung - das ist praktisch wie wenn man einen Berufsanfaenger anleitet der alle Patternbooks auswendig gelernt hat, aber nicht so richtig versteht wie man das in eine funktionierende Anwendung zusammensetzt. Wirklich gute Erbebnisse bekommt man auch nur wenn man von Anfang an so arbeitet dass die KI ihren Code testen kann (wer schon laenger dabei ist wird sich an "test driven development" erinnern - die Methodik ist ideal mit KI). Aber auch da gibt es Ausreden ("ich hab den Test nicht kaputtgemacht, der hat noch nie funktioniert"), und oft genug Probleme die sich mit Erfahrung schneller (und eventuell billiger) loesen lassen als mit KI. Man sieht da recht schoen dass der erzeugte Code am Anfang oft nicht compiliert - ohne dass die KI selber Compilieren kann scheitert das schon daran. Und bei Problemen werden so lange Variationen durchprobiert bis das tut - was sehr schoen zeigt dass eben keinerlei Codeverstaendnis vorhanden ist.

Gerade bei existierenden Projekten fuehrt das dann dazu dass die vorgeschlagenen Aenderungen deutlich groesser sind als noetig - was fuer die Nachvollziehbarkeit spaeter ein Problem ist.

Wir machen als Firma viel um CI und Testautomatisierung - und haben da immer wieder Bedarf an spezialisierten und relativ kleinen Tools. Fuer den Spezialfall ist das ideal - das ist so Groessenordnung 20 EUR API-Credits und ein Tag Anleitung, gefolgt von 3-4 Tagen Code saubermachen gegenueber 2-3 Wochen komplett selber machen.

Ich koennte mir denken dass man in einer reinen Microservicesumgebung (sofern man die einzelnen Services bei 10-20k LOC halten kann) damit die Entwicklung deutlich beschleunigen kann - das trifft aber eben nur auf einen Bruchteil der Software da draussen zu.

[–] HaraldvonBlauzahn@feddit.org 7 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Übrigens fällt dieser Beitrag (und einige weitere hier im Faden) exakt in das Muster, das ich erst heute morgen in meinem Kommentar auf c/programning@programning.dev als eine weitere Marketing-Strategie unter einem Arsenal von Strategien beschrieben habe, mit der versucht wird GenAI unter Softwareentwicklern an den Mann, bzw an die Frau zu bringen:

da wird erstens eingeräumt, dass GenAI unter bestimmten Bedingungen (Entwickleunerfahren / zu erfahren / Problem zu komplex / keine genaue Spezifikation / Lösungsstrategie schon klar usw.) keinen Vorteil bringt
und dann wird behauptet, dass es aber unter anderen Bedingungen (Entwickler erfahrener / weniger erfahren / genaue Spezifikationen vorhanden / Problem nicht definiert / Problem einfach / "Boilerplate") dann doch angeblich einen Vorteil hat.

Belege für diese angeblichen Vorteile gibt es nie.

Eindeutige Untersuchungen, die z.B. Vorteile für erfahrene Entwickler belegen, gibt es nicht.

Offizielle Angaben, wozu KI nun gut geeignet sein soll und wozu nicht, gibt es keine.

Das ist letztlich eine Variante von "moving the goal posts".

[–] aard@kyu.de 3 points 2 weeks ago (2 children)

Ich beschreibe hier lediglich meine eigenen Erfahrungen - ich halte nicht viel davon Dinge blind zu hassen ohne sich das naeher angeschaut zu haben. I spiele seit etwa drei Jahren mit LLMs, hauptsaechlich auf lokaler Hardware. Die letzten Monate kamen Claude credits dazu weil es fuer bestimmte Probleme tatsaechlich Sinn gemacht hat.

Mein Hauptproblem mit LLMs ist der massive Energieaufwand, vor allem fuer Training - da sollte reguliert werden dass das zwingend erneuerbare Energien sein muessen (und zwar dafuer neu gebaut, nicht bestehende), und entsprechende Strafzoelle auf Benutzung von LLMs ausserhalb von EU wo wir nicht regulieren koennen. Das naechste ist dass der aktuelle Hype zum einen eine unnoetige Investitionsblase ist, zum anderen dann ohne Nachzudenken ueberall LLMs eingebaut werden, ohne dass verstanden wird zu welchem Zweck, oder auch wie das Fehlerverhalten ist. Zu Fehlerverhalten bei Codegenerierung habe ich oben ja was geschrieben - ich hab bisher grob 100EUR an Claude Credits verbrannt einfach nur um zu beobachten wie das Ding versucht weiterzumachen wenn es steckenbleibt (tl;dr: in dem Fall ist es praktisch immer besser das von Hand zu machen - teilweise ist es klar billiger, und ansonsten wird ziemlich sicher der erzeugte Code scheisse sein, bzw, deutlich zu viel neu schreiben).

Ich gehe davon aus dass wir langfristig mit LLMs arbeiten werden - aber sicher >95% der aktuellen Einsatzzwecke ein Platzen der Investitionsblase nicht ueberleben werden, aus einer Kombination von "das war von Anfang an doof" und "nachdem die jetzt tatsaechliche Kosten bezahlt haben wollen ist das zu teuer". Ich gehe auch nicht davon aus dass bei Bezug auf Code wir eine Verbesserung ueber die 10k-20k LOC sehen werden - auch um das zu erreichen steigt die Koordinationsarbeit vom Menschen um die relevanten Informationen im Context Window zu halten, und ein Vorhalten von nennenswert groesseren Context Windows wuerde das zu sehr verteuern.

Ich wuerde darauf tippen dass generell das Generieren von Code mit Ende der Blase deutlich weniger werden wird - das duerfte sich dann nur noch bei Modellen lohnen die man lokal laufen lassen kann. Bei Reverse Engineering und aehnlichen Analysen wuerde ich erwarten dass das weiterhin viel genutzt wird - da sind heute schon lokale Modelle recht nuetzlich.

[–] HaraldvonBlauzahn@feddit.org 4 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Ich beschreibe hier lediglich meine eigenen Erfahrungen - ich halte nicht viel davon Dinge blind zu hassen ohne sich das naeher angeschaut zu haben.

Da gibt es bei mir zwei Aspekte:

Ich halte meinerseits ganz sachlich nichts davon, so quasi das Wohlergehen der gesamten Wirtschaft auf eine angebliche Wundertechnologie zu wetten, bei der nicht ansatzweise belegt werden kann, dass die hält, was das Marketing verspricht. Extraordinary claims require extraordinary evidence.

Beim Ausgangspost ging es darum, dass ein genaues Verständnis des Codes in der Softwareentwicklung wesentlich ist, und dass der Zeitanteil für die Codeeingabe so gering ist, dass selbst eine völlig automatisierte Eingabe Softwareentwicklung gar nicht nennenswert beschleuniglen kann. Gibt es irgendwelche Evidenz, dass das nicht so ist?

Ich hasse es allerdings in der Tat, ständig Bullshit erzählt zu bekommen und damit regelrecht vollgespammt zu werden. Da finde ich es auch angemessen, mal deutlich zu werden.

[–] aard@kyu.de 1 points 2 weeks ago (1 children)

Gibt es irgendwelche Evidenz, dass das nicht so ist?

Hatte ich doch geschrieben - ich habe diverse Tools die mich etwa 2-3 Wochen Arbeit gekoestet haetten, und ich so in knapp unter einer Woche gebaut habe. Mit Aufarbeiten des Codes damit er wartbar ist - fuer Wegwerftools ist das etwa ein Tag. Weitere Entwicklung danach mach ich manuell, da taugt das nicht fuer, unter anderem wegen fehlendem Codeverstaendnis fuer das was er generiert hat. Hauptarbeit ist auch das so zu lenken dass wartbarer Code rauskommt.

Ergebnis haengt auch sehr stark von der Sprache ab - ich hatte mit Abstand die besten Ergebnisse mit elisp (und mir da auch diverse Sachen gebastelt fuer die ich sonst keine Zeit gehabt haette). Das hilft da deutlich dass es durch den lisp-interpreter gute Fehlermeldungen gibt, und die eingebaute Dokumentation exzellent ist. Da die Welt wohl leider nicht auf Emacs umsteigen wird ist das allerdings fuer die meisten Leute wohl eher nicht relevant.

[–] HaraldvonBlauzahn@feddit.org 3 points 2 weeks ago

Deine persönliche Anekdote ist keine Evidenz, weil die Nutzung von KI/GenAI es offensichtlich auch erschwert, den dadurch entstandenen Zeitaufwand realistisch einzuschätzen.

Da gibt es die METR Studie mit erfahrenen Open Source Entwicklern:

https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Surprisingly, we find that when developers use AI tools, they take 19% longer than without—AI makes them slower.

Der Knackpunkt ist, dass die Leute an ihnen gut bekannten Projekten gearbeitet haben unf auch Erfahrung mit KI Nutzung hatten.

Die hatten definierte Tasks und wurden vor dem Beginn der Arbeit gefragt, wie sie denn Zeitaufwand schätzen. Dann wurde zufällig festgelegt, ob sie für diese Task KI nutzen oder nicht. Nach Beendigung der Task wurden sie noch mal gefragt, ob sie glauben dass KI ihnen geholfen hat.

Ergebnis war, dass die Leute geglaubt haben, dass es mit KI schneller geht, dass sie aber objektiv in der Statistik deutlich(!) länger gebraucht haben, als sie geschätzt haben, dass die Aufgaben ohne KI statistisch schneller gingen, und dass sie trotzdem hinterher immer noch glaubten, dass es mit KI schneller sei.

So eine Wahrnehnungsverzerrung macht subjektive Anekdoten wertlos.

Und aus genau solchen Gründen arbeitet man in der Medizin oft mit Doppelblindversuchen und so weiter.

[–] gandalf_der_12te@feddit.org 0 points 2 weeks ago

Weiter so - lass dich nicht entmutigen :-)

Es gibt zu viele Menschen die blind KI haten weil es neu ist und Arbeitsplätze gefährdet. Der Weg in die Zukunft ist ein Bedingungsloses Grundeinkommen, nicht ein Festhalten an Jobs und einer damit einhergehenden Blindheit für die Potenziale von KI, die durchaus beachtlich sind.

[–] HaraldvonBlauzahn@feddit.org 4 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

Zu "test driven development" hat John Ousterhout einiges geschrieben in "A Philosophy of Software Design".

tl;dr: "test driven development" ist kacke.

Ousterhout nennt das "debugging a system into existence". Man erstellt erst ohne durchgängiges Konzept code mit beliebig vielen Fehlern. Dann testet man ein bisschen und beseitigt die Fehler, auf die man trifft. Fälle, die man nicht testet, werden logischerweise wahrscheinlich wieder in Fehler laufen. Weil dem Code kein solides Konzept zugrunde liegt. Weitere Änderungen macht man dann so, dass wieder mit minimalen Änderungen - kein Design, kein grundsätzliches Refactoring - die gewünschte Funktionalität zu sehen ist.

Und den Code durch ausgiebiges Testen und korrigieren einigermaßen Fehlerfrei zu machen, dauert länger als ihn gleich richtig zu designen.

[–] bleistift2@sopuli.xyz 3 points 2 weeks ago

Cool. Ich habe selbst festgestellt, dass ich mit TDD den Code mehr rate als darüber nachzudenken. Schön zu wissen, dass ich nicht der einzige bin, der so fühlt.

[–] Ephera@lemmy.ml 2 points 2 weeks ago (1 children)

Das entspricht so gar nicht meiner Vorstellung von TDD. Für mich ist TDD, dass man sich explizit vorher Gedanken macht und diese in einer Spezifikation niederschreibt. Die Spezifikation wird dabei in Form von Unit- und Integrationstests verfasst, damit automatisch geprüft werden kann, dass der Code der Spezifikation entspricht.

[–] bleistift2@sopuli.xyz 3 points 2 weeks ago (1 children)

Echtes TTD, so wie ich es gelernt habe, erfordert, dass du immer nur die kleinstmögliche Änderung an den Unit-Tests machst. Der erste Test prüft z.B. nur, ob es eine Funktion gibt. Dann schreibst du den Code, der genau diese Anforderung umsetzt, also eine Methode, die nichts macht.

Danach fügst du die nächste kleine Anforderung zum Test hinzu und programmierst dann genau die.

Vielleicht gibt’s TTD in verschiedenen Geschmacksrichtungen. Dein Ansatz umgeht zumindest den Nachteil, dass durch das inkrementelle Hinzufügen winziger Funktionen kein „im Großen und Ganzen“ sauberes Modul dabei herausfällt.

[–] Ephera@lemmy.ml 3 points 2 weeks ago

Joa, habe TDD nie als Dogma gelernt, sondern aus der Praxis, also kann gut sein, dass das was ich kenne ein pragmatischerer Ansatz ist.

Für mich war immer der relevante Aspekt, dass man eben nicht einfach drauf loscodet, sondern sich vorher Gedanken macht, was die Anforderungen sind, was wiederum eine Grundvoraussetzung für sinnvolles Design ist, daher hat mich eure Beschwerde gerade etwas überrascht...

[–] aard@kyu.de 0 points 2 weeks ago

So wie ich test driven development erlebt habe ging es darum die Tests vor der Implementation zu entwickeln - das hatte nichts mit unsolidem Konzept zu tun. Das war bei Programmierern eher ungeliebt weil das Gegenteil erforderlich war: Sie muessten sich darueber Gedanken machen wie der Code aussehen soll bevor sie den taetsaechlichen Code schreiben um dafuer sinnvolle Tests zu bauen. Das wurde oft als "das sollten doch Architekten machen" gesehen, "ich leg einfach los und das wird dann irgendwann".

[–] gandalf_der_12te@feddit.org 2 points 2 weeks ago

Ich koennte mir denken dass man in einer reinen Microservicesumgebung (sofern man die einzelnen Services bei 10-20k LOC halten kann) damit die Entwicklung deutlich beschleunigen kann - das trifft aber eben nur auf einen Bruchteil der Software da draussen zu.

Ich bin schon seit Jahren der Meinung dass jedes Projekt überhalb 30K LOC zerteilt werden muss in kleinere Teilprojekte, denn nur so bleibt ein Projekt wirklich übersichtlich. Darüber ist es praktisch nicht mehr möglich, zu durchschauen, was ein Programm überhaupt macht.

Code-Nachvollziehbarkeit hilft schon heute, und kleinere Projekte helfen mit der Code-Nachvollziehbarkeit. Leider ist es scheinbar ein Bedürfnis der menschlichen Psyche meiner Mitmenschen, ein gigantomanisches Monolith-Projekt zu bevorzugen. Denn das ist wie mit großen Autos: Hauptsache groß, dann fühlt man sich selber groß. Schlau ist das nicht.

[–] bleistift2@sopuli.xyz 2 points 2 weeks ago* (last edited 2 weeks ago)

Ich denke, da gibt es auch große Unterschiede in dem, was man programmiert. Im Web-Frontend habe ich festgestellt, dass die Aufgabe „Mach ein Formular, in das ein Nutzer x, y, z, v und falls q auch w eintragen kann” wahnsinnig viel Tipparbeit ist, weil sich die Formularfelder untereinander nicht viel (aber doch zu viel, um sie zu copy/pasten) unterscheiden.

Gleichzeitig können Formularfelder auch so individuell sein, dass es sich nicht lohnt, irgendwie ein wiederholbares Stück Code zu entwerfen (z.B. ein generisches Feld), weil das so viele Parameter entgegen nehmen müsste, dass man am Ende mehr Aufwand betreibt, als es wäre, das Feld einfach direkt zu schreiben.

In dem Punkt ist KI echt toll. Ich schreibe einmal ein Feld ins HTML, habe daneben die Datenstruktur offen und KI kann das Feld dann schlau mit den kleinen, nötigen Abweichungen kopieren.

Kürzlich hatte ich ein Formular zu produzieren, das ca. 20 Felder hatte, manche davon wiederholbar (d.h. „für jede Auswahl des Nutzers in Feld x, frage y, z und w ab). Das hätte mich geschätzt 2 Stunden gekostet. Ein Kollege hat den Fragebogen gegen ChatGPT geworfen und nach 10 Minuten ein brauchbares Gerüst geliefert, das ich nur noch 30 Minuten anpassen musste, weil in der Spezifikation das Domänenwissen fehlte.

Und zum Argument: „Ja, aber die Spezifikation aufzuschreiben, hat doch auch Zeit gekostet!” Ja – aber das hatte ich vorher schon gemacht, unabhängig davon, ob KI zum Einsatz gekommen wäre oder nicht. Ich muss ja auch wissen, was ich schreiben soll.

Zugegeben, „Programmiere ein Formular” ist nicht die hohe Kunst in der Informatik, aber ein großer Teil zumindest meines Berufs. Deshalb die Schlussfolgerung „es auch große Unterschiede in dem, was man programmiert“.

[–] aaaaaaaaargh@feddit.org 14 points 2 weeks ago (1 children)

Erzähl das mal den KI Bros auf LinkedIn. Schön, mal eine realistische Meinung dazu zu lesen.

[–] HaraldvonBlauzahn@feddit.org 10 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Der völlig überzogene Hype um generative KI zählt wohl zusammen mit der Verschleierung der realen Folgen des Rauchens zu einer der größten Desinformationskampagnen aller Zeiten.

Sehr viele der Blog Posts und YouTube-Videos die das hypen sind wohl bezahlt. Objektive Untersuchungen zur Produktivität gibt es fast keine - und die, die es gibt, fallen negativ aus.

[–] gandalf_der_12te@feddit.org 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

du hast die Klimaleugnung vergessen

"clean, beautiful coal" - Trump, vor 2 Wochen

Objektive Untersuchungen zur Produktivität gibt es fast keine - und die, die es gibt, fallen negativ aus.

Das ist übrigens bei jeder neuen Technologie so und sagst daher nichts aus.

[–] HaraldvonBlauzahn@feddit.org 1 points 2 weeks ago* (last edited 2 weeks ago)

Das ist ja mal wieder Bullshit. Es gab neue Technologien wie Eisenbahn, elektrisches Licht, Telefon und Waschmaschine, die klar erkennbare und auch messbare Vorteile hatten und sich schnell durchsetzten. Dann gab es erfolglose Technologien.

Und dann gab es Hype und Bullshit, die wirklichen Schaden angerichtet haben, wie der Gebrauch von Radium in Dingen wie Zahnpasta nach der Entdeckung der Radioaktivität durch Marie Curie.

GenAI gehört nicht zu den Techniken mit klar erkennbaren Vorteilen. Und trotzdem werden da Geldmengen rein gesteckt, die für die Stabilität der Ökonomie bedrohlich sind.

[–] Chemo@feddit.org 13 points 2 weeks ago* (last edited 2 weeks ago)

Softwareentwicklung gilt als langsam.

Ich verstehe den Gedanken aber in Wahrheit ist Softwareentwicklung extrem schnell. Ich kenne kein anderes Feld das bei ähnlicher Komplexität und technologischem Stand ähnlich schnell neue Produkte erzeugt.

[–] cows_are_underrated@feddit.org 7 points 2 weeks ago

Ich aus meiner eigenen Erfahrung kann sagen, dass die Nutzung von KI durchaus die Entwicklung verschnellern kann. Anstatt die ganzen Variablen von Hand mit den Werten aus meiner Config zu parsen, macht das halt die KI.

Jedoch muss ich auch sagen, dass die KI echt teils unfassbar beschissen darin ist Code zu schreiben (kommt auf die Sprache an) und vor allem komplexere Dinge sind faktisch nicht möglich, dass das die KI hin bekommt.

Ich will übrigens nicht dem Artikel wiedersprechen, mit Voranschreitender Komplexität wird der Koordinationsaufwand immer größer und der Kontext in dem neue Features entstehen wird immer größer. KI kann lediglich dabei helfen einzelne kleine und recht isolierte Features zu bauen oder das man lästige manuelle Arbeiten, die viel Zeit brauchen aber nicht komplex sind einfach automatisiert.

Ein Beispiel was ich letzten hatte: ich gebe einem KI Modell meine config file und das schreibt mir dann einen Parser und überprüft die Werte auf Korrektheit. Ich hätte das logisch selber machen können, hätte mich dann vermutlich 10-20 Minuten gekostet, hat mich so aber nur vielleicht 2 gekostet.

[–] gandalf_der_12te@feddit.org 6 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

The Zen of Programming:

The bad programmer writes a lot of spaghetti code that is impossible to debug or fix, so it has to be rewritten. The good programmer writes a few lines of efficient code and is done with the work. The enlightened programmer realizes this feature already exists somewhere else and doesn't have to be rewritten. The enlightened programmer writes no code.

Das Problem war nie das Schreiben von Code, sondern wie man es schafft, mit möglichst wenig Code möglichst das zu haben, was man braucht. Frei nach Elon Musk: The best part is no part. Bedeutet, wenn es ohne geht, dann besser ohne.

[–] muelltonne@feddit.org 12 points 2 weeks ago (2 children)

Interessant, dass du hier Elon Musk zitierst, der ja bekannterweise nach der Twitter-Übernahme Leute auf Basis von "Lines of code written last year" gefeuert hat.

[–] HaraldvonBlauzahn@feddit.org 6 points 2 weeks ago

Ich glaube nicht, dass das von Musk ist. Die Idee ist älter als Musk selber.

Auch die Kritik an überbordender Konplexität in Software ist nicht neu. Z.B. hat Niklaus Wirth nicht nur schon diese Kritik geäußert, sondern mit dem Projekt Oberon schon seit 1985 gezeigt, dass man Software wie ein ganzes Betriebssystem mit weniger Komplexität schreiben kann und auch schneller fertig wird. Ähnliche Gedanken hat un jüngerer Zeit Rich Hickey entwickelt , von dem es eine Reihe Brillante Youtube-Videos gibt, und der die extrem elegante Sprache Clojure entwickelt hat.

[–] gandalf_der_12te@feddit.org 3 points 2 weeks ago (1 children)

ja haha das war wohl etwas unglücklicj zitiert.

[–] muelltonne@feddit.org 6 points 2 weeks ago

Zeigt halt schön, welches gute Marketing der hatte. Dein Zitat wird irgendwer ihm geschrieben haben, er hat es ausgeplaudert, Leute haben ihn deswegen für klug gehalten. Und dann stellt sich nachher raus, dass er null Plan hat.

[–] glasratz@feddit.org 4 points 2 weeks ago (2 children)

Ah ja, Elon Musk. Der Meister der Rationalisierung. /s

[–] luciferofastora@feddit.org 4 points 2 weeks ago (1 children)

Auch ein blindes Huhn stiehlt mal ein Korn

[–] glasratz@feddit.org 2 points 2 weeks ago

Gerade ja nicht. Er hat ja das Konzept versucht mit DOGE umzusetzen und fast das Gegenteil bewiesen.

[–] MonkderVierte@lemmy.zip 2 points 2 weeks ago (1 children)

Er mag das von einem Ingenieur gestolen haben, aber wahr ist es trotzdem.

[–] glasratz@feddit.org 1 points 2 weeks ago (1 children)

Naja, ich meine eher, weil er ja tatsächlich versucht hat das im großen Stil umzusetzen und damit nur gezeigt hat, dass es eben doch nicht so wahr ist.

[–] MonkderVierte@lemmy.zip 2 points 2 weeks ago

Dochdoch. Wenn man etwas mit mehr code effizienter / schöner / besser wartbar macht, dann ist das nicht unnützer Code. Abgesehen davon ist weniger = mehr im coden. Jede Zeile Code ist eine Schuld in Wartung und Bugs.

[–] 30p87@feddit.org 6 points 2 weeks ago

Weil's dann eher Koten gleicht.

[–] MonkderVierte@lemmy.zip 3 points 2 weeks ago

So close. But they forgot at the end, that LLM "AI" is not a long-term viable business model, without delivering what it promised: obliterating the job/cost of developers.

[–] luciferofastora@feddit.org 2 points 2 weeks ago

Ich bin kein Software-Entwickler (mehr), sondern bau Datenmodelle (hauptsächlich für BI). Einiges davon sind Routine-Tasks, die bestimmt auch eine KI für mich machen könnte. Manche Tasks könnte eine KI vielleicht auch schneller als ich.

Der schwierige und zeitaufwendige Teil ist aber, die Systeme inhaltlich und technisch nachzuvollziehen. Das sind bei mir keine Standard-ERP-Lösungen von der Stange (haben wir auch, kümmert sich aber wer anderes drum) sondern Spezialisten-Systeme mit entsprechend speziellen Datenstrukturen und Anforderungen.

Damit ich überhaupt die richtigen Abfragen an die KI formulieren könnte, muss ich erst mal das System genug verstehen, um aus den Kunden (Kollegen) die Infos rauszuholen, was genau sie denn brauchen. Bis dahin ist dann zumindest ein Skelett des Modells eh vorhanden, also brauch ich die KI auch nicht mehr für viel.

[–] smokeysnilas@feddit.org -1 points 2 weeks ago (1 children)

KI Coden hat bei mir zwei Anwendungen. Einmal schnelle Skripte die nicht in den Produktivcode kommen. Sowas wie "lade die sqlite und filtere alle Einträge mit Kriterium xy aus". Sowas macht Copilot schneller als ich das runtertippen kann. Und eine bessere Autovervollständigung, was oft hilfreich ist aber manchmal auch totalen Müll produziert. Z.b. nicht existierende Variablen verwendet oder unreachable code erzeugt usw.

[–] HansGruber@sh.itjust.works 3 points 2 weeks ago (1 children)

Wie kannst du die Query schneller einer KI beschreiben als sie eigenhändig in der effizientesten Sprache hierfür -> SQL <- zu schreiben?

Also um das Offensichtliche zu benennen: würdest du SQL Lernen wärst du schneller, du wärst unabhängiger und würdest weniger Ressourcen verschwenden.

[–] smokeysnilas@feddit.org -1 points 2 weeks ago* (last edited 2 weeks ago)

Es geht mehr um den Gluecode wenn die Query eigentlich trivial ist. Sowas wie erstmal die Python Imports machen und ne main mit Argumentliste usw.

würdest du SQL Lernen wärst du schneller

Copilot macht das halt in 10sek. Ich kann schnell tippen, aber nicht so schnell.

würdest weniger Ressourcen verschwenden

100 Copilot Token sind 0,006Wh, ne durchschnittliche Anfrage liegt bei 0,4Wh. Wenn man dafür bloß 5min eher den Arbeitsrechner abschalten kann dürfte sich das lohnen.

DACH - Deutschsprachige Community für Deutschland, Österreich, Schweiz