Wie man mit Intent Integrity Chain AI überlebt

Die „php2shell“-Patches (CVE-2026-109618 und CVE-2026-109619) für PHP am Ende des Lebenszyklus (EOL) sind nun verfügbar. Da die Antworten des Vertriebs aufgrund der hohen Nachfrage derzeit langsamer als gewöhnlich ausfallen, ist der schnellste Weg zu den gepatchten Paketen der Online-Kauf von ELS für Runtimes (wird in einem neuen Tab geöffnet). Lesen Sie die FAQ zu den Patches

Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags

  • Fasse diesen Beitrag mit Perplexity zusammen
  • Fasse diesen Beitrag mit Gemini zusammen

Dass bald jeder wegen KI gefeuert wird, mag für manche wie ein Witz klingen, aber es ist eine beunruhigende Realität, mit der viele Entwickler zu kämpfen haben. Auf dem Weg in die Zukunft schreibt die KI keinen Code mehr, sondern ersetzt die Programmierer.

Satya Nadella von Microsoft erklärte kürzlich, dass fast 30 % des Codes von Microsoft inzwischen von KI-Tools wie Copilot geschrieben wird. Nur wenige Tage nach der Bekanntgabe dieser Zahl kam der Schlag: Microsoft entlässt 2.000 Mitarbeiter. Könnte das ein Zufall sein, oder gibt es einen Zusammenhang zwischen 30 % KI-Anteil am Code und der Entlassung von Mitarbeitern?

Solche Zufälle sind nicht nur mit Microsoft allein verbunden. Ein ähnliches Phänomen lässt sich bei CloudStrike, IBM und anderen beobachten. Sogar Goldman Sachs prognostiziert dass bis zu 300 Millionen Arbeitsplätze durch KI ersetzt werden, und das in einer Branche, in der noch vor wenigen Jahren fast zwei Millionen Ingenieure fehlten.

Es ist nicht das erste Mal, dass die Tech-Welt in Panik über das Aussterben von Arbeitsplätzen gerät. 

Ob Java-Bytecodes oder die Migration in die Cloud - Entwickler hatten schon immer mit Skepsis, Angst und Widerstand zu kämpfen, wenn neue Technologien aufkamen. Aber dieses Mal ist es anders. Und warum?

Denn dieses Mal haben wir es mit Werkzeugen zu tun, die nicht nur automatisieren, sondern auch Ergebnisse liefern, die nicht vorhersehbar sind. Diese Werkzeuge halluzinieren. Sie mögen schnell sein, aber sie sind nicht zuverlässig. Trotzdem vertraut man ihnen bei der Erstellung von Code auf Produktionsebene. 

In diesem Artikel gehen wir auf dieses Spannungsverhältnis ein und erläutern, warum die so genannte Intent Integrity Chain unsere beste Option sein könnte, um KI zu überleben, ohne die Kontrolle zu verlieren. Legen wir los! 

Panik und Fortschritt - Der Zyklus geht weiter

 

Die Panik um KI in der Softwareentwicklung mag neu erscheinen, ist es aber nicht. Tatsächlich folgen auf jede Abstraktion in der Technik, sei es Java, die Verwendung von SaaS-Tools oder der Wechsel in die Cloud, immer auch Zweifel.

Es gab eine Zeit, in der Ingenieure den Java-Bytecode in Frage stellten und fragten, ob man ihm trauen könne. Es gab diejenigen, die Cloud Computing für zu riskant für sensible Daten hielten. Der Widerstand war immer da, aber trotzdem hat jede Veränderung, die sich bisher durchgesetzt hat, den Entwicklern geholfen, besser als zuvor zu arbeiten. 

Im Laufe der Zeit bildeten Abstraktionen das Rückgrat der Skalierbarkeit und führten zur Entwicklung schnellerer, komplexerer und widerstandsfähigerer Systeme. Der Unterschied zum jetzigen Zeitpunkt liegt jedoch in der Natur der KI. Bei den traditionellen Abstraktionen ging es eher darum, die Komplexität zu vereinfachen und gleichzeitig ein konsistentes, wiederholbares Verhalten aufrechtzuerhalten. Fortschritte wie große Sprachmodelle (Large Language Models, LLMs) lassen jedoch Raum für Zufälligkeiten. 

LLMs sind wahrscheinlichkeitsbasiert, was bedeutet, dass die Ergebnisse dieser Modelle selbst bei identischen Eingaben unterschiedlich ausfallen können. Diese Unvorhersehbarkeit ist ein Bruch mit der bisherigen Abstraktion.

Die Werkzeuge der Vergangenheit lösten zwar Ängste und Widerstand aus, aber sie boten einen Rahmen, der bestimmt werden konnte. Mit LLMs arbeiten die Entwickler nun mit Systemen, die sich jedes Mal anders verhalten, was bedeutet, dass sich die Entwickler neuen Herausforderungen in Bezug auf die Genauigkeit und Zuverlässigkeit der von diesen Modellen erzeugten Software stellen müssen. 

