KI in der Softwareentwicklung – schneller, aber nicht unkontrolliert

Speaker 1

00:00

Mr. Ciso und Mr.

Speaker 2

00:01

AI im Gespräch. Der Podcast für sichere und zuverlässige Digitalisierung.

00:06

Mr. Ciso und Mr.

00:08

AI im Gespräch

Speaker 1

00:11

Klappe, die dritte. Herzlich willkommen zu diesem Podcast, Mr. Cizo und der Mr. AI. Jetzt zum Thema. Was ist jetzt das Thema?

Speaker 2

00:22

Ja, mein Thema. KI in der Softwareentwicklung. Endlich mal. Danke, Dani.

Speaker 1

00:28

Genau. Tobi, du hast schon umfangreiche Softwareentwicklungsfirma und heute das Thema Wie sieht dein Alltag heute aus im Vergleich zu früher als Softwareentwickler? Wie bist du vom Softwareentwickler zu Mr. AI geworden?

Speaker 2

00:43

Was hätte ich dich auf diesem Weg begleitet? Ja, ich muss gestehen, also KI und Softwareentwicklung gehören für mich doch sehr eng zusammen. In dem Podcast schon ein bisschen reingehört habe. Für mich macht KI einige Aufgaben. Und in der Softwareentwicklung finde ich es extrem stark, was man damit schon machen kann. Also selber Software entwickeln, muss ich gestehen, ist schon längere Zeit her, dass ich es gemacht habe. Aber ich habe in der Zwischenzeit doch ab und zu mal für einen Kunden was entwickelt und da unterstützt mich KI-extrem. Also jetzt, wenn ich irgendwas programmieren musste, heute Morgen war ich beim Kunden, Ich brauche dann mal so ein Wegwerfprototyp, ein KI-Agent, ein Multi-Agentens-System mit MCPs und so. Das erste, was ich gemacht habe, ich habe meinen Editor gestartet. Ich bin Studio Code und GitHub Co-Pilot, ist so mein Stack momentan und habe da gesagt, hey du, mach mir mal einen Plan. Ich möchte gern das und das haben und habe meine Anforderungen da sehr kurz reingetan und gesagt, mach mir einen Plan. Und dann habe ich so, ich glaube, 500 Seiten, äh nicht 500 Seiten, aber 500 Zeilen wenigstens Markdown, also Tags bekommen von der KI, wo drinsteht, was ich haben will. Und das nächste, was ich dann mache, die nächste viertelhalbe Stunde, ist das Ganze anschauen und gucken, okay, ist das das, was ich haben will? Ich kann damit Prompt das Ganze noch ein bisschen anpassen. Ich möchte gerne die Technologie haben. Ich brauche jetzt kein buntes Frontend. Ich möchte gerne einfach nur zum Beispiel die Applikationslogik haben. Die anderen Sachen kommen später dazu. Und dann kann ich Schritt für Schritt in der Maschine eigentlich einen Plan schreiben lassen, damit ich es nicht machen muss, weil ich bin da viel langsamer als die Maschine. Und für mich ist wiederum einfacher zu gucken, was die Maschine machen will. bevor es sich dann macht und ich kann es entsprechend kontrollieren und da sicherstellen, dass eigentlich das rauskommt, was ich haben möchte. Und der nächste Schritt ist da eine Kreditkarte zücken und Kaffee trinken gehen oder Mittagessen gehen oder vielleicht auch mal schlafen gehen, wenn es abends ist. Und dann die KI-Arbeit machen lassen. Also KI kann entsprechend auch schon sehr umfangreiche Aufgaben umsetzen, wenn sie gut genug beschrieben sind. Und das ist eigentlich das Wichtigste. Für mich der Schritt, die Spezifikation schreiben. Das ist jetzt eher die technische Spezifikation. Ich muss schon mal selber als Mensch verstehen, was ich haben will. Ja. Und dann muss ich der Maschine mitteilen und dann muss ich kontrollieren, was sie für mich macht. Wie früher, wenn ich meinem Team irgendwo Aufgaben gegeben habe, Die Feature-Tickets mussten da entsprechend ganz detailliert drin sein, dass man ungefähr wusste, was man bekommt, sonst ist das Ergebnis nicht so klar. Ja. Also das ist der erste Schritt, oder? Geht die Maschine arbeiten, braucht auch ganz viele Tokens entsprechend, rechnet viel. Das kann ich auf meiner Maschine machen, ich kann es irgendwo auslagern, ich kann mehrere Aufgaben parallel im Hintergrund laufen lassen, mehrere Agents, die mit Git Workflows und anderen Sachen. entsprechend da unabhängig voneinander arbeiten können. Ich kann da zwischendrin wieder reingucken, wie steht es, wenn es Fragen gibt, kann ich die beantworten. Oder ich kann es wirklich komplett auch in der Cloud laufen lassen und dann einfach am nächsten Tag, wenn es fertig ist. Heißt dann, hey du, der Code ist fertig, guckst dir an, dann hast du irgendwo Tausende oder Millionen von Zeilen und Code, die sich geändert haben. Und das wie früher als Architekt oder als Senior-Entwickler, wo du die Verantwortung trägst für sowas, musst du das dann irgendwo prüfen und sicherstellen. Ist es das, was ich erwartet habe? Ist es sicher?

