Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Macht sie Projekte einfacher?
Herzlich Willkommen zu einer weiteren Episode von Software-Architektur im Stream, dieses Mal von den TechRiders.
Und zwar wollen wir uns unterhalten über das Thema KI.
Macht Software vermeintlich billiger?
Macht sie auch Projekte einfacher?
Und dazu sind Sebastian und Axel zu uns gekommen.
Fangen wir an mit einer Vorstellungsrunde.
Sebastian, möchtest du etwas für dich sagen?
Ja.
Hi, ich bin Sebastian Kleinschmager, bin Mitgründer, Geschäftsführer und CTO von SparePartsNow, einer Plattform, einem Marktplatz für den Handel von industriellen Ersatzteilen.
Ja, hallo auch von meiner Seite, Axel Schulz, mein Name.
Ich habe, ich weiß nicht wann, vor 25 Jahren angefangen zu programmieren.
Ich glaube, es war Turbo Pascal, dann kam Delphi, dann habe ich als Microsoft-Partner ganz viel C# gemacht.
An der Uni musste ich Java machen, habe mich viel mit dem Thema Software-Engineering, Metamodellierung auseinandergesetzt.
Und natürlich in meinem beruflichen Leben, danach in unterschiedlichen Stationen bei SAP und der Deutschen Bahn, auch unterschiedliche Sprachen und, ich sage mal, Entwicklungsstile kennengelernt.
Natürlich das Thema KI in der Softwareentwicklung ist eines der großen, heißen Themen, die mich auch seit mehreren Jahren jetzt umtreibt.
Genau.
Danke, dass ihr euch die Zeit nehmt.
Danke, dass ihr da seid.
Und auch danke an TechRiders, die uns den Raum zur Führung gestellt haben und wo wir, glaube ich, alle heute oder gestern Talks gehalten haben, sodass das so ein bisschen Rahmen bildet.
Die Frage oder die Aussage ist ja, KI macht Software vermeintlich billiger.
Da steckt billiger drin und vermeintlich.
Macht es denn Software, Softwareentwicklung billiger?
Tja, ich würde behaupten, das kommt darauf an, auf welchem Bereich des Spektrums man sich befindet, wie groß das Projekt ist, der Umfang der fachlichen Domäne, wie groß das Team ist und wie gut das Team ist.
Wir haben vorhin noch einen Vortrag von David Thielke gesehen, der in einem Projekt gezeigt hat, dass eine Person Faktor 90 produktiver sein kann beim Entwickeln von Software, KI gestützt.
Die Frage ist, schaffen alle Organisationen diesen Reifegrad?
Hört sich für mich an wie Prinzipiell ja und zwar massiv, aber es hängt von Organisationen ab.
Wie siehst du das?
Ich würde eher sagen, nein, weil wir die Folgekosten noch gar nicht abschätzen können.
Ich sehe es tagtäglich.
Menschen, die zu mir kommen und sagen, guck mal, ich habe hier was Weib gekodet, aber es macht sich keiner Gedanken darüber, was für eine Qualität ist das?
IT-Security, passt das denn noch?
Kann ich das überhaupt in Produktion betreiben?
Kann ich das später maintain, wenn ich neue Feature reinbringe?
Das wird alles noch nicht mitgedacht.
Die Leute sind einfach schnell an einem gewissen Ziel, wo sie fertig sind und sagen, natürlich, ganz schnell gebaut und alles gut.
Aber lasst mal diese Software, die so entstanden ist, in zwei, drei Jahren anschauen.
Da würde ich sagen, nein, es ist nicht billiger.
Ich würde das gerne nochmal detaillierter fragen.
Du hast ja gesagt, dass das Bauen schneller wird.
Du hast sogar von Faktor 90 gesprochen.
Das heißt also, mindestens der Trall tatsächlich, das Coden wird schneller und signifikant.
Ist das so?
Coden wird schneller.
Definitiv.
Das heißt aber nicht, dass der Code dadurch besser wird.
Das stimme ich dir vollkommen zu.
Wenn man das, was man so abfällig als Weib-Coding bezeichnet macht, dann ist die Wahrscheinlichkeit sehr hoch, dass da Lücken drin sind, Bugs, Sicherheitslöcher oder ähnliche Dinge.
Definitiv.
Ich habe am Wochenende mal ein WM-Tipp-Spiel gebaut und ich hatte eine Einstiegshürde.
Also Content bauen und so weiter war alles total gut.
Aber das Zeug dann am Ende zu dockerisieren und irgendwo betreibbar zu machen auf meinem eigenen NAS, das war echt schwierig für mich.
Normalerweise geht man auf Stack Overflow und schaut, was die Fehlermeldung sagt.
In dem Fall einfach hier das Cloud-Modell gefragt.
Was tue ich?
Was tue ich?
Ich habe irgendwann eine Antwort bekommen.
Ganz ehrlich, zwischendrin, ich habe fünfmal weitergeklickt und er hat irgendwas gemacht auf meinem Rechner, was ich dann nicht mehr nachvollziehen kann.
Aber ich bin gefühlt deutlich schneller, so jetzt mein Axel-Blick als Axel-Person, deutlich schneller über diese typischen Tücken der Entwicklungsumgebung hinweg gekommen, als ich das früher gewohnt war.
Und das war schon beeindruckend, muss ich sagen.
Dann können wir eigentlich versuchen, uns vielleicht ein bisschen dem zweiten Teil der Frage zu nähern.
Also macht es Projekte einfacher?
Also wenn man jetzt sagt, also wenn ihr sagt, dass tatsächlich das Coden selber schneller geht, wäre es ja, also um sozusagen meine Meinung zur Diskussion zu stellen, wäre es ja irgendwie überraschend, wenn nicht am Ende dadurch auch die Projekte einfacher werden, oder?
Ich würde behaupten, auch das muss noch gelernt werden.
Ich bin eben ja ganz stark vom Thema Vibe-Coding eingestiegen.
Das heißt, ich kann eigentlich ja über gutes Prompting sehr schnell ganze Projekte bauen.
Was ich aber auch hier wieder feststelle und merke, ist, sobald ich in eine Welt komme, wo ich mehr Menschen habe, die an einem System bauen, sobald ich in eine Welt komme, wo ich zusätzliche Feature integrieren möchte oder meinen initialen Ansatz zu komplex mache, bleibe ich in einer Schleife hängen, wo ich immer wieder mit dem System interagieren muss, Einzelteile rausnehmen muss.
Das heißt, es wird teurer, ich habe einen höheren Creditverbrauch und gleichzeitig haben wir noch gar keine Methodiken entwickelt, wie ich in einem Team vernünftig interagieren soll.
Und deswegen glaube ich, wir müssen bestimmte Mechanismen, manche sprechen ja von Spectre Development, noch entwickeln und institutionalisieren, um wirklich sagen zu können, Projekte werden einfacher.
Ja, das ist ein guter Punkt.
Und schneller.
Ein sehr guter Punkt, weil das Individuum wird möglicherweise produktiver, erzeugt schneller Code, aber selten arbeitet man alleine in großen Unternehmen oder in größeren Projekten und dann ist das Bottleneck an einer ganz anderen Stelle und die Probleme an einer ganz anderen Stelle, als wenn ich zu Hause meine Buchhaltung live code.
Ja, definitiv.
Also wir haben tatsächlich Sachen aus dem Chat bei YouTube.
Die Joana Tyrell, Tyrell Joana, so rum ist es, sagt also, ihr spricht ein Experte, die Zukunft ist vor allem Specification Engineering von KU und Mensch.
Ich vermute, dass das die Erstellung von Spezifikationen ist, im Zusammenspiel von KU und Mensch.
Damit stellt sie in Abrede, dass das Coding eigentlich das Thema ist, worüber wir diskutiert haben.
Würdet ihr dem zustimmen oder eher sagen, das ist nicht so?
Eingeschränkt zustimmen.
Wenn KI-basierte Softwareentwicklung funktionieren muss, dann wird es nur so rüber funktionieren, dass die Spezifikation von Mensch mit der KI zusammen designt wird und der Mensch immer weiter weg von dem Bärmittel kommt, also von dem Code, von der tatsächlichen Umsetzung.
Nur dann kann man diese Produktivitätsgewinne wirklich heben, die KI versprochen werden.
Also mein Verständnis der Frage und dieser Aussage ist halt, also eine Spezifikation würde ich jetzt verstehen, ist halt eine fraktliche Anforderung, nehme ich halt an.
Und die können wir ja jetzt gemeinsam erheben.
Also wir können ein System bauen fürs verfechtigte Stream, wo es eine Terminplanung gibt für irgendwelche Streams, was auch immer, oder nicht ein WML-Tippspiel, da gibt es ja frachliche Anforderungen.
Das würde ich zusammen mit KI erstellen, das ist zwingend?
Das sind unterschiedliche Ansätze und ich glaube, das ist das, was ich eben schon gesagt habe, es kommt darauf an, wo ich ansetze und was für Fähigkeiten ich mitbringe.
Nehmen wir mal das Beispiel Softwareentwickler, die seit vielen Jahren oder Jahrzehnten coden.
DNS-Hit ist es vielleicht, schnellere Migrationen auf andere Sprachen, auf neue Module irgendwie hinzukriegen.
Die werden sich weiter nah am Code bewegen, die werden sehr wahrscheinlich nicht plötzlich auf einen spec-driven-Ansatz irgendwie rübergehen.
Das ist das, was ich eben skizziert habe.
Menschen, die in der Ops-Sicht sind, die Pipelines-Probleme haben, die werden auch nicht über Spezifikationen arbeiten.
Aber auf der anderen Seite, jetzt wieder auf mich geschaut, ich habe viele Jahre nicht selber gecodet, ich habe letztes Jahr mal wieder Python gelernt und ich finde gerade spec-driven total cool, weil ich muss mich eigentlich gar nicht auf eine Code-Ebene hinunterbegeben.
Ich kann über klare Spezifikationen sagen, das und das habe ich gern.
Dann kann ich die Agenten am Ende alles bauen lassen bis zum finalen Container und ich muss mir niemals den Code angucken.
Das ist eine ganz andere Art und Weise, wie ich Dinge entwickle, die sicherlich auch Bestand haben wird.
Aber die Frage ist, du hast ja vorhin auch schon gesagt, ist das dann eher für Ein-Personen-Projekte oder entwickelt sich das dann auch in große Entwicklungsteams?
Vielleicht auch ein Mischmodell, wo wir Teile haben, die spec-driven arbeiten, aber andere sind noch nah am Code.
Das wird sich zeigen.
Ich glaube, wir haben noch keine guten Antworten darauf.
Und ich denke, das Verhältnis ist auch sehr stark abhängig von der Fachdomäne.
Also wie viel macht die KI, wie viel macht der Mensch?
Wenn es was sehr Innovatives ist, was Neues, wird wahrscheinlich der Mensch noch einen größeren Teil haben.
Wenn es eine gelöste Fachdomäne ist, wie Buchhaltung, dann braucht der Mensch wahrscheinlich nur sagen, ich möchte ein Buchhaltungssystem, was A, B, C kann.
Und die KI hat dieses Wissen schon, um die Spezifikation runterzuschreiben.
Der Mensch muss es vielleicht nur reviewen.
Zu dem Punkt, weil das eigentlich, finde ich, eine gute Vorlage ist für eine andere Frage.
Niemand schreibt ein Buchhaltungssystem, dafür gibt es halt SAP.
Das heißt, wenn man das zu Ende denkt, könnte man jetzt argumentieren, das ist die Frage, ob du dem zustimmen würdest, dass so etwas wie Buchhaltung, was eben verstanden ist, das ist Standardsoftware, das schreibe ich eben nicht.
Das heißt also, ich habe nichts, wo ich KI wirklich benutzen kann, weil ich eben nur die Dinge schreibe, die innovativ und neu sind, die ich nicht mit Standardsoftware erschlagen kann.
Also wenn ich ein Problem habe, was ich mit Standardsoftware, wo ich verstanden ist, mit Standardsoftware erschlagen kann, dann würde ich es wirklich dringend mit Standardsoftware erschlagen, weil wir wollen ja nicht Individualsoftware schreiben.
Das ist halt teuer, aufwendig, risikoreich.
Dann bedeutet es aber, dass wir Schwierigkeiten haben, mit KI überhaupt zurechtzukommen.
Ich würde vielleicht die Annahme, die du da getroffen hast, hinterfragen.
Wenn die Annahme stimmt, KI macht Software billiger und schneller, warum soll ich mir eine Standardsoftware kaufen wie SAP, von der ich vielleicht nur drei Prozent Funktionsumfang nutze, aber Tausende Euro im Monat bezahle, und ich kann mir das Funktionsset, was ich davon brauche, zusammenbauen lassen von einer KI?
Das ist ja das, was manche sagen, SARS wird sterben und vielleicht auch solche Standardsoftware haben.
Also die Annahme hätte ich an der Stelle vielleicht schon hinterfragen.
Glaubst du das, dass SARS sterben wird?
Zum Teil ja.
Nicht alle.
Die gut Integrierten mit sehr viel Fachdomänenwissen werden sich noch länger halten, aber es wird, glaube ich, eine Menge SARS-Dienste geben, die sterben werden in den nächsten Jahren.
Ich bin mir gar nicht sicher, ob die sterben werden, weil es ist ja eigentlich erkannt, wie du sagst, dass Integrierbarkeit jetzt King ist.
Am Ende, ich denke mal, alle, und mir fällt gerade keiner ein, der es nicht hat, alle Standardprodukte von einem Confluence, von einem Jira, über ServiceNow, über SAP, kannst du eigentlich über einen MCP-Server zugreifbar machen.
Und sobald ich einen MCP-Server habe, auf die Standardfunktionalitäten, die ich in einem Standardsystem habe, bin ich viel leichter dran, mir etwas zu customisen, was meinem Spezial-Need auch genügt.
Und ich glaube, diesen Trend haben alle Großen erkannt, lassen sich den aber natürlich auch teuer bezahlen.
Was dann bedeutet, Standardsoftware wird eben über MCP dann etwas, was ein LLM nutzen kann.
Ja.
Genau.
Es gibt noch mehr Sachen von den Zuschauern.
Das hat einmal der MrYear auf YouTube, der sagt, also ich glaube tatsächlich, es wird dann wohl ein Der sein, Weibcoding ist ganz nett für Kleinigkeiten, die man privat nutzt.
Interessanter ist Agentic Engineering, wo sich die Frage stellt, was und wie viel Agentic sein sollte.
Also Agentic ist ja das, wo man eben mehrere Agenten hat, die eben Teile des Systems bauen.
Was ist euer Eindruck?
Also ist das tatsächlich eher das Thema, wie viel Agentic soll es sein?
Hm.
Ich glaube, wir sind auch hier in der Lernphase.
Wir können momentan eigentlich jede Rolle, die wir in einem Softwareprojekt haben, durch ein oder mehrere Agenten nachbauen.
Und natürlich muss die Zukunft sein, dass sich jemand, der Tests schreibt, ein oder mehrere Agenten hat, um Tests zu produzieren und Tests zu validieren.
Genauso wie der Coder seine Agenten hat.
Ich glaube aber auch da, die Welt, die wir gerade erleben, Credits werden massiv teurer seit Juni.
Wir wissen eigentlich gar nicht, was ein Credit wert ist.
Wir wissen gar nicht, wie viele Agenten wir uns leisten können.
Wir wissen auch gar nicht, wie der Output dieser Agenten ist.
Das muss sich alles noch finden.
Momentan sind wir inflationär unterwegs.
Für jeden Mist bauen wir gerade einen Agenten, weil wir glauben, der schafft Wert.
Und es kann ja dann sein, dass die Agenten sich untereinander in einer ewigen Diskussion befinden.
Nein, mein Test ist besser.
Nein, mein Test ist besser.
Ach, dein Test schlägt wert.
Da müssen wir noch lernen.
Damit du aber interessanterweise im Prinzip diese Frage hinterfragst, ob es wirklich billiger wird.
Damit sagst du ja, dass die Kosten vielleicht dann eben doch andere sind.
Ja, wir wissen einfach noch.
Ich glaube, wir haben es noch nicht im Griff.
Wir haben es noch nicht verstanden.
Bzw. wir müssen auch noch passende Mechanismen für Kostenmonitoring einfach entwerfen, die jeder verwenden kann.
Aber auch dieses Mehragenten, viel hilft viel, war ja schon auch bei anderen Themen nie gut.
Und auch gerade mit den steigenden Kosten, die möglicherweise drohen, weiß, glaube ich, keiner von uns, wo es hingeht.
Ja, also was man tatsächlich mal machen müsste, das ist so ein Exercise, worauf ich eigentlich mal Lust hätte.
Man müsste es ja ausrechnen können.
Man müsste ausrechnen können, was eben diese Firmen an Geld verbrennen und wobei man dann irgendwie herausrechnen müsste, wie viel davon Investment sind.
Und dann müsste man eigentlich herausbekommen, was sozusagen die Leistung eigentlich kosten sollte.
Aber das ist ein anderes Thema.
Ich habe noch mehr Sachen aus dem Chat, da ist heute tatsächlich ziemlich viel los.
Jude Root hat geschrieben, Jude Root bei YouTube hat geschrieben, ich bin x-mal schneller in Ideen verproben, POC erstellen, aber die Wartung, dessen wird langfristig mehr und mehr Entwicklerarbeit brauchen und ist kontextabhängig.
Spotify versus Bankenumfeld, Regulatorik etc.
Und da ist halt dann der Scepter, würde ich jetzt sagen, ist das in Leadspeech, der hat halt hinzugefügt, Erstellung von Software ist doch nur 10 Prozent, 10 bis 20 Prozent, der Rest ist Wartung.
Ich würde erstmal die Frage stellen, würdet ihr dem zustimmen?
Also ist der Faktor Wartung tatsächlich 80 bis 90 Prozent der Kosten?
Ich kann da gar keine konkrete Zahlen nennen, ehrlich gesagt.
An der Aussage an sich ist was dran.
Einfach nur Software zu bauen und die dann liegen zu lassen, das wird nicht funktionieren.
Wartung, Betrieb, Maintenance in irgendeiner Form ist ein wichtiger Faktor.
Ob es 90 Prozent sind, kann ich nichts zu sagen.
Das ist super individuell, kommt ja wirklich darauf an, wie lange ein IT-System eingesetzt wird.
Wenn ich im Bankenumfeld bin, dann ich baue drei Jahre und betreibe es 20 Jahre, da ist Wartung natürlich 90 Prozent oder mehr.
Wobei das ja nicht automatisch gegen agentische Entwicklung sprechen muss, denn wenn diese Systeme sich noch weiterentwickeln und diese Dinge berücksichtigen können, diese Wartungstätigkeiten und die Wartbarkeit der Software, was spricht dagegen, dass sie es irgendwann können?
Das wäre nämlich für mich jetzt, also erstmal, ich würde tatsächlich zu der Wartung noch sozusagen etwas fallen lassen, weil du ja auch sagtest, dass es halt schwer abschätzbar ist.
Ich finde das total nachvollziehbar, weil das halt so ein Modell ist, wo man sagt, nicht ich erstelle, sondern warte ist.
Und es gibt halt zumindest eine bestimmte Fraktion innerhalb der Softwareentwicklung, die ja sagt, dass Software never done ist.
Und nicht also, ist der Amazon-Shop oder was auch immer es halt ist, Fahrplanauskunft oder so, ist das etwas, was gewartet wird?
Also ist das nicht etwas, was ständig weiterentwickelt wird?
Und deswegen finde ich den Begriff schwierig.
Aber das ist ein anderes Thema.
Ich glaube, der Hintergrund ist ja die Frage, ob Wartung eigentlich der Kern der Herausforderung ist.
So und jetzt ist ja die implizite Annahme, dass, also das ist das, was Juju sagt, die Wartung dessen wird langfristig mehr und mehr Entwickler in Arbeit brauchen.
Das heißt also, die Aussage ist, die sich daraus ergibt, ist das also ein Software-System, wenn wir es bauen, können wir es schnell bauen, aber mithilfe von AI-Systemen, aber bei der Wartung des Systems, das hat er nicht geschrieben, aber das ergibt sich, versagen diese Systeme und es ist mehr Entwickler in Arbeit.
Also um es sozusagen ein bisschen zu poetieren und auf die Spitze zu bringen, würde dir das unterschreiben?
Wir haben ja verschiedene Sachen, die passieren.
Das Erste ist natürlich, ich generiere mehr Code automatisch.
Das heißt, der Mensch geht eher in einen Wartungsmodus im Sinne, ich verstehe den Code, den irgendjemand produziert hat.
Also normalerweise, du brauchst Code, dann gehst du aus dem Projekt raus und dann übernehme ich es für die Wartung.
Das wird definitiv zu nehmen.
Eigentlich glaube ich was anderes, was ich eher in dem Teil sehen würde, nämlich, desto mächtiger die Modelle werden, und wir sehen es ja jetzt wieder die letzten Tage, desto mächtiger die Modelle werden, desto mehr Probleme finden sie in bestehendem Code.
Und eigentlich nimmt Wartungsaufwand eher deshalb zu, weil ich immer mehr Mist in den alten Sachen, die früher mal gebaut wurden, entdecke und nacharbeiten muss.
Das können also substanzielle Erkenntnisse sein, wie irgendwelche kritischen Sicherheitslücken, es können einfache Sicherheitslücken sein.
Da sehen wir einen massiven Anstieg, wo jetzt Menschen nacharbeiten müssen, die Bestandssysteme, die da sind, die wieder auf den Stand zu kriegen, dass sie nicht mehr angreifbar sind.
Und dieser Teil der Wartung, ich glaube, der wird einfach massiv zu nehmen.
Aber hinter der Aussage steckt auch die Annahme, dass diese Systeme zwar gut im Erzeugen, aber nicht im Warten von Code sind.
Und die halte ich für sehr gewagt.
Ich muss zugeben, hätten wir diesen Talk hier vor einem halben Jahr geführt, hätte ich dann das noch unterschrieben.
Ich habe aber die letzten sechs Monate so viel mit KI gemacht, dass ich sage, die Dinge sind so viel schneller und besser als ich im Warten von Code.
Sei es Backtriage und Fixen, sei es Library Updates, sei es Security-Issues im Code finden und sofort fixen.
Also ich sehe das jetzt nicht mehr so.
Ich sage, diese Systeme können das jetzt schon.
Die helfen uns, bei SAP Apparts Now, innerhalb von kürzester Zeit technische Schulden abzubauen, die wir Monate vor uns hergeschoben haben.
Aber ist es wirklich so, dass technische Schulden abgebaut werden?
Also ich verstehe es, dass du schneller im Fixen bist, also dass du schneller in der Erwartung bist, weil du gibst ja eigentlich schon natürlich einen Prompt.
Hier ist ein Problem Behepers.
Aber was ich schon an vielen Stellen wahrgenommen habe, ist, dass die Maschine dann den ursprünglichen Code derart verändert, dass du als Mensch dich ja dann gar nicht mehr wieder findest und du dann erstmal wieder einen substanziellen Arbeitsaufwand hast.
Nicht nur diese kleine Zeile Code, die vielleicht den Backt produziert hat, sondern das Ganze drumherum, weil er die Klassenstrukturen und alles verändert hat, auch noch zu verstehen.
Also wie ist denn deine Wahrnehmung?
Sind wir fokussiert schon, dass wir sagen können, hier, da ist der Fehler und da behebe ich?
Oder hast du schon wahrgenommen, was ich wahrgenommen habe, dass sich das große Ganze auch verändert, auch wenn es nur ein kleiner Fehler ist?
Also ich nehme wahr, dass langsam das große Ganze sich verändert.
Es hängt sehr stark davon ab, wie man die KI steuert.
Also das, was viele jetzt so dieses KI-Harnisch nennen und dieses Harness, dass man sagt, das sind unsere Coding-Guidelines, kleine Klassen, die müssen bestimmte Eigenschaften erfüllen, dies und das, Architektur-Guidelines.
Wenn man die KI immer bei jeder Aufgabe mit diesem Zeug gefüttert, dann schreibt die möglicherweise Code, der sehr ähnlich ist wie alles, was im eigenen Repository passiert.
Und dann findet man sich hoffentlich da immer noch drin wieder.
Man kann ja der KI sogar personalisiert sagen, wie sie arbeiten soll, wie sie mit einem sprechen soll.
Hat bei den Menschen damals übrigens auch super funktioniert.
Ich glaube, jedes Unternehmen, in dem ich war, es gab ganz klare Guidelines, wie entwickelt werden solle.
Und dann plötzlich kam bei mir mal einer und hat gesagt, oh, ich mache jetzt Clean Code.
Und im Clean Code, oh, was ist das Paradigma?
Ich kommentiere nicht mehr.
Ja, hast du mal so ein Projekt und die Guideline, alles wird kommentiert, ist plötzlich overruled, weil jemand eine andere Meinung hatte.
Glaubst du, das passiert nicht, wenn du irgendeinen LLM-Wechsel durchführst?
Das glaube ich nicht, nein.
Ich glaube, die KI wird sich sogar konsequenter an diese Vorgaben halten als die meisten Menschen.
In dem Kontext, also einmal, ich entnehme der Diskussion, dass ihr der Meinung seid, dass Menschen den Code angucken.
Man könnte ja auch sagen, also es gibt diese Aussagen, du hast es glaube ich auch gesagt, also ich schreibe selber keinen Code mehr, daraus könnte man ja jetzt aber auch ableiten.
Das heißt, ich muss den Code auch nicht mehr verstehen.
Das würdet ihr nicht sagen.
Oder ist das so?
Also sagt ihr, dass man den Code nicht mehr verstehen muss, weil dann wird die Diskussion eine andere, nicht?
Also dann ist es halt so, dass die menschliche Verständlichkeit des Codes zunehmend weniger relevant wird.
Tja, wenn man einen unglaublich hohen Reifegrad hätte heute, vielleicht wäre das so.
Ich kann für uns sagen, wir sind da noch nicht.
Ich glaube, es ist auch weniger ein technisches Problem.
Es ist ein Problem von uns Entwicklern und unserer Identität, alles verstehen zu wollen, alle Sonderfälle berücksichtigen zu wollen, dass wir weiterhin, ich schätze auch mindestens die nächsten ein, zwei Jahre noch, den KI-Code anschauen werden, zu verstehen, was sie tut.
Aber wenn man es konsequent weiterdenkt, ist es schon so, dass wir wahrscheinlich irgendwann an einen Punkt kommen, wo wir nur noch die Anforderungen reingeben, einen guten Harnisch für Architektur, für Maintenance, für Ops und so weiter mitgeben und uns vielleicht den Code gar nicht mehr anschauen.
Ist es dann nicht sogar ganz wild in die Zukunft gesprungen, so in zwei Jahren oder so?
Brauchen wir dann überhaupt noch lesbaren Code?
Oder wäre dann die Welt nicht so, keine Ahnung.
Das LLM überlegt sich eine Art und Weise, wie es meine Anforderungen umsetzen, wenn es am Ende nur Nullen und Einsen sind.
Bin ich vielleicht sogar effizienter in der Programmausführung.
Ja, es gibt ja genug Leute, die sagen, dass was früher der Wechsel von Assembly Code zu Compiler-basierten Sprachen war, ist jetzt einfach der Wechsel von Programmiersprachen zu natürlicher Sprache als Spezifikation.
Und was darunter läuft, interessiert uns als Menschen irgendwann nicht mehr.
Nicht, dass ich das jetzt so unterschreiben würde, also nicht in den nächsten fünf Jahren, aber da könnte es hingehen.
Aber das bedeutet, dass das tatsächlich sozusagen das Endziel oder das Endergebnis sein wird aus deiner Sicht.
Ja, der Martin Pasch bei LinkedIn hat gesagt, man kann viel mehr Code in kurzer Zeit erzeugen.
Fertig getestet, gut dokumentiert, relevante Teile sind leicht zu finden.
Wenn das der Kunde auch mitbekommt, ist er nicht mehr bereit, den Preis von heute zu zahlen.
Dann wird die Messdate, die Kundenerwartung angerufen werden, die Systeme werden noch komplexer.
Somit ist das Erstellen günstiger.
Das Ganze wird aber auch durch die Erwartungshaltung wieder kompensiert.
Zustimmung, Ablehnung?
Also Zustimmung, also jetzt rein aus einer Sicht, wenn ich ein Unternehmen beauftragen würde, mir etwas zu bauen, würde ich in der heutigen Zeit sagen, du solltest 30 Prozent günstiger sein als letztes Jahr.
Definitiv.
Ja, es gab doch sogar ein Gesetz, irgendein ökonomisches Gesetz, dass wenn etwas billiger zu erzeugen wird, dass automatisch auch die Nachfrage danach steigt.
Ich schätze mal, dieses Gesetz wird hier auch ähnlich funktionieren, also dass wir so eine Art Inflation an Software erleben werden.
Egal, ob da jetzt jemand für bezahlt oder ob die sie selbst baut.
Das ist ein realistisches Szenario.
Es ist ja nicht so, dass wir nicht schon 100 Millionen Apps im App Store hätten.
Genau.
Also du beschreibst den Rebound-Effekt, dass diese Geschichte mit, wenn wir halt, ich glaube es ist mit Licht, also wenn Licht effizienter ist, also elektrisches Licht, dann steigt trotzdem der Energieverbrauch für elektrisches Licht, weil eben mehr Sachen beleuchtet werden.
Und dann habe ich eben diesen Rebound-Effekt, dass sozusagen die Summe steigt, obwohl das Individuelle produktiver wird.
Und das wäre jetzt eben der Rebound-Effekt für Softwareentwicklung.
Ich habe also der SEPTA, von dem ich vorhin sprach, da hat er das gesagt, von wegen Software.
Die Erstellung von Software ist nur 10 bis 20 Prozent, der Rest ist halt Wartung.
Er hat jetzt ergänzt, ich meinte das aus Sicht von Total Cost of Ownership und Software Entropie.
Sicherlich wird die KI bei der Wartung helfen, aber da in der Regel die Verantwortung noch beim Menschen liegt, ist die teure Überprüfung noch beim Menschen.
Da macht es für mich wenig Sinn, viel Individualsoftware zu implementieren.
Ist das denn so?
Also es ist noch so, dass die Verantwortung beim Menschen liegt.
Ich würde argumentieren, das wird halt immer so sein, irgendein Mensch sagt, dass man Werkzeug benutzt wie AI.
Das kann man glaube ich nicht hinterfragen, aber es ist tatsächlich so, dass die Sachen überprüft werden.
Also dass ich jetzt sage, dass ich einen Prompt mache, daraus einen Code generiere und dann eben tatsächlich das überprüfe.
Ich glaube, du hattest bei mir den Eindruck erweckt, das ist so, zumindest weil du sagtest, dass diese Code-Ebene zumindest aktuell noch ein Thema ist.
Ist das so, würdest du sagen?
Bei uns ist es halt auch so, dass wir sagen, ja, du kannst den Code mit KI schreiben, aber du bist als Entwickler noch verantwortlich dafür, dass er funktioniert, dass er reviewed ist und möglichst keine Fehler hat, vor allem keine fachlichen und auch keine security-technischen.
Und diese Verantwortungsfrage ist ja auch super spannend, weil ich als Geschäftsführer bin immer mit einem Bein im Knast, wenn ich weitgecodete Software ausliefere, die vielleicht Security-Leaks hat, die irgendwann zu Datenabfluss oder zu schlimmeren Dingen führen würde.
Das heißt, das ist wahrscheinlich das, was am ehesten Menschen zurückhält und auch große Organisationen zurückhält.
Gar nicht so, dass das technisch nicht geht, sondern das juristisch von so aus Governance-Sicht, da alle lieber die Zügel anhalten.
Jetzt habe ich vor einiger Zeit so ein Mastodon-Prostit gesehen, wo hat irgendjemand sowas schrieb im Sinne von, das ist irgendwie ganz schlimm, wo ich halt arbeite.
Alle Menschen, die um mich herum benutzen, hat irgendwie AI und also verdummen dabei, wenn ich sozusagen zusammenfassen darf.
Das ist aber gar nicht der Punkt, auf den ich randhinaus will und lesen halt einfach nicht mehr die Pull-Requests durch, sondern lassen das einfach durchlaufen.
Was ich nachvollziehbar finde, Pull-Requests zu reviewen und das wirklich ernsthaft zu tun, ich bin gar nicht sicher, ob das nicht sogar aufwendiger ist als Entwicklung.
Wie verhinderst du das denn?
Weil du hast gesagt, das ist etwas, was tatsächlich dann zu Schwierigkeiten führen würde.
Gibt es einen Mechanismus, mit dem du das verhinderst oder hast du da Vertrauen in deine Entwickler, dass es bei euch eben anders läuft, was ja auch gutes Zeichen ist, wenn du das Vertrauen hast?
Also ich muss da meinen Leuten vertrauen und natürlich gibt es auch irgendwie schon die Vorgabe, die wir für verantwortlich sind.
Trotzdem sehe ich natürlich diese Entwicklung nicht nur bei meinen Leuten, sondern auch bei mir selbst.
Je mehr ich mit AI arbeite, desto mehr wächst mein Vertrauen und desto weniger habe ich das Bedürfnis, da im Detail draufzuschauen.
Das ist interessant, dass ich das bei mir selbst beobachte, obwohl ich selber auch immer ein sehr gründlicher Mensch war, was diese Themen angeht.
Ja, aber solange die Haftung noch bei mir irgendwo ist als Mensch, bin ich schon noch daran interessiert, da zumindest möglichst viele Schichten an Prüfungen draufzulegen.
Es kann sein, dass die irgendwann auch AI-basiert sind, vollständig.
Aber die müssen halt zu einem gewissen Konfidenzlevel mein Vertrauen in das System erfüllen.
Gut, also sozusagen zu dem Punkt.
Ich fand, das passte mir ganz gut.
Jakob bei YouTube hat geschrieben, Entwickler werden zukünftig wohl daran gemessen, wie gut sie KI möglichst effizient einsetzen und dazu bringen, möglichst Qualität zum wartungssicheren Outcome zu generieren.
Was dann bedeutet, dass du deinen EntwicklerInnen haben möchtest und halt einstellen wirst und das sozusagen verantwortlich tun können?
Wie auch immer man das konkret umsetzt.
Achso, hier stand noch.
Ich weiß nicht, ob ich das verstehe, aber ich finde die Frage gut.
Mächtige vs. doofe Modelle, also von Siluse bei YouTube.
Mächtige vs. doofe Modelle.
Modelle, die Zero-Day-Exploits in kurzer Zeit finden.
Also Bugs, die vorher sicherheitsrelevante Bugs, die halt vorher noch nicht relevant sind.
Und Modelle, die Probleme haben, simpel zur Anweisung zu verstehen.
Wohin führt das gesellschaftlich bei Projekten?
Ja, ich bin auch nicht sicher, ob ich die Frage verstehe.
Was es ja gibt, ist die Behauptung, dass dieses Mythos beispielsweise von Anthropic so viele Sicherheitsstücken findet und so gut ist, dass sie das erst mal nur begrenzt freigegeben haben und dann anschließend generell frei, weil das so wahnsinnig gefährlich ist.
Anthropic hat sich auch vor ein paar Tagen hingestellt und hat, glaube ich, gesagt, sie wollen halt erst mal so einen Stopp bei LLM-Entwicklung.
Bei mir stellt sich die Frage, ist das Marketing oder glaubt ihr das?
Also das kann ja auch Marketing sein, dass man sagt, guck mal hier, wir haben ein Produkt, das ist so gefährlich, dass es halt eine Waffe ist.
Und ich habe irgendwann mal ein Post-it gemacht, ich weiß nicht, ob ihr euch erinnert.
Es gab 1999 diesen schönen Apple-Werbespot, wo die Aussage war, dass Power Mac G4 eine Waffe ist, weil der zu schnell ist und unter die Supercomputing-Export-Beschränkungen der USA fährt.
Also ist das Marketing, so wie der Apple-Werbespot?
Es ist natürlich Marketing.
Ganz ehrlich, also welches Unternehmen erwartet denn, hey, mein Panzer ist stärker als deiner, ich höre jetzt auf, Panzer zu bauen.
Es passiert doch nicht.
Wenn Anthropic jetzt sagt, sie wollen erst mal nicht weiter investieren, dann verlieren sie einfach ihren Stand am Markt, weil jemand anders wird, ist ganz gewiss.
Es ist reines Marketing.
Die Grundsatzfrage, die sich einfach stellt, wann kommen wir an einen Punkt, dass wir jetzt mit Blick auf Softwareentwicklung mehr Probleme schaffen, als wir lösen können, glaube ich, werden wir nicht erreichen.
Weil das Modell, was die Probleme schafft, wird genauso gut, diese Probleme zu fixen.
Das wird sich immer in Waage halten, glaube ich.
Und damit würde ich jetzt auch wieder mit Einschränkungen im Blick auf Softwareentwicklung da gar keine Reklamentierung machen, sondern am Ende ist es ja genau die Frage, die wir eben gestellt haben.
Wann ist denn die nächste Evolutionsstufe erreicht, dass wir gar nicht mehr die Menschen haben, die in den Code schauen müssen, weil das Endprodukt nur noch zählt und du übernimmst dann nur noch die Verantwortung für das Endprodukt, was ein Output hat und gehst davon aus, dass der Teil davor mindestens genauso gut ist, wie wenn ihn ein Mensch gebaut hätte.
Das wird niemals zu 100 Prozent sein, sondern es hat am Ende vielleicht die gleiche Fehlerquote und die gleiche Angreifbarkeit.
Gute Aufhänger, um die Frage zu stellen, die mir die ganze Zeit im Hinterkopf irgendwie herumschwirrte.
Also wir sind uns ja alle darüber einig, oder das ist ja das, was du gerade gesagt hast, dass LLMs mindestens mit dem jetzigen Stand nicht so qualitativ gut sind wie Menschen.
Bei mir gibt es da sozusagen zwei Erfahrungen.
Die eine Sache ist, wenn ich mir das typische Legacy-System angucke, da ist die Qualität des Codes durchschnittlich.
Und es ist ja impliziert, dass wir halt im wirtschaftlichen Kontext Systeme akzeptieren und das sind ein bisschen kritische Systeme, bei denen die Codequalität eben sehr durchschnittlich ist.
Sind LLMs vielleicht gut genug?
Ist das vielleicht der Punkt?
Und deswegen ist das eben etwas, was eingesetzt wird, weil Legacy-Code ist eben schwer wartbar.
Also es hat nicht Legacy-Code und da kommen sie wahrscheinlich rüber über die Schwelle oder zumindest schneller vielleicht.
Ja, würde ich so unterschreiben.
Also, bevor ich bei Apraznau war, war ich fast zehn Jahre IT-Freelancer und habe Schulungen gegeben und habe sehr viele Legacy-Systeme bei Kunden mitbetreut.
Und das, was die KI heute produziert, ist um Längen besser, als was in diesen Legacy-Systemen an Code existiert.
Also allein deswegen kann man schon sagen, ist die KI zumindest gut genug.
Ja, ich kann es so schwer beantworten, weil auf was wurden die Modelle denn trainiert?
Die Modelle wurden auf Basis von öffentlichen Repositories, die man da draußen findet, trainiert.
Das heißt, der eigentliche Code, wo ich teure Leute bezahlt habe, hochspezielle Systeme zu bauen, den hat so ein Sprachmodell ja nie gesehen.
Normalerweise.
Das, was wirklich ein komplexer Business-Logik ist, das, was wirklich gut durchdesignt ist.
Deswegen glaube ich eher, dass wir noch ein paar Evolutionsstufen gehen müssen, damit ich wirklich auf dem Level von Business-Code, wie ich ihn in der Business-Umgebung habe, auch sein kann.
Denn das System, noch sind wir ja nicht in einer Welt, dass das System sich selbst hinterfragt, ist das wirklich guter Code, den ich schreibe?
Sondern es passt mehr oder weniger zu dem, was ich schon mal da draußen gesehen habe.
Und naja, da gibt es halt unterschiedliche Qualitäten.
Bei vielen Projekten bin ich glücklich, dass die KI damit nicht trainiert wurde.
Also ja, auch viele Open-Source-Projekte haben jetzt nicht den schönsten Quellcode.
Das ist so.
Genau.
Die durchschnittliche Qualität ist eben durchschnittlich.
Hier ist noch ein Hinweis von Mr. Yer auf YouTube, bald überall Schilder menschenhaftend für ihre Agenten. Übrigens, das finde ich tatsächlich eine gute Idee.
Da könnte man halt so Aufkleber draus machen.
Das passt ja zu dem, was ihr vorhin sagtet, mit der nicht Haftung, aber Verantwortung.
Das ist ein Werkzeug, den man aus Frankfurt übernehmen muss.
Ich fand, das war noch eine gute Ergänzung dazu.
Und dann von ihm auch noch der Hinweis, wo ich ein nett Positiv der KI sehe, ist Dokumentation.
Wir Entwicklende hatten nie Bock auf DOKU und LLMs sind prädestinierte Labertaschen für die Aufgabe.
Ist das so?
Ist Dokumentation vielleicht das, wo LLMs insbesondere helfen?
Ja, natürlich.
Die Frage ist nur, wer liest es, oder?
Ja, es dürfte nicht zu einer Inflation von Dokumentation führen, weil dann liest es auch wieder keiner.
Nur weil Produzieren von Text billig wird, sollte man es vielleicht nicht machen.
Aber dem Punkt an sich stimme ich auf jeden Fall zu.
Dokumentation generieren macht es einfacher.
Man sollte es mit Augenmaß machen.
Der Wald und Wiesen Developer stirbt aus, KI übernimmt das schneller und zuverlässiger.
Bei uns dokumentieren wir dadurch viel mehr, auch KI gestützt.
Anforderungen werden automatisch auf Lücken und Widersprüche geprüft.
Mit dem Code-Kontext beschleunigt uns das und es bleibt Zeit für Architektur und Features, die sich früher nicht lohnten.
Ich weiß nicht, ob ihr etwas dazu sagen wollt.
Es ist im Prinzip eine Aussage über ein individuelles Erleben und insbesondere, dass dadurch für andere Themen Zeit bleibt.
Wir haben übrigens Freitagmorgen eine Episode mit dem Ralf und dem Martin Lippert zum Thema, welche Auswirkungen das mit dem AI-Track auf Entwickler hat.
Das fällt mir dabei gerade ein, weil die Folge sagt, zwischen KI-Hype und KI-Vampire, wie wir den Einsatz von KI im Alltag erleben.
Und das ist, glaube ich, nochmal was, was vielleicht ganz Spannendes und dazu irgendwie gut passt.
Was ist denn ein KI-Vampir?
Ja, das habe ich mich jetzt auch gefragt.
Das Leben aus dir raus sorgt, so verstehe ich das.
Es gibt tatsächlich den Effekt, dass Entwickler sich dadurch unter Druck gesetzt fühlen und tatsächlich nahezu psychologische Effekte davon haben.
Das ist wie in Futurama, diese grünen Brain Slugs.
Das wären dann quasi die LLMs, die dann…
Brain Slug ist vielleicht noch ein besserer Begriff.
Und Jakob hat geschrieben, gute Entwickler müssen wissen, wie kurz die Leine sein muss, an die sie den Agenten von Fall zu Fall nehmen und haben den Weg und das Ergebnis schon während des Promptings vor Augen.
Würdet ihr das unterschreiben?
Ich finde das interessant mit haben das Ergebnis schon während des Promptings vor Augen.
Das heißt, das hört sich an wie, das Ding schreibt halt nur noch was runter, was ich halt eh schon weiß.
Vielleicht ist es darauf bezogen, dass man als Entwickler schon von den Anforderungen so eine Art mentales Modell im Kopf entwickelt.
Und die Kunst ist natürlich, dieses mentale Modell der KI zu vermitteln, damit sie es auch in Code gießt.
Vielleicht ist der Beitrag so gemeint, dann würde ich sagen, ja, kann ich so bestätigen.
Aber auch das wird vielleicht irgendwann gar nicht mehr nötig sein.
Das heißt, es passiert bei deiner Arbeit nicht, dass irgendwie plötzlich durch die Nutzung von AI dieser Plan sich irgendwie ändert und es in eine andere Richtung geht, die du vorher nicht vorhergesehen hast?
Aber dann wäre es ja so, dass es eben gerade nicht so ist, dass du halt sozusagen diesen Plan im Kopf hast und der einfach nur noch umgesetzt wird, sondern der ändert sich dann ja eben auch.
Aber das war auch schon vorher so.
Ich hatte zwar immer ein mentales Modell von einer Lösung im Kopf, aber während ich versucht habe, es zu entwickeln, habe ich gemerkt, oh, da war ein konzeptioneller Fehler, da habe ich falsch gedacht, da muss ich nochmal nachschärfen.
Ich glaube, dieser Prozess bleibt jetzt auch durch KI bestehen.
Vielleicht wird er aber auch leichter.
Typischerweise hat man ja Architekten.
Also ich weiß irgendwie, ich brauche eine Datenbank, um Daten vorzuhalten.
Du hast einen Architekten, der trifft eine Entscheidung.
Was nehme ich?
Nehme ich ein Oracle?
Nehme ich ein MS SQL?
Nehme ich ein Postgres oder sonst irgendwas?
Meine Wahrnehmung ist eher, dass diese Entscheidungen gar nicht mehr getroffen werden müssen von Menschen.
Also über die machst du dir gar keine Gedanken mehr.
Du hast eigentlich nur noch das Bild im Auge.
Jetzt nehme ich mein WM-Tippspiel.
Ich muss irgendwie meine Daten ablegen.
Aber wie sie abgelegt werden, ganz ehrlich.
LLM sucht dir eine Möglichkeit.
Ich gebe vielleicht irgendwie noch rein.
Muss möglichst günstig sein, muss open source sein und sonst irgendwas.
Aber ich mache mir gar keine Gedanken mehr über Technologien.
Vielleicht ist das eine Stufe, die kommt.
Ob die gut ist, weiß ich nicht.
Wird sich zeigen.
Die meisten Entwickler kriegen schon Gänsehaut.
Darf ich fragen, wie dein WM-Spiel die Daten ablegt?
Weil du gerade das Beispiel genannt hast?
Und wie du dahin gekommen bist?
Der macht es ganz einfach.
Der hat eine JSON-Datei, die einfach speichert.
Ein Filesystem.
Und das ist ein Ergebnis von dem, was das System überlegt hat?
Genau.
Ich habe es auch nicht hinterfragt, weil ich gesagt habe, es muss halt persistiert werden.
Fertig.
Er hätte genauso gut sagen können, ich hole mir einen open source Datenmarkt-Stack noch runter.
Hört sich für mich ein bisschen wie ein Widerspruch an.
Also die eine Aussage ist, es gibt einen Plan, den man im Kopf hat, der durch Feedback in der Entwicklung mit der AI sich irgendwie ändert.
Die andere Aussage ist, nein, dieser Plan gerade kommt von der AI.
Ist das ein Widerspruch?
Nein, ich wollte es bewusst als Evolution skizzieren.
Also als mögliche weitere Evolution?
Ja, genau.
Ich glaube, heute gehst du eben mit diesem Plan rein und gerade wenn man noch selber viel Softwareentwicklung macht, dann definiert man so ein bisschen seinen Stack rein, den man immer gehabt hat.
Angular.
Ich will unbedingt Angular nach vorne haben.
Aber ich habe schon immer Angular gemacht.
In der nächsten Evolutionsstufe glaube ich, muss man sich darüber gar keine Gedanken machen.
Ich will einfach nur ein Frontend haben.
Wie du es mir generierst, ist mir vollkommen egal.
Hauptsache es ist maintainable, Hauptsache es ist die neueste Version und keine Ahnung was.
Weil du gerade von diesem Feedback-Zyklus gesprochen hast.
Es ist ja nicht das erste Mal, dass es Bestrebungen gibt, Softwareentwicklung zu öffnen und einfacher zu machen.
Da gibt es eine Tradition.
Cobol hat das damals versucht.
Ich weiß nicht, wie eure Erlebniswelt ist, aber ich kenne das prototypische Beispiel, was mir in meinem Kopf herumschwirrt.
Diese Unternehmen, die von einem Excel getrieben werden, wo sich irgendjemand eingestellt hat und ein großes Excel-Storage-Sheet gemacht hat, dann irgendwann nicht Formeln und Makros reingebaut hat.
Das ist das Ding, was jetzt magisch irgendetwas steuert.
Das Gerät hat subjektiv vollkommen außer Kontrolle.
Meine Behauptung wäre, dass das bedeutet, dass Menschen, die nicht Software entwickeln können, wenn sie Software entwickeln, zum Beispiel mit Excel, scheitern, obwohl sie technisch das können, aber es wird chaotisch und schlimm.
Jetzt ist die Frage, wenn wir die von LM setzen.
Meine Behauptung wäre, das geht auch schief.
Deswegen frage ich mich, ob es einen Skill gibt, der Softwareentwicklung ist.
Ist dieser Feedback-Zyklus für dich, für die Softwareentwicklung, das, was es ausmacht?
Ich habe Informatik studiert.
Ihr seid offensichtlich auch Menschen, die sich lange Zeit sehr intensiv mit Softwareentwicklung beschäftigt haben.
Das heißt, wir haben eine formale Ausbildung oder eine Erfahrung.
Ich würde unterstellen, wenn wir uns jetzt vor ein LLM-System setzen, kriegen wir wahrscheinlich ein vernünftiges Ergebnis.
Wenn wir jemanden davor setzen, der eben nur Domänen-Experte ist, dem das technische Wissen fehlt, wird es wahrscheinlich ein Desaster.
Würdet ihr das auch denken?
Und wenn ja, warum?
Was ist der Skill?
Ist das der Skill?
Ich musste ein bisschen grinsen, weil ich da eine interessante Anekdote zu im Kopf habe.
Als Entwickler ist man so ein bisschen arrogant und würde erstmal wahrscheinlich sagen, das können diese Personen oder solche Menschen nicht gut.
Aber vorhin noch bei einem Vortragenden gesehen, er hat gesagt, sein 13-jähriger Sohn hat jetzt als Hobby, Computerspiele zu entwickeln.
Er hat uns eines davon gezeigt.
Das war ein Flugsimulator, der im Browser lief, der tatsächlich sehr gut aussah, sich bedienen ließ.
Und der 13-jährige Sohn hat eine 5 in Informatik und überhaupt keinen Plan von Softwareentwicklung.
Und das war ein Flugsimulator mit Missionen, mit Schießen und Fliegen und Landen.
Und das ist jetzt vielleicht keine Fachdomäne, wo man sagen will, oh ja, ganz mega komplex.
Aber das ist heute so.
Was passiert in fünf Jahren?
Also ich glaube, diese Arroganz, die wir als Entwickler haben, nur wir sind die Gatekeeper.
Wir dürfen Software entwickeln.
Ich glaube, von dem Rost werden wir die nächsten Jahre runtergestoßen.
Das bedeutet, also damit unterstellst du sozusagen, wenn wir uns jetzt hinsetzen würden und dasselbe tun würden wie dieser 13-Jährige, glaube ich, dann wäre das Ergebnis genauso gut oder schlecht?
Es wäre zumindest wahrscheinlich nicht massiv besser.
Also ein wichtiger Skill als Softwareentwickler war schon immer, sich in der Fachdomäne einzudenken und nicht unbedingt die Technik dahinter.
Ich glaube, das ist mir zu hart.
Jetzt komme ich wieder zu dem, was wir eben diskutiert haben.
Ich glaube, ein Softwareentwickler, der schon längere Software schreibt, der hat seinen Stack.
Und schon allein, weil er seinen Stack hat, weil er weiß, was gut funktioniert, was gut miteinander interagiert, was am Ende auch performant ist, was am Ende auch betreibbar ist, wird auf Basis dieser Erfahrung Stand heute noch die Software eines Softwareentwicklers besser, als wenn ich jetzt den Jungen nehme, der das Ganze per Prompt generieren lässt.
Da kriege ich ja einen Mischmarsch aus Technologien, vielleicht auch unterschiedliche Sprachen, die irgendwie vereint werden.
Ganz ehrlich, eine 13-Jährige muss sich ja nicht damit auseinandersetzen, ist das Zeug betreibbar am Ende oder was für Kosten hat es denn, wenn ich es irgendwo auf einem Server hoste oder sonst irgendwas.
Ja, es wird was rauskommen, es wird auch gut aussehen, weil das kann er alles gut prompten.
Ich glaube aber wirklich mit Blick auf Qualität stand heute noch, ist Softwareentwicklungs-Know-how, Wissen welches Stacks wie funktionieren, immer noch ein Qualitätslevel.
Stimme ich zu.
Ich mache jetzt gerade so ein bisschen den Advokatus Diabolo hier heute, aber heute sehe ich das definitiv noch genauso wie du.
Aber die Tendenzen sind da.
Das ist wirklich die steile Hypothese, die wir jetzt heute schon mehrfach gehört haben.
Wie entwickelt sich die Rolle eines Softwareentwicklers in Zukunft?
Was macht der noch?
Und deswegen suche ich eben genau diesen Skill, wenn er denn irgendwie existiert.
Da war noch eine Anmerkung von Marco N3Z8G bei YouTube.
Was bringt mir mein Spring-Stack bei einer Flugsimulation?
Da muss ich mir einen passenden neuen Stack zusammensuchen, um die Probleme einer Flugsimulation zu lösen.
Basiert halt auf deiner Aussage zu dem Stack sozusagen.
Können wir, glaube ich, so stehen lassen, weiß ich nicht.
Ich habe eine Frage, die ich so ein bisschen, die finde ich passt gut zu dem Festival hier und passt auch gut sozusagen als Abschlussfrage oder vielleicht als Abschlussbemerkung.
Das ist von Florian6764.
Der sagt, mit KI wird das Softwaredefizit in deutschen Unternehmen deutlich und es kommt mehr Software und vor allem Custom-Software zugestimmt für das Unternehmen in die Firma.
Was ja erstmal impliziert, wir haben ein Softwaredefizit und zwar in Deutschland, im Ausland halt nicht und KI löst das.
Ist das so?
Also haben wir ein Softwaredefizit?
Vielleicht in manchen Branchen, in manchen Unternehmen.
Also für den Maschinenbrauer kann ich sagen, da wir ja in dieser Branche unterwegs sind, da passierte vor wenigen Jahren noch alles analog oder sehr viel analog.
Manche Arztpraxen kriegen auch immer noch Faxe heute.
Also vielleicht haben wir ein Softwaredefizit.
Ich kann es aber überhaupt nicht mit Zahlen untermauern.
Das ist, glaube ich, eine Meinung.
Hast du eine Meinung dazu?
Ich glaube, wir haben kein Softwaredefizit.
Im Gegenteil, ich glaube, wir sind in einer Welt unterwegs, wo wir für sehr viele Probleme sehr viele unterschiedliche Lösungen haben und diese Welt wird noch schlimmer werden.
Weil, keine Ahnung, ich habe irgendwo in der Fachdomäne vor allem Buchhaltung, ich habe irgendwo jemanden, der macht Buchhaltung in Excel, der lernt Weib-Coding, der wird sich irgendwann seine kleine Anwendung vielleicht noch für seine Kollegen nebenan bauen und irgendwo hinsetzen.
Und ich glaube, das wird überall passieren.
Deswegen, wir haben heute schon zu viel Software, die wir nicht maintainen können, die wir aus T-Security-Sicht nicht mal im Griff haben und nicht mal nacharbeiten können.
Wir hatten das Thema Wartungen, wo wir nicht mehr hinterherkommen.
Das wird schlimmer werden.
Ich weiß nicht, wie man das nennt, nehmen wir es als Software-Overload?
Eigentlich steuern wir darauf hinaus.
Gut, noch irgendwas, was ihr loswerden wolltet?
Irgendwelche Sachen, die ich vergessen habe zu fragen?
Oder irgendwelche anderen Themen?
Danke für die Einladung auf jeden Fall und danke auch TechRiders für gefühlt 45 Grad, aber kalte Geträcke.
Vielen Dank auch von mir.
Vielen Dank an TechRiders.
Vielen Dank an Alaa und Martina, die das mitorganisiert und durchgeführt haben.
Und vielen Dank an euch, dass ihr euch die Zeit genommen habt und die Fragen gestellt habt.
Danke auch an die Menschen, die draußen die Fragen im Stream gestellt haben.
Da sind jetzt irgendwie nicht alle durchgekommen, aber trotzdem vielen, vielen Dank.
Und ich wünsche euch noch einen schönen Tag hier.
Und wie gesagt, morgen ist gleich die nächste Episode mit den AI-Vampiren.
Und da bin ich auch drauf gespannt.
Ich weiß auch nicht so genau, den exakten Inhalt weiß ich nicht, aber ich bin auf jeden Fall sehr gespannt.
Sehr schön.
Danke.
Bis bald.
Hier ein Hinweis in eigener Sache.
Software-Architektur im Stream ist live vor Ort.
Wir sind beim TechRider Summit im Juni in Köln dabei.
Mehr Infos dazu und einen speziellen Rabattcode für unsere Community findest du auf unserer Website. software-architektur.tv Sei dabei, stell Fragen und komm auch gern auf uns zu.