Sind LLMs nur ein Affe mit einer GPU?

 

Trotz ihrer Beliebtheit bleiben LLMs unzuverlässig, wenn es um die Softwareentwicklung geht. Ihre Fähigkeiten zur Codegenerierung sehen eher nach Versuch und Irrtum aus als nach der Arbeit eines Ingenieurs.

Statt eines präzisen, intelligenten Werkzeugs kann man sich einen LLM als einen Affen mit einer GPU vorstellen, der einfach Dinge ausprobiert, bis sie funktionieren.

Wie sieht diese Realität in der realen Entwicklung aus? Es gibt zahlreiche Beispiele dafür, dass diese Modelle einfach Funktionen erfinden, Paketnamen fälschen und sogar eine Logik produzieren, die gefährlich fehlerhaft ist. 

So haben LLMs beispielsweise auf npm-Bibliotheken verwiesen, die nicht existieren, und böswillige Akteure haben diese halluzinierten Namen verwendet, um Pakete zu registrieren, wodurch ein neuer Vektor für Angriffe auf die Lieferkette geschaffen wurde.

Viele mögen dieses Risiko nur in der Theorie sehen, aber das ist nicht der Fall. Studien, die die Ergebnisse der Codequalität von führenden Tools wie GitHub Copilot, Amazon CodeWhisperer und ChatGPT korrekten Code erzeugen nur 31 % bis 65 % der Zeit korrekten Code, was bedeutet, dass der Code fast die Hälfte der Zeit fehlerhaft ist.

Noch schlimmer ist jedoch, dass 40 % des KI-Codes anfällig warenanfällig, da er ausnutzbare Schwachstellen enthielt und grundlegende Sicherheitspraktiken nicht befolgte.

Aus heutiger Sicht ist es klar, dass es nicht nur um Ungenauigkeiten geht. Es geht auch um unangebrachtes Vertrauen. Diese Tools präsentieren ihren Code mit einem hohen Maß an Sicherheit, selbst wenn die Ergebnisse falsch sind.

Es hat Fälle gegeben, in denen Entwickler die KI gebeten haben, ihren Code auf Geschwindigkeit zu optimieren. Das Ergebnis? Das Modell entfernt Validierungsprüfungen oder bricht die Testabdeckung zugunsten der Leistung vollständig ab.

In Anbetracht dessen können wir sagen, dass LLMs kein Ersatz für Menschen sind, zumindest nicht im Moment. Sie sind Werkzeuge, die jedoch die Absichten und Fähigkeiten derjenigen, die sie verwenden, verstärken können. Allerdings fehlt diesen Modellen ein ausgeprägtes Verständnis für Systeme und Zusammenhänge; man kann ihnen nicht blind vertrauen, und das menschliche Urteilsvermögen ist heute wichtiger als je zuvor.  

Die Kette der Absichtsintegrität 

 

Nach allem, was wir bisher besprochen haben, ist klar, dass das Vertrauen in KI-generierten Code eine Reihe von Risiken mit sich bringt. Die Intent Integrity Chain ist ein Rahmenwerk, das sicherstellen soll, dass solche Risiken nicht vorherrschen und dass die ursprüngliche Idee eines Entwicklers in funktionale und zuverlässige Software umgesetzt wird. 

Das grundlegende Konzept dieses Rahmens ist, dass etwas zwischen der Idee eines Entwicklers und der endgültigen Ausgabe verloren geht, und das wird als Übersetzungslücke bezeichnet. Diese Lücken bestehen zwischen einer Eingabeaufforderung und der endgültigen Ausgabe, die ein LLM-Modell erzeugt. Dies geschieht, weil das Verhalten des Modells unvorhersehbar ist und auf Improvisation beruht, was bedeutet, dass es keine Garantie dafür gibt, dass das, was herauskommt, auch das widerspiegelt, was hineingegeben wurde. 

Die Intent Integrity Chain kann dabei helfen, dies durch einen mehrstufigen Prozess zu erreichen, der sich auf vier Artefakte konzentriert:  

  • Eingabeaufforderung - Von Menschen geschrieben, stellt dies die eigentliche Absicht oder gewünschte Funktionalität dar.
  • Spezifikation - Eine strukturierte, standardisierte Version des Prompts, immer noch in natürlicher Sprache, aber aus Gründen der Klarheit und Konsistenz formatiert.
  • Test - Automatisch aus der Spezifikation generiert; diese Tests definieren, wie korrektes Verhalten aussieht.
  • Code - Vom LLM generierter Code, der die auf der Spezifikation basierenden Tests bestehen soll.