Speaker 2

03:30

Entspricht es den Anforderungen des Kunden? Entspricht es unseren Quality-Guidelines? Und das ist schon noch was, was irgendwie wieder zurückschlägt. Ja, KI macht zwar schon Arbeit, aber am Schluss muss man das Ganze kontrollieren, verantwortlich. Dreh ist immer noch du am Schluss. Ja, genau. Ja, ich finde es auch gut. Also ich finde es spannend. Wir haben mit Kollegen gesprochen, die auch gesagt haben. Ich hätte mir früher nie vorstellen können, dass ich nicht mehr Software entwickle, aber ich finde es cool, so wie es jetzt ist. Wenn man so viel produktiver ist, also wenn ich jetzt selber herausfinden müsste, wie muss ich jetzt das Framework und die Oberfläche mit den Schnittstellen kombinieren und die neueste Version von dem, wie funktioniert die jetzt? Das ist KI so viel schneller, als wenn ich das rausfinden müsste. Also Faktor 5 bis 10 ist das, was sicher möglich ist. Also wenn ich einen Tag brauche, braucht die KI vielleicht, keine Ahnung, eine Stunde oder so. Oder vielleicht zwei, aber ich muss immer noch viel Input liefern, dass es gutes Ergebnis gibt und das Ganze am Schluss kontrollieren. Also den Speed, den das Ding zwar auf der Zwischenstrecke hat, unsere KI. Am Anfang und am Ende muss ich da wieder Zeit reinstecken, um die Qualität sicherzustellen, die ich sonst eigentlich im Entwicklungsprozess für mich selber mache, weil ich ja für mich selber weiß, was ich haben will und am Schluss auch kontrollieren kann, ob es das Richtige ist. Und ich glaube, das ist das, was man häufig unterschätzt. Der Aufwand, eine gute Spezifikation zu machen und am Schluss sicherzustellen, dass die Qualität dem entspricht, was man erwartet und auch die Funktionalität.

Speaker 1

04:43

Also die Anforderungen Formulieren und Definieren am Anfang, das hat sich nicht geändert. Ich war früher als Requirements Engineer unterwegs, dass es genau die Aufgabe war. Dann Anforderungen definieren, die in die Entwicklung geschlossen sind. Das heisst, Ohne das geht es erhöht nicht.

Speaker 2

04:58

Absolut. Ja, spannend. Also man kann auch KI nutzen, um die Anforderungen gezielt auch beim Kunden zum Beispiel zu erheben oder auch zu qualifizieren. Ist das, was er erzählt, das Richtige? Stimmt das mit dem, was man sonst drin hat? Da ist KI auch super, um so Abhängigkeiten auch zu prüfen. Das finde ich ein gutes Hilfsmittel, aber man muss halt die Inhalte auch so aufsetzen, dass das überhaupt funktioniert. Und das ist heute noch bei den meisten Unternehmen schwieriger. Confluence sind sie zwar schön abgelegt, aber wie kann man jetzt wirklich sicherstellen, dass die Spezifikation miteinander kompatibel ist, dass da nicht auf der einen Seite was steht, was auf der anderen genau entgegensetzt. beschrieben steht, da könnte KI schon nachhelfen, aber das ist glaube ich noch was, wo man dran ist. Da sind wir nicht ganz fertig.

Speaker 1

05:33

