Künstliche Intelligenz ist momentan das Thema schlechthin in der Softwareentwicklung. Nahezu überall wird darüber gesprochen oder geschrieben, sei es auf LinkedIn, in Podcasts, auf Konferenzen oder in Fachartikeln. In der vergangenen Woche bin ich auf einen Artikel bei heise Developer gestoßen, der dieses Thema in einer interessanten Weise aufbereitet hat: „KI Navigator #11: Fünf Stufen der KI-Nutzung in der Softwareentwicklung“ von Bastian Weinlich und Semjon Mössinger. In diesem Artikel haben die beiden ein Modell vorgestellt, das beschreibt, wie Entwicklerinnen und Entwickler KI jeweils einsetzen.

Ich habe mir gedacht, dass wir uns diese fünf Stufen heute einmal etwas genauer ansehen. Zudem möchte ich erläutern, wie ich diese Stufen selbst erlebt habe und wo ich Chancen sowie Risiken sehe.

Stufe 1: Nichtnutzer von KI

Beginnen wir ganz vorne: Die erste Stufe ist eigentlich wenig spektakulär. Sie beschreibt schlicht den Fall, dass Sie in der Softwareentwicklung keine Künstliche Intelligenz einsetzen. Also im Prinzip genau das, was bis vor wenigen Jahren für alle völlig normal war. Oder anders gesagt: Sie entwickeln Software so, wie es bislang üblich war – Editor oder IDE öffnen, selbst nachdenken, selbst Code schreiben, selbst testen und so weiter. Es beschreibt die Zeit, in der Softwareentwicklung im Wesentlichen noch Handarbeit war.

Natürlich war man dabei nicht völlig auf sich allein gestellt. Man hat Dokumentationen gelesen, Suchmaschinen genutzt und war vor allem auf Stack Overflow unterwegs. Stack Overflow war über lange Zeit hinweg die Plattform schlechthin, um Antworten auf Fragen zu finden. Mittlerweile hat die Bedeutung der Plattform jedoch deutlich abgenommen, nicht zuletzt aufgrund der Entwicklungen rund um KI. Tatsächlich haben wir bereits vor über zwei Jahren ein Video mit dem Titel „StackOverflow ist tot, es lebe ChatGPT!?“ veröffentlicht.

Ich selbst habe Stack Overflow über viele Jahre hinweg sehr intensiv genutzt. Allerdings weniger, um Fragen zu stellen, sondern vor allem, um Fragen anderer zu beantworten. Das war für mich oft ein Anreiz, mich mit einem Thema tiefer zu beschäftigen. Durch das Beantworten habe ich zudem selbst sehr viel gelernt. Man muss die Fragen anderer zunächst wirklich verstehen und die Antwort dann nicht nur kennen oder herausfinden, sondern sie auch strukturiert und nachvollziehbar erklären können. Genau das lernt man dabei sehr gut.

Auf diese Weise war ich über viele Jahre hinweg in den Top 0,5 Prozent der Nutzerinnen und Nutzer dort gerankt. Nicht, weil ich das bewusst angestrebt hätte, sondern weil sich das durch die intensive Nutzung im Laufe der Zeit so ergeben hat. Mein letzter Beitrag dort stammt allerdings von März 2023. Trotzdem war ich vergangene Woche immer noch auf Platz 274 in deren Ranking – was eine gewisse Ironie hat.

Nun wird diese „gute alte Zeit“ gerne etwas verklärt. Natürlich gab es damals vieles, das positiv war: Man hat sehr viel selbst erarbeitet (weil man es musste) und dadurch oft erst wirklich verstanden, was man gemacht hat. Man hat seine Grundlagen geschärft, sich mit Algorithmen, Design-Patterns, Architektur und vielem mehr beschäftigt. Dieses Wissen musste man sich aktiv aneignen. Allerdings wird dabei oft vergessen, dass es auch damals schon viele Entwicklerinnen und Entwickler gab, die Code einfach blind von Stack Overflow kopiert und so lange angepasst haben, bis er irgendwie funktionierte – mit Betonung auf „irgendwie“. Ohne zu verstehen, was sie da eigentlich machten oder warum das funktionierte.

