Max von WebelSehr schöner ChatGPT Takedown an einem sehr simplen aber extrem lustigen Beispiel https://mindmatters.ai/2025/08/chatgpt-5-tries-out-rotated-tic-tac-toe-you-be-the-judge/
Ralf Stockmann
@rstockm Abgesehen davon, dass ich so eine „aber dieses 0.0.1 Update ändert alles“ Argumentstion sehr dünn finde. ChatGPT 5.2 ist kaum mehr als ein marketing Update über 5.0, es ändert nichts daran wie diese Modelle funktionieren und ändern somit auch nichts an der fundamentalen Kritik selbst wenn die neue Version bei dem konkreten Beispiel vielleicht marginal besser abschneidet.
@343max Na ja, es ist aber halt andersrum: dieses „Beispiel" funktioniert bei exakt KEINEM der aktuellen Flagship-Modelle. Getestet: Mistral (lokal!), Gemini 3 Pro, ChatGPT 5.2, Claude Sonnet 4.5.
Keines fällt darauf rein, die Antwort von Gemini mal als hübsches Beispiel.
Und so läuft das seit 2 Jahren:
10 „haha, schaut was die GPTs alles nicht können"
20 ich setze mich 1 Minute dran und exakt das funktioniert in allen neuen Modellen
30 goto 10
🤷🏻♂️
@rstockm Aber ich habe dir doch eben einen Screenshot geschickt wie das aktuelle ChatGPT genau darauf reinfällt.
Für mich ist es exakt andersrum wie du beschreibst. Seit Jahren:
10 du und andere AI believer: “ja, noch vor ein paar Wochen war das Modell noch strunzdumm, aber heute können sie exakt dieses eine Beispiel lösen, darum sind sie perfekt”
20 jemand findet ein neues Beispiel wie ein "Flagship-Model" haarstäubend dumme weise auf die Fresse fällt… (1/2)
30 die AI Firmen bringen neue Modelle raus die auf exakt diesen Fall nicht mehr reinfallen
40 goto 10
le sigh
Wir haben exakt die selbe Diskussion schon diverse Male geführt. Was bringt dich auf die Idee das ChatGPT 5.2.4 Code Red Edition dieses mal aber wirklich all die Versprechen einlöst, die all die anderen Versionen nicht einlösen konnten? (2/2)
@343max Ich rede nicht von ChatGPT sondern generell von den rechts unten Modellen, auch der anderen Hersteller. Bei deinen Screenshot kann ich nicht sehen, welches das ist. Das mit Abstand beste Besispiel das du bisher hattest war das Zahlenraten-Spiel, weil es so hübsch die Schwäche von LLM (will alles könne) mit den Limitierungen (unfähig, eigene Grenzen zu erkennen) exploited hat. 1/2
@343max Aber auch dort habe ich in 20 Minuten einen Weg gefunden (dank KI) um dieses Spiel auf beliebigen LLMs zu 100% perfect „ready to ship“ laufen zu lassen.
Und darum geht es mir: mir gehen wirklich die Szenarien aus, wo LLMs mit etwas Tuning, RAG Modellen etc. _nicht_ zu "ready to ship" zu bringen sind. Da ist mir dann AGI ziemlich egal.
Gemini 3 Pro kann meine Handschrift lesen, und zwar perfekt. das schaffen 99% der Menschen um mich herum nicht - was für eine Basis für Automatisierung!
Und darum geht es mir: mir gehen wirklich die Szenarien aus, wo LLMs mit etwas Tuning, RAG Modellen etc. _nicht_ zu "ready to ship" zu bringen sind. Da ist mir dann AGI ziemlich egal.
Gemini 3 Pro kann meine Handschrift lesen, und zwar perfekt. das schaffen 99% der Menschen um mich herum nicht - was für eine Basis für Automatisierung!
@rstockm Das Beispiel mit dem Zahlenratespiel gilt exakt so noch heute. Das eine LLM so ein Zahlenratespiel in Software gießen kann war nicht die Aufgabe, das ist trivial für eine LLM weil es dafür Millionen Codebeispiele gibt. “Ja, es kann das nicht aber dafür kann es was anderes” ist keine Lösung des Originalproblems.
@343max Oh das war ohne Software, nur über einen Prompt.
@rstockm Exakt. Du lässt die AI ein anderes Problem lösen als das was ich ihr gegeben hatte. Was ist damit bewiesen außer das es andere Probleme möglicherweise lösen kann. (Ich bezweifle übrigens nach wie vor, dass dein Beispiel besser funktioniert als meins, du hast es einfach nur viel komplexer gemacht, was es mühseliger macht die Schwächen zu finden. Abgesehen davon, dass es ein komplett anderer Prompt ist)
@343max Das ist mir als Produktmanager aber doch völlig egal. Es ist "ready to ship“, das zählt. Und es kann ja ausprobiert werden - funktioniert wunderbar und 100% zuverlässig.
@rstockm Aber MIR ist es nicht egal. MIR ist es schon wichtig, dass eine AI ein sehr einfaches Problem das jeder Mensch problemlos lösen kann von dem die AI behauptet es lösen zu können dann auch lösen kann. Ich habe dieses Beispiel gewählt, weil es sehr anschaulich macht, wie die AI es einfach per Design nicht kann.
@rstockm Du sagt “aber es kann ein komplett anderes Problem lösen und das reicht mir”. Okay. Aber stimmst du mir zu, dass es das eigentliche von mir beschriebene Problem nach wie vor nicht lösen kann?
@343max Ich glaube in der Sache sind wir gar nicht weit auseinander, wir haben nur sehr unterschiedliche Perspektiven auf die Grundfrage. These:
1)
Ralf: zentral ist, dass ein Problem verlässlich mit LLM gelöst werden kann. Egal wie der Weg ist.
Max: zentral ist: dass auch der komplette Weg vom LLM perfekt gegangen wird ohne Begleitung
2)
Ralf: nutzt ausschließlich die besten für Geld verfügbaren Modelle, ignoriert den Rest
Max: nutzt was gerade da ist, auch die freien Versionen
1)
Ralf: zentral ist, dass ein Problem verlässlich mit LLM gelöst werden kann. Egal wie der Weg ist.
Max: zentral ist: dass auch der komplette Weg vom LLM perfekt gegangen wird ohne Begleitung
2)
Ralf: nutzt ausschließlich die besten für Geld verfügbaren Modelle, ignoriert den Rest
Max: nutzt was gerade da ist, auch die freien Versionen
LBDie prinzipiellen Schwächen dieser Systeme ignoriert er oder erzählt mir das wenn ich nur wohlhabender wäre und 200€/Monat Abos hätte alles total toll wäre (kann ich halt nicht überprüfen und scheint mir auch nicht glaubhaft) (2/2)
@343max Das Schöne ist ja, dass es Forschung gibt und die ist bisher ziemlich eindeutig. Man fühlt sich als Softwareentwickler mit LLM-"Unterstützung " deutlich produktiver als man tatsächlich ist.
@rstockm @343max 2020 ist nicht ganz 10 Jahre her. Und ja, ich habe das Gefühl, dass es in den letzten 1-2 Jahren eher eine Stagnation gibt
@rstockm @343max Bisher hat mich noch kein LLM für die Softwareentwicklung überzeugt. Ja, die kotzen schnell einen Prototypen raus, aber sobald die echte Welt damit in Verbindung kommt, explodiert alles.
Für kleine Nischenprobleme kann es vielleicht was taugen, aber da sind spezielle Lösungen sicher besser als LLMs.
@lbenedix @343max Alles hier aus den letzten 2 Jahren dazu zwei nicht öffentliche die noch komplexer sind:
https://github.com/rstockm?tab=repositories
Es kommt halt auch darauf an ob man die LLMs beim Coden als Gegner sieht den man aufs Kreuz legen möchte oder als endlos geduldig motivierten Junior DEV den man ins eigene Projekt einarbeitet.
@343max @rstockm Bei der Beurteilung, ob ein LLM gute Arbeit macht, spielen viele psychologische Verzerrungen mit. Es fängt schon damit an, dass man selbst etwas tut, also einen Prompt formuliert und dann passiert etwas. Das ist natürlich toll.
Aber ja, es gibt glaub ich kein erfolgreiches Open Source Projekt, bei dem der überwiegende Anteil der Contributions von LLMs kommt. Oder?
@lbenedix @343max Schön, dass ihr euch einig seid, dass meine Apps alle unterkomplex sind. Was ich sagen kann:
1) ich habe keine Zeile davon selbst geschrieben
2) keines der Projekte hätte ich angefangen ohne LLMs (ich kann kein JavaScript)
3) die Oneshot Quote ist mit den Monaten kontinuierlich gestiegen, bei Testabend fast alles bis auf mobil CSS
4) Einigen der Tools würde ich doch gesellschaftlichen Nutzen zuschreiben wie Mastowall, Mastotags oder Fedipol.
1) ich habe keine Zeile davon selbst geschrieben
2) keines der Projekte hätte ich angefangen ohne LLMs (ich kann kein JavaScript)
3) die Oneshot Quote ist mit den Monaten kontinuierlich gestiegen, bei Testabend fast alles bis auf mobil CSS
4) Einigen der Tools würde ich doch gesellschaftlichen Nutzen zuschreiben wie Mastowall, Mastotags oder Fedipol.
Uckermark MacGyver 
@343max @rstockm @lbenedix Aber bei komplexen Projekten arbeitet man doch nicht mit dem EINEN prompt. Man führt eine Unterhaltung mit dem LLM, beschreibt seine Ideen, das LLM fragt nach, schreibt die Specs auf , macht Designvorschlaege etc. und am Ende schreibt es auch noch den Code. Das ist durchaus ein iterativer Prozess. Das funktioniert nach meiner Erfahrung ziemlich gut. In diesem Prozess muss das LLM aber nichts Neues lernen. Nur vorhandenes "Wissen" über Software richtig anwenden. Und das können die Dinger ziemlich gut.
@maxheadroom @rstockm @lbenedix Ja, so nutze ich coding Assistants. So wie ich diese Tools nutze haue ich einen Prompt rein, schaue mir ein paar Sekunden oder Minuten später das Ergebnis an, werfe es weg, fixe es oder akzeptiere es.
Aber in diesem Strang ging es ja genau darum wie Ralf verlässlich Probleme von einer AI lösen lässt, also sie Code schreibt, Tests schreibt, Bugs fixt etc ohne das man ihr dabei ständig die Hand halten und neue Anweisungen geben muss.
@343max @rstockm @lbenedix Ich denke das würde gehen, wenn Du Spezifikationen im vornherein genau weißt und dem LLM sehr präzise Anweisungen gibst und es dann machen lässt. Ggf. braucht es Agenten die sich gegenseitig überwachen.
Aber genau das gleiche Problem hast du ja mit menschlichen Entwicklern auch. Am Anfang steht erstmal eine Produktidee und die musst entwickeln. Die wirfst du ja dem Entwickler auch nicht einfach hin und nach ein paar Stunden oder Tagen kommt es genau so raus wie du es dir vorgestellt hast.
@maxheadroom @343max @rstockm man muss nur die Spezifikation ganz genau formulieren... Joah... Dann kann man auch mit Menschen mit echter Intelligenz zusammenarbeiten
@lbenedix @343max @rstockm Ja, genau. Nur schreiben die LLMs dann viel schneller den Code und debuggen usw. Aber dem Conversationsteil fand ich schon ähnlich zur Arbeit mit mehreren Leuten. Kommt vielleicht einem Outsourcing Projekt am nächsten wo man dem Dienstleister genau erklärt was man haben will. Je genau man das erklärt , desto besser das Ergebnis
@maxheadroom @rstockm @lbenedix Nach meiner Erfahrung geht das nicht wirklich, weil die LLM sich dann meistens irgendwann auf die Fresse packt oder der Kontext vollläuft und sie anfängt Amok zu laufen.
Außerdem klingt das für mich extrem nach Wasserfall.
Mit den menschlichen Entwicklern könnte man schnell iterieren, vielleicht sogar den eigenen Stolz überwinden und selbst ein wenig programmieren lernen auch wenn das natürlich eigentlich unter dem Niveau eines Managers ist.
@343max @maxheadroom @rstockm spec driven development heißt das heute und klingt sehr danach, dass man "agile" ohne Menschen macht. 🫣
Mindestens für größere Projekte sehe ich das nicht so bald kommen.
@343max @rstockm @lbenedix ja, das ist "Wasserfall". Aber egal wie du es nennst, die Dinger sind dabei einfach zig mal schneller beim Schreiben von Code, beim lesen langer Fehlermeldungen, beim recherchieren in Dokumentation etc. Und das ist ein sehr großer Vorteil.
Es entsteht einfach viel Software die es so nicht geben würde weil jemand mit zu wenig skills oder Geduld/Zeit sich nicht an seine Idee rangetraut hat. Mit einem Coding Assistant kann so jemand solche Ideen komplett umsetzen.
Was glaube ich auch nicht zu verachten ist, ist die "Attitude" des LLM. Das ist immer nett und will dir helfen. Egal wie dumm du dich anstellst. Stellst Du menschlichen Enticklern eine Frage die dich als Anfänger outed bekommst du mit hoher Wahrscheinlichkeit eine anfällige oder sehr oberlehrerhafte Antwort. Das motiviert nicht immer dran zu bleiben.
@maxheadroom @343max @rstockm Ich bin immer vorsichtig dabei, LLMs zu vermenschlichen. Ein LLM lernt nicht und recherchiert nicht.
Und ob jeder mit wenig skills Software schreiben sollte ist ich ein bisschen fraglich. Kleine Spielprojekte, die einem selbst das Leben erleichtern sind wohl unproblematisch, aber wie oben schon geschrieben gibt es meines Wissens nach kein größeres Open Source Projekt bei dem ein signifikanter Teil des Codes durch LLMs generiert wurde.
@maxheadroom @rstockm @lbenedix Ich habe nicht bestritten das LLMs ihren Wert haben können. Wir reden hier aber von Autonom, Zuverlässig Qualitativ hochwertige Software auf dem Niveau eines junior Devs. Davon sind LLMs meiner Meinung nach weit entfernt. Ralf ist sehr Stolz darauf keine Ahnung von JS zu haben und ich finde das sieht man den Projekten auch an. Schon die Readme’s sind ausufernder AI Slop mit offensichtlichen Fehlern und Text nur um Text zu haben. (1/4)
Der Code ist nicht wartbar, dain jemals einen Bug zu finden dürfte erstmal massives Refactoring voraussetzen. Was ist der Wert von solchem Code über den reinen Gebrauchswert hinaus? Wie soll sowas weiterentwickelt werden, wie soll das gewartet werden? Und wäre es jetzt so ein massiver sozialer Abstieg ein ganz klein wenig Coden zu lernen um das wenigstens wartbar zu machen? (2/4)
Was ist der Wert all dieser zusätzlichen Software? Ich habe mit LLMs eine Katzenfutter Tracking App gebaut. Das hätte man auch in Excel oder AirTable zusammenklicken können, ganz ohne sich böse Codingskills aneignen zu müssen. Software an sich hat ja keinen Wert, im Gegenteil sie verursacht in erster Linie Kosten, darum probieren wir ja alle wie so wenig davon zu produzieren wie es geht. Das ist doch so als würde man ImageGen damit vertreidigen, dass es mehr Bilder produziert. (3/4)
Wir brauchen aber nicht mehr Bilder. Wir brauchen auch nicht mehr Software. Wir brauchen bessere Software die Menschen ermöglicht produktiver zu sein, die einfach wartbar ist, keine hohen Folgekosten hat, zuverlässig ist. Sich von einer LLM irgendeine App zusammenschrauben lassen ist da doch nicht nur keine Verbesserung sondern sogar eine Verschlechterung. (4/4)
Und ich sehe nicht, dass mich LLMs massiv produktiver machen. Sehe ich nicht. Wenn dann vielleicht 10%. Wenn man noch mal in Betracht zieht wie wenig seiner Zeit Entwickler mit programmieren verbringen, dann ist das kaum mehr als ein Rundungsfehler. Im besten Fall.
Aber hey, wir können jetzt endlich simpelste Greenfield Tools von einer LLM bauen lassen und können weiterhin überall rumerzählen, dass wir dafür nicht mal die Sprache lernen mussten wie so ein Loser.
@343max es ist sogar noch schlimmer. Laut dieser Studie verliert man Produktivität wenn man AI einsetzt.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
@343max Puh, ich weiß gar nicht wo ich hier anfangen soll, und es dreht sich im Kreis. Mal ein anschließender Gedanke von meiner Seite: „wir brauchen nicht mehr Software". Das sagten die Mönche im Mittelalter auch, als der Buchdruck erfunden wurde: „Die Menschen brauchen nicht mehr Bücher, die Bibel reicht. Schon gar keine selbst gesetzten, da geht jede Handwerkskunst verloren wenn wir die Bücher nicht monatelang selber zeichnen. Sollen die Leute halt Latein lernen.“
1/2
1/2
@343max Coding LLMs werden die Druckpressen für Software werden, oder genauer der Laserdrucker der zu Hause steht und manigfaltige Probleme löst. App Entwicklung wird allgemeingut wie das Drucken einer Seite. Und ihr könnt euch beschweren dass Comic Sans eine uncoole Schrift ist, und all die Rechtschreibfehler, und das Design - aber die Entwicklung ist nicht aufzuhalten. Und es ist nicht an euch zu sagen „dein A4 Ausdruck ist doch Quatsch, braucht niemand“.
Checkt mal eure Privilegien.
Checkt mal eure Privilegien.
@lbenedix Der Vergleich könnte kaum mehr hinken. Die Druckpresse hat ein vorher unzugängliches Kulturgut für eine breite Masse zugänglich gemacht. Softwareentwicklung ist schon seit Jahrzehnten so leicht zugänglich wie kaum etwas anderes: man braucht irgendeinen Computer und kann anfangen, die Einstiegshürde ist Nahe null. Jeder kann sich die Basics absolut problemlos an einem Nachmittag draufschaffen. Der einzige Grund warum du kein JS kannst ist weil du es nicht können willst. (2/4)
Keine Ahnung von Computern oder Programmierung zu haben ist ja besonders in Deutschland ein wichtiges Distinktionsmerkmal. (3/4)
Niemand hat jemals eine App nicht geschrieben weil er/sie nicht programmieren konnte, das ist als würde man sagen man könnte kein Buch schreiben weil man ja nicht gelernt hätte auf einer Tastatur zu tippen. Und: auch um einer LLM halbwegs brauchbaren Code abzuringen muss man immer noch wissen was man tut. Der harte Teil der Softwareentwicklung ist nach wie vor hart, der einfache für jeden leicht zugängliche ist vielleicht minimal leichter geworden. (4/4)
Thomas Bartz@rstockm @343max Der Unterschied ist: Ein Buch von vor 500 Jahren kann heute noch gelesen werden und hat Mehrwert, Software von heute wird ohne Wartung schon in 10 Jahren unbrauchbar sein. Deswegen ist mehr Software auch ein Mehr an Aufwand. Technical Debt usw.
Hab die Diskussion genau deswegen so interessiert verfolgt, weil ich Ralf einerseits zustimme, dass Prototyping mit LLM enorm vereinfacht wird, ich beruflich aber ganz andere Probleme zu lösen habe, die - wie Max imho korrekt anmerkt 1/2
Hab die Diskussion genau deswegen so interessiert verfolgt, weil ich Ralf einerseits zustimme, dass Prototyping mit LLM enorm vereinfacht wird, ich beruflich aber ganz andere Probleme zu lösen habe, die - wie Max imho korrekt anmerkt 1/2
@rstockm @343max LLMs lange nicht lösen können werden. Ich habe sehr große Vorbehalte davor, einen Coding Assistent auf die komplexen Legacy-Projekte zugreifen zu lassen, wo Anpassungen über mehrere Applicationen & Architekturen verteilt orchestriert werden müssen.
Denke, beide Seiten Argumentieren hier aus grundlegend verschiedenen Ausgangspositionen und treffen falsche Annahmen über die Gegenseite. Jedenfalls mein Eindruck.
Trotzdem spannend, danke! Und seid nett zueinander :)
2/2
@sixumbrellas @rstockm Ich habe da überhaupt keine Vorbehalte und habe es schon mehrfach probiert. Ich habe in ein großes Android Projekt ein paar kleinere Features einbauen lassen. Das funktioniert bis zu einem gewissen Grad und kann auch erstaunlich befriedigend sein. Aber macht es mich deutlich produktiver oder ermöglicht es Menschen ohne Ahnung diesen Job zu übernehmen? roflol, nope. (1/2)
Ich habe von Github Copilot auch schon mal sinnvolle Änderungsvorschläge auf meine PRs bekommen, aber eben auch sehr sehr viele komplett überflüssige. Hat mir oder dem Team das Zeit gespart? Schwer zu sagen, viel war es jedenfalls nicht. (2/2)
msaehn@343max @sixumbrellas @rstockm ich stimme zu, dass ihr irgendwie aneinander vorbeiredet. die einstiegshürde für software furch llms deutlich gesunken&das ist doch gut (klar kann man programmieren lernen, aber react,ts,js,npm,tailwind,.. das ist viel). und ja, llms scheitern immer noch oft,aber bei bestimmten usecases sind sie sehr gut, sogar besser als ein junior dev (sehe ich wöchentlich auf der arbeit). aber trotzdem haben wir bei uns juniordevs.
@msaehn @sixumbrellas @rstockm Das stimmt, das ist viel. Und man muss es auch mit LLMs immer noch können, weil zumindest Claude das aufsetzen eines leeren Projekts mit bun, vite, react, tailwind in ts bestenfalls so in 30% aller Fälle hinbekommt und es dann meist auch nicht gefixt bekommt. Und dabei auch gerne irgendwelche veralteten Versionen installiert. Und wenn ich nicht genau sage welche Tools es installieren soll endet man wie Ralf mit Vanilla html, Bootstrap und jQuery.
@msaehn @sixumbrellas @rstockm Wenn ich mir so ein Projekt das Claude generiert habe anschaue: wahnsinnig viele Redundanzen, massenhaft ungenutzter Code, Tests die nichts testen, try/catch Blöcke die nichts anderes machen als weiter zu werden. Man kann sich nicht drauf verlassen das Anweisungen befolgt werden. (1/2)
Ich hab mal ausführlich eine Formel beschrieben wie was zu berechnen ist, die hat es dann brav mit Tests und allem implementiert und sich dann eine komplett andere Formel aus dem Finger gesaugt als es darum ging die einzusetzen und den anderen Code ungenutzt liegen zu lassen. So eine scheisse produzieren doch keine Junior Devs. (2/2)
@343max das stimmt. aber wir hatten zb nen renderer nach pdf/png/svg/dxf/canvas schreiben lassen. inkl styling&clipping. ist sehr getrennt vom rest des codes. aber das selber zu schreiben hätte vielleicht mehrere wochen gebraucht. das llm hat das „einfach so“ mit etwas hand halten gemacht. oder bugbot, was vermutlich in 30-50% aller PRs relevante bugs findet.
@msaehn Den Renderer gibt es auch als Bibliothek. Entweder hat euch die AI da die Bibliothek eingebaut, was euch auch nicht mehrere Wochen gekostet hätte oder es hat euch die Bibliothek nachgebaut mit ein paar zusätzlichen Fehlern drin und ohne Möglichkeit zu aktualisieren. Bugbot kenne ich nicht, ich weiß nur, dass GitHub Copilot selten irgendwas außerhalb von „ich sage irgendwas um meinen Wert zu beweisen“ beizutragen hat.
@msaehn Und ich sage gar nicht, das LLMs keinen Wert haben. Für wegwerf Apps sind sie oft brauchbar, für greenfield Sachen können sie okay sein, für „konvertiere dieses JSON in ein zod Schema“ kann es hervorragend sein. Aber das LLMs zuverlässig seien und man sie alleine machen lassen könnte ist weit weg von der Realität.
@343max es gibt diese bibliothek nicht, aber bestimmt hat die llm sich ideen von unserem vorherigem renderer und existierenden projekten genutzt. natürlich können wir es aktualisieren, wir maintainen ja den code jetzt. copilot nutze ich nicht, weil es zu schlecht war. -zuverlässig und alleine, natürlich nicht (bis auf mini tickets und genug context) -und trotzdem ist da was.
Cegorach@343max @msaehn @sixumbrellas @rstockm klingt wie das typische Enterprise-Projekt dass Leute in meinem Umfeld auch vor Code-LLM-Zeugs immer schon produzierten
Und gerade weil die Leute auch so schon immer Schwachsinn bauten, glaube ich auch nicht daran dass LLMs da irgendwie kurz-/mittelfristig merkbar besser werden. Sie haben ja nicht mal sinnvollen Input, wie sollten sie sinnvollen Output produzieren können?
/s
Und gerade weil die Leute auch so schon immer Schwachsinn bauten, glaube ich auch nicht daran dass LLMs da irgendwie kurz-/mittelfristig merkbar besser werden. Sie haben ja nicht mal sinnvollen Input, wie sollten sie sinnvollen Output produzieren können?
/s
@sixumbrellas @rstockm Die 10 Jahre halte ich für eine extrem optimistische Annahme. Wie jede Infrastruktur braucht auch Software ständige und dauerhafte Wartung um nicht innerhalb kürzester Zeit umzufallen. Ich wollte das auch lange nicht wahrhaben, aber bin zu dem Schluss gekommen, dass es vermutlich eine unabänderbare Realität ist.
@rstockm
@lbenedix Drucker werden immer eine Nische sein, und selbst die die einen haben werden ihn zum allergrößten Teil nur nutzen um irgendwelche fertigen Dokumente auszudrucken. 3D Drucker werden immer eine Nische sein. Heimwerken wird immer eine Nische sein. Softwareentwicklung wird immer eine Nische sein, weil sie schon sehr lange alles hat was es braucht um die Masse zu erreichen so wie so ziemlich jede andere kreative Kulturtechnik auch.
@lbenedix Drucker werden immer eine Nische sein, und selbst die die einen haben werden ihn zum allergrößten Teil nur nutzen um irgendwelche fertigen Dokumente auszudrucken. 3D Drucker werden immer eine Nische sein. Heimwerken wird immer eine Nische sein. Softwareentwicklung wird immer eine Nische sein, weil sie schon sehr lange alles hat was es braucht um die Masse zu erreichen so wie so ziemlich jede andere kreative Kulturtechnik auch.
Ich finde schön, dass Ralf seine Prompts hier im repository hat. Man sieht sehr, dass er ziemlich viel mit dem LLM interagieren musste, um ein vergleichbar einfaches Problem zu lösen. Die Commits enthalten dann auch ziemlich viele Änderungen für eigentlich kleine Fixes.
@lbenedix @maxheadroom @rstockm Ui! Da bekomme ich ja nur vom Lesen Prompt-PTSD. Das ist so ungefähr das Niveau auf dem auch ich LLMs erlebe, man fragt sich bei jedem Prompt „das sind garantiert nicht mehr als fünf Zeilen Änderung, soll ich das nicht lieber von Hand machen aber dann muss ich mich erst mal in diese widerliche Projektstruktur reinarbeiten und muss erst mal alles eefsctoren, vielleicht finde ich ja doch noch einen Prompt der es fixt. Nur noch ein Prompt Bro!“ (1/2)
Aber ganz ehrlich: wie will irgendjemand erzählen, dass wäre Produktiver als es einfach von Hand zu machen (oder auch einfach die halbe Stunde investieren damit ungenutzte Variablen in der CI aufleuchten) (2/2)
Ein weiterer Blick zeigt, was mir bei AI generierten Code immer wieder auffällt: die Abhängigkeiten sind extrem veraltet.
In dem Fall der Mastowall wird eine 6 Jahre alte Version eines CSS Framework verwendet.
Bei den anderen Abhängigkeiten sieht es nicht viel besser aus...
@lbenedix @343max @rstockm Ja, das stimmt alles. Und die Dinger machen auf doofe Fehler. Aber berichtigen sie dann auch einigermaßen. Sicher ist die Code Qualität nicht optimal. Aber es funktioniert. Und für die überwiegende Mehrheit der Projekte duerfte das ausreichen. Man überlege nur mit welcher Qualität sich Millionen Unternehmen bzgl. Microsoft Software "zufrieden " geben.
Ich vergleiche diese Coding LLMs gerne mit elektrischen Werkzeugen eines Handwerkers. Es erlaubt einem Profi die Arbeit viel viel schneller zu erledigen. Und auch ein Anfänger bekommt damit bestimmte Sachen hin, die er ohne gar nicht schaffen würde.
@maxheadroom @343max @rstockm In einer handwerklichen Ausbildung lernt man aber immer erst die Grundlage, damit man versteht, was passieren muss.
Man fängt nicht mit der CNC Fräse an.
@maxheadroom @343max @rstockm Damit wird man aber kein Haus bauen können, dass viele Jahrzehnte überdauert.
Wenn es nur darum geht, sich vor Regen zu schützen, reicht auch ne Plane und ein Seil.
@maxheadroom @lbenedix @rstockm Da gehe ich überhaupt nicht mit. Microsofts Softwarequalität hängt null damit zusammen ob sie gute Entwickler finden können. Das liegt an Prioritäten, Firmentielen, Organisationsproblemen, also Bereichen die weit oberhalb der Entwicklung sind und in denen niemand auch nur drüber nachdenkt LLMs einzusetzen. (1/3)
Wenn man mit LLMs Software baut, dann muss man die ganzen schweren Teile ja immer noch machen: Anforderungen, Architektur, Implementierung, Sicherheit, Deployment, Wartung… Da zu sagen, dass das am eigentlichen Coding scheitert ist wie zu sagen, dass man das man ein Hochhaus geplant, berechnet und genehmigt bekommen hat aber es nicht bauen kann, weil man leider keinen Hammer halten kann. (2/3)
Es mangelt nicht an Entwicklern, es mangelt an Bereitschaft und Willen Software zu bauen und da helfen LLMs null. (3/3)
@343max 💯 in großen Organisationen ist das Problem ganz sicher nicht der Mangel an (guten) Softwareentwicklern.
@lbenedix Wenn ich so drüber nachdenke: es ist schon irre wie lang jetzt schon die Idee nicht aussterben will das wenn man einfach nur den Entwicklern feste genug auf die Füße tritt Softwareentwicklung sich ja von alleine löst. Schon vor 15 Jahren habe ich von Firmen gehört, die für ihr egalo-Startup nur die besten 0,5% der Entwickler einstellen, weil die unteren 99,5% einfach nicht gut genug sind um zum 20. mal die Farbe für den Submit Button anzupassen. (1/2)
Und jetzt eben die LLMs die es uns endlich erlauben Softwareentwickler rauszuschmeißen und die Probleme unseres Prozesses nicht anzugehen. (2/2)
@343max man kann von AWS halten was man will, aber die keynotes von Werner Vogels sind eigentlich immer ganz gut.
In der Letzten zeigt er ganz pointiert auf, wie man 1970 schon mit Cobol der Meinung war, dass jetzt alle Menschen ohne Ahnung Software entwickeln können.
Man muss sich nicht die ganze Stunde geben, da kommt auch noch viel Quark.
AWS re:Invent 2025 - Keynote with Dr. Werner Vogels
@lbenedix Stimmt, die Friedhof der Softwaretools ist voll mit versuchen Development für jedermann zugänglich zu machen. No-Code Tools sind ja auch schon länger wieder in Mode. Die Leute liiieeeeben es irgendein grafisches Tool zu erlernen mit begrenzten Möglichkeiten um damit irgendwas zu bauen, obwohl sie in der gleichen Zeit eine Sprache lernen könnten mit der sie das selbe bauen und noch 1000 mal mehr. Auch Code Generatoren gibt es ja schon lange genug und praktisch keiner davon taugt was.
@343max hey hey hey... Ich setze im letzen Jahr sehr viel AWS Stepfunctions ein, weil man da sehr viel Monitoring, Updates, ... "geschenkt" bekommt. Mit dem Vorteil, dass man am Ende nicht 6 Jahre alte dependencies hat.
@lbenedix Ich bin gespannt auf den Tag an dem Amazon dir das nicht mehr schenkt und du den Preis des Lock-In Effekts kennenlernst.