Bevor man damit beginnt, muss man wissen, dass jedes Artefakt ein Glied in der Kette ist, dem man aber nicht blind vertrauen kann.

Während der Prompt nicht validiert werden muss, da er nur ein Ausgangspunkt ist, muss die Spezifikation von Menschen überprüft werden, um sicherzustellen, dass sie die Absicht des Prompts erfasst. In ähnlicher Weise muss der Test gesperrt und überprüfbar sein, und der vom LLM generierte Code sollte nur validiert werden, wenn er den gesperrten Test besteht.

Diese Struktur führt im Grunde in jeder Phase Kontrollpunkte ein, die dazu beitragen können, das Risiko von Sicherheitsmängeln und halluzinierten Funktionen zu verringern und sicherzustellen, dass das Ergebnis mit der menschlichen Absicht übereinstimmt. 

Vertrauen, Prüfen, Schnelligkeit

 

KI-generierter Code wird immer häufiger. Angesichts dessen geht es bei der Erstellung von Leitplanken nicht darum, gute Praktiken zu befolgen; es geht ums Überleben.

Ohne klar definierte Einschränkungen wie Spezifikationen und Tests können LLMs unsichere oder völlig fehlerhafte Software erzeugen. Darüber hinaus bieten Techniken wie Test-Driven Development (TDD) und Behavior-Driven Development (BDD) eine frühe Strukturierung, aber sie haben es schwer, angenommen zu werden, weil Entwickler dazu neigen, eher Code als Tests zu schreiben.

Da Entwicklung und KI inzwischen mehr als nur ein Trend sind, ist die wichtigste Fähigkeit, die sich Entwickler aneignen können, die Artikulation von Absichten. 

Das bedeutet, dass Entwickler jetzt zu Prompt-Ingenieuren werden müssen, die in der Lage sind, Anforderungen präzise zu formulieren, testbare Spezifikationen zu entwerfen und LLM-Ausgaben auf Fehler zu überprüfen. In Anbetracht dessen geht es bei der technischen Führung heute mehr um die Fähigkeit, ein Modell durch strukturiertes Prompting und Constraint-Validierung zu führen. 

Ein gemeinsames Verständnis und eine zukunftssichere Qualifikation 

 

Die Verwendung strukturierter Spezifikationen wie Gherkin kann dazu beitragen, Missverständnisse zwischen Menschen und Maschinen zu vermeiden. Diese Spezifikationen sind zwar kein Code, aber sie sind formal genug, um von Menschen und Maschinen verstanden zu werden.

Die Arbeit mit den Spezifikationen, um zu testen und dann zu programmieren, kann dazu beitragen, KI-Fehler im Endergebnis zu begrenzen.

Sie müssen aufhören, LLMs als Experten zu betrachten, und sie als ein Werkzeug ansehen, das die Absicht verstärken soll. Wenn jedoch die ursprüngliche Absicht schlecht ist, wird auch das Ergebnis des Codes schlecht sein.

Zu den drei wichtigsten Fähigkeiten, auf die sich Entwickler konzentrieren müssen, um zukunftsfähig zu sein, gehören das Schreiben besserer Prompts, die Validierung von Ergebnissen und die Erstellung klarer Spezifikationen. Diejenigen, die diese drei Schlüsselkompetenzen entwickeln, haben bessere Chancen, in ihrem Beruf erfolgreich zu sein. Diejenigen, die dies nicht tun, könnten am Ende durch KI ersetzt werden. 

Abschließende Überlegungen

 

Die künstliche Intelligenz hat und wird die Softwareentwicklung in einer Weise verändern, wie wir es noch nie erlebt haben. Sie kann zwar schneller und effizienter programmieren, aber ihre Ergebnisse entsprechen nicht immer den Vorstellungen oder enthalten logische Fehler und ausnutzbare Schwachstellen, falsch konfigurierte Sicherheitsrichtlinien und vieles mehr.

Entwickler können jedoch die Intent Integrity Chain nutzen, um die Kontrolle zu behalten und sicherzustellen, dass der KI-Code wie beabsichtigt generiert wird, indem sie die menschliche Absicht mit der maschinellen Ausgabe durch Struktur und Validierung in Einklang bringen.

 

Zusammenfassung
Wie man mit Intent Integrity Chain AI überlebt
Artikel Name
Wie man mit Intent Integrity Chain AI überlebt
Beschreibung
Möchten Sie wissen, wohin sich die Softwareentwicklung entwickelt, jetzt wo KI die Oberhand gewinnt? Erfahren Sie, was Entwickler tun sollten, um diese Welle zu überleben!
Autor
Name des Herausgebers
TuxCare
Logo des Herausgebers

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

Inhaltsübersicht
Holen Sie sich die Open-Source-Sicherheitslösungen, die Sie brauchen

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.