Was für schüchtige Risiken siehst du jetzt so in der Softwareentwicklung KI unterstützt? Also ich glaube, das Wichtigste ist, dass man sich bewusst sein muss, KI macht Sachen.

Speaker 2

05:44

Also sie macht Sachen auf meiner Maschine, zum Beispiel. Ich habe jetzt einen Mac, für mich ist wichtig. Wenn ich irgendwo Software-Projekte habe, nehme ich einen Docker-Container, wo das drin läuft. Das sind so sogenannte Dev-Containers. Da läuft meine ganze Software drin. Ich habe alle Abhängigkeiten, die ich brauche, sind drin installiert. Es ist wie eine Art Sandbox, also ein Sandkasten. Und wenn KI einen Fehler macht, ist im schlimmsten Fall der Sandkasten kaputt, da muss ich halt einen neuen hinsetzen. Also ich kann einfach die Software wieder auschecken. Das sitzt voraus, dass man die Software irgendwo. zentral verwaltet, also zum Beispiel ein Skit entsprechend auch einsetzt oder ein GitHub entsprechend zum Beispiel einen Code ablegt, dass man den versioniert und die ältere Version wieder rausziehen kann und kann sagen, okay, gut, da hat es noch funktioniert, jetzt gehen wir dort wieder weiter und machen damit . Also das ist das Wichtigste, dass man einerseits die Kontrolle über die Infrastruktur hat, dass KI nichts auf meinem PC kaputt machen kann. Und das zweite, dass man einen vorherigen Schritt wieder zurückholen kann. Genau. Ja, okay, dann läuft das Ding mal irgendwo, es produziert Code, was hat es trainiert? Das hat es auswendig gelernt, also trainiert ist ja nichts anderes als Auswendig gelernte Sachen, die jetzt stochastisch mit gewissen Wahrscheinlichkeiten wiederkommen. Wenn man mal guckt, was da als Trainingsdaten gerade in der Softwareentwicklung verwendet wurden, ist ja viel Code, der offen rum liegt. Das größte ist natürlich GitHub, das hat ganz viele Repositories, die unter irgendwelchen Lizenzen stehen. Und die Qualität von dem Code ist jetzt nicht unbedingt jetzt im Senior Master Enterprise Niveau, sondern eher meistens so Anfängerniveau. Und da muss man schon aufpassen, dass man dann nicht Code einfängt, der vielleicht jetzt nicht unbedingt den eigenen Qualitätsstandard entspricht. Das muss man sehr gute Prompts auch mitgeben. Man kann das entsprechend auch hinterlegen, dass automatisch, wenn Code generiert wird, gewissen Standards entspricht, auch gerade die eigenen Standards mitgeben. Und dann kann man auch sicherstellen, dass man eine gewisse Qualität bekommt von Code. Genau. Und dann das nächste Thema ist ja, wenn man Software entwickelt, verwendet man ja auch meistens irgendwelche Frameworks, das heißt irgendwelche Software, Pakete, die man nutzt, wo gewisse Funktionalität drin ist, die man aus dem Internet runterladen kann. Das fängt bei Java an oder bei . NET, dass man irgendein Framework hat, was man runterlädt und verwendet. Und dann gibt es ganz viele Open-Source-Libraries meistens. Die man dann verwendet, auch fürs Frontend, dass da schöne Sachen drin sind, dass es gut aussieht. Und da gibt es ganz viele Möglichkeiten, da Blödsinn reinzubekommen. Einerseits, dass natürlich KI wissen muss, was gibt es überhaupt für Bibliotheken, welche möchte ich gerne verwenden. was ist die richtige Version, die neueste. Ich möchte gerne immer die neueste haben, damit die entsprechend auch sicher ist. Und wenn die KI halt die falsche Bibliothek, zum Beispiel eine, die fast gleich heißt oder wurde prompt und dann die. Beschreibung zu der Library ein bisschen besser klingt als die offizielle Standard Library, die es gibt, weil das halt jemand gerade so einem High-Checken möchte, der dann zum Beispiel seine schlechte Library unterschieben möchte mit irgendwelchen bösen Code drin. dann sehe ich das als Mensch gar nicht unbedingt. Das muss ich dann ganz genau kontrollieren, okay, was hat KI jetzt gemacht? Was hat sie jetzt für neue Abhängigkeiten reingetan? Also meine Lieferkette irgendwo von den abhängigen Software. Elementen, die ich brauche, ist vielleicht gewachsen, irgendwas, was ich gar nicht kontrollieren kann. Das ist ganz wichtig, da auch hinzuschauen, wenn man den Code dann schlussendlich übernimmt, ist es das, was ich haben will? Und es gibt Kollegen, die sagen, KI darf für mich keine neuen Abhängigkeiten dazu tun. Ja, möchte ich kontrollieren, die muss mich erst fragen und dann kontrolliere ich das. Das ist je nach Unternehmen oder vielleicht auch persönlicher. Erfahrung oder Vertrauen entsprechend auch sicher wichtig, sich das zu überlegen, wo KI mich unterstützen darf, wo es mich auch vielleicht ersetzen darf und wo nicht. Und da ist für mich schon die Grenze, wo ich genau wissen will. Okay, ist das wirklich die richtige Library? Ist es die richtige Version? Ich habe genau gelesen, gestern gab es vielleicht einen Security-Incident auf der Library. Ist es die neueste Version, die es jetzt reingetan hat oder ist es eine ältere, die unsicher ist, die jetzt halt reinkommt, weil in Trainingsdaten früher ganz viel die alte Version drin waren? Das muss man kontrollieren. Du merkst schon, ich bin schon mittendrin im Flow, gell? Ich könnte dir glaube ich noch zwei Stunden erzählen.

