# AI in Software Development: Cost, Governance, and Strategic Shifts

**Podcast:** Software Architektur im Stream
**Published:** 2026-07-01

## Transcript

Herzlich willkommen zu einer weiteren Episode von Software-Expektoren-Stream, dieses Mal von den Tech-Riders.
Und zwar wollen wir uns unterhalten über das Thema KI, macht Software vermeintlich billiger, macht sich auch Projekte einfacher.
Und dazu sind Sebastian und Axel zu uns gekommen.
Fangen wir an mit einer Vorstellungsrunde.
Sebastian, möchtest du etwas wirklich 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.
Ersatz teilen.
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 Torbopascal, dann kam Delphi, dann habe ich als Microsoft-Tutent-Partner ganz VSC Sharp 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 halt den Raum zur Verfügung gestellt haben und wo wir...
glaube ich, alle heute oder gestern Talks gehalten haben, sodass das so ein bisschen den 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, in 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 Hielke gesehen, der in einem Projekt gezeigt hat, dass eine Person ein 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 der Organisation 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, ey, guck mal, ich habe hier was Vibe gekodet, aber es macht sich keine 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 maintainen, wenn ich neue Feature einbringe?
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 lass 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 sozusagen nochmal detaillierter fragen.
Das heißt, du hast ja gesagt, dass das Bauen schneller wird.
Du hast sogar von Faktor 90 gesprochen.
Das heißt also mindestens der Trai, 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.
Was man so abfällig als Vibe-Coding bezeichnet macht, dann ist die Wahrscheinlichkeit sehr hoch, dass da Lücken drin sind.
Bugs, Sicherheitslöcher oder ähnliche Dinge.
Ja, definitiv.
Was schneller wird auch aus eigener Erfahrung.
Ich habe am Wochenende mal ein WM-Tippspiel gebaut und ich hatte eine Einstiegshürde.
Also Font entbauen 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, was macht man?
Man geht aufs TakeOverflow und schaut, was sagt die Fehlermeldung.
In dem Fall einfach hier das Cloud-Modell gefragt.
Ja, 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 da nicht mehr nachvollziehen kann.
Aber ich bin gefühlt deutlich schneller, so jetzt mein Achselblick als Achselperson, deutlich schneller über diese typischen Tücken, der Entwicklungsumgebung hinweggekommen, 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 er halt sagt, dass tatsächlich das Coden selber schneller geht, wäre es ja...
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 Vibecoding 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.
teurer durch, 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 and Development, noch entwickeln und institutionalisieren, um wirklich sagen zu können, Projekte werden einfacher.
Ja, das ist ein guter Punkt.
Und schneller.
Sehr guter Punkt.
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 Vibecode.
Ja, definitiv.
Also wir haben tatsächlich Sachen aus dem Chit bei YouTube.
Die Joanna Tyrell, Tyrell Joanna, so rum ist es, sagt also, ihr spricht ein Experte.
Die Zukunft ist vor allem Specification Engineering von Cajun Mensch.
Ich vermute, dass das die Erstellung von Spezifikationen ist im Zusammenspiel von KI und Mensch.
Damit stellt sie in Abrede, dass 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 vom Menschen mit der KI zusammendesignt wird.
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 über 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 fragliche Anforderung, nehme ich halt an.
Und die können wir ja jetzt gemeinsam Also wir können ein System bauen für Self-Facted-Term Stream, wo es eine Terminplanung gibt für irgendwelche Streams, was auch immer.
Oder nicht, wer einen Tipp spielt, da gibt es ja fachliche Anforderungen.
Das will 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.
DN-Asset ist es vielleicht, schnellere Migration 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-drivenen 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 Speck-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?
Wird sich zeigen.
Ich glaube, wir haben noch keine guten Antworten drauf.
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.
ich nenne es mal 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 noch reviewen.
Zu dem Punkt, weil das eigentlich, finde ich, eine gute Vorlage ist für eine andere Frage.
Das impliziert so ein bisschen, also ich meine, Buchhaltung, niemand schreibt ein Buchhaltungssystem.
Dafür gibt es halt SAP.
Das heißt, wenn man das sozusagen zu Ende denkt, könnte man jetzt argumentieren, das ist die Frage, ob du denen zustimmen würdest, dass halt sowas wie Buchhaltung, was eben verstanden ist, das ist Standardsoftware, das schreibe ich eben nicht.
Das heißt also, ich habe sozusagen nichts, wo ich KI wirklich benutzen kann, weil ich eben eh nur die Dinge schreibe, die innovativ und neu sind, die halt eben, die ich nicht mit Standardsoftware erschlagen kann.
Also wenn ich ein Problem habe, was ich mit Standardsoftware, was halt wohl 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 halt Schwierigkeiten haben, mit KI überhaupt zurecht zu kommen.
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 3% Funktionsanfang nutze, aber tausende Euro im Monat bezahle?
Und ich kann mir das Funktionsset, was ich davon brauche, zusammenbauen lassen von der 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 hinterfragt.
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.
Ich denke mal, alle, und mir wird gerade keiner ein, der es nicht hat, alle Standardprodukte von einem Confluence, von einem Gyra, ü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 ja dran, mir etwas zu customisen, was meinem Spezialneed 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 eine LM nutzen kann.
Ja.
Genau.
Es gibt noch mehr Sachen von den Zuschauern.
Das hat einmal der Mr.
Yeah auf YouTube, der sagt, also ich glaube tatsächlich, das wird dann wohl ein Der sein, Vibe-Coding ist ganz nett für Kleinigkeiten, die man privat nutzt.
Interessanter ist Agentic.
Das 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?
Ich, auch hier wieder, 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 dieses...
Die Welt, die wir gerade erleben.
Credits werden massiv teurer seit Juni.
Wir wissen eigentlich gar nicht, was für 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 fertig.
Da müssen wir auch lernen.
Damit du aber interessanterweise im Prinzip diese Frage hinterfragst, ob es wirklich billiger wird.
Also 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.
Beziehungsweise wir müssen auch noch passende Mechanismen für Kostenmonitoring einfach entwerfen, die jeder verwenden kann.
Ich glaube auch, dieses Mehragenten-Vielhilfe-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, was...
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 was eigentlich, wobei man dann irgendwie rausrechnen müsste, wie viel davon Investment sind und dann müsste man eigentlich rausbekommen, 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.
DudeRoot hat geschrieben, DudeRoot 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 Zepter, würde ich jetzt sagen, ist das in Lead Speech, der hat halt hinzugefügt, Erstellung von Software ist doch nur 10%, 10 bis 20%, der Rest ist Wartung.
Ich würde erstmal die Frage stellen, würdet ihr dem zustimmen?
Also ist der Faktor, ist Wartung tatsächlich 80 bis 90 Prozent der Kosten?
Ich kann da gar keine konkrete Zahl 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 Banking-Umfeld bin, dann ich baue drei Jahre und betreibe 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 dem Begriff 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 es.
Und es gibt halt zumindest eine bestimmte Fraktion innerhalb der Softwareentwicklung, die ja sagt, das Software halt 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 Stuart Ritz sagt, die Wartung dessen wird langfristig mehr und mehr Entwickler in Arbeit brauchen.
Das heißt also, die Aussage ist, wir haben mit 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ürdet ihr das unterschreiben?
Wir haben ja verschiedene Sachen, die 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 zunehmen.
Das ist aber 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 substanzielle Erkenntnisse sein, wie irgendwelche kritischen Sicherheitslücken.
Das 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 zunehmen.
Aber hinter der Aussage steckt auch die Annahme, dass diese Systeme zwar gut im Erzeugen, aber nicht im Warten von Code sind.
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 Bug-Triage und fixen, seien es Library-Updates, seien 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 SBR Paznau, 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 Erwartung bist, weil du gibst ja eigentlich nur natürlich praktisch ein Prompt, hier ist ein Problem, beheb es.
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 wiederfindest und du dann erstmal wieder einen substanziellen Arbeitsaufwand hast.
Nicht nur diese kleine Zeile Code, die vielleicht den Back 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, 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.
Und es hängt sehr stark davon ab, wie man die KI steuert.
Also das, was viele jetzt so dieses KI-Harnisch nennen oder dieses Harnes, 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 in diesem Zeug fü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 Mal nehme ich wahr, es gab ganz klare Guidelines, wie entwickelt werden soll.
Und dann plötzlich kam bei mir mal einer und hat gesagt, oh, ich mache jetzt Clean Code.
Und im Clean Code, oh, es ist 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, was weiß ich, vielleicht sogar einen 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, ich schreibe halt selber keinen Code mehr, daraus könnte man ja jetzt irgendwie auch ableiten.
Das heißt, ich muss den Code auch nicht mehr verstehen.
Das würde ich ja nicht sagen.
Oder ist das so?
Also sagt er, dass man den Code nicht mehr verstehen muss, weil dann wird die Diskussion eine andere.
Also dann ist es halt so, dass die menschliche Verstehbarkeit 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.
Es ist dann nicht sogar ganz wild in die Zukunft gesporn, 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, gibt ja genug Leute, die sagen, das was früher der Wechsel von Assembly Code zu...
compiler-basierten Sprachen war, ist jetzt einfach der Wechsel von Programmiersprachen zu natürliche Sprache als Spezifikation.
Und was da runterlä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 so, aber da könnte es hingehen.
Okay, aber das bedeutet, dass das tatsächlich sozusagen das Endziel oder das Endergebnis sein wird aus deiner Sicht.
Der Martin Pasch.
bei LinkedIn hat gesagt, man kann viel mehr gut 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 Kundenerwartung angehoben 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 der sie selbst baut.
Das ist das realistische Szenario.
Ist ja nicht so, dass wir nicht schon 100 Millionen Apps im App Store hätten.
Genau, also du beschreibst den Rebound-Effekt, das ist diese Geschichte mit, wenn wir halt, ich glaube es ist mit Licht, also wenn halt 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 Septer, von dem ich vorhin sprach, Der hat halt dieses gesagt, von wegen Software, die Erstellung von Software wird, ist nur 10 bis 20 Prozent, der Rest ist halt Wartung.
Hat jetzt ergänzt, ich meinte das aus Sicht von Total Cost of Ownership und Softwareentropie.
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.
Der 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 halt, 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, also nicht, dass ich einen Prompt mache, daraus einen Bikot 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 halt diese Code-Ebene zumindest aktuell noch ein Thema ist.
Also 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 weibgecodete 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 dass juristisch, also aus Governance-Sicht, da alle lieber die Zügel anhalten.
Jetzt habe ich halt ein...
Vor einiger Zeit so ein Mastodon-Posted gesehen, wo halt irgendjemand sowas schrieb im Sinne von, das ist irgendwie ganz schlimm, wo ich halt arbeite.
Alle Menschen, die um mich herum benutzen, halt irgendwie AI.
Und also verdummen dabei, wenn ich sozusagen zusammenfassen darf.
Das ist aber gar nicht der Punkt, auf den ich halt hinaus will.
Und lesen halt einfach nicht mehr die Pull-Requests durch, sondern lassen das einfach durchlaufen.
Was ich...
wie soll ich sagen, nachvollziehbar finde.
Also Pull-Requests zu reviewen und das halt 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 ein gutes Zeichen ist, wenn du das Vertrauen hast.
Ich muss da meinen Leuten vertrauen.
Und natürlich gibt es auch irgendwie schon die Vorgabe, dass die dafür verantwortlich sind.
Trotzdem sehe ich natürlich diese Entwicklung nicht nur bei meinen Leuten, sondern auch bei mir selbst.
Und je mehr ich mit KI arbeite, desto mehr wächst mein Vertrauen und desto weniger habe ich das Bedürfnis, da im Detail drauf zu schauen.
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 KI-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 müssen, werden zukünftig wohl daran gemessen, wie gut sie KI möglichst effizient einsetzen und dazu bringen, möglichst qualitäts- und wartungssicheren Outcome zu generieren.
Was dann bedeutet, dass sozusagen für diesen Punkt du deine Entwickler haben möchtest und halt einstellen wirst und beschäftigen wirst, die eben das sozusagen verantwortlich tun können.
Was auch immer das halt irgendwie bedeutet.
Also nicht, wie auch immer man das halt dann konkret umsetzt.
Ähm, achso, hier stand noch, ich weiß nicht, ob ich das verstehe, aber ich finde die Frage gut.
Mächtige versus doofe Modelle, also von Silose bei YouTube.
Mächtige versus 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, sind bis zur Anweisung zu verstehen.
Wohin führt das gesellschaftlich bei Projekten?
Ja, ich bin auch nicht sicher, ob ich die Frage verstehe.
Also was es hier gibt, ist halt die Behauptung, dass eben dieses Mythos beispielsweise von Anthropic halt...
so viele Sicherheitsstücken findet und halt so gut ist, dass sie halt irgendwie sagen, dass sie das halt erstmal nur begrenzt freigegeben haben und dann halt anschließend generell frei, weil das halt so wahnsinnig gefährlich ist.
Und Anthropic hat sich auch vor ein paar Tagen hingestellt und hat, glaube ich, gesagt, sie wollen halt erstmal so einen Stopp bei LLM-Entwicklung.
Und bei mir stellt sich halt 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 der Power Mac G4 eine Waffe ist, weil der zu schnell ist und unter die Supercomputing-Exportbeschränkung der USA fällt.
Also ist das Marketing so wie der Apple-Werbespot?
Es ist natürlich Marketing, ganz ehrlich.
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 Antrofic jetzt sagt, sie wollen erstmal 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 den 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 wieder mit Einschränkung im Blick auf Softwareentwicklung da gar keine Reglementierung 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?
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 100 Prozent sein, sondern es hat am Ende vielleicht die gleiche Fehlerquote und die gleiche Angreifbarkeit.
Guter Aufhänger, um die Frage zu stellen, die mir die ganze Zeit im Hinterkopf irgendwie herumschwirrte.
Also wir sind uns ja alle darüber ein, oder nicht, das ist ja das, was du gerade gesagt hast, dass halt LLMs die mindestens mit dem jetzigen Stand nicht so qualitativ gut sind wie Menschen.
Und bei mir gibt es da sozusagen zwei Erfahrungen.
Die eine Sache ist halt, also wenn ich mir das typische Legacy-System angucke, da ist die Qualität des Codes, sagen wir mal, durchschnittlich.
Und es ist ja, was ja impliziert, dass wir halt im wirtschaftlichen Kontext Systeme akzeptieren und das sind businesskritische Systeme, bei denen die Codequalität eben sehr durchschnittlich ist.
Sind LMs vielleicht gut genug?
Ist das vielleicht der Punkt und deswegen ist das eben etwas, was eingesetzt wird?
Da kommen Sie wahrscheinlich rüber über die Schwelle oder zumindest schneller vielleicht.
Ja, würde ich so unterschreiben.
Also bevor es bei Paznau 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 diesem Legacy-System 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 Quote, wo ich teure Leute bezahlt habe, hochspezielle Systeme zu bauen, den hat so ein Sprachmodell ja nie gesehen, normalerweise.
Das, was wirklich ein komplexer Businesslogik 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 Businesscode, wie ich in der Businessumgebung habe, denn auch sein kann.
Denn das System, noch sind wir nicht in einer Welt, dass das System sich selbst hinterfragt, ist das wirklich guter Code, den ich schreibe?
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.
Jetzt noch von Mr.
Yeah auf, ich glaube das ist YouTube, ein Hinweis, bald überall Schilder Menschen haften für ihre Agenten.
Übrigens, das finde ich tatsächlich eine gute Idee.
Nicht, könnte man halt so Aufkleber draus machen.
Weil das passt ja zu dem, was ihr vorhin sagtet, mit der nicht Haftung, aber Verantwortung.
Also das ist ein Werkzeug, irgendjemand muss Verantwortung übernehmen.
Ich fand, das war noch eine gute Ergänzung dazu.
Und dann von ihm auch noch der Hinweis, wo ich ein Net Positive der KIs sehe, ist Dokumentation.
Wer entwickelnde hat 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, also es dürfte nicht zu einer Inflation von Dokumentation führen, weil dann liest es auch wieder keiner.
Also nur weil Produzieren von Text billig wird, sollte man es vielleicht nicht machen.
Ja, aber dem Punkt an sich stimme ich auf jeden Fall zu.
Dokumentation generieren macht es einfacher und sollte es mit Augenmaß machen.
Ich habe noch, also, weiß nicht, ob das Kitzki schreibt.
Der Wald- und Wiesendeveloper 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 was dazu sagen wollt.
Es ist halt im Prinzip eine Aussage über ein individuelles Erleben und eben insbesondere, dass eben dadurch sozusagen für andere Themen, Zeit bleibt.
Wir haben übrigens Freitagmorgen eine Episode mit dem Ralf und dem Martin Lippert zum Thema, welche Auswirkungen das halt eigentlich hat mit dem AI-Zeug auf Entwickler hin.
Das fällt mir dabei gerade ein, weil die Folge sagt, mal gucken.
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 spannend ist und dazu irgendwie gut passt.
Was ist denn ein KI-Vampir?
Ja, das habe ich jetzt auch gefragt.
Der sozusagen das Leben aus dir raussorgt, so verstehe ich das.
Also es gibt tatsächlich den Effekt, dass eben EntwicklerInnen sich dadurch unter Druck gesetzt fühlen und halt, also tatsächlich nahezu psychologische Effekte davon haben.
Ist dann wie so ein, was heißt das, Futurama, diese...
Grüne Brainslugs, das wären dann quasi die LLMs, die dann...
Brainslug ist vielleicht noch ein besserer Begriff, ja.
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 so unterschreiben?
Ich finde das interessant mit haben...
haben...
Quatsch.
haben das Ergebnis schon während des Prompting 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?
Okay, 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.
Als Beispiel, typischerweise hat man ja einen Architekten.
Also ich weiß irgendwie, ich brauche eine Datenbank, um Daten vorzuhalten.
Du hast einen Architekten, der trifft eine Entscheidung, was nehme ich?
Nöme ich einen Oracle, nehme ich einen MS SQL, nehme ich einen Postgres oder sonst irgendwas?
Meine Wahrnehmung ist eher die, dass diese Entscheidungen gar nicht mehr getroffen werden müssen vom Menschen.
Also über die machst du dir gar keine Gedanken mehr.
Du hast eigentlich nur noch das Bild im Auge.
Jetzt nämlich wieder 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.
Darf ich fragen, wie dein WM-Spiel die Daten ablegt?
Weil du gerade das Beispiel genannt hast.
Und wie du da hingekommen bist?
Der macht es ganz einfach.
Der hat eine JSON-Datei, die einfach speichert.
Ein Filesystem.
Okay, und das ist ein Ergebnis von dem, was das System überlegt hat.
Ich habe das auch nicht hinterfragt, weil ich einfach gesagt habe, muss halt persistiert werden, fertig.
Er hätte genauso gut sagen können, ich hole mir irgendeinen Open-Source-Datenbank-Stack noch runter.
Hört sich für mich ein bisschen wie ein Widerspruch an.
Also die eine Aussage ist, es gibt ein...
Plan, den man im Kopf hat, der durch Feedback in der Entwicklung mit der AI sich irgendwie ändert.
Die andere Aussage ist, nee, dieser Plan gerade kommt von der AI.
Ist das ein Widerspruch?
Ich wollte es bewusst als Evolution skizzieren.
Achso, 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.
Ja, was weiß ich?
Angular.
Ich will unbedingt Angular vorne haben.
Ja, weil ich habe schon immer Angular gemacht.
In der nächsten Evolutionsstufe will ich mir darüber gar, oder 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 halt Bestrebungen gibt, Softwareentwicklung halt zu öffnen und halt, sagen wir mal, einfacher zu machen.
Also da gibt es eine Tradition, nicht?
Kobol hat das damals versucht und ich weiß nicht, wie eure Erlebnisfeld ist, aber ich kenne halt das prototypische Beispiel, was mir halt immer im Kopf sozusagen rumschwirrt, ist diese Unternehmen, die halt von einem ...
Excel getrieben werden, wo irgendjemand sich halt hingestellt hat und ein großes Excel-Specialist gemacht hat, dann irgendwann nicht Formeln und Makros reingebaut hat und das ist das Ding, was jetzt magisch irgendetwas steuert.
Und das Gerät hat subjektiv vollkommen außer Kontrolle.
Und meine Behauptung wäre, dass das bedeutet, dass halt Menschen, die halt sozusagen nicht Software entwickeln können, wenn sie Software entwickeln, zum Beispiel mit Excel, obwohl sie ja technisch das können, aber es wird irgendwie chaotisch und schlimm.
Und jetzt ist halt die Frage, wenn wir die jetzt irgendwie von LM setzen, meine Behalte wäre, das geht halt irgendwie auch schief.
Und deswegen frage ich mich halt, ob es sozusagen einen Skill gibt, der Softwareentwicklung ist.
Dieser Feedback-Zyklus für dich, für die Softwareentwicklung, ist das das, was es ausmacht?
Ich versuche herauszufinden, vielleicht wäre das die Frage, ich habe Informatik studiert, ihr seid offensichtlich auch Menschen, die sich lange Zeit sehr intensiv mit Softwareentwicklung beschäftigt haben.
eine formale Ausbildung oder hat 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?
Also was ist der Skill?
Ist das der Skill?
Ich muss ein bisschen grinsen gerade, weil ich da eine interessante Anekdote zu im Kopf habe.
Als Entwickler ist man so ein bisschen arrogant und würde erstmal wahrscheinlich sagen, ja, nee, das kann diese Personen oder können solche Menschen nicht gut.
Aber vorhin noch bei einem Vortrag gesehen, er hat gesagt, sein 13-jähriger Sohn hat jetzt als Hobby Computerspiele zu entwickeln und hat uns eins 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 Fünfer-Informatik und überhaupt keinen Plan von Softwareentwicklung.
Und das war ein Flugsimulator mit Missionen, mit Schießen und Fliegen und Landen.
Und 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.
Und das bedeutet, also damit unterstellst du sozusagen, wenn wir uns jetzt hinsetzen würden und dasselbe tun würden wie dieser 13-Jährige, 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.
Das ist mir zu hart.
Jetzt komme ich wieder zu dringend, was wir eben diskutiert haben.
Ich glaube, ein Softwareentwickler, 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, führt auf Basis dieser Erfahrung, stand heute noch die Software eines Softwareentwicklers besser, als wenn ich jetzt den Jungen nehme, der das Ganze per Promts generieren lässt.
Da kriege ich ja einen Mischmasch aus Technologien, vielleicht auch unterschiedliche Sprachen, die irgendwie vereint werden.
Der ganz ehrliche 13-Jährige Junge muss sich ja nicht mit 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 welche Stacks, wie funktionieren, immer noch ein Qualitätshebel?
Stimme ich zu.
Also ich mache jetzt gerade so ein bisschen den Advocatus 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 durch 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 Software-Defizit?
Vielleicht in manchen Branchen, in manchen Unternehmen.
Also für den Maschinenbraucher kann ich sagen, da wir hier 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 Software-Defizit.
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 Software-Defizit.
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 Fachtomäne vorhin hatten wir Buchhaltungen.
Ich habe irgendwo jemanden, der macht Buchhaltungen in Excel, der lernt Vibe-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 IT-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.
Das ist 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 Tag Riders für gefühlt 45 Grad.
Aber kalte Getrecke.
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.
Ich wünsche euch 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.
Softwarearchitektur 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.
Sei dabei, stell Fragen und komm auch gerne auf uns zu.