• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Künstliche Intelligenz
    • Ein erster AI-Agent für die Softwarearchitektur: Qualitätsziele im Dialog
  • Datenbanken
  • IT-Security
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
  • IT-Karriere
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Wiebke Apitzsch 04. November 2026

Cowboy oder Ingenieur? Wer denkt richtig und was hat das mit IT zu tun?

Gute Softwareentwicklung ist eine philosophische Frage

Als GenAI vor ein paar Jahren auftauchte, war es interessant zu sehen, wie viele Menschen auf Basis von vergleichsweise gut formulierten E-Mails auf das Ende unserer Zeit geschlossen haben. 

Der einzige Ausweg: jetzt alle Vorsicht fallen lassen und AI First werden. Wie die Amerikaner. Diese Forderung ist interessant. Denn wer hat, privat oder beruflich, je erlebt, dass ein Satz wie "Sei doch nicht so" dazu geführt hat, dass die Person ihren Charakter geändert hätte? Ich persönlich nicht. Deswegen die Hypothese: Das funktioniert nicht. 

Aber was kann man tun? 

In meiner Coaching-Ausbildung habe ich ein sehr spannendes Modell kennengelernt: fünf Schritte zur Überwindung des inneren Schweinehundes. Es ist eine Schreibübung, in der man zuerst erklärt, was man nicht hinbekommt, z. B. 3 kg abnehmen. Und wie einfach es eigentlich wäre: weniger essen. 

Aber dann kommt eine Wendung: Statt Tipps eine Frage. Was wäre, wenn du es ab sofort perfekt umsetzen würdest? Exakt korrekt essen. Keine Snacks. Absolute Kontrolle. Genau ein Bier. Das wäre furchtbar, oder? Keiner will das. Und dieser innere Schweinehund ist eigentlich ein sehr, sehr tapferer, loyaler Beschützer. Der vielleicht ein KLEINES bisschen zu sehr den Genuss verteidigt. 

Also macht man einen Deal mit ihm, und danach klappt es oft besser mit der Veränderung. Oder man lässt das mit der Veränderung bewusst sein. Und nennen wir den inneren Schweinehund ab jetzt Wertebeschützer. 

Was bedeutet das jetzt für die deutsche Angst und unsere Bedenkenträger? Welchen wichtigen Wert verteidigen sie, dankenswerterweise? Und welchen verteidigen die Menschen auf der anderen Seite des Atlantiks oder auf anderen Kontinenten?

Was ist der Wert unserer schlechten Eigenschaften?

Wenn du kurz darüber nachdenkst, liegt die Antwort für Deutschland ziemlich nahe: Qualität. Zuverlässige, gründliche, gut gemachte Arbeit. 

Frag einen Ingenieur, warum er bremst. Die wenigsten werden sagen, dass sie Innovation verhindern wollen. Die meisten werden sagen: Ich habe keine Lust, in Zukunft nur noch Fehler zu korrigieren. Ich will nicht unter einem Berg aus Bugs, Incidents und Hotfixes zusammenbrechen. Dann lieber langsamer, aber beständig etwas aufbauen. 

Ich kann diese Aussage absolut verstehen. Ja, ein bisschen mehr Dynamik wäre gut. Unser Schweinehund, nein, Werteverteidiger, verteidigt die Qualität. Frage: Welches Versprechen braucht es, damit die Verteidigung die Waffen ablegt und zuhört? 

Natürlich geht es auch mit Zwang, Druck und Konfrontation. Aber die Variante mit dem Versprechen ist billiger, schneller und hat ein deutlich geringeres "Told you so"-Potenzial. Dass es ein Phänomen und kein Einzelfall ist, öffnet natürlich die Frage, woher es kommt. Es gibt sicher viele Gründe. Aber einen Gedanken möchte ich vorstellen. Er kommt aus dem Herzen der Ethik. 

Die Frage ist, wie wir überlegen können, was richtig und gut ist. Kein persönliches "Mag ich nicht.", sondern ein System, das auf viele Fälle angewendet immer eine sinnvolle Antwort gibt. So ein System wäre toll, leider gibt es das nicht. Aber es gibt verschiedene Modelle, die je nach Fall, aber auch Kultur mehr oder weniger gut akzeptiert werden. 

Philosophen testen diese Modelle mit Gedankenexperimenten, in denen sie imaginäre Straßenbahnen a) passiv über fünf oder b) aktiv über eine Person fahren lassen. Oder Sätze schreiben, die dann in verschiedenen Szenarien getestet werden. Es gibt viele verschiedene Varianten, aber zwei bekannte möchte ich vorstellen. Weil es manchmal hilft, sich bewusst zu machen, wie man gerade denkt, um gute Entscheidungen zu treffen.

Deontologische Ingenieure