Speaker 1

09:14

Ja, jetzt haben wir ja über die Risiken geredet, jetzt können wir noch kurz darüber reden. Was können wir denn dagegen machen oder was machen wir, um die Risiken zu machen oder minderen? Supply chain, Abhängigkeit, die Libraries war das Thema. Trainingsmaterial, das zum Teil schrott ist und den potenziellen Kontrollverlust, die wir noch haben. Was kannst du über Frameworks, die man einsetzen, die du einsetzt oder für, weißt du, Best Practice? Sache.

Speaker 2

09:43

Ich denke, Standard ist sicher die Over-Sachen, die man ja irgendwo auch kennt, die entsprechend in Softwareentwicklung sehr gute Vorgaben liefert, zu typischen Problemen Einfallsvektoren.

Speaker 1

09:52

Das ist in der Webentwicklung vielleicht OFASP Top Ten für Web Applications, die geht inzwischen eben auch für LLM-spezifische Top Ten. Und die finde ich immer noch cool. Die nehmen wir gerne auch zur Hand. Genau.

Speaker 2

10:06

Also ich denke, das muss man sich sicher auch bewusst sein. Einerseits, wenn ich KI nutze, um Software zu entwickeln, hat sie natürlich auch Einfallsvektoren. Heißt sie liest zum Beispiel im Internet irgendwelche Daten. oder Abhängigkeiten von irgendwelchen Libraries und da könnten ja auch irgendwo Prompt Injections drin sein. Also das muss sich einerseits bewusst sein, dass da vielleicht falsche Entscheide getroffen werden, weil es manipuliert worden ist. Also das hilft sicher und umgedreht ja auch, wenn ich Software entwickle, wie kann ich das Ergebnis dann auch testen? Ich denke, das ist immer im klassischen DevSec-Ops-Bereich, genau. Das Shift-Left oder ich gebe die Sicherheit immer möglichst früh schon in den Entwicklungsprozess rein. Dass ich nicht erst am Schluss merke, dass ich ein Problem habe, sondern früh entsprechend schon Maßnahmen machen kann. Und das finde ich extrem wichtig, das muss man sich dessen auch bewusst sein, das gerade mit reinnimmt.

Speaker 1

10:46