Im Kern ist das genau dasselbe Muster, das heute vielen Entwicklerinnen und Entwicklern vorgeworfen wird, die KI verwenden: Damals dauerte es nur länger und war mühsamer. Wer nicht verstehen wollte, konnte auch damals drumherum kommen. Und die Ergebnisse waren entsprechend genauso wackelig, wie sie es heute oft sind, wenn ohne Verständnis gearbeitet wird.

Stufe 2: ChatGPT-Nutzer

Damit kommen wir zur zweiten Stufe, dem Research-User. Das ist bei vielen der erste Kontaktpunkt mit KI, indem sie beispielsweise ChatGPT für Recherchen verwenden. Das bedeutet, man fragt nach einem kleinen Codebeispiel, lässt sich eine Library erklären, erkundigt sich nach einem HTTP-Status-Code, einem JSON-Struct oder Ähnlichem. Also im Wesentlichen all das, wofür man früher Google oder eben Stack Overflow genutzt hat.

Ich erinnere mich noch gut daran, dass ich, als ich ChatGPT das erste Mal geöffnet habe, überhaupt nicht wusste, wie ich damit umgehen sollte – was ich dort überhaupt eingeben sollte. Ich stand wie der sprichwörtliche Ochse vor dem Berg. Von Google war ich gewohnt, ein paar Schlagwörter einzugeben, und die Suchmaschine erledigte den Rest. Hier war jedoch gefordert, einen vollständigen Text einzugeben. KI-Systeme funktionieren an dieser Stelle ein wenig anders. Das merkt man sehr schnell: Es ist enorm wichtig, ausreichend Kontext mitzugeben, Rahmenbedingungen zu formulieren, präzise zu sein, gegebenenfalls iterativ nachzusteuern oder im Zweifel sogar eine neue Session zu starten. Dieses ganze Thema des Prompt-Engineerings, das inzwischen in das umfassendere Context-Engineering übergeht, habe ich mir dann im Laufe der Zeit selbst beigebracht. Einfach, indem ich gelernt habe, was für mich gut funktioniert und was weniger. So wird man nach und nach besser.

Was mir dabei sicher geholfen hat, ist, dass ich schon seit vielen Jahren intensiv mit Sprache arbeite. Nicht nur auf YouTube, sondern auch durch hunderte, wenn nicht inzwischen tausende Fachartikel für Zeitschriften und Plattformen wie die iX, die dotnetpro, heise Developer und viele andere. Dazu kommt die intensive Beschäftigung mit Domain-Driven Design, Event-Sourcing und den Themen, die damit verbunden sind. All das hat mir geholfen, ein gutes Gespür dafür zu entwickeln, wie man mit einer KI am besten kommuniziert, damit sinnvolle Ergebnisse entstehen.

KIs machen das Ganze natürlich zunächst extrem komfortabel: Ich erhalte heute auf eine Frage, für die ich früher zehn Tabs bei Stack Overflow gebraucht hätte, innerhalb von Sekunden eine Antwort. Aber auch hier gilt im Grunde dasselbe wie damals: Wer will, kann sich die Antworten irgendwie zusammenbauen und hat dann zwar oberflächlich eine Lösung, aber kein wirkliches Verständnis erlangt und dabei auch nichts gelernt. Das war früher so und ist heute nicht anders.

Stufe 3: Copilot Coder

Die dritte Stufe beschreibt das, was für die meisten Entwicklerinnen und Entwickler heute vermutlich Alltag ist: die Arbeit mit Unterstützung durch einen in den Editor oder die IDE integrierten KI-basierten Code-Assistenten wie zum Beispiel Copilot in Visual Studio Code. Für mich persönlich war und ist das jedoch immer noch klar getrennt von Tools wie ChatGPT. ChatGPT ist für mich eher wie eine virtuelle Kollegin, mit der ich über Ideen, Architektur, Konzepte, Patterns und Lösungsansätze diskutiere. Copilot empfinde ich hingegen als eine Art sehr intelligente Autovervollständigung. Copilot nimmt mir viel Schreibarbeit ab, indem es repetitiven Code ergänzt, fehlende Tests erzeugt, Boilerplate erstellt und so weiter. Das sind alles Dinge, die ich problemlos auch selbst hätte schreiben können. Ich hätte nur länger gebraucht. Insofern beschleunigt Copilot meine Arbeit, weil ich schneller durch die eher monotonen Teile des Codes komme. Die Verantwortung für den Code bleibt aber bei mir.

