Software entsteht heute um ein Vielfaches schneller, geprüft wird sie gleich langsam wie vorher.

Vor zwei Jahren hat eine neue Funktion in einer bestehenden Anwendung bei uns typischerweise zwei bis drei Tage gebraucht: lesen, was schon da ist, schreiben, testen, prüfen, ausliefern. Heute liegt derselbe Umfang oft am selben Nachmittag vor. Das ist keine Zahl aus einem Produktvideo, sondern unsere eigene Zeitmessung. Trotzdem sind unsere Projekte nicht dreimal schneller fertig und das hat einen einfachen Grund: Schneller geworden ist ein Teil der Arbeit und es war nicht der Teil, der am längsten gedauert hat.

Schneller geworden ist der Teil, den man tippt und der war nie der teuerste.

Am deutlichsten ist der Gewinn bei vier Dingen: beim ersten Entwurf einer Funktion, bei den Tests, beim Umbau von Datenformaten und bei der Dokumentation. Dazu kommt etwas, das selten erwähnt wird und im Alltag am meisten bringt: das Einlesen in fremden Code. Ein Repository, das man nicht kennt, bedeutete früher ein bis zwei Tage Orientierung, bevor man die erste Zeile guten Gewissens ändern konnte. Heute stellt man Fragen und bekommt Antworten mit Verweis auf die Stelle, an der es steht.

Für einen Entwurf, der früher einen Arbeitstag gekostet hat, rechnen wir heute mit ungefähr einer Stunde plus der Zeit zum Prüfen. Dafür bezahlen wir rund USD 100 pro Monat und Person, was bei diesem Verhältnis nach dem ersten Arbeitstag im Monat verdient ist. Wir nennen die Zahl, weil sie ehrlicher ist als jedes Adjektiv und weil sie erklärt, warum wir bei diesem Teil der Arbeit gar nicht erst diskutieren.

Gleich langsam geblieben ist alles, wo jemand verstehen, entscheiden oder verantworten muss.

Die andere Hälfte eines Projekts hat sich kaum bewegt. Herauszufinden, was überhaupt gelöst sein muss, dauert genau gleich lang wie vorher, weil dafür Leute reden müssen, die den Betrieb kennen. Ein Entscheid, der beim Kunden fällt, braucht weiterhin die Sitzung, in der er fällt und oft noch die zweite. Die Entscheide, die man später nicht mehr billig ändern kann, brauchen nach wie vor jemanden, der sie bewusst trifft und aufschreibt.

Und dann ist da das Lesen. Ein Mensch liest und versteht Code ungefähr gleich schnell wie vor fünf Jahren, unabhängig davon, wer ihn geschrieben hat. Dasselbe gilt für die Abnahme durch die Fachabteilung, für die Migration echter Daten und für den Abend, an dem etwas produktiv geht. Kein Werkzeug hat diese Stunden verkürzt und keines wird es so bald tun, weil sie nicht aus Tippen bestehen, sondern aus Verantwortung.

Dazu kommt alles, was ausserhalb des eigenen Teams liegt. Ein Zugang beim Hoster, eine Schnittstelle beim Treuhänder, eine Freigabe beim Anbieter der bestehenden Software: Diese Wartezeiten sind seit der KI nicht kürzer geworden und in vielen KMU Projekten machen sie mehr aus als die eigentliche Entwicklung.

Der Engpass ist nicht verschwunden, er ist ans Ende der Kette gerutscht.

Wenn ein Glied einer Kette dreimal schneller wird und der Rest nicht, wird die Kette nicht dreimal schneller. Es bildet sich eine Schlange vor dem langsamsten Schritt und dieser Schritt heisst heute Prüfung: lesen, verstehen, vergleichen mit dem, was gefordert war. Wer vorne dreimal so viel produziert, muss hinten dreimal so viel prüfen können, sonst wächst am Ende nur der Stapel.

Genau hier trennen sich zwei Wege. Der eine baut die Prüfung aus, schneidet Änderungen kleiner und plant die Zeit dafür ein. Der andere lässt sie weg, weil das Ergebnis ja läuft. Der zweite Weg ist Vibe Coding und sein Preis wird nicht beim Schreiben fällig, sondern Monate später bei jemandem, der das Ergebnis nicht lesen kann. Ein Fehler, den jemand beim Prüfen findet, kostet Minuten. Derselbe Fehler im Betrieb kostet einen Abend, im schlechteren Fall den Arbeitstag von Leuten, die mit Entwicklung nichts zu tun haben.

In kleinen Teams zeigt sich das sofort. Wo eine Person schreibt und eine zweite prüft, ist die zweite ab dem Moment der Engpass, in dem die erste mit einem Werkzeug arbeitet. Wer dann die Prüfung nicht als eigene Arbeit einplant, hat sie in der Praxis abgeschafft, ohne es je entschieden zu haben.

Praktisch heisst das bei uns, dass eine Änderung so geschnitten wird, dass eine Person sie in zwanzig Minuten lesen kann. Und für alles, wo ein Fehler mehr kostet als Zeit, gilt ohnehin unsere Regel dazu, was ein Agent unbeaufsichtigt tun darf und was nicht.

Für ein KMU heisst das, dass die Offerte günstiger wird und die Verantwortung nicht.

Wer 2026 eine Offerte für eine eigene Anwendung einholt, sieht den Unterschied am Preis. Eine App, für die wir vor zwei Jahren mit 10'000 bis 30'000 Franken gerechnet haben, hat heute im unteren Bereich Luft, weil der Teil, der Code produziert, weniger Stunden braucht. Was nicht weniger wird, sind die Stunden für Anforderungen, Abnahme, Betrieb und Wartung. Wenn eine Offerte gegenüber früher um die Hälfte gefallen ist, lohnt sich deshalb die Frage, welcher dieser Posten gestrichen wurde.

Zwei Fragen bringen im Gespräch mit einem Anbieter am meisten:

• Wer liest den Code, bevor er produktiv geht und ist diese Person in der Offerte eingerechnet.
• Was passiert in zwei Jahren, wenn etwas geändert werden muss und niemand mehr weiss, warum es so gebaut wurde.

Beides sind keine Fragen an die Technik, sondern an den Vertrag. Sie gelten genauso, wenn die Antwort am Ende gar keine eigene Entwicklung ist, sondern ein fertiges Produkt.

Das ist der eigentliche Unterschied zu vor zwei Jahren: Die Frage ist nicht mehr, ob etwas gebaut werden kann, sondern ob am Ende jemand versteht, was gebaut wurde und dafür geradesteht. Diese Frage beantwortet kein Werkzeug, die beantwortet eine Person mit Namen.