Wie eine Mac-App in ein paar Tagen fertig wird

Der erste Commit von Spesenwerk ist vom 15. Oktober 2026. Die App rechnet Verpflegungspauschalen mit 214 Auslandssätzen, liest Beträge per Texterkennung aus Belegfotos und exportiert DATEV-Buchungsstapel. Crestmark hat am selben Tag angefangen, Showpiece einen Tag früher. Hidewell ist mit dem 7. Oktober die älteste der fünf Apps.

Zusammen kommen die Apps auf rund 45.000 Zeilen Code. Getippt haben sie KI-Coding-Agenten. Gesteuert und geprüft hat sie ein Entwickler, der den Brief schreibt, die Diffs liest, die App startet und entscheidet, was rausgeht.

Das klingt nach Wunder oder nach Pfusch. Beides trifft es nicht. Das Tempo kommt aus einer festen Abfolge, die bei jeder App gleich bleibt, und aus Prüfungen, die nach jedem Schritt laufen.

Vier Stationen, jedes Mal gleich

Jede App durchläuft dieselben vier Stationen: Brief, Build, Test, Release. Die Reihenfolge ist langweilig, und genau das ist gewollt. Wer nicht jedes Mal neu überlegen muss, wie gearbeitet wird, kann sich auf das konzentrieren, was die App können soll.

Brief. Am Anfang steht eine schriftliche Beschreibung der App. Sie legt fest, was die App können soll, für wen sie gedacht ist und was ausdrücklich nicht dazugehört. An diesem Text wird später jede Änderung gemessen. Ein unklarer Brief rächt sich im Build, weil die Agenten die Lücken mit eigenen Annahmen füllen.

Build. Die Agenten schreiben den Code in Schritten. Nach jedem Schritt liest der Entwickler den Diff, bevor es weitergeht. Das ist die eigentliche Arbeit an dieser Station, und sie kostet mehr Zeit, als man vermuten würde.

Test. Hier laufen die automatischen Tests und die Selbsttests, die in den Apps selbst stecken. Showpiece kann eine Aufnahme starten, absichtlich abstürzen und sich danach wiederherstellen, alles per Kommandozeile. Crestmark rendert Beispiele, steuert die Zeichenwerkzeuge mit künstlichen Mausereignissen und zeichnet das Editorfenster ohne Bildschirm in eine PNG-Datei. Dazu kommt das Einfachste, die App starten und benutzen.

Release. Ein Skript baut die App und packt sie für den Download. Veröffentlicht ist sie damit noch nicht. Den letzten Klick macht ein Mensch.

Warum die Logik ohne Oberfläche lebt

Die Kernlogik der Apps steckt in Modulen, die keine Oberfläche kennen. Bei Mirrorline ist das ein eigenes Core-Modul. Darin liegen der Scanner, der Abgleich der Verzeichnisbäume, der Inhaltsvergleich, die Filter, der Sync-Planer mit seiner Ausführung, die Snapshots, der Text- und Binärdiff und der CSV-Export. Bei Spesenwerk enthält es Datenmodell, Pauschalen, den TripCalculator, die Buchungsliste für DATEV, die Berichte und die Parser für CSV, EZB-Kurse und Belegtext.

Das hat einen praktischen Grund. Tests für so ein Modul laufen in Sekunden mit einem Befehl:

swift test

Niemand muss dafür ein Fenster öffnen oder klicken. Ein Agent kann die Tests nach jeder Änderung selbst ausführen und sieht eine kaputte Berechnung, bevor sie irgendwer anders sieht. Und wenn die Oberfläche umgebaut wird, bleibt die Rechnung, wo sie war. Eine Änderung an einem Dialog kann die Mahlzeitenkürzung nicht verschieben, ohne dass ein Test rot wird.

Über alle Apps hinweg sind es 108 Testfälle. Für 45.000 Zeilen ist das keine Zahl zum Angeben, und ich will sie auch nicht größer reden. Die Tests sitzen dort, wo Fehler teuer werden. Bei Hidewell prüfen sie Kryptografie, Tresor, Referenzen und den Agenten. Bei Spesenwerk prüfen sie Berechnung, Buchungen, Exporte und Importe. Bei Mirrorline prüfen sie den Kern, der entscheidet, welche Datei wohin kopiert oder gelöscht wird. Eine Oberfläche, die um einen Pixel verrutscht, ärgert. Ein Sync-Planer, der die Richtung vertauscht, kostet Daten.

Was der Entwickler entscheidet

Die Agenten schreiben Code. Was die App tun soll und was sie im Zweifel lieber nicht tut, entscheidet der Entwickler.

Ein Beispiel ist der Umgang mit Löschen. In Mirrorline landen ersetzte und gelöschte Dateien standardmäßig im Papierkorb. Der Plan "Update" löscht nie etwas, und ein Plan von der Kommandozeile wird nur geplant, ausgeführt wird er erst mit einem Klick auf Execute. Das sind keine technischen Notwendigkeiten. Es sind Entscheidungen darüber, welcher Fehler passieren darf und welcher nicht.

Ein anderes Beispiel sind ehrliche Grenzen. Die Produktseite von Hidewell sagt offen, wogegen die App nicht schützt. Solange der Tresor entsperrt ist, kann jedes Programm unter deinem Benutzer Secrets anfragen. Diesen Satz hineinzuschreiben ist eine Entscheidung. Eine Beschreibung, die nur Stärken aufzählt, wäre schneller geschrieben.

Und schließlich entscheidet der Entwickler, was ausgeliefert wird und wann.

Was KI-Agenten falsch machen

Agenten machen Fehler, und zwar andere als Menschen. Einzelfälle erzähle ich hier keine. Es geht um die Arten von Fehlern, auf die wir bei jeder App prüfen.

Plausibel, aber daneben. Code kompiliert, sieht ordentlich aus und löst eine etwas andere Aufgabe als die gestellte. Das fällt beim Lesen des Diffs auf, wenn man ihn neben den Brief legt. Es fällt nicht auf, wenn man nur prüft, ob der Build durchläuft.

Tests, die den Fehler mitbestätigen. Schreibt derselbe Agent Code und Test, können beide auf derselben falschen Annahme beruhen. Der Test ist dann grün und beweist nichts. Deshalb schaut der Entwickler auf die erwarteten Werte in den Tests und vergleicht sie mit der Quelle, bei Steuerregeln also mit dem Regelwerk und nicht mit dem Code.

Fertig gemeldet, nie gesehen. Ein Agent meldet eine Funktion als erledigt, weil der Code dafür existiert. Ob der Knopf im Fenster das tut, was draufsteht, zeigt sich erst, wenn jemand die App startet. Dafür gibt es die Selbsttests, die die echte Oberfläche steuern, und den Entwickler, der die App von Hand benutzt.

Mehr geändert als verlangt. Ein Auftrag betrifft eine Funktion, und der Diff berührt Dateien, die damit nichts zu tun haben. Manchmal ist das nötig, oft nicht. Auch das sieht man nur im Diff.

Keine dieser Prüfungen ist neu. Sie sind das, was gute Code-Reviews schon immer verlangt haben. Neu ist, dass sie fast die ganze Arbeit sind.

Wenn du sehen willst, wie das in der Praxis aussieht, nimm Mirrorline und vergleiche, was die App auf dem Bildschirm macht, mit dem, was dieser Text verspricht. Die kostenlose Demo findest du auf der Mirrorline-Seite, Hinweise zur Installation auf der Support-Seite.