Das ist für mich ein wesentlicher Punkt. Für mich gilt immer: Ich übernehme keinen Code, den ich nicht auch selbst hätte schreiben können. Copilot ist für mich klar ein Werkzeug, das mir das Tippen abnimmt, nicht das Denken. Ich weiß, dass viele Entwicklerinnen und Entwickler das anders sehen, sich darüber freuen, dass Copilot das „irgendwie macht“ und die Vorschläge oft unkritisch übernehmen, ohne sie zu hinterfragen. Das halte ich für äußerst gefährlich, weil man dadurch letztlich die Verantwortung abgibt, die man aber trotzdem selbst tragen muss. Genau das war auch der Grund, warum ich Copilot vielen anderen KI-Werkzeugen vorgezogen habe, die zwischenzeitlich stark gehypt wurden, dabei aber suggerierten, man müsse selbst gar nicht mehr verstehen, was passiert. Dass das eine eher schlechte Idee ist, dazu haben wir vor einigen Wochen ein Video veröffentlicht.

Stufe 4: Chat First Coder

Die vierte Stufe beschreibt, was der eingangs erwähnte Artikel als „Chat First Coder“ bezeichnet. Hier verschiebt sich der Schwerpunkt noch stärker in Richtung KI: Man nutzt ChatGPT oder andere Tools nicht mehr nur, um einzelne Fragen zu klären, sondern entwickelt ganze Features oder Module damit. Auch ich habe irgendwann begonnen, Code direkt in ChatGPT zu entwickeln und mit der KI über den Code zu diskutieren, Rückfragen zu stellen, Bewertungen und Einschätzungen einzuholen. Dadurch wurde ChatGPT für mich noch mehr zu einem Sparringspartner. Ich diskutiere mit der KI, erhalte Ideen, lasse mir Alternativen vorschlagen und entscheide dann, was sinnvoll ist.

Allerdings gibt es hier klare Grenzen. ChatGPT kennt immer nur das, was explizit vorgegeben wird: Sie können eine Datei hineinkopieren, vielleicht auch zwei oder drei, aber ChatGPT hat keinen Überblick über das gesamte Projekt, über Ihre Imports, Build-Skripte, die Umgebung, Tests, Branches und so weiter – all das, was am Ende dazugehört. Natürlich könnte man das theoretisch alles manuell mitgeben, aber das ist aufwendig und nicht wirklich praktikabel. Genau hier liegt der große Vorteil von Copilot und ähnlichen Tools, weil sie direkt in der IDE arbeiten und den Kontext kennen.

Eine Möglichkeit ist Copilot Chat, das hat mich bislang allerdings wenig überzeugt. Meist war es ernüchternd und nicht besonders hilfreich. Für mich ist das bisher nicht auf einem Niveau, das wirklich weiterhilft. Was ich mir langfristig wünschen würde – und was vermutlich über kurz oder lang kommen wird –, ist ein Chat-Interface, das gleichzeitig vollen Zugriff auf meine Projekte über alle Repositories hinweg hat und darauf basierend präzise und passgenaue Antworten liefert.

Tatsächlich gehen die aktuellen Entwicklungen genau in diese Richtung. GitHub hat kürzlich vorgestellt, dass man Issues direkt einem KI-gestützten Assistenten zuweisen kann, der übrigens ebenfalls „Copilot“ heißt. Diese Issues werden dann von einer KI komplett autonom bearbeitet, und das Ergebnis wird später als Pull-Request bereitgestellt. Diese Funktion halte ich meiner bisherigen Erfahrung nach für sehr gelungen. Sie ist zwar noch nicht direkt in die IDE integriert, aber das dürfte nur eine Frage der Zeit sein und zeigt bereits gut, wohin die Reise aktuell geht. Wenn das dann einmal direkt in den IDEs verfügbar ist, dürfte das ein echter Meilenstein sein.

Stufe 5: Vibe Coder