Die erste kennen wir in Deutschland sehr gut. Für sie gibt es nicht nur ein Bauchgefühl, sondern ein ganzes Gedankengebäude. Es ist über 200 Jahre alt, stammt aus Königsberg und hat einen Namen, mit dem man auf keiner Party punktet: Deontologie, die Pflichtethik. Geprägt hat sie Immanuel Kant. 

Die Idee dahinter ist einfach: Jeder einzelne Schritt soll für sich genommen gut sein, nicht erst das Ergebnis. Und wir vertrauen darauf, dass wir auf diesem Weg am Ende auch gut ankommen. Saubere Daten, saubere Architektur, saubere Tests, sauberes Deployment. Mit der Konsequenz, dass wir nichts tun, was sich nicht auf einem guten Weg erreichen lässt. Und wir merken uns, was schon schiefgegangen ist, damit es nicht nochmal passiert. Das endet in Regulierung. Natürlich! Und weil wir sehr viel wissen, ist die Liste lang. Es gibt bestimmt viele Regeln, die wir nicht mehr brauchen. Aber die Idee ist gut und wir sollten sie behalten. Eigentlich ist es oft gut, dass es so viele dokumentierte Learnings gibt. Man müsste sie nur schneller finden, verstehen und etwas flexibler anwenden. 

Kant hat versucht, in seiner Ethik Regeln zu finden, die universell gelten. Daraus entstand sein berühmter kategorischer Imperativ [1]. Das Originalzitat ist sperrig. Man könnte es, verkürzt und vereinfacht, so zusammenfassen: "Mach nur Dinge, die dir gern jeder nachmachen darf." Das könnte zu der Regel "Coding-Agenten sind in produktiven Systemen verboten." führen. Das ist aber etwas zu hart. Wenn Entwickler sie nutzen, könnte es okay sein. Aber wir können das nicht einfach für alle freigeben. Und wenn Kollegen sehen und hören, was andere tun können, ist es wahrscheinlich, dass sie andere Wege suchen. Die berühmte Schatten-IT. Code prompten können heute alle. Ihn sicher produktiv zu setzen, nicht. 

Vorschlag: Wer nicht im Development-Team ist, darf Coding-Agenten in produktiven Systemen nicht verwenden, WEIL sonst das Risiko besteht, dass sie absolut alles löschen und damit die Firma als Ganzes gefährden. Menschen mit guten Ideen können gern mit der IT über Alternativen sprechen. Das kann für eine Firma eine gute Regel sein, sie ist verständlich, nachvollziehbar und vermeidet Schaden. Genau wie DevOps, Code Reviews, Tests und Rollen. Software Development und AI-Assisted Coding können eben verbunden oder komplett unterschiedlich sein. 

Schreibt Euch das auf: Es ist erstmal gut, dass wir sind, wie wir sind. Es gibt gute Gründe dafür.

Kreative Cowboys bitten um Entschuldigung, nicht um Erlaubnis

Aber es ist auch klar, dass die wilden Cowboys im Silicon Valley tolle Dinge entwickelt haben. Sehr spannende Dinge. Trotz der Fehler und Lücken. Und auch diese Art zu denken hat System und einen Namen.

Ihr Grundsatz: Je mehr Gutes am Ende entsteht, desto mehr rechtfertigt das die Mittel. Mehr Wohlfahrt, mehr Glück, mehr Erfolg. Der Weg ist zweitrangig, das Ergebnis zählt. Diese Denkweise heißt Utilitarismus. Sie ist vorwiegend auf der anderen Seite des Atlantiks zu Hause.

Man kann das sogar daran sehen, wie die Geschichten in den Krimis meistens geschrieben werden. US-Geschichten haben oft einen Helden, der sehr viel falsch und gegen die Regeln macht, aber nur so am Ende das wirklich Gute erreichen kann.

Im deutschen Tatort verhaftet der Kommissar mit tragischer Miene die Person, die aus besten Gründen einen anderen erschossen hat. Außer es war Notwehr. Die Regeln sind die Regeln. Ganz fremd ist das Modell uns in Deutschland nicht. Oft ist es einfach absolut sinnvoll. Und auch viele Menschen hier mögen amerikanische Filme und können der Moral am Ende folgen. Manchmal ist es das bessere System.

Wenn das Schlimmste, das passieren kann, ein gezwungen strafender Blick von Oma ist (und Oma eigentlich nicht wirklich ärgerlich ist, sondern innerlich lacht): Klar schnappt man sich so viele Gummibärchen, wie man in die kleine Hand bekommt. Wer das als Kind nicht gemacht hat, werfe den ersten Stein. Die Freude an den geklauten Goodies ist maximal. Und der Schaden deutlich kleiner. Und wenn bei James Bond der Weltuntergang verhindert wird, kümmert es uns wirklich, dass er deutlich zu schnell gefahren ist?

