Eine ziemlich große Softwareänderung wurde an einen KI-Agenten delegiert.
Zunächst sah es nach einer Aufgabe von wenigen Minuten aus. Doch auf GitHub kamen weitere Commits, Tests, Integrationsänderungen und Nachbesserungen hinzu. Stunden später wurde echter Code immer noch verändert.
Währenddessen erledigte der Mensch Aufgaben in der realen Welt — bis hin zu einem kompletten Umzug.
Der Umzug war fertig, der Refactor noch nicht.
Das Bild wirkt bereits ziemlich futuristisch.
Noch merkwürdiger: Die Bedienoberfläche war nur ein Smartphone. Die Person, die Anweisungen gibt, muss nicht jedes TypeScript-Modul, jedes CI/CD-Detail oder jede Graph-Learning-Regel selbst beherrschen. Sie kann Ziel, Invarianten, Berechtigungen, verbotene Änderungen und Abschlusskriterien in natürlicher Sprache angeben; der Agent liest das Repository, entwirft, programmiert, ergänzt Tests, öffnet PRs und integriert Änderungen.
Ist das also „Senior Engineer werden mit nur einem Handy“?
Nicht genau. Aber es kommt diesem Bild deutlich näher, als das alte Modell der Softwareentwicklung vermuten ließ.
1. Das Smartphone selbst rechnet nicht auf Senior-Niveau
Das Telefon erzeugt nicht lokal Hunderte Zeilen Production Code. Es ist die Kommandozentrale.
Dahinter stehen KI-Modelle, GitHub, CI, Cloud, Produktionsumgebungen, Suche und Entwicklungstools. Das Smartphone überträgt Absicht und Einschränkungen.
Die präzisere Beschreibung lautet deshalb nicht „Softwareentwicklung auf dem Handy“, sondern:
„entfernte kognitive und rechnerische Ressourcen vom Handy aus orchestrieren.“
Das Rechenzentrum ist nicht in die Hosentasche geschrumpft.
Die Hosentasche hat eine Fernbedienung für Rechenzentrum und Agenten bekommen.
2. Warum diese Arbeit Senior-Niveau hat
Schwierigkeit lässt sich nicht nur in Codezeilen messen.
Eine solche Änderung erfordert Verständnis der bestehenden Architektur, Vermeidung doppelter Mechanismen, Schutz der Produktionspfade, Verständnis der Grenzen zwischen Scheduler/GitHub/CI/Publishing, Einbindung neuer Logik in einen bestehenden zentralen Loop, Datenschutz, korrekten Umgang mit fehlenden Daten, Tests, Trennung von Code- und Infrastrukturfehlern sowie die Entscheidung, was nicht angefasst werden darf.
Das ist nicht nur die Umsetzung eines kleinen Tickets. Es ist Management des Blast Radius einer Änderung in einem lebenden System.
Bei Menschen entspricht das eher einem Senior-Backend- oder Platform-Engineer. Mit Verantwortung für die Gesamtarchitektur nähert sich ein Teil der Entscheidungen Staff-Engineer-Niveau.
Schwierig ist nicht nur, klugen Code zu schreiben.
Schwierig ist zu wissen, wo kluger Code liegen darf, ohne einen Unfall auszulösen.
3. Wie groß war die reale Änderung
In einem anonymisierten Beispiel umfasste der zentrale PR 11 geänderte Dateien, 13 Commits und ungefähr 895 neue Zeilen, dazu einen autonomen Germination-Runtime, Schutz der Article DNA, Behavioral Learning, begrenztes Feedback in die interne Linkoptimierung, Tests und eine eigene CI-Definition.
Nach dem Merge ging die Arbeit weiter. Zusätzliche Gates verhinderten, dass Behavioral Learning den Produktionsgraphen vor Verifikation verändert; fehlende Telemetrie blieb UNKNOWN statt stillschweigend zu Null zu werden.
Das war also kein „895-Zeilen-Job“.
Es war das System verstehen, bevor 895 Zeilen geschrieben werden, und danach einen Käfig bauen, damit diese 895 Zeilen nicht frei herumlaufen.
Codezeilen sind eine schlechte Einheit für Schwierigkeit. Hundert Zeilen können eine Datenbank löschen. Zehntausend können einen ausgesprochen motivierten Taschenrechner ergeben.
4. Wie lange würde ein Mensch brauchen
Für einen guten Entwickler, der das Repository zum ersten Mal sieht, sind grob 5–15 Personentage für denselben Verantwortungsumfang plausibel.
Dazu gehören Lesen von Code und Betriebsregeln, Design, Implementierung, Tests, Diagnose von CI/Infrastruktur, Review und Prüfung der Produktionsauswirkungen.
Das reine Tippen kann schneller sein.
In Produktion kann der Nachweis, nichts kaputt gemacht zu haben, teurer sein als die Änderung selbst.
Die japanische IPA erklärt, dass ohne andere Definition ein Personenmonat mit 160 Personenstunden angesetzt werden kann: 8 Stunden × 20 Tage.[1]
5–15 Personentage entsprechen damit ungefähr 0,25–0,75 Personenmonaten.
5. Was würde ein Mensch kosten
Es gibt keinen universellen Preis. Vertragsform, Verantwortung, Systemkenntnis, Review und Produktionsgarantie verändern die Kosten stark.
Öffentliche Marktpreise geben aber eine Größenordnung.
Levtech nennt für einen freiberuflichen IT-Consultant in Vollzeit an fünf Tagen pro Woche ungefähr 1,0–1,1 Mio. Yen pro Monat, basierend auf Daten von Juli 2025.[2]
Einfach auf 20 Arbeitstage verteilt sind das etwa 50.000–55.000 Yen pro Tag. Für 5–15 Personentage ergibt sich direkte Arbeitszeit von ungefähr 250.000–825.000 Yen.
Ein echter Auftrag kann durch Projektmanagement, Review, Nacharbeit, Garantie, Overhead und Marge höher liegen.
Das ist also kaum als „kleine Aufgabe für ein paar tausend Yen“ zu beschreiben.
Umgekehrt wäre „die KI hat 800.000 Yen verdient“ ebenfalls irreführend. Geschwindigkeit, Parallelität, Fehlerarten, Überwachung und Toolkosten sind anders.
Die nützlichere Aussage lautet: Arbeit, die mehrere Tage oder Wochen hochqualifizierter menschlicher Engineering-Zeit verbrauchen könnte, kann heute von einer Person über ein winziges Gerät gestartet werden.
6. Sind sechs Stunden Agent gleich sechs Stunden Senior Engineer
Nein.
Eine KI macht keine Kaffeepause, wird nicht in Meetings gezogen, verliert keine halbe Stunde an Chat-Benachrichtigungen und starrt nicht an die Decke mit der Frage, wer diese Architektur genehmigt hat.
Sie kann aber sehr schnell in die falsche Richtung laufen, Produktionszustände falsch verstehen, Runner-Ausfälle mit Codefehlern verwechseln, Berechtigungen ausweiten oder „ein Test existiert“ mit „der Test ist tatsächlich erfolgreich gelaufen“ verwechseln.
Deshalb sollte man fertige Änderung, Belege, Verifikation und Production Readback bewerten, nicht nur die Uhr.
„Sechs Stunden und noch aktiv: ausdauernd“ ist okay.
„Sechs Stunden, also sechs Stunden korrektes Engineering“ ist es nicht.
7. Was ist mit Menschen, die nicht alles selbst programmieren können
Die Rolle verändert sich.
Früher musste aus einer Idee oft erst Git, eine Sprache, Frameworks, Deployment und Testing gelernt werden, bevor Software daraus wurde.
KI-Agenten reduzieren diese Implementierungsreibung.
Hochwertige menschliche Arbeit verschiebt sich zu Fragen wie: Was bauen wir? Warum? Was darf nie kaputtgehen? Wie weit dürfen automatische Änderungen gehen? Was zählt als Erfolg? Was muss UNKNOWN bleiben? Wann stoppt ein Fehler das Ganze und wann wird er isoliert?
„Jede Zeile selbst schreiben können“ ist nicht mehr der einzige Eintrittsschein.
Technisches Verständnis bleibt trotzdem wichtig. Je besser Ziele, Risiken, Abhängigkeiten und Verifikation verstanden werden, desto besser sind die Anweisungen.
Man muss keinen Motor bauen können, um Auto zu fahren.
Aber man sollte wissen, was eine rote Ampel bedeutet.
8. Warum „die KI macht das schon“ gefährlich ist
Der gefährlichste Fehler ist nicht der rote Error-Screen.
Es ist falsch zu liegen und dabei erfolgreich auszusehen.
Ein PR kann gemerged sein, ohne Produktion erreicht zu haben; eine CI-Datei kann existieren, ohne dass ein Runner je einen Step startet; nicht verfügbare Daten können zu Null werden; alte und neue Logik können doppelt laufen; „Sicherheit“ kann die ganze Automation abschalten; „Autonomie“ kann Rechte zu weit ausdehnen.
Gute Automation bewegt sich nicht nur weiter.
Sie unterscheidet beim Weiterlaufen Fakten von ungeprüften Zuständen.
9. Wie man vom Smartphone sicherer delegiert
Zuerst das Ergebnis definieren
Nicht nur „ändere diese Datei“, sondern sagen, was am Ende wahr sein muss.
Invarianten festhalten
Bestehende Funktionen, Datenschutz, Bildregeln, Publishing-Pfade und SEO, die nicht kaputtgehen dürfen.
Befugnisse definieren
Darf überschrieben, ein PR geöffnet, gemerged oder Produktion verändert werden?
Aktuellen Zustand zuerst lesen lassen
Current main, echter Runtime und echter Public State sollten alte Gespräche überstimmen.
Verifikation zum Lieferumfang machen
„Code geschrieben“ ist nicht fertig. Tests, CI und Production Readback können dazugehören.
UNKNOWN erlauben
Unbekanntes nicht künstlich in PASS oder FAIL pressen.
Der Handybildschirm ist klein.
Die Verantwortung der Spezifikation ist es nicht.
10. Fazit: Vielleicht ist die alte Eintrittsbarriere kaputtgegangen
Eine Person, die selbst keinen fortgeschrittenen Production Code schreiben kann, kann heute einen KI-Agenten stundenlang vom Smartphone aus steuern und Änderungen mit Senior-Level-Architekturentscheidungen in GitHub integrieren.
Vor wenigen Jahren klang dieser Satz seltsam.
Heute kann er operativ wahr sein.
Das bedeutet nicht, dass Engineers unnötig werden.
Ein Teil des Wertes verschiebt sich von manueller Implementierung zu Architektur, Constraints, Verifikation und Verantwortungsgrenzen.
KI vernichtet Wert nicht.
Sie verändert, wo er liegt.
Und die größte Veränderung ist vielleicht, dass Menschen, die früher bei „technisch kann ich das nicht bauen“ stoppten, eine Frage früher beginnen können:
„Was sollten wir dann bauen?“
Das Smartphone ist weiterhin nur eine Glasplatte.
Aber diese Glasplatte kann zur Fernbedienung für Engineering-Ressourcen auf Senior-Niveau werden.
Ja, die Welt wirkt ein wenig kaputt.
Auf eine ziemlich interessante Art.
Quellen
- IPA, FAQ zur Software Development Data White Paper-Reihe. Standardumrechnung: 1 Personenmonat=160 Personenstunden (8×20) ipa.go.jp
- Levtech, Leitfaden zu Kosten von IT-Beratung, aktualisiert 2026-08-18. Etwa ¥1,0–1,1 Mio./Monat für freiberufliche IT-Berater in Vollzeit, basierend auf Daten von Juli 2025 levtech.jp