Die fünfte Stufe schließlich ist das, was häufig als „Vibe-Coding“ bezeichnet wird. Das bedeutet, dass Sie der KI in einem Prompt nur noch aus inhaltlicher Sicht beschreiben, was Sie haben möchten, und der Code, der dabei entsteht, ist Ihnen völlig egal. Es zählt nur, ob das Ergebnis funktioniert und die Anforderung erfüllt ist oder nicht. Das klingt für viele äußerst reizvoll, weil man damit vermeintlich alles abgeben und nur noch das fertige Ergebnis erhalten kann. Ich persönlich glaube daran allerdings nicht und halte das vor allem für keine besonders gute Idee. KI ist am Ende immer nur ein Werkzeug. Und jedes Werkzeug, das man einsetzt, sollte man – meiner Meinung nach – verstehen: Wie funktioniert es? Warum funktioniert es? Wofür ist es geeignet und wofür nicht?

All diese Fragen sind wichtig, denn es gibt in der Regel nicht nur einen Weg, um zu einem Ergebnis zu gelangen, sondern viele. Diese unterscheiden sich oft in vielerlei Hinsicht. Da kann man nicht einfach pauschal sagen, dass der eine Weg besser oder schlechter sei. Es sind häufig Abwägungen und Kompromisse, die stark vom eigenen Wertesystem und den konkreten Anforderungen abhängen. Das betrifft unter anderem Themen wie Sicherheit, Performance, Wartbarkeit, Testbarkeit und vieles mehr. Gerade weil das alles Querschnittsbelange sind, werden sie bei vollständig automatisch generiertem Code oft übersehen oder geraten gerne in den Hintergrund.

Ich glaube, dass genau das auch erklärt, warum insbesondere Personen, die selbst nicht oder nicht sehr gut programmieren können, davon so begeistert sind. Sie erkennen gar nicht, wo die Schwächen und Mängel liegen – wie auch, wenn sie nie gelernt haben, so etwas professionell zu beurteilen? Ich kann zumindest aus meiner Erfahrung sagen, dass ich bislang niemanden auf Senior-Niveau getroffen habe, die oder der gesagt hätte:

„Das halte ich für eine wirklich gute Idee.“

Natürlich kann es sein, dass die Zeit für dieses Vorgehen einfach noch nicht reif ist. Vielleicht wird das irgendwann kommen. Im Moment bin ich da jedoch eher skeptisch. Mir ist das alles noch viel zu leichtfertig.

Was bedeutet das nun abschließend? Ich finde, es zeigt zunächst: KI ist ein enorm mächtiges Werkzeug, das die Art und Weise, wie wir Software entwickeln, in kürzester Zeit sehr grundlegend verändert hat. Wir können davon ausgehen, dass das auch noch eine ganze Weile so weitergehen wird. KI ist aber eben auch „nur“ ein Werkzeug. Jedes Werkzeug sollte man verstehen – nicht nur das Ergebnis, sondern auch den Weg dorthin. Denn das Ergebnis ist nicht alles. Es macht einen Unterschied, wie man zu diesem Ergebnis gelangt ist. Letztlich gilt immer noch: Sie selbst sind verantwortlich für den Code, den Sie entwickeln. Keine KI der Welt wird Ihnen diese Verantwortung abnehmen. Deshalb ist es heute wichtiger denn je, fundiertes Wissen aufzubauen, sich weiterzubilden und eigene Erfahrungen zu sammeln, um KI-generierte Ergebnisse überhaupt beurteilen zu können. Wer das nicht tut, wird es in Zukunft sehr schwer haben.

(rme)

Digitale Souveränität ist in diesem Jahr in vielen Unternehmen und Behörden zu einem wichtigen Thema geworden. Sie ist die Voraussetzung dafür, die Digitalisierung der eigenen Organisation selbst zu gestalten, und die Grundlage einer resilienten und verlässlichen IT.

Auf dem IT Summit by heise zeigen renommierte Experten aus Politik, Wissenschaft und Wirtschaft, wie Unternehmen und Behörden Abhängigkeiten in den Bereichen Cloud, KI, IT-Security und Software verringern können. Erfahren Sie,