Auch Kant sieht natürlich, dass es im Leben Rollen gibt. Und kann das mit seinen Regeln abgleichen. Aber bei großen Themen wie der Lüge ist er sehr streng und tut sich mit menschlichen Dingen wie der Notlüge sehr schwer. Unsere klassischen IT-Systeme sind eigentlich alle Kantianer. Sie haben ihre Regeln und folgen ihnen. Egal, ob der Mensch davor Gutes oder Böses tun will.

Also in einfachen Worten geht es hier um:

Der Weg ist das Ziel

vs.

Ende gut, alles gut.

GenAI Use Cases sind häufig solche Cowboy-Fälle. Die Fachbereiche brauchen schnell eine Lösung. Es soll "einfach nur funktionieren". Das gepromptete Tool macht, zumindest nach außen hin und mit den drei generierten Test-Fällen. Und das ist grundsätzlich eine gute Sache.

Problematisch wird es, wenn Schaden entsteht. Etwa, weil die Zahlen zwar gut aussehen, aber falsch sind. Wenn Sicherheitslücken entstehen, die Kosten hoch sind oder andere Systeme gefährdet werden. Etwa wenn Praktikanten mit Claude Code mit guten Absichten versehentlich zu internen Hackern werden. Viele von uns ärgern sich ja über die Preise zur Datennutzung bei ERP-Anbietern , weshalb manche Services einfach nicht lizenziert sind.

Warum nicht einen kleinen Workflow bauen? Zur Not Screenshots auslesen? Was passsiert, wenn so eine indirekte Nutzung, ein illegales Scraping oder eine heimlich angelegte Analyse der Persönlichkeit aller Kollegen auffliegt, kann sich der motivierte Kollege nicht vorstellen. Dass die Anwendung nur für eine bestimmte Zahl an Aufrufen am Tag ausgelegt ist, weiß ebenfalls nicht jeder.  Man muss die Regeln kennen, um sie zu beachten. All diese Ideen habe ich schon gehört.

Mal so, mal so: Schaden gegen Nutzen

Philosophisch ist dieser Konflikt sehr alt. Es kann sein, dass er offen bleibt, solange es denkende Menschen gibt. Aber praktisch ist das etwas anderes. Und praktisch interessiert uns hier mehr. Im Software Development gibt es in jedem Use Case und in jeder Phase klare Konsequenzen. Die IT eines Unternehmens hat sensible Bereiche. Und andere, in denen kreative Ideen mit etwas Anleitung absolut möglich sind.

Wir brauchen nicht das eine System, das alle Fragen klärt. Wir brauchen eine gute Antwort pro Frage. Eine sehr gute Frage, um dahin zu kommen, ist: Was ist das Schlimmste, was passieren kann?

Solange das Schlimmste, das passieren kann, von mir selbst verantwortet und bereinigt werden kann, kann ich es machen. Etwa, wenn ich über die Höhe des Trinkgelds beim Firmenessen entscheide. Wenn ich weiß, dass ich es zur Not einfach persönlich zahlen kann und es mir persönlich wichtig genug ist, dass ich das auch tun würde, kann ich frei bestimmen, wie viel Trinkgeld es sein muss. Sollte es einen Konflikt mit Chef oder Buchhaltung geben, könnte ich den sofort beenden, indem ich "Na, dann erstattet mir das einfach nicht." sage. Damit ist es geklärt. Und tatsächlich kommt es praktisch nie zu solchen Eskalationen, wenn die erste Regel angewandt wird.

Als Beispiel in der IT: 

Szenario A)

Im schlimmsten Fall haben wir einen Tag in einen Mini-PoC gesteckt und wissen, was wir nicht brauchen.

Das ist gut vertretbar. Im schlimmsten Fall arbeite ich dann etwas schneller in den Tagen danach.

Szenario B)

Im schlimmsten Fall lösche ich das ERP und die Firma steht ein paar Monate still.

Würde ich nicht machen.

Zusammengefasst: Kann ich das Risiko nicht tragen, dann sollte ich mich lieber vorher absichern. Kantianisch. Nach den Regeln, mit gutem Willen. Schritt für Schritt. Es geht um Stabilität der Systeme, Sicherheit, Haftung, Datenschutz, AI Act, Compliance. Kann ich das Risiko tragen: Rock’n Roll.

Vorsicht, es gibt eine neue Art von Risiken: Fehler, die niemand sieht

