Ich habe den Swift-Code nie gelesen

Im Frühling 2026 bin ich aus Versehen Maintainer eines Swift-Open-Source-Projekts geworden. Mit über 5.000 Sternen. Ich kann kein Swift. Ich habe den Code nie gelesen. (Na gut, manchmal schaue ich kurz drauf.)

Das Projekt heißt apfel, ein Kommandozeilen-Tool, das mit dem Apple-Intelligence-Modell spricht, das auf jedem modernen Mac mit macOS Tahoe sowieso schon drauf ist. Ein paar Leute haben mich gefragt, wie das funktioniert. Also hier der kurze Meta-Gedanke.

Wer den Code geschrieben hat

apfel ist in Swift gebaut. Ich habe mir nie die Mühe gemacht, Swift zu lernen. Den Code hat Opus 4.6 geschrieben, dann Opus 4.7, und Codex (damals 5.5) hat Review und Refactoring gemacht. Das waren die Modelle im Mai 2026. AI First, durchgehend.

Und es ist nicht nur das eine CLI. Rundherum gibt es einen kleinen Baum an Tools, darunter einen SwiftUI-Chat-Client mit Spracheingabe und Sprachausgabe. Gleiches Prinzip. Diesen Code habe ich auch nicht gelesen.

Wie hält das überhaupt zusammen?

Das ist die Frage, die ich am öftesten höre. Meine Antwort hat drei Teile.

1. TDD

Test-driven Development. Tests zuerst. Die Tests prüfen Verhalten, nicht Implementierung. Wenn die Tests grün sind, funktioniert das Ding für die Fälle, die mir wichtig sind.

Ich muss nicht wissen, wie das Swift es macht. Ich muss wissen, was es macht. Und das sagen die Tests.

2. Spezifikationen

apfel implementiert eine OpenAI-kompatible HTTP-API. Es läuft als lokaler Server auf localhost:11434, du kannst es also überall einsetzen, wo deine Tools OpenAI erwarten.

Diese Spezifikation gibt es. Ich musste sie nicht erfinden. Es gibt öffentliche Konformitätstests, ich kann sie laufen lassen, und wenn sie grün sind, verhält sich mein Server so, wie die Spezifikation es verlangt. Jemand anderer hat schon aufgeschrieben, was “korrekt” heißt. Ich prüfe nur dagegen.

3. Qualitätsschleifen, immer wieder

Jeder PR lässt die ganze Testsuite laufen.
Jedes Release verwende ich selbst (Dogfooding).
Jedes gemeldete Issue beginnt mit einem fehlschlagenden Test, den die KI dann grün machen muss.

Ein Bug-Report ist kein Grund, Code zu lesen. Er ist ein Grund, einen Test zu schreiben, der fehlschlägt, und den dann der KI zu geben.

Die interessante Frage

Die interessante Frage bei KI-gebautem Open Source ist nicht “hat eine KI den Code geschrieben”.

Die interessante Frage ist “haben die Tests die Regression erwischt”.

Wenn ja, ist die Programmiersprache ein Detail.

Der Haken

Aber … hier ist der Haken: Ein Open-Source-Projekt zu haben ist echte Arbeit, auch wenn der Code automatisiert entsteht.

Denn die Entscheidungen, die Verantwortung, liegen am Ende immer noch bei mir. Leute melden Issues. Leute verlassen sich auf das Binary. Leute bauen Produkte darauf. Dieser Teil wird nicht wegautomatisiert.

Er verschiebt sich nur. Von “wo setze ich den Strichpunkt” zu “ist das das richtige nächste Verhalten, das wir einbauen”.

Das ist jetzt der Job. Entscheiden, was das Ding tun soll, aufschreiben, wie man es prüft, und für das Ergebnis geradestehen, wenn sich jemand darauf verlässt.

Wohin das geht

Ich glaube, so wird in zwei Jahren ein großer Teil von Open Source aussehen. Wir werden sehen.

Wenn du dir anschauen willst, wie das aufgesetzt ist: Das Repo ist öffentlich, github.com/Arthur-Ficial/apfel. Gratis. MIT.