• was europäische Cloud-Hoster leisten und wie sie die Abhängigkeit von US-Hyperscalern verringern;
• wie man KI lokal betreiben kann, sodass die Daten das Unternehmen nicht verlassen;
• warum selbst verwaltete digitale Identitäten ein Schlüssel zu mehr digitaler Souveränität sind;
• wie Open Source die eigene Software-Landschaft unabhängiger macht;
• warum mehr digitale Souveränität die IT-Sicherheit verbessert.

Mehrere Fallstudien demonstrieren, mit welchen Schritten Unternehmen und Behörden ihre digitale Souveränität verbessert haben. Details zu den Vortragenden und den Themen finden Sie im Programm.

Der IT Summit 2025 findet am 11. und 12. November im Nemetschek Haus in München statt. Er richtet sich an IT-Verantwortliche, die selbst entscheiden wollen, wo sie welche Abhängigkeiten in ihrer IT eingehen. Wer jetzt bucht, kann noch ein vergünstigtes Early-Bird-Ticket erhalten.

(odi)

„Star Trek“ hat seit seiner Premiere im Jahr 1966 die Fantasie zahlreicher Menschen beflügelt – und darunter natürlich auch Spieldesigner. Den ersten Ausflug in interaktive Gefilde gönnte sich die Crew der Enterprise bereits zu ihrem fünften Geburtstag, im Jahr 1971: „Star Trek“ von Mike Mayfield, in einfachem BASIC geschrieben, bestand aus phosphorgrün leuchtendem Text und drehte sich darum, über in die klackernde Tastatur der euphemistisch „Minicomputer“ betitelten Rechenschränke wie dem „SDS Sigma 7“ eingetippte Befehle aus ASCII-Zeichen bestehende Klingonenschiffe zu finden und zu zerstören. Im Grunde also eine „Schiffe versenken“-Variante, nur dass hier die Pötte auch zurückschießen.

Von da aus ging es Schlag auf Schlag, Photonentorpedo auf Photonentorpedo, die „Star Trek“-Spiele, offiziell und inoffiziell, schossen wie Tribbles aus aus den Getreidespeichern. Logischerweise war nicht jedes davon ein Spielspaßvolltreffer – und genau deswegen haben wir uns sechs alte und neue Spiele aus Gene Roddenberrys Universum herausgefischt, die uneingeschränkt empfehlenswert sind.

Star Trek: Judgment Rites (1993)

Das Anfang 1992 veröffentlichte und damit die in seinem eigenen Namen enthaltenen Feierlichkeiten nur ganz knapp verpassende „Star Trek: 25th Anniversary“ war ein echt gutes Point-n-Click-Abenteuer. Es bot zwar nicht gerade die logischsten Rätsel diesseits des Delta-Quadranten – aber es war Fanservice pur, lebte und atmete den Geist von „Star Trek“ wie kein anderes Spiel zuvor. Was nicht zuletzt daran lag, dass für die später nachgeschobene CD-Veröffentlichung die komplette Originalcrew vor die Mikrofone geschoben wurde, inklusive William „It sickens me“ Shatner.

Was aber natürlich nicht bedeutet, dass da nicht noch Platz für Verbesserungen gewesen wäre. Wie gesagt: Bei einigen der Puzzles hätte selbst Mr. Spock die kritische Augenbraue gehoben, die aufgezwungenen Raumschlachten im „Wing Commander“-Stil waren ruckelig und gerade zum Ende hin frustrierend schwer. Und das ganze Abenteuer war auch nicht sonderlich lang. Kein Wunder also, dass im November 1993 der offizielle Nachfolger in den Läden stand: „Star Trek: Judgment Rites“ war auf den ersten Blick mehr vom Gleichen: gleiche Grafik, gleiche Bedienung, alles gleich. Unter der Haube allerdings war vieles neu: deutlich aufgebohrte Präsentation, viel mehr Abwechslung im Kader (Kirk bestritt die Missionen jetzt nicht mehr nur mit Spock, Pille und einem Wegwerf-Redshirt), umfangreichere Missionen, die jetzt einen übergreifenden Handlungsrahmen boten – und die vermaledeiten Balleraufträge waren jetzt endlich optional.