Schon seit dem Aufkommen von Machine Learning und den ersten großen Simulationen wissen wir, dass es in manchen Fällen praktisch und teilweise auch theoretisch unmöglich geworden ist, genau zu verstehen, was in einem Modell passiert. Wir wissen auch, dass die Modelle teilweise andere Dinge zur Mustererkennung nutzen als die, die wir Menschen nutzen würden. Bekannt ist hier zum Beispiel die Erkennung von Kühen auf der Wiese anhand der Wiese [2].

Das war aber bisher in Ordnung, weil wir die Workflows verstanden haben. Wissenschaftler haben Beweise, die KI vorgeschlagen hat, nachgerechnet und damit einfach nur schneller gute Hypothesen gefunden.

Der Unterschied: Experten nutzen Tools, verstehen ihre Grenzen und wissen, wie sie sauber anschließen.

Mit Coding-Agenten und anderen GenAI Tools demokratisiert sich dieser Prozess und nun arbeiten Menschen mit guten Ideen direkt mit den Tools. Sie verstehen, was sie möchten, sie sehen das Ergebnis, aber sie können nicht nachvollziehen, ob der Weg, den sie gepromptet haben, auch der Weg ist, den die KI entwickelt hat. Und das ist eine zentrale Veränderung. Es kann sein, dass etwas wahr ist, man es glaubt und einen guten Grund dafür hat. Nur ist der Grund falsch. Das nennt sich Gettier-Problem [3] und klingt abstrakt. Philosophische Theorie eben. Aber mit KI wird das ein Problem. Es könnte sein, dass jemand immer E-Mails mit komplexen Fragen zum Geschäft bekommt. Darauf muss die Person antworten und ein Bild zur Erklärung schicken. Dafür baut sie einen Workflow. Der funktioniert super und erzeugt gute E-Mails mit tollen Bildern.

Die Person denkt, das läge daran, dass sie einen sehr guten Prompt geschrieben und die eigene Datenbank selbstgemachter Fotos und Grafiken eingebunden hat. Tatsächlich hat aber ein kluger Hacker Glück gehabt: Die KI hat ein Snippet mit seiner Backdoor eingebaut. Was tatsächlich passiert ist? Dass er die E-Mails im Hintergrund an sich weiterleitet. Er liest mit, baut bei sich als Service auch die Antwort, schickt sie zurück. Mit Top-Qualität. Die spannendsten Infos verkauft er aber an die Konkurrenz. Von irgendwas muss er ja auch leben. Weil unsere Person keinen Code lesen kann, hat sie keine Chance, das zu erkennen. Ihr Frontend macht genau das, was es soll. Vielleicht fällt es nie auf. Vielleicht gibt es irgendwann ein Forensik-Team, das prüfen muss, wie die Informationen verloren gegangen sind.

Dann wird die Lücke natürlich gefunden. Aber wer ist schuld? Jemand, der im Rahmen seiner Arbeit "was mit KI gemacht hat", exakt das geliefert hat, was erwartet wurde? Mit den besten Absichten? Die IT, weil sie ein System, von dem sie nichts wusste, nicht geprüft hat? IT-Security? Weil E-Mails geschickt werden? Die ersten Fälle zeigen jedenfalls, dass die Modellanbieter sehr gute Klauseln gegen eigene Haftung haben. Den Schaden hat das Unternehmen aber auf jeden Fall.

Nicht mauern, sondern verhandeln

Wir könnten also unserem inneren Wertebeschützer folgenden Deal anbieten:

Generell haben wir sehr viel Verantwortung und keine Zeit, interne Hacker zu beaufsichtigen. Grundsätzlich arbeiten wir, wie der Ingenieur das tun sollte.

Aber: Wir sind jeder Idee gegenüber offen und unterstützen Cowboy-Ideen, wo wir nur können. In einem Rahmen, der nur vertretbaren Schaden erzeugen kann.

Damit das funktioniert, ist es notwendig, dass alle, die gern Cowboys sein wollen, das Reiten lernen. Als Vorschlag mit Augenzwinkern haben meine Kollegen und ich einen Test und ein kleines Manifest geschrieben. Es ist unten verlinkt.

Das hat nichts mit AI Act oder AI Literacy allgemein zu tun, sondern mit Software-Entwicklung. Denn eins ist klar: Wenn der kleine PoC genau das ist, was der Fachbereich möchte, folgt darauf die Anfrage, das "kurz einzubinden". Es ist essenziell, dafür zu sorgen, dass schon vorher ein Verständnis entsteht, wie eine spätere Zusammenarbeit funktionieren würde. Was Zeichen sind, dass IT eingebunden werden muss. Wo die Aufwände liegen werden.

Gleichzeitig nimmt es der IT sehr viel Sorge, wenn diese Grundlage besteht. Es fällt viel leichter, den inneren Wertebeschützer zu beruhigen, wenn man ihm sagen kann, dass der Kollege die Regeln kennt und versprochen hat, sich daran zu halten.

Autorin