Connect with us

Entwicklung & Code

KI Navigator #11: Fünf Stufen der KI-Nutzung in der Softwareentwicklung


Willkommen zur elften Ausgabe der KI-Navigator-Kolumne der DOAG KI Community!




ist Informatiker, Softwarearchitekt, Projektleiter und KI-Enthusiast. Seit über zehn Jahren entwickelt er Software in unterschiedlichsten Domänen. Er programmiert seit dem Aufkommen von GitHub Copilot und Cursor bevorzugt mit KI-Unterstützung und setzt sich aktiv für das Konzept des Vise Coding ein. Seine Erfahrungen teilt er regelmäßig auf Konferenzen und gibt Schulungen zum Thema „KI und Softwarearchitektur“.




ist Softwareentwickler bei WPS – Workplace Solutions und realisiert seit über zehn Jahren Anwendungen in unterschiedlichen Sprachen und Frameworks. Sein Schwerpunkt liegt auf Testautomation, Requirements Engineering und dem produktiven Einsatz von KI-gestützten Entwicklungswerkzeugen wie GitHub Copilot und JetBrains AI Assistant. Praxiserfahrungen dazu vermittelt er in Trainings, Meetups und auf verschiedenen Konferenzen.

Im Umfeld der Softwareentwicklung lassen sich unterschiedliche Typen der KI-Nutzung ausmachen, die wir bei uns in der WPS GmbH in fünf Typen unterteilen:

  1. Nichtnutzer von KI
  2. ChatGPT-Nutzer
  3. Copilot Coder
  4. Chat First Coder
  5. Vibe Coder

Richtig angewendet führt KI meist zu höherer Effizienz und besserer Codequalität. Dennoch haben viele Entwicklerinnen und Entwickler ihr persönliches Optimum beim KI-Einsatz noch nicht erreicht. Wie stark KI den Entwicklungsprozess unterstützt, hängt von mehreren Faktoren ab: dem Erfahrungsgrad, den verfügbaren KI-Tools und den eingesetzten Technologien.

Im Folgenden stellen wir die fünf Typen näher vor – wie sie arbeiten, warum sie so arbeiten und welche Einschätzung wir jeweils dazu haben.

Diejenigen, die KI gar nicht nutzen, arbeiten wie in den vergangenen 15 oder 20 Jahren: Sie schreiben den gesamten Programmcode selbst. Sie verschaffen sich ohne KI-Unterstützung einen Überblick über vorhandenen Code, recherchieren über Google, Dokumentation sowie Foren und Diskussionen wie etwa auf Stack Overflow oder GitHub.

Dass sie so arbeiten, kann unterschiedliche Gründe haben. Der naheliegendste und vermutlich häufigste ist, dass ihre Firma den Einsatz von KI (noch) nicht erlaubt – etwa aus Sicherheitsbedenken. Andere haben KI eventuell aus grundsätzlichen Vorbehalten noch nicht ausprobiert. Manche haben KI getestet und waren von den Ergebnissen enttäuscht.

Eine Enttäuschung kann an mangelnder Erfahrung im Prompting oder fehlendem Bewusstsein für den nötigen Kontext liegen – beides lässt sich schnell aufholen. Möglicherweise war auch der Effekt der sogenannten Jagged Technological Frontier (die scharfe technologische Grenze) dafür verantwortlich. Das Prinzip beschreibt, dass KI scheinbar ähnliche Aufgaben teils erstaunlich gut, teils überraschend schlecht löst.

Es ist auch eine Frage des Typs, ob man von KI profitiert. Wer schon lange mit einer bestimmten Technologie arbeitet, schnell recherchiert und effizient adaptieren kann, spürt womöglich (noch) keinen echten Effizienzgewinn durch KI. Allerdings hat eine Studie gezeigt, dass gerade Leistungsträger eher Bedenken vor KI haben, obwohl sie laut Untersuchungen paradoxerweise mehr profitieren.

