Der Rat, den ich meinen Kunden gebe, ist unkompliziert: Ohne KI-Unterstützung kannst du nicht konkurrieren. Mit KI-Slop kannst du auch nicht konkurrieren. Nutze die Werkzeuge und behalte die Fachkenntnis, die nötig ist, um sie richtig zu nutzen.
Shopify-CEO Tobi Lütke hat ungeprüfte KI-Ergebnisse, die an Kolleginnen und Kollegen weitergereicht werden, kürzlich als „Slop-Granaten“ bezeichnet. Sein Beispiel waren unter anderem aufgeblähte E-Mails, bei denen die Empfängerin die Arbeit hat, die nützliche Information herauszuziehen. Jemand darf sich produktiv fühlen, während jemand anderes das Aufräumen erbt.
Das ist eine gute Beschreibung. Aber wenn so etwas innerhalb einer Organisation passiert, ist meine erste Frage, was das Management zu belohnen beschlossen hat, welche Fachkenntnis es behalten hat und ob überhaupt jemand die Arbeit misst, die entsteht, nachdem jemand auf „fertig“ geklickt hat.
Ich nutze KI ausgiebig, um Software zu bauen. Ich habe kein Interesse daran, in eine Welt zurückzukehren, in der ich jede Codezeile von Hand tippe. Die Kombination, die ich empfehle, sind erfahrene Menschen mit leistungsfähigen KI-Werkzeugen, und der menschliche Beitrag beginnt, bevor der Agent irgendetwas schreibt. Jemand muss einen Ansatz wählen, die Randbedingungen festlegen und erkennen, welche Lösung es wert ist, gebaut zu werden.
Ist das ein Engineering-Problem oder ein Managementproblem?
Das Managementproblem kommt zuerst. Shopify hat im Juli 2022 rund 10 % der Belegschaft abgebaut, wobei Lütke einräumte, die Dauerhaftigkeit des E-Commerce-Booms der Pandemie überschätzt zu haben. Im Mai 2023 kündigte er eine weitere Reduzierung um etwa 20 % samt Verkauf von Shopify Logistics an. Diese zweite Ankündigung hob auch die Chancen der aufkommenden KI-Ära hervor. Das waren Führungsentscheidungen über Richtung, Personal und Prioritäten des Unternehmens.
Im April 2025 machte Lütke den Einsatz von KI zur Grunderwartung, verankerte ihn in Leistungs- und Peer-Bewertungen und verlangte von Teams, die zusätzliches Personal oder Budget wollten, zu erklären, warum KI den Bedarf nicht decken könne. Sein Memo plädierte außerdem ausdrücklich dafür, menschliches Können mit KI zu vervielfachen. Diesem Prinzip stimme ich zu.
Diese Fakten belegen nicht, dass Shopifys Entlassungen die Slop-Granaten verursacht haben, oder dass erfahrene Entwicklerinnen und Entwickler flächendeckend durch nichttechnische Prompt-Bediener ersetzt wurden. Sie belegen aber, warum die Managementfrage zählt. Wer die Personalpolitik und die Erwartungen an den KI-Einsatz festlegt, trägt auch die Verantwortung dafür, dass diese Kombination funktioniert.
Mein Einwand richtet sich gegen ein Betriebsmodell, das von Beschäftigten verlangt, KI-Nutzung vorzuweisen, ohne dem Urteilsvermögen, der Überprüfung und der Wartung dasselbe Gewicht zu geben, die nötig sind, um generierte Ergebnisse in nützliche Arbeit zu verwandeln. Bevor man fragt, ob KI eine Aufgabe erledigen kann, sollte das Management fragen, was es braucht, um das Ergebnis korrekt zu liefern. Das sind nicht dieselben Fragen.
Kann ein Agent einen Pull Request erzeugen? Schön. Wer weiß, ob er das richtige Problem löst? Wer prüft die architektonischen Folgen? Wem gehört er, wenn er kaputtgeht? Wie viel vom Tag einer anderen Person verschwindet im Prüfen und Reparieren?
Beschäftigte bleiben verantwortlich für das, was sie einreichen. Aber wenn Menschen einander wiederholt Arbeit übergeben, die sie nicht beurteilen können, sehe ich ein Problem im Organisationsdesign und nicht bloß eine Ansammlung enttäuschender Mitarbeiter. Die Führung kann nicht die Produktivitätsgewinne für sich reklamieren und das Aufräumen als Talentproblem behandeln.
Ist Enter drücken schon Ingenieursarbeit?
Enter drücken ist keine Ingenieursarbeit. Es ist nichts falsch daran, dass nichttechnische Menschen mit KI Dinge bauen. Die Hürde zum Experimentieren zu senken, gehört zum Spannendsten an dieser Technologie. Wer eine Idee früher nicht über eine Skizze hinausbrachte, kann jetzt einen funktionierenden Prototyp erkunden, und das finde ich großartig.
Ein Prototyp und ein Produktivsystem sind allerdings unterschiedliche Verantwortungen. Jemand muss trotzdem verstehen, was gebaut wurde, von welchen Annahmen es abhängt und welche Belege zeigen würden, dass diese Annahmen falsch sind.
Einen Menschen zwischen einen Agenten und einen Deploy-Button zu stellen, sorgt nicht automatisch für echte Aufsicht. Diese Person braucht das Wissen, um dem Agenten zu widersprechen, die Zeit, seine Arbeit zu prüfen, und die Befugnis, das Ergebnis abzulehnen. Sonst ist der Freigabeschritt bloß Zeremonie.
Das ist nicht nur die Sorge von KI-Skeptikern. GitHubs eigene Hinweise warnen davor, dass die Agenten falschen oder unsicheren Code produzieren können, empfehlen, ihre Ergebnisse zu prüfen und zu testen, und sagen, dass KI-Code-Reviews die menschliche Prüfung ergänzen und nicht ersetzen sollen.
Blinde Freigabe ist ein Garbage-in-Garbage-out-Problem, aber der Müll steckt nicht zwangsläufig nur im Prompt. Es kann eine unvollständige Anforderung sein, eine fehlende Randbedingung, ein Anreiz, zu schnell zu sein, oder ein Prüfprozess, der darauf hinausläuft, dasselbe System zu fragen, ob es gute Arbeit geleistet hat. Die Lösung ist, Menschen zu beschäftigen, die wissen, wann sie widersprechen müssen.
Ingenieursarbeit heißt zu wissen wie, nicht nur zu fragen was
Es ist ein erheblicher Unterschied, ob man einem Agenten sagt, was ein Produkt tun soll, oder ob man weiß, wie dieses Produkt implementiert werden sollte. „Bau mir ein System, das diese Datensätze verarbeitet“ beschreibt ein Ergebnis. Es sagt sehr wenig über Architektur, erwartete Last, Speicherbudget, Sicherheitsgrenzen oder das Verhalten im Fehlerfall.
Eine gute KI-gestützte Ingenieurin liefert diese fehlende Richtung. Sie kann dem Agenten sagen, er solle den etablierten Code-Mustern des Projekts folgen, eine vorhandene Abstraktion wiederverwenden, eine passende Datenstruktur wählen oder einen Algorithmus vermeiden, der mit wachsender Eingabe unbezahlbar wird. Repository-Anweisungen zu schreiben nützt nur, wenn jemand weiß, was darin stehen sollte.
Das heißt nicht, jedes Implementierungsdetail zu diktieren oder anzunehmen, die erste Idee des Menschen müsse die bessere sein. Ich will, dass der Agent Alternativen vorschlägt und Annahmen hinterfragt. Aber jemand braucht genug Verständnis, um diese Alternativen zu bewerten, statt die Erklärung zu übernehmen, die am selbstsichersten klingt.
„Mach es effizient“ ersetzt kein Verständnis von Effizienz. „Mach es sicher“ ist kein Sicherheitsmodell. Das sind Wünsche, bis jemand sie in konkrete Anforderungen übersetzt und überprüft, dass die Implementierung sie erfüllt.
Zählt das O-Kalkül noch, wenn die KI den Code schreibt?
Das O-Kalkül ist nicht verschwunden. Nehmen wir ein einfaches Beispiel: Datensätze aus zwei Sammlungen über eindeutige Kennungen einander zuordnen. Eine Implementierung könnte für jeden Datensatz der ersten Sammlung wiederholt die zweite durchsuchen. Bei zwei Sammlungen mit n Datensätzen kann das n² Vergleiche erfordern. Alternativ kann man bei Kennungen fester Größe eine Hash-basierte Nachschlagestruktur aufbauen und die Zuordnung auf erwartete O(n)-Laufzeit bringen, um den Preis von O(n) zusätzlichem Speicher. Das ist ein Kompromiss zwischen Zeit und Speicher, keine Frage von Formatierungsvorlieben.
Beide Implementierungen liefern in einer kleinen Demo womöglich das richtige Ergebnis. Die Ingenieursfrage ist, was unter der Last passiert, die das Produkt tatsächlich tragen muss. Wie viele Daten verarbeitet es? Wie viel Speicher steht zur Verfügung? Ist das eine gelegentliche Operation oder etwas, das bei jeder Anfrage passiert?
Eine erfahrene Bedienerin kann dem Agenten nützliche Richtung geben: „Durchsuche nicht für jeden Datensatz die ganze Sammlung erneut. Baue eine Nachschlagestruktur, berücksichtige ihren Speicherbedarf und miss die Implementierung gegen unsere erwarteten Eingabegrößen.“ Diese Anweisung kommt aus dem Verständnis des Problems, nicht aus dem Fund eines magischen Prompts.
Dasselbe Verständnis sollte unnötige Optimierung verhindern. Ich will nicht, dass ein Agent aus einer trivialen Operation ein aufwendiges Framework macht, nur weil ihm jemand gesagt hat, er solle die Performance maximieren. Ich will, dass die Bedienerin Zeitkomplexität, Speicherkomplexität und die tatsächlichen Anforderungen gut genug versteht, um eine angemessene Lösung zu wählen.
Informatik ist nicht optional geworden, weil die Anweisungen jetzt auf Deutsch geschrieben werden. Wir haben verändert, wie wir Software anfordern. Wir haben nicht die Eigenschaften verändert, die Software korrekt, effizient oder wartbar machen.
Manchmal muss man sagen: Bau einen endlichen Automaten
Angenommen, ich baue einen Hintergrund-Importprozess, der in der Warteschlange, laufend, abgeschlossen, fehlgeschlagen oder abgebrochen sein kann. Eine plausible Implementierung würde den Fortschritt über eine Sammlung einzelner Flags verfolgen. Aber dieser Entwurf muss widersprüchliche Kombinationen verhindern, etwa einen Job, der gleichzeitig läuft und abgeschlossen ist.
Ein endlicher Automat gibt diesem Ablauf eine explizite Menge von Zuständen und definierte Übergänge dazwischen. Statt die Entscheidungen darüber, was als Nächstes passieren darf, über die ganze Anwendung zu verstreuen, kann ich modellieren, welche Ereignisse den Prozess von einem Zustand in einen anderen bewegen dürfen. Das sind die Grundbegriffe hinter der Zustandsautomaten-Notation: Zustände, Ereignisse und Übergänge.
Der Agent schlägt diesen Ansatz vielleicht von selbst vor. Prima. Vielleicht aber auch nicht, und die Person, die ihn anleitet, muss erkennen, wann das Problem danach verlangt. Manchmal lautet die nützliche Anweisung: „Implementiere das als endlichen Automaten. Definiere die erlaubten Übergänge, behandle den Abbruch explizit und teste, was passiert, wenn ein Abschlussereignis nach einem Abbruch eintrifft.“ Das heißt, ein Modell für das Verhalten des Systems zu wählen.
Endliche Automaten, Statecharts und andere Automatenmodelle gehören in den technischen Werkzeugkasten der menschlichen Bedienerin. Nicht weil jede Funktion ein formales Modell braucht, sondern weil sie erkennen sollte, wann eines das Problem klärt und wann es unnötige Komplexität hinzufügt. Den Namen eines Musters zu kennen reicht nicht. Man muss verstehen, wo es greift, was es garantiert und was es offenlässt.
Und „nimm einen Zustandsautomaten“ ist keine Zauberformel, die die Implementierung korrekt macht. Ich muss die Übergänge trotzdem prüfen und das Verhalten testen. Der Wert liegt darin, dass ich dem Agenten eine Struktur gegeben habe, über die ich nachdenken kann, statt eine Anordnung von Bedingungen zu akzeptieren, nur weil sie den Happy-Path-Test bestanden hat.
Mensch-Computer-Interaktion ist ebenfalls nicht optional
Informatik ist nicht die einzige Expertise, die wir weiterhin brauchen. Mensch-Computer-Interaktion zählt auch, und ich bin nicht bereit, sie als optionalen letzten Schliff zu behandeln, bloß weil ein Agent einen Bildschirm so schnell generiert wie den Code dahinter.
Ich erwarte, dass ein wachsender Teil des Internets agent-first wird. Aber ich baue weiterhin Produkte, die Menschen verstehen und benutzen müssen. Diese Menschen müssen wissen, was gerade passiert, was ihre Optionen bedeuten, ob eine Aktion erfolgreich war und wie sie sich erholen, wenn etwas schiefgeht. Sichtbarkeit, Konsistenz, Nutzerkontrolle und Fehlervermeidung sind etablierte Prinzipien des Interaktionsdesigns, keine dekorativen Vorlieben.
„Mach eine gute Oberfläche“ ist ungefähr so nützlich wie „mach den Algorithmus effizient“. Eine kompetente Fachkraft kann dem Agenten viel präzisere Richtung geben: Ordne die Information um die Aufgabe der Nutzerin herum, erhalte die vertraute Navigation, unterscheide primäre von destruktiven Aktionen und mache Fortschritts- und Fehlerzustände verständlich. Barrierefreiheit ergänzt konkrete Implementierungsanforderungen, darunter Tastaturbedienbarkeit, sichtbarer Fokus, aussagekräftige Beschriftungen und zugängliche Statusmeldungen.
Nehmen wir den Hintergrund-Import aus dem Beispiel mit dem Zustandsautomaten. Die internen Zustände richtig zu treffen, ist nur ein Teil der Arbeit. Ich will auch, dass die Oberfläche zwischen wartet auf Start, importiert gerade, teilweise abgeschlossen, abgebrochen und fehlgeschlagen unterscheidet. Wer sie benutzt, sollte diese Unterschiede nicht aus einem Ladekringel erraten müssen.
Meine Anweisungen an den Agenten könnten lauten: „Erhalte die Auswahl der Nutzerin nach einem Fehler. Erkläre, welche Datensätze importiert wurden und welche nicht. Zeige keine Erfolgsmeldung, bevor die Operation tatsächlich abgeschlossen ist. Zeige an, ob ein Abbruch noch möglich ist, und mach das Verhalten bei einem erneuten Versuch explizit.“
Das ist Implementierungsanleitung, keine Bitte um hübschere Farben. Ich muss die entstandene Oberfläche trotzdem benutzen, die relevanten Zustände testen und beobachten, ob Menschen sie verstehen. Ein polierter Screenshot ist kein hinreichender Beleg dafür, dass die Interaktion funktioniert.
Dasselbe gilt für die Oberflächen der Agenten selbst. Menüs durch Konversation zu ersetzen, hebt die Notwendigkeit nicht auf, Umfang, Fortschritt, Unsicherheit und Konsequenzen zu kommunizieren. Ich würde sogar sagen: Ein Agent, der über mehrere Systeme hinweg handelt, macht diese Designentscheidungen wichtiger, nicht unwichtiger. Der Mensch braucht weiterhin einen Weg, die Arbeit zu verstehen, zu unterbrechen, zu korrigieren und freizugeben.
Ein agent-first-Internet ist kein menschenirrelevantes Internet. Solange Menschen die Arbeit anleiten und mit ihren Folgen leben, muss jemand diese Beziehung gestalten.
Wer haftet für die Sicherheit, wenn ein Agent den Code schreibt?
Enter drücken ist keine Sicherheits- oder Datenschutzstrategie. Codequalität ist nur ein Teil der Verantwortung. Ein Agent kann auch Zugriff auf Dateien anfordern, Befehle ausführen, mit Diensten interagieren und Code mit Schwachstellen erzeugen. GitHubs eigene Hinweise warnen ausdrücklich vor falschen oder unsicheren Ergebnissen und vor der Notwendigkeit sorgfältiger Prüfung und Tests.
Bevor ich eine Aktion freigebe, will ich, dass die Bedienerin fragt, worauf sie zugreifen kann, was sie ändern kann und wohin die Daten gehen können. Braucht diese Aufgabe Produktionszugangsdaten? Könnten diese Debug-Logs Kundeninformationen enthalten? Warum hat eine Operation, die nur lesen muss, die Berechtigung zum Ändern oder Löschen?
Das sind keine Details, um die man sich kümmert, nachdem die Demo läuft. OWASP nennt übermäßige Funktionalität, Berechtigungen und Autonomie als Risikoquellen in agentischen Systemen. Zu den Empfehlungen gehören, Fähigkeiten zu begrenzen, das Least-Privilege-Prinzip durchzusetzen, für folgenreiche Aktionen eine Freigabe zu verlangen und Autorisierung außerhalb des Modells zu implementieren, statt ihm die Entscheidung über das Erlaubte zu überlassen.
Wer jede Anfrage blind freigibt, bewertet diese Risiken nicht ernsthaft. Aber die Antwort lautet auch nicht einfach, jemanden Erfahrenen einzustellen und zu erwarten, dass er alles bemerkt. Gebt dieser Person eine Umgebung mit durchgesetzten Grenzen, angemessenen Zugriffskontrollen und einem Prüfprozess, der nicht auf perfekter Wachsamkeit beruht.
Deshalb ist mir das Verständnis der Bedienerin wichtig. Sie muss helfen, die Schutzmechanismen zu entwerfen, und nicht bloß den Stuhl vor dem Freigabeknopf besetzen.
Compliance gehört zur Ingenieursarbeit
Ein Produkt, das in der Demo funktioniert, ist nicht zwangsläufig eines, das eine Organisation verantwortungsvoll betreiben kann. Jemand muss auch verstehen, welche Informationen es verarbeitet, wer darauf zugreifen kann, welche Pflichten gelten und welche Nachweise die Organisation braucht, um zu zeigen, dass ihre Kontrollen wirken.
Je nach Geschäft kann das SOC 2, PCI DSS und HIPAA umfassen. Das sind unterschiedliche Arten von Pflichten und Prüfmechanismen, keine drei austauschbaren Plaketten:
- SOC 2 ist eine unabhängige Prüfung von Kontrollen anhand der einschlägigen Trust Services Criteria. Zu diesen Kriterien gehört das Änderungsmanagement: Systemänderungen autorisieren, dokumentieren, testen, genehmigen und einführen. Dass ein Agent einen erfolgreichen Build erzeugt, belegt nicht, dass die Organisation diesen Prozess eingehalten hat.
- PCI DSS legt technische und operative Sicherheitsanforderungen für Zahlungskontodaten fest. Der Geltungsbereich kann Systeme und Dienstleister einschließen, die die Sicherheit der Karteninhaberdatenumgebung beeinflussen, und nicht nur eine Datenbank, die Kartennummern direkt speichert. Diesen Geltungsbereich zu verstehen, gehört zum verantwortungsvollen Entwurf und Betrieb des Systems.
- HIPAA bringt, wo es für abgedeckte Einrichtungen und deren Geschäftspartner gilt, Anforderungen an den Schutz elektronisch geschützter Gesundheitsdaten mit sich. Die Security Rule umfasst Risikoanalyse, Zugriffskontrollen, Auditkontrollen und angemessene Vereinbarungen mit Geschäftspartnern. Diese Pflichten verschwinden nicht, weil ein KI-Assistent beim Schreiben der Anwendung geholfen hat.
Ich erwarte nicht, dass jede Entwicklerin Compliance-Juristin oder Auditorin ist. Ich erwarte von einem erfahrenen Team, dass es erkennt, wann diese Anforderungen einen Entwurf betreffen, und die passende Expertise hinzuzieht, bevor es ausliefert. „Das hat dem Agenten niemand gesagt“ ist ein Anforderungsfehler, keine Ausnahme.
Für folgenreiche Produktionsänderungen will ich eine Prüfspur, die die Anfrage mit der Implementierung, den Tests, der Prüfung, der Freigabe und dem Deployment verbindet. Was hat sich geändert? Warum? Welche Version wurde geprüft? Wer hat sie mit welcher Befugnis freigegeben? Was ist tatsächlich in Produktion gelandet?
Dieser Nachweis sollte entstehen, während die Arbeit läuft, und nicht hinterher aus jemandes Erinnerung und der fröhlichen Zusammenfassung eines Agenten rekonstruiert werden. Ein Eintrag „freigegeben“ belegt, dass jemand einen Knopf gedrückt hat. Er belegt für sich genommen nicht, dass eine ernsthafte Prüfung stattgefunden hat.
Was heißt es eigentlich, die Arbeit eines Agenten freizugeben?
Eine Freigabe ist eine Entscheidung, kein Tastendruck. Enter zu drücken, ohne die Folgen zu prüfen, kann die Organisation, ihre Kunden und die freigebende Person in Gefahr bringen. Stellen wir uns einen Agenten vor, der vorschlägt, Produktionslogs zum Debuggen an einen externen Dienst hochzuladen. Bevor man das freigibt, muss jemand feststellen, was in diesen Logs steht und ob dieses Ziel zulässig ist. Die Bequemlichkeit der vorgeschlagenen Lösung beantwortet keine der beiden Fragen.
Es kann auch Folgen für Beschäftigte geben, die vorgeschriebene Schutzmechanismen umgehen. Die HHS-Hinweise zu HIPAA-Sanktionsrichtlinien etwa erörtern Konsequenzen von der Verwarnung bis zur Kündigung, überlassen die angemessene Reaktion aber der Organisation und den Umständen. Das ist keine Behauptung, dass jede Fehlfreigabe jemanden den Job kosten sollte. Es ist eine Erinnerung daran, dass eine Freigabe berufliche Verantwortung tragen kann.
Aber das Management kann diese Verantwortung nicht fair zuweisen, ohne das Wissen, die Zeit, die Informationen und die Befugnis bereitzustellen, die nötig sind, um sie auszuüben. Jemandem eine Warteschlange von Freigaben zu geben, die er nicht beurteilen kann, ihn daran zu messen, wie schnell er sie abarbeitet, und ihm dann das Ergebnis vorzuwerfen, ist keine verantwortungsvolle Delegation.
Die Freigabeoberfläche selbst muss die Entscheidung stützen. Bei einem Deployment will ich, dass die prüfende Person die tatsächliche Änderung, die Zielumgebung, die relevanten Testergebnisse, offene Risiken und den Wiederherstellungsplan sieht. Ich will nicht, dass „Fortfahren? J/n“ eine Erklärung dessen ersetzt, was gleich passiert.
Genauso wenig will ich einen Ablauf, der für jede harmlose Aktion menschliche Freigabe verlangt. Mein Ziel ist, risikoarme Arbeit innerhalb festgelegter Grenzen zu automatisieren und menschliche Aufmerksamkeit für Entscheidungen zu reservieren, die Urteilsvermögen brauchen. Mehr Knöpfe sind nicht dasselbe wie mehr Aufsicht.
Ford musste die verlorene Expertise neu aufbauen
Bloomberg berichtete im Juni 2026, Ford habe in den drei Jahren zuvor 350 erfahrene Ingenieurinnen und Ingenieure eingestellt, darunter ehemalige Beschäftigte und Fachleute von Zulieferern. Sie halfen, Qualitätsprobleme anzugehen, jüngere Kollegen auszubilden und KI-Werkzeuge zu verbessern, die hinter den Erwartungen geblieben waren. Das war eine Geschichte über Fahrzeugtechnik und Qualitätssysteme, nicht die Behauptung, Ford habe 350 Softwareentwickler zurückgeholt, um generierten Anwendungscode aufzuräumen.
Das ist die Lehre, die ich in ein Softwareunternehmen mitnehmen würde. Bevor man eine teure Ingenieurin aus einer Tabelle streicht, sollte man verstehen, was diese Person jenseits sichtbarer Ergebnisse beiträgt. Fragt, was sie verhindert, was sie früh erkennt und worauf sich der Rest des Teams bei ihr verlässt. Und überlegt dann, was sie mit besseren Werkzeugen erreichen könnte.
Bedeuten niedrigere Gehälter wirklich niedrigere Kosten?
Hört auf, niedrigere Gehälter mit niedrigeren Kosten zu verwechseln. Das Management will Personalkosten senken. Verstehe ich. Ich führe auch Unternehmen und schlage nicht vor, Geld ohne Renditeerwartung auszugeben. Aber ich würde diese Rendite an den Kosten für die Lieferung und Wartung eines nützlichen Produkts messen, nicht einfach am Gehalt der einzelnen Person, die daran arbeitet.
Ein Freund schickte mir kürzlich eine Stellenanzeige für eine Präsenzstelle als Softwareentwickler in New York City. Sie verlangte einen Master und sechs Jahre Berufserfahrung und bot 200.000 Dollar. Diese Kombination ergab für mich keinen Sinn. Für das Kaliber an Ingenieur, das ich mir für folgenreiche KI-gestützte Entwicklung wünsche, würde ich die Stelle anders zuschneiden.
Zuerst würde ich die Master-Anforderung streichen, es sei denn, es wäre eine Forschungsstelle, bei der diese Ausbildung wirklich zählt. Ich will wissen, was jemand gebaut hat, welche schwierigen Entscheidungen er verantwortet hat und ob er die Folgen dieser Entscheidungen versteht. Informatikkenntnisse zu verlangen ist nicht dasselbe wie ein bestimmtes Diplom zu verlangen.
Kann die Person erklären, warum sie eine Architektur einer anderen vorgezogen hat? Erkennt sie eine Sicherheitsgrenze, kann sie über Performance nachdenken und ein System entwerfen, das sich im Fehlerfall sinnvoll verhält? Kann sie einen Agenten zu einer guten Implementierung führen und eine scheinbar erfolgreiche ablehnen, die die tatsächlichen Anforderungen nicht erfüllt?
Das sind die Fähigkeiten, für die ich einstellen würde. Dann würde ich rund 350.000 Dollar Jahresgehalt einplanen, mit bis zu 2.000 Dollar pro Monat für KI-Unterstützung, und vom Auswahlprozess erwarten, dass er belegt, dass die Kandidatin diese Investition rechtfertigen kann.
Das ist mein Budgetvorschlag für eine besonders wirksame Rolle, nicht die Behauptung, jede Ingenieursstelle solle gleich bezahlt werden. Ein höheres Gehalt entbindet das Management auch nicht davon, Kandidatinnen ordentlich zu prüfen. Der Punkt ist, offensiv um die Expertise zu konkurrieren, auf der die Strategie beruht, statt anzunehmen, ein KI-Abo mache diese Expertise weniger wertvoll.
Wie hoch sollte das Werkzeugbudget einer Ingenieurin sein?
Gebt der Ingenieurin ein ernst gemeintes Werkzeugbudget. Die monatlichen 2.000 Dollar wären ein Gesamtbudget für KI-Werkzeuge, nicht der Preis eines einzelnen Abos und keine Pflicht, jeden Dollar auszugeben. Für einen genehmigten Anwendungsfall denke ich an so etwas wie einen erstatteten Claude-Max-Plan plus zusätzliche Nutzung. Anthropic bietet kostenpflichtige Nutzung über das im Plan enthaltene Kontingent hinaus an, mit Ausgabenkontrollen.
Konto und Einsatz müssen weiterhin zu den Sicherheits-, Datenschutz- und Vertragsanforderungen der Organisation passen. Ein persönliches Abo zu erstatten klärt diese Fragen nicht. Das Team muss die passende Lösung für die beteiligten Informationen und Systeme wählen.
Beim vollen Budget sind das 24.000 Dollar KI-Ausgaben im Jahr neben einem Gehalt von 350.000 Dollar, also 374.000 Dollar für Gehalt und Werkzeuge vor Sozialleistungen, Arbeitgeberabgaben, Boni, Beteiligungen und sonstigem Overhead. Die Werkzeuge kosten weniger als 7 % des Gehalts. Ich würde diese Ausgabe daran messen, was sie die Ingenieurin liefern lässt.
In einem bewusst vereinfachten Vergleich von Gehalt und Werkzeugen allein sind 374.000 Dollar das 1,87-Fache von 200.000 Dollar. Wenn die teurere Kombination mehr als das 1,87-Fache an vergleichbarer, nützlicher Arbeit liefert, sind ihre Kosten je Arbeitseinheit niedriger. Das ist eine Veranschaulichung der Ökonomie, keine Prognose. Ein echter Vergleich braucht die vollen Kosten auf beiden Seiten.
Der Anspruch ist, aus einer 10x-Entwicklerin eine 100x-Entwicklerin zu machen. Diese Zahlen beschreiben, was ich anstreben will, keinen garantierten Produktivitätsmultiplikator. Ich würde erwarten, dass eine sorgfältig ausgewählte Ingenieurin mit starken Werkzeugen eine Einstellungsstrategie schlägt, die darauf setzt, jemanden Billigeren zu finden und anzunehmen, KI liefere das fehlende Urteilsvermögen. Aber ich würde diese Erwartung an der gelieferten Arbeit überprüfen.
Nichts davon macht Junior-Entwickler entbehrlich. Ich will, dass sie neben erfahrenen Leuten lernen und KI nutzen, während sie das Wissen entwickeln, sie zu hinterfragen. Der teure Fehler ist, ihnen die Mentoren zu nehmen und ihnen Verantwortung zu übertragen, für die sie noch nicht bereit sind, weil das Management entschieden hat, ein Agent liefere die Erfahrung.
Eine Organisation für Menschen und Agenten
Das ist die Kombination, um die herum ich mit Orgabot baue: Menschen und KI-Agenten in definierten Rollen einer Organisation, mit Workflows, die Verantwortlichkeiten, Berechtigungen, Prüfungen und Freigaben festlegen. Es geht darum, die Arbeitsweise der Organisation explizit genug zu machen, damit autonome Arbeit innerhalb sinnvoller Grenzen stattfinden kann.
Die Unterscheidung, die mir wichtig ist, verläuft zwischen dem, worüber ein Agent nachdenken darf, und dem, was die umgebende Software erzwingen muss. Flexible Planung und Implementierung gehören neben Kontrollen über Werkzeugzugriff, erforderliche Freigaben, Testergebnisse und Auditnachweise. Die Pflicht, eine Freigabe einzuholen, sollte keine Empfehlung in einem Prompt sein, die der Agent uminterpretieren kann.
Für eine folgenreiche Produktionsänderung beginnt der Ablauf, den ich will, damit, dass ein qualifizierter Mensch Ziel und Randbedingungen festlegt. Agenten können untersuchen, Ansätze vorschlagen, die Änderung umsetzen und bei Tests und Prüfung helfen. Die Verantwortlichen bewerten dann dem Risiko angemessene Nachweise, bevor die freigegebene Änderung in Produktion geht.
Ich will, dass die Freigabe an die tatsächlich geprüfte Version gebunden ist. Ändert sich die Implementierung danach wesentlich, muss sie erneut die nötige Prüfung durchlaufen. Ich will außerdem einen klaren Nachweis über die Anfrage, die geleistete Arbeit, die durchgeführten Prüfungen, die getroffenen Entscheidungen und das Ergebnis des Deployments.
Das bedeutet es für mich, Orgabot mit Blick auf Compliance zu entwerfen: Verantwortlichkeiten und Nachweise zu einem Teil des Prozesses zu machen. Es bedeutet nicht, ein Werkzeug zu installieren und die Organisation für konform zu erklären. Die Organisation muss weiterhin ihre Pflichten bestimmen, passende Kontrollen einrichten und zeigen, dass sie wirken.
Der menschliche Beitrag zählt durchgehend. Jemand muss den Bedarf an einem Zustandsautomaten erkennen, einen teuren Algorithmus hinterfragen, eine Datenschutzgrenze schützen, eine einschlägige Compliance-Anforderung identifizieren oder erklären, warum eine Oberfläche Menschen verwirren wird. Diese Verantwortungen können bei mehreren erfahrenen Fachleuten liegen. Ein Organigramm sollte klarmachen, wem was gehört.
Wie lassen sich Slop-Granaten vermeiden?
Besetzt für Verantwortung, nicht für Freigaben. Gebt folgenreiche Arbeit an jemanden, der das Ergebnis beurteilen kann und auch nach dem Deployment dafür verantwortlich bleibt. Stellt nach nachgewiesenem Verständnis ein, nicht bloß nach Abschluss, langem Lebenslauf oder Begeisterung für das neueste Modell. Gebt weniger Erfahrenen Anleitung und einen Weg, dieses Verständnis zu entwickeln.
Definiert Erfolg, bevor ihr die Lösung generiert. Schreibt auf, welches Verhalten ihr braucht, welche Randbedingungen unverletzlich sind und welche Nachweise nötig sind, um die Arbeit anzunehmen. Nehmt Fehlerfälle auf. Dass ein Agent Code produziert und dann Tests, die diesem Code zustimmen, reicht nicht; die Überprüfung muss zu den ursprünglichen Anforderungen zurückkehren.
Macht die Prüfung echt und finanziert sie entsprechend. Plant Zeit ein, um Änderungen zu inspizieren, Annahmen zu hinterfragen, Integrationen zu testen und die tatsächliche Nutzererfahrung zu prüfen. Nutzt KI zur Unterstützung dieser Tätigkeiten, aber macht die Zustimmung eines weiteren Modells nicht zur alleinigen Grundlage des Vertrauens. Die verantwortliche Person muss den Prozess stoppen können, ohne als Produktivitätshindernis behandelt zu werden.
Messt die ganze Arbeit. Zählt die Zeit fürs Klären, Generieren, Prüfen, Reparieren, Ausliefern und Betreuen mit, dazu die Kosten der Werkzeuge. Vergleicht das mit dem gelieferten Ergebnis. Eine Aufgabe ist nicht effizienter, weil eine Person schneller fertig war, während drei Kolleginnen die Differenz aufgefangen haben.
Nichts davon verlangt, KI abzulehnen oder absichtlich langsam zu sein. Es verlangt Ehrlichkeit darüber, was „fertig“ heißt.
Das Management verantwortet die Bedingungen
Lütke hat recht, wenn er sich gegen Arbeit wehrt, die anderen Arbeit macht. Mein Einwand richtet sich dagegen, dieses Verhalten von der Personalausstattung, den Anreizen und den Standards ringsum zu trennen. Zur KI-Strategie eines Unternehmens gehört, wer die Werkzeuge benutzt, was diese Menschen verstehen und was das Management von ihnen zu überprüfen erwartet.
Ich verstehe den Wunsch, Personalkosten zu senken. Ich würde ihn über bessere Ergebnisse pro Dollar verfolgen, auch wenn das heißt, für eine einzelne Ingenieurin mehr auszugeben. Stellt nach nachgewiesener Expertise ein, zahlt genug, um darum zu konkurrieren, und schafft die Werkzeuge und Arbeitsbedingungen, die sie zur Geltung bringen.
Die Fähigkeit zu beschneiden, Arbeit zu beurteilen, während man die Fähigkeit ausbaut, sie zu erzeugen, ist ein sehr effizienter Weg, Slop-Granaten zu produzieren. Ohne KI-Unterstützung kannst du nicht konkurrieren. Mit KI-Slop kannst du auch nicht konkurrieren. Das Management verantwortet die Bedingungen, die bestimmen, welches Ergebnis dabei herauskommt.
Quellen
- The Knowledge Project
- Shopifys Ankündigung von 2023
- Shopifys Ankündigung von 2022
- Lütkes Memo vom April 2025
- GitHubs Hinweise
- Die Zustandsautomaten-Notation des W3C
- Die Usability-Prinzipien der Nielsen Norman Group
- Die Barrierefreiheitsrichtlinien des W3C
- OWASPs Hinweise zu übermäßiger Handlungsmacht
- Die Trust Services Criteria der AICPA
- PCI Security Standards Council
- Die HHS-Zusammenfassung der Security Rule
- Die HHS-Hinweise zu Sanktionsrichtlinien
- Die Bloomberg-Berichterstattung
- Anthropics Nutzungsdokumentation
- Orgabot
