Beim Studio hinter „Oblivion Remastered“ verlieren offenbar Entwickler ihren Job: Das berichtet der französische Journalist Gauthier Andres auf Bluesky. Virtuos-Angestellte in Frankreich haben mit Bethesda an dem Remaster von „The Elder Scrolls 4“ Oblivion gearbeitet, das im April überraschend veröffentlicht wurde.

Verglichen mit den großen Entlassungswellen, die kürzlich etwa bei Xbox-Studios wüteten, lesen sich die Zahlen bei Virtuos eher moderat: Andres berichtet von insgesamt 300 Entlassungen, was rund 7 Prozent der Belegschaft entsprechen soll. Der Löwenanteil der gestrichenen Stellen soll die Virtuos-Studios in China betreffen, aber auch europäische Studios, darunter drei Niederlassungen in Frankreich, sollen betroffen sein.

„Oblivion Remastered“ und „Cyberpunk 2077“

Virtuos ist als Studio vor allem für Dienstleistungen bekannt – das Team greift anderen Studios unter die Arme. Die Entwicklung von „Oblivion Remastered“ mit Bethesda gehört zu den bekanntesten Projekten des Teams, das auch für CD Projekt Red einige „Cyberpunk 2077“-Patches entwickelt hat. Auch an Patch 2.3 für „Cyberpunk 2077“, der am Freitag erscheinen soll, war Virtuos beteiligt.

Zudem unterstützt Virtuos Konami bei der Entwicklung des kommenden Action-Spiels „Metal Gear Solid Snake Eater“. Auf der Webseite von Virtuos finden sich zahlreiche weitere Projekte, an denen das Team mitgearbeitet hat – von „League of Legends“ bis „Dave the Diver“. Laut Gauthier Andres sollen die Stellenstreichungen die Wettbewerbsfähigkeit von Virtuos stärken.

In der Spielebranche wurden weltweit in den vergangenen Jahren zehntausende Stellen gestrichen. Zuletzt traf es erneut Microsofts Xbox-Studios hart: Das Studio The Initiative in Santa Monica wurde komplett geschlossen, das Rennspiel-Studio Turn10 entkernt. Auch bei Rare, Undead Labs und King hat Microsoft Stellen gestrichen.

(dahe)

Das chinesische Unternehmen Potensic bietet eine Reihe von Mini-Quadrokoptern an, die den Drohnen von DJI im Aussehen und zumindest auf dem Papier auch im Leistungsumfang stark ähneln, im Vergleich aber oftmals günstiger sind. Wir haben uns das aktuelle Topmodell Atom 2 angeschaut, das mit Controller und einem Akku für rund 265 Euro zu bekommen ist. Die meisten dürften jedoch gleich zu der von uns getesteten Fly More Combo greifen, die für rund hundert Euro mehr noch zwei zusätzliche Akkus samt Ladegerät und eine Tasche enthält.

Für Potensics Atom 2 gibt es kein hundertprozentiges Gegenstück im DJI-Sortiment. Am ehesten liegt sie zwischen der DJI 4K (alias DJI Mini 2 SE) und DJI Mini 3 (Test). Die Straßenpreise der DJI 4K bewegten sich im Testzeitraum etwa auf dem Niveau der Potensic-Drohne, die DJI Mini 3 kostete einzeln im Schnitt 65 Euro mehr als die Atom 2 im Standard-Paket.

Die Atom 2 wiegt wie ihre DJI-Konkurrenz weniger als 249 Gramm, weshalb man sie ohne Führerschein fliegen darf, nur eine Versicherung benötigt und sich – wegen der eingebauten Kamera – beim Luftfahrtbundesamt registrieren muss (siehe Ratgeber zu Mini-Drohnen). Als C0-Drohnen gilt für sie eine maximale Flughöhe von 120 Metern.

Das war die Leseprobe unseres heise-Plus-Artikels „DJI-Alternative: Kameradrohne Potensic Atom 2 im Test“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.

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)