Nicht zuletzt stellt sich die Frage: Wie aktuell sind die negativen Erfahrungen mit KI-Unterstützung? Unsere Beobachtung zeigt: Was vor drei bis sechs Monaten noch nicht zufriedenstellend funktionierte, kann heute bereits robust einsatzfähig sein.

Nach unserer Definition nutzen ChatGPT-Anwender KI nur gelegentlich – etwa ein paar Mal pro Tag. Dieses Nutzungsverhalten beobachtet man häufig, wenn ChatGPT das einzige verwendete KI-Tool ist. Die Intensität der Nutzung hängt stark vom verfügbaren Tooling ab: Ist KI wie bei GitHub Copilot direkt ins Entwicklungstool integriert, kommt sie meist deutlich häufiger zum Einsatz.

ChatGPT-Nutzer setzen KI vor allem für Recherche ein und ersetzen damit teilweise das Googeln, das Lesen von Dokumentationen und das Durchforsten von Foren. Auch zum Generieren von Code-Snippets oder Beispielen, zum Erklären von Code oder Analysieren von Fehlermeldungen ziehen sie ChatGPT gelegentlich heran.

Was ist die Motivation, (nur) das pure ChatGPT oder vergleichbare Chatbots wie Claude oder Gemini zu verwenden? Zum einen ist der Einsatz ähnlich niederschwellig wie die Google-Suche. Zum anderen behalten Entwicklerinnen und Entwickler die volle Kontrolle darüber, welchen eigenen Code sie der KI zur Verfügung stellen.

ChatGPT ist oft das bevorzugte Werkzeug, wenn eine Firma keine klare oder offizielle Regeln für den Umgang mit KI-Tools definiert hat und sich der Einsatz in einem Graubereich bewegt. Um diesem unerwünschten Zustand entgegenzuwirken, haben wir in unserer Firma eine KI-Richtlinie entwickelt, die den Developern eine klare Orientierung bietet.

Copilot-Coder haben ihren KI-Programmierassistenten ständig im Einsatz. Er ist direkt in die Entwicklungsumgebung integriert und lässt sich dadurch einfach und ohne Hürden verwenden. Der wohl größte Vorteil gegenüber der Nutzung von ChatGPT liegt in der Autovervollständigung: Während des Codens macht die KI automatisch Vorschläge für den weiteren Code – oft mit erstaunlich guten Ergebnissen.

Mittlerweile existiert eine Vielzahl solcher KI-Tools. Der bekannteste Vertreter ist GitHub Copilot, aber auch JetBrains AI Assistant oder die KI-Entwicklungsumgebung Cursor bieten beeindruckende Funktionen. Beispiele sind das Beheben von Programmierfehlern per Klick, das automatische Generieren der Dokumentation und die nahtlose Integration eines KI-Chatbots mit einer Auswahl der besten und aktuellsten Modellen.

Copilot-Coder bleiben meist stark codezentriert. Sie beschränken den Einsatz der KI bewusst auf einen kleinen, selbst definierten Kontext innerhalb ihrer Projekte, etwa beim Generieren einer Filterfunktion für eine Liste. Das Einfügen eines Buttons, der den Filter auslöst, oder das Abspeichern des Ergebnisses würden anschließend in separaten, KI-unterstützten Schritten erfolgen.

Diese Arbeitsweise etabliert sich nach unserer Erfahrung ganz natürlich bei engagierten Entwicklern und Entwicklerinnen, die mit einem Copilot-ähnlichen Tool arbeiten. Ausschlaggebend dafür ist in vielen Fällen, dass das Unternehmen eine Business-Lizenz bereitstellt. Nach unseren Beobachtungen markierte diese Vorgehensweise bis etwa Ende letzten Jahres das maximal Machbare mit den damals verfügbaren Tools.