„Star Trek: Judgment Rites“ ist natürlich kein Hochglanzprodukt. Aber für Fans der Originalserie bietet es noch bis heute einige der interessantesten Knobel-Abenteuer der Seriengeschichte.

Erhältlich bei: GOG, Steam

Star Trek: The Next Generation – A Final Unity (1995)

Apropos Knobel-Abenteuer: Am 23. Mai 1994 fand die gefeierte „Star Trek“-Nachfolgeserie „Star Trek: Das nächste Jahrhundert“ (engl: „Star Trek: The Next Generation“) mit der preisgekrönten Folge „Gestern, heute, morgen“ (engl: „All Good Things…“) seinen furiosen Abschluss. Es sollte dann noch gut ein Jahr dauern, bis die Fans weitere Abenteuer mit Picard, Riker und und Data, Worf oder Geordi La Forge erleben durften. Und zwar in einem Point-n-Click-Adventure von einer Firma, die man bis dahin eher nicht mit dieser Art von Spiel in Verbindung brachte: den Flugsimulationsexperten von Spectrum Holobyte.

Spielt aber nicht die geringste Rolle, denn die Fans hatten bei „Star Trek: The Next Generation – A Final Unity“ nicht den geringsten Grund zur Beschwerde. Die Crew der neuen Enterprise legt sich mal wieder mit den Romulanern an, ein mysteriöses Artefakt deutet in Richtung einer lange verschollenen Zivilisation. Es gibt sehr viele Gespräche mit freundlichen und unfreundlichen Personen und Aliens zu führen, ein großer Teil der Enterprise-D darf erkundet werden. Und dann warten natürlich noch jede Menge Außenmissionen mit Tricorder-Scannereien, vielen Gegenständen und zum Teil sehr cleveren Puzzles.

„A Final Unity“ ist für Fans von TNG das, was „Judgment Rites“ für TOS-Trekker ist: Ein rundum gelungenes Abenteuer mit der jeweils besten Enterprise-Crew, das die Serienatmosphäre beeindruckender Präzision auf den Kopf trifft. Außerdem kamen auch hier alle Darsteller persönlich zu Wort – was für die meisten deutschen Spieler wohl den Erstkontakt mit den Originalstimmen der Schauspieler bedeutet haben dürfte.

Erhältlich: aktuell leider nirgends offiziell

Star Trek: Voyager – Elite Force (2000)

„Star Trek: Voyager“, die 1995 angelaufene fünfte Serie im offiziellen „Star Trek“-Kanon, spaltet die Fangemeinde noch bis heute: Auf der einen Seite gibt es fantastische Charaktere wie Captain Janeway, Commander Tuvok, den Holo-Doc sowie (ab der vierten Staffel) Seven of Nine. Auf der anderen Seite warten hier einige der schlimmsten TV-Verbrechen aller Zeiten (hust, „Threshold“, husthust) sowie eine Serie, die es niemals geschafft hat, eine wirklich eigene Identität aufzubauen.

Das ist aber für Spieler vollkommen wurscht, denn Voyager stellte den Rahmen für den noch bis heute besten Ego-Shooter im „Star Trek“-Universum. Der auf der englischen Verpackung mit dem wunderbar martialischen Motto „Set Phasers To Frag.“ gleich mit Anlauf klar machte, dass hier nicht geredet und verhandelt, sondern geballert wird. Das von den Shooter-Experten Raven Software entwickelte und im Herbst 2000 über Activision veröffentlichte Spiel nutzte die damals noch ofenfrische „Quake 3“-Engine von id Software, und lieferte damit eines der grafisch aufregendsten Abenteuer seiner Zeit. Darin konnte man sich als Mitglied des Elitetrupps „Hazard Team“ nicht nur packende Gefechte mit Borg, Klingonen oder Hirogen liefern, sondern auch eine spannende Handlung verfolgen und zwischen den Einsätzen sogar einen bemerkenswert großen Teil der Voyager erkunden.

Drei Jahre später folgte dann noch der bereits von Ritual Entertainment entwickelte zweite Teil mit dem simplen Titel „Star Trek: Elite Force II“, der ebenfalls sehr zu empfehlen ist.

Erhältlich bei: GOG