Die spannende Frage bei KI-Coding ist nicht mehr, ob Entwickler KI verwenden. Die Frage ist, ob daraus produktive Engineering-Arbeit entsteht.
Genau hier setzt der Cognition-Artikel an. Er beschreibt eine Verschiebung, die ich auch in Unternehmen sehe: Vor kurzer Zeit wurde noch gefragt, ob Teams genug KI nutzen. Heute wird gefragt, ob diese Nutzung wirklich Wert erzeugt. Mehr Token, mehr Sessions, mehr generierter Code oder mehr Pull Requests sind noch keine Produktivität.
Das ist ein wichtiger Punkt. KI-Coding kann Arbeit beschleunigen, aber es kann auch Aktivität vortäuschen. Ein Agent kann viele Dateien anfassen und trotzdem am Problem vorbeiarbeiten. Ein Entwickler kann viele Prompts schreiben und trotzdem keine belastbare Lösung erzeugen. Und ein Team kann hohe KI-Nutzung melden, ohne dass sich Durchlaufzeit, Qualität oder Wartbarkeit verbessern.
Das Problem: Aktivität ist nicht Wert
Softwareentwicklung besteht nicht nur aus Codeproduktion. Viel Arbeit liegt in Problemverständnis, Fehleranalyse, Architekturentscheidungen, Abwägungen, Teststrategie, Review, Integration und Betrieb. Genau diese Arbeit ist schwerer zu messen als Zeilen Code, aber sie entscheidet über den Wert.
Deshalb greift Cognition auf eine näherliegende Denkweise zurück: Wie viele produktive Engineering-Stunden wurden tatsächlich ersetzt oder unterstützt? Das ist nicht perfekt, aber es ist deutlich näher an der Wirklichkeit als reine Aktivitätsmetriken.
Für mich folgt daraus eine zweite, noch praktischere Frage: Wie müssen Menschen mit KI-Coding arbeiten, damit solche produktiven Stunden überhaupt entstehen?
Meine These: Der größte Hebel liegt nicht darin, möglichst schnell noch mehr KI-Coding-Tools auszurollen. Der größte Hebel liegt darin, Softwareentwickler in einer sauberen KI-Arbeitsweise zu schulen.
Warum Schulung wichtiger ist als Tool-Nutzung
Viele Unternehmen behandeln KI-Coding noch wie eine neue IDE-Funktion: Tool bereitstellen, Lizenz verteilen, kurze Einführung machen, Nutzung messen. Das reicht nicht.
KI verändert den Entwicklungsprozess. Entwickler schreiben nicht mehr nur Code. Sie formulieren Aufgaben, prüfen Annahmen, begrenzen Kontext, führen Agenten, bewerten Zwischenergebnisse und entscheiden, wann eine KI-Antwort belastbar genug ist. Das ist eine neue Arbeitstechnik.
Wer diese Arbeitstechnik nicht trainiert, bekommt sehr unterschiedliche Ergebnisse. Einige Entwickler werden enorm produktiv, weil sie KI wie einen strukturierten Engineering-Partner einsetzen. Andere bekommen oberflächlichen Code, unklare Diffs, fehlende Tests oder Lösungen, die zwar plausibel aussehen, aber das eigentliche Problem nicht sauber treffen.
Ask, Plan, Code
Ein einfaches Muster, das ich für sehr wirksam halte, ist Ask, Plan, Code. Es klingt banal, verändert aber den gesamten Umgang mit KI-Coding.
Der entscheidende Punkt ist die Reihenfolge. Viele schlechte KI-Coding-Ergebnisse entstehen, weil direkt mit "Code" gestartet wird. Das Modell erzeugt dann eine Lösung, bevor das Problem wirklich verstanden ist. Ask und Plan holen diese Arbeit nach vorne.
Ask: Das Problem zuerst schärfen
Im Ask-Schritt sollte die KI nicht sofort lösen, sondern fragen, strukturieren und widersprechen dürfen. Ein guter Entwickler nutzt diesen Schritt, um Lücken sichtbar zu machen: Was fehlt im Ticket? Welche Annahmen sind riskant? Welche Architekturentscheidung ist implizit? Welche bestehenden Muster im Codebase müssen beachtet werden?
Das ist besonders wichtig in Unternehmenssoftware. Dort ist selten die isolierte Codeänderung das Problem. Entscheidend ist, ob die Änderung in bestehende Prozesse, Berechtigungen, Datenmodelle, Tests, Deployment-Wege und Betriebskonventionen passt.
Wenn dieser Schritt fehlt, misst man am Ende vielleicht viel KI-Aktivität, aber wenig echte Entlastung. Der Mensch muss nachträglich korrigieren, erklären, umbauen oder zurückrollen.
Plan: Kleine Schritte statt großer Sprung
Der Plan-Schritt ist die Qualitätskontrolle vor der Umsetzung. Er zwingt die KI, die Aufgabe in überprüfbare Einheiten zu zerlegen. Ein guter Plan enthält nicht nur "Datei ändern", sondern auch "bestehendes Muster prüfen", "Akzeptanzkriterium abbilden", "Test ergänzen", "Edge Case validieren" und "Diff kontrollieren".
Gerade bei Coding-Agenten ist das entscheidend. Ein Agent kann mehrere Schritte selbst ausführen, aber er braucht eine Richtung. Ohne Plan läuft er Gefahr, aus Zwischenergebnissen immer neue Aktivität abzuleiten. Mit Plan kann man sehen, ob er konvergiert.
Das passt direkt zum Produktivitätsproblem: Wenn ein Unternehmen wissen will, ob KI echte Engineering-Zeit spart, muss die Arbeit nachvollziehbar sein. Ein kleinteiliger Plan macht sichtbar, was die KI übernommen hat und wo der Mensch bewusst eingegriffen hat.
Code: Umsetzung mit Grenzen
Im Code-Schritt darf die KI dann tatsächlich arbeiten. Aber auch hier ist Disziplin nötig. Gute KI-Coding-Arbeit ist inkrementell. Kleine Änderungen, Tests, Diffs, Review. Nicht ein riesiger Patch, der auf den ersten Blick beeindruckt und auf den zweiten Blick Wartungsarbeit erzeugt.
Wichtig sind klare Stop-Regeln. Wenn Kontext fehlt, wenn Tests nicht laufen, wenn Anforderungen widersprüchlich sind oder wenn eine Änderung fachliche Freigabe braucht, muss die KI stoppen und fragen. Autonomie ohne Eskalation ist kein Produktivitätsgewinn, sondern Risiko.
Praktischer Maßstab: KI-Coding ist dann produktiv, wenn der Arbeitsstand überprüfbar besser ist: weniger Unsicherheit, klarerer Plan, getesteter Code, sauberer Diff oder eine gute Entscheidungsvorlage.
Was Unternehmen konkret trainieren sollten
Aus meiner Sicht brauchen Unternehmen ein KI-Coding-Training, das über Prompt-Tipps hinausgeht. Es sollte Entwickler darin schulen, Aufgaben so zu führen, dass KI-Agenten kontrolliert Wert erzeugen.
Produktivität entsteht im Prozess
Der Cognition-Artikel zeigt aus meiner Sicht eine wichtige Reifephase im KI-Coding: Weg von oberflächlicher Nutzungsmessung, hin zu echtem Engineering-Wert. Das ist richtig. Aber die Messung allein löst das Problem nicht.
Wenn Unternehmen KI-Coding produktiv machen wollen, müssen sie den Entwicklungsprozess anpassen. Nicht als große Transformation mit schwerer Methodik, sondern sehr konkret im Alltag: erst Problem klären, dann Plan erzeugen, dann umsetzen. Ask, Plan, Code.
Das ist keine Bremse. Es ist der Weg, wie KI schneller wird, ohne beliebig zu werden. Wer diesen Ablauf beherrscht, kann KI-Agenten viel gezielter einsetzen. Wer ihn nicht beherrscht, wird mehr Output sehen, aber nicht zwingend mehr Wert.
Zusammenfassung
KI-Coding-Produktivität entsteht nicht automatisch durch Tool-Rollout. Sie entsteht, wenn Entwickler lernen, KI als strukturierten Engineering-Partner zu führen. Das bedeutet: Problem diskutieren, Kontext klären, Plan prüfen, Umsetzung begrenzen, Ergebnis testen.
Für Unternehmen ist das eine sehr konkrete Aufgabe. Nicht nur Lizenzen kaufen. Nicht nur Nutzungszahlen reporten. Sondern Softwareentwickler darin schulen, mit KI sauber Softwareentwicklung zu machen.
Ask, Plan, Code ist dafür ein einfacher Einstieg. Erst fragen. Dann planen. Dann coden. In dieser Reihenfolge liegt ein großer Teil der Qualität.