Dieser Ansatz ist erst seit dem Jahreswechsel 2024/2025 praktikabel. Entscheidend dafür war die Einführung von KI-Agenten in gängige Programmierassistenten – zunächst in Cursor und seit April 2025 auch standardmäßig in GitHub Copilot und Junie von Netbrains. Abgesehen von einigen Kinderkrankheiten und längeren Rechenzeiten können wir KI-Agenten für die meisten Anwendungsfälle empfehlen – auch für diejenigen, die noch eher im Stil der Copilot-Coder arbeiten.

Chat-First-Coder behandeln den Quellcode und den Chat mit dem KI-Assistenten als gleichwertige Elemente. Sie beschreiben ein Feature vollständig oder teilweise im Chat – der Assistent entwickelt daraufhin eigenständig einen Plan, passt den Programmcode an, testet Änderungen und nimmt bei Bedarf Korrekturen vor. Für die obige Beispielanforderung zum Filtern einer Liste würde die KI den nötigen Button und das Abspeichern in einem Schritt hinzufügen. Unsere Herangehensweise dabei ist, dass wir vor dem Chat mit der KI eine klare Erwartungshaltung entwickeln, an der wir das anschließend generierte Ergebnis überprüfen.

Besonders für Chat-First-Coder ist es unerlässlich, den generierten Quellcode nie ungesehen oder unverstanden zu übernehmen. Des Weiteren sind eine klare Vorstellung von der Struktur des Programmcodes, im Großen wie im Kleinen, und sorgfältiges Testen essenziell. Hier liegt die Verantwortung bei den Developern, und unsere Erfahrung zeigt: Genau an dieser Stelle entstehen derzeit bereits erste Qualitätsprobleme, weil die Sorgfalt manchmal fehlt.

Die kontrollierte, eng geführte Form der Code-Generierung durch KI-Agenten wird teilweise als Vise-Coding bezeichnet. Im Gegensatz dazu steht die letzte Stufe der KI-Nutzung: das Vibe-Programming.

Vereinfacht gesagt bedeutet Vibe-Coding, Software zu entwickeln, ohne den entstandenen Programmcode überhaupt anzusehen: Man formuliert lediglich einen Prompt, beobachtet das Ergebnis und schreibt dann den nächsten – die Arbeit erfolgt nach dem Motto: „Hauptsache, es funktioniert.“ Andrej Karpathy hat den Begriff Anfang 2025 geprägt.

Das ist die Richtung, in die Tools wie Devin schon seit einiger Zeit drängen – bislang mit eher mäßigem Erfolg oder stark eingeschränktem Anwendungsbereich. Seit der Einführung des Agentenmodus ist dieser Ansatz nun grundsätzlich auch mit Tools wie GitHub Copilot, Cursor, Codex und Google Firebase Studio umsetzbar.

Nach aktuellem Stand lassen sich mit dieser Methode zwar definitiv keine größeren, robusten Softwareprojekte realisieren – für kleine Prototypen kann sie jedoch bereits hilfreich sein. Insbesondere bei kurzen Skripten, etwa in einem Auswertungscode in Python lassen sich bereits gute Ergebnisse erzielen.

Es ist absehbar, dass KI-Assistenz künftig immer leistungsfähiger wird – und sich darauf aufbauende Arbeitsabläufe unter Entwicklern zunehmend etablieren. Eine aus unserer Sicht hilfreiche Prognose liefert Lars Röwekamp in seinem Kolumnenbeitrag „Läutet KI das Ende der Spezies Softwareentwickler ein?“ Wer sich aus einer alternativen Perspektive mit den Stufen der KI-Adaption befassen möchte, dem sei ein unterhaltsamer Artikel auf Zef+ empfohlen.

Um den Einsatz von KI-Programmierassistenten konkret voranzutreiben, möchten wir abschließend zwei Empfehlungen geben:

Entwicklerinnen und Entwickler sollten gezielt überlegen, in welchen Bereichen KI ihnen beim Coden helfen kann – es gibt fast immer geeignete Use Cases. Und sie sollten diese Evaluation regelmäßig wiederholen, da sich die Möglichkeiten in sehr kurzen Zyklen verändern. Gerade derzeit kann sich eine Neubewertung alle drei bis sechs Monate lohnen.

Unternehmen sollten den Einsatz von KI-Programmierassistenten ermöglichen. Wo es sinnvoll ist, sollten sie ihren Developern Wahlfreiheit bei den Tools lassen, ihnen aber klare Richtlinien an die Hand geben, wie die Tools zu nutzen sind.

Wer sich über KI-Programmierassistenten und den Einsatz von KI allgemein weitergehend informieren möchte, findet dazu auf der Konferenz KI Navigator am 19. und 20. November in Nürnberg Gelegenheit.


(rme)



Source link

Entwicklung & Code

Peer Review für Google Jules: KI-Assistent schaut KI-Assistenten auf die Finger


Google hat für seinen KI-Assistenten für die Softwareentwicklung Jules einen neuen Modus eingeführt: Die sogenannte Critic-Augmented Generation übergibt alle Änderungsvorschläge zunächst an einen in Jules integrierten Kritiker, der sie gründlich überprüft. Der Kritiker führt also ein Peer Review durch und konzentriert sich dabei auf gute Codequalität.

Google hatte Jules im Rahmen der diesjährigen Google I/O im Mai vorgestellt. Der KI-Agent macht keine Codevorschläge innerhalb des Editors wie Cursor, sondern untersucht Projekte, um Bugs aufzuspüren, Tests zu erstellen oder neue Features zu integrieren.

Ein allgemeines Problem der KI-gestützten Softwareentwicklung ist, dass die Modelle typischerweise Code erstellen, der auf den ersten Blick scheinbar problemlos funktioniert. Dabei berücksichtigen sie jedoch häufig nur den typischen Programmverlauf, sodass die Anwendungen in Grenzfällen scheitern können.

Auch gehen die KI-Agenten meist von passenden, regulären Eingaben aus, sodass unerwarteter Input zu Fehlern oder im schlimmsten Fall Schwachstellen führen kann. Außerdem erstellt der KI-Assistent nicht immer den effizientesten Code für eine bestimmte Aufgabe.

Die Critic-Augmented Generation soll ebendiese Fehler oder Schwächen aufspüren. Der integrierte Kritiker korrigiert sie nicht selbst, sondern markiert sie und gibt sie Jules zum Überarbeiten zurück.

Als Beispiel nennt der Blogbeitrag mit dem Titel „Triff Jules schärfsten Kritiker und wertvollsten Verbündeten“ unter anderem Code, der zwar alle Tests besteht, aber einen subtilen Logikfehler einführt. Jules erhält den Code mit dem Kommentar „Output matches expected cases but fails on unseen inputs.“ zurück.

In der jetzigen Variante erhält der Kritiker den kompletten Output von Jules, überprüft ihn und gibt seine Kommentare zurück. Jules verbessert daraufhin seinen Code und übergibt ihn erneut zum Peer Review. Der Prozess wiederholt sich so lange, bis der Kritiker zufrieden ist. Erst dann gibt Jules die Änderungen an die User zurück.

Google will den Prozess künftig erweitern, damit Jules den Kritiker auch für Teilaufgaben befragen kann und dieser Zugang zu externen Tools wie Suchmaschinen oder zu Codeinterpretern zum Ausführen und Prüfen des Codes erhält.


(rme)



Source link

Weiterlesen

Entwicklung & Code

Erfolgreiche Jailbreak-Angriffe auf GenAI arbeiten mit schädlichen Prompts