Genau, das ist eines der Security Best Practice Themen, also Shift-Left. Auch nichts Neues, aber es hat einfach eine Relevanz nochmal zugenommen, dass man Informationssicherheit von Anfang an mitdenkt. Wieso ist das noch wichtiger? weil mit der Beschleunigung diesen ganzen Prozessen auch potenzielle Fehler entsprechend wahnsinnig schnell skalieren hinterher, darum unbedingt von Anfang an Man kann sich hier viel Zeit oder viel Nerven und Risiken sparen, wenn man Informationssicherheit von Anfang an mitdenkt und das Thema oder der Begriff, den wir dort immer wieder gehört, Shift-Left. Also auf der Softwareentwicklungszeitlinie das Thema Informationssicherheit nach links schieben, also früher im Prozess. Das sieht zum Beispiel so aus: als Beispiel, Wenn man dort irgendwelche Use Case-Diagramme macht, ein UML-Use-Case-Diagramm, könnte man vielleicht noch mit dem Anwendungsfall und dem Männchen darauf, wer das was macht, kann man zum Beispiel einfach auch ein Miss-Use-Case, also nicht ein Miss-Use-Case, sondern ein Miss-Use-Case. Diagramm machen und dort feindliche Akteure hineinnehmen und sich überlegen, was könnte, wie dieser Anwendungsfall aus Angriffersperspektive. Das wäre mal so in der Modellierung, also ganz am Anfang im Prozess. Das ist eine gute Idee, ja. Oder wenn man von Frameworks redet, Metro-Atlas Ist auch spannende Quellen für die, die Softwareentwicklung machen oder wie man so LLM oder Plattformen kompromittieren kann. Was sind die Angriffspunkte?

Speaker 2

12:21

Ist ja auch ein bisschen das, was man schlussendlich hat. Man hat ja auch eine, also der KI-Chatbot ist ja auch nichts anderes als eine KI-Applikation, wo entsprechend gewisse Angriffsvektoren möglich sind. Und alles, was von außen reinkommt, ist potenziell unsicher, aber das wird nicht unbedingt unterschieden, weil es technisch momentan einfach nicht gut geht. Und da kann man sich schnell irgendwas Blödes einfangen oder irgendeinen Wurm bös gesagt, der das eigene LLM infiziert. und dann vielleicht gewisse Sachen macht. Gibt es natürlich, die Hersteller machen entsprechend auch Maßnahmen dagegen. Man muss sich dessen auch bewusst sein, dass da halt ein neuer Angriffsvektor ist.

Speaker 1

12:51

Ja, was sind so die Takeaways von heute? Was möchte man da damit zuhören mitgeben?

Speaker 2

12:56

Also für mich das Wichtigste, ich setze immer auf Dev-Container oder irgendeine Einschränkung. Privilege ist das Stichwort in der Security. Ich gebe der KI möglichst begrenzte Möglichkeiten, sie darf nicht alles machen und ich kontrolliere ganz genau, was sie macht. Gut, das geht. Deswegen möglichst einschränken und vereinfachen.

Speaker 1

13:14

Und aber so die bekannte Frameworks nutze mal es Energie zur Verkehr spezifisch geht oder auch einfach die Secure Development Application, Security Verification Standard ist auch von was übrigens. Das ist jetzt auch nicht kein spezifisch, aber die südtige Best Practice geht dann immer an. Absolut.

Speaker 2

13:34

Für mich sind ja auch richtig, oder? Wenn du eine Pipeline hast, am Schluss deine Software kompilierst und testest. Dass du genauso auf Quality- und Security-Sachen dann testest. Abhängigkeiten, statische Code-Analyse, auch die gelten weiterhin. Die darf KI nicht anders machen. Also ich denke, das ist ganz wichtig, dass man hohe Standards hat und die auch weiterhin einhält und besser macht eigentlich sogar.

Speaker 1

13:53

Und unbedingt ausprobieren, einfach mit einfachen Cases, die nicht gerade riesen Schaden können anrichten, AV, ausprobieren. Und sicher der wichtigste Punkt als Ingenieur, da wäre es. .

Speaker 2

14:06

Ja, schlussendlich, wer ist verantwortlich von das, was man macht? Wenn ich eine KI anstoße, dass die Aufgaben für mich machen soll, muss ich am Schluss auch gerade stehen für das, was sie macht. Ich muss kontrollieren, was sie eincheckt. Man muss sicherstellen, dass die Code-Vorgaben eingehalten sind und das nach bestem Wissen und Gewissen auch machen. Das ist, glaube ich, ganz wichtig. Die Verantwortung, sich Bewusstsein, man selber ist zwar eher vielleicht der Manager und weniger als der Engineer, aber am Schluss, die Verantwortung ist bei einem, wenn man das entsprechend mit KI zusammen umsetzt, ist man weiterhin dafür verantwortlich.

Speaker 1

14:35

Ja, Verantwortung bleibt beim Menschen. Ja, genau. Noch. Hey, Tobias, danke für mal für die heutige Session. Spannend war.

Speaker 2

14:44

Danke, Dani. To be continued.