Das Model Context Protocol (MCP) ist noch recht jung, vom November 2024, und seit einiger Zeit tauchen immer häufiger Sicherheitslücken in Verbindung damit auf – und zwar sowohl server- als auch clientseitig. Umgekehrt gibt es Tausende von MCP-Quellen im Netz, die sich mit wenigen Klicks in die eigene KI-Anwendung einbinden lassen.

Eine lange, kuratierte Liste findet sich auf GitHub. Umgekehrt hat Docker eine Liste mit Angriffspunkten und Sicherheitsproblemen gesammelt. Konkrete Beispiele sind ein Angriff über Repositories auf den MCP-Server GitHub oder eine Attacke auf die Cursor IDE via MCP. Mirko Ross, Gründer und CEO der Sicherheitsfirma asvin spricht mit heise developer über die Sicherheit des als „USB-C der KI“ bezeichneten Protokolls.

Mirko, Du beschäftigst Dich schon länger mit der Sicherheit von KI und MCP, wo liegen denn die Hauptschwachstellen Deiner Meinung nach?

MCP ist in Hinblick auf eine einfache Verknüpfung von Applikationen mit GenAI-Modellen hin entworfen worden, das Ganze in einem sich schnell entwickelnden AI-Tech-Umfeld. Die Schwachstelle liegt in der Genese des Protokolls: Das Design von MCP ist auf eine einfache und schnelle Integration ausgelegt, was zulasten der Protokoll- und Systemsicherheit geht. Zudem haben wir generell noch viel zu wenig die Cybersicherheit-Schwachstellen von GenAI-Systemen umfassend begriffen. Wir sehen in einem täglichen Rhythmus, wie Angreifer sich neue Muster und Jailbreak-Attacken ausdenken und anwenden, mit denen die angegriffenen Systeme aus den Sicherheitsschranken ausbrechen. MCP hat im Protokoll keine wirksamen Sicherheitselemente zur Abwehr solcher Angriffe.

Gibt es Risiken, die ihre Ursachen nicht im Protokoll haben, aber bei der Nutzung von MCP dennoch eine Rolle spielen?

Ja, insbesondere Angriffe in der Softwarelieferkette sind eine Gefahr. Angreifer publizieren Bibliotheken für MCP-Clients und Server, die Schadcode enthalten, in öffentlichen Code-Repositorys. Gerade unerfahrene Entwicklerinnen und Entwickler, die nach einem Einstieg in MCP und KI-Agentensystem suchen, sind hier potenzielle Opfer der Angreifer. Ist eine solche Bibliothek einmal integriert, kann der darin enthaltene Schadcode in Firmennetzwerken ausgeführt werden – beispielsweise als Einfallstor für Ransomware-Angriffe.

Mit Void Programming, also wenn GenAI Programmcode für KI-Agenten oder MCP-Services erzeugt, ergeben sich zusätzliche Sicherheitsprobleme: Bereits jetzt kopieren Angreifer populäre Softwarebibliotheken, kompromittieren sie mit Schadcode und publizieren sie unter ähnlich lautenden Namen. Ziel ist es, dass GenAI bei der Codeerzeugung nicht die Originalbibliothek referenziert, sondern die ähnlich benannte schädliche Kopie. Daher gelten auch bei Void Programming die Grundregeln: erstens jede extern eingebundene Quelle auf Vertrauenswürdigkeit prüfen und zweitens den erzeugten Code auf Schadcode scannen, bevor dieser in eine Produktivumgebung gelangt.


Schloss mit Code

Schloss mit Code

(Bild: Titima Ongkantong/Shutterstock)

Am 30. September und 1. Oktober findet die heise devSec 2025 in Regensburg statt. Auf der von iX, heise Security und dpunkt.verlag ausgerichteten Konferenz stehen in Themen wie Threat Modeling, Software Supply Chain, OAuth, ASPM, Kubernetes und der Einfluss von GenAI auf Security im Programm.

Eine erste Korrektur des Protokolls, die Authentifizierung betreffend, gab es Ende April. Hätte man das Protokoll gleich von Anfang an mehr auf Sicherheit optimieren sollen?

MCP wurde in einem aufgeheizten Markt unter hohem Zeitdruck konzipiert. Dabei spielt der Gedanke des MVP – Minimal Viable Product – eine Rolle. Also die schnelle Einführung von Grundfunktionen, die von Anwendern angenommen werden. Aus Sicht der Cybersecurity bedeutet MVP allerdings „Most vulnerability possibilities“.

Es gibt von der OWASP seit kurzem Empfehlungen für den MCP-Einsatz. Bieten sie umfassende Sicherheit für Server- und Client-Anbieter?

Wer sich an die OWASP-Empfehlungen hält, ist sich zumindest der Risiken einer MCP-Integration bewusst und kann damit die entsprechenden technischen Schutzmaßnahmen aufbauen. Einen umfassenden Schutz gibt es allerdings nicht – denn GenAI-Systeme sind leider grundlegend angreifbar und versierte Täter sind sehr kreativ im Design der Angriffe.

Wie kann sich ein Serveranbieter vor Angriffen am besten schützen?

Erstens gilt es, die Grundregeln der Softwareentwicklung zu beachten: Entwicklerinnen und Entwickler müssen alle verwendeten Bibliotheken per SBOM dokumentieren und auf Schadcode scannen. Zweitens müssen sie MCP-basierte Dienste über Authentifizierung einbinden. Dabei müssen die Identitäten der Authentifizierungen gemanagt werden. Und drittens gilt es, die MCP-Dienste in der Applikationsarchitektur von anderen IT-Diensten zu segmentieren und beispielsweise über Zero-Trust-Prinzipien abzusichern.

Inzwischen gibt es große Sammlungen an einsatzbereiten Servern, die jedermann mit ein paar Klicks einbinden kann. Welche Risiken bestehen denn für die Clients beim Anzapfen von MCP-Quellen?

Sehr erfolgreiche Jailbreak-Angriffe auf GenAI arbeiten mit schädlichen Prompts, die die Angreifer beispielsweise in Dateien verstecken. Soll beispielsweise eine GenAI eine Zusammenfassung einer Word- oder PowerPoint-Datei erstellen, wird der darin versteckte Prompt vom KI-Agenten ausgeführt. Wir müssen lernen, dass wir solche Dateien auf schädliche Prompts überprüfen, bevor wir sie der GenAI zur Bearbeitung übergeben.

Worauf sollte man achten, wenn man MCP-Quellen einbinden will?

Generell gilt: nur Quellen einbinden, die als vertrauensvoll gelten und über eine gute Reputation verfügen. Unbekannte Quellen sollte man nicht einbinden.

Mirko, vielen Dank für das Gespräch!


(who)



Source link

Weiterlesen

Entwicklung & Code

Software Testing: Developer Friendliness für bessere Software


Richard Seidl und Lars Luthmann gehen in dieser Folge des Podcasts Software Testing der Frage nach, welche Bedeutung „Developer Friendliness“ in der Softwareentwicklung hat. Sie plaudern darüber, wie ein angenehmes Arbeitsklima und geeignete Werkzeuge, wie Testschnittstellen und Testdatengeneratoren, den Alltag von Entwicklerinnen und Entwicklern erleichtern können.

Lars Luthmann teilt Einblicke aus einem Automobilprojekt, in dem innovative Ansätze wie REST-Schnittstellen und Mock-Services den Testprozess optimierten.

„Wenn man diese Maßnahmen dann umsetzt und die am Ende tatsächlich auch den Nutzen haben, den man denkt, dann spart man langfristig Zeit. Und das ist eben der eine ganz wichtige Punkt meiner Meinung nach.“ – Lars Luthmann

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Developer Friendliness für bessere Software – Lars Luthmann“ und steht auf YouTube bereit.


(mdo)



Source link

Weiterlesen

Beliebt