Drei Tage Entwicklungsarbeit? Nein. Zwei Stunden mit Sokrates.

Es gibt in der Softwareentwicklung einen besonderen Moment. Den Moment, in dem man auf ein Projekt blickt, das eigentlich noch gar nicht existiert, und dennoch bereits die ersten Architekturdiagramme, Klassen, Schnittstellen und Teststrategien vor sich sieht. Früher begann an dieser Stelle eine mehrtägige Reise durch Dokumentationen, StackOverflow-Beiträge, Tutorials und eine nicht unerhebliche Menge Kaffee.

Diesmal dauerte es ungefähr zwei Stunden.

Der Auslöser war eine scheinbar einfache Frage: Lässt sich aus Reisefotos automatisch ein Blogbeitrag erzeugen?

Aus dieser Frage entstand innerhalb kürzester Zeit ein vollständiges Python-Projekt mit Bildanalyse, Provider-Abstraktion, automatisierten Tests, GitHub-Integration, CI-Pipeline, Qualitätsprüfungen und einer ersten OpenAI-Anbindung. Während ich noch darüber nachdachte, welche Ordnerstruktur wohl sinnvoll wäre, hatte Sokrates bereits eine vorgeschlagen.

„Das ging ungewöhnlich schnell“, bemerkte ich.

Der Bildschirm flackerte kurz und Sokrates erschien.

„Die Alternative wäre gewesen, drei Tage lang dieselben Entscheidungen erneut zu treffen, die bereits tausendfach getroffen wurden.“

Ein schwer widerlegbares Argument.

Interessanterweise war die eigentliche Bildanalyse dabei nicht die größte technische Herausforderung. Die größere Frage lautete: Wie entwickelt man so etwas, ohne später von den Betriebskosten überrascht zu werden?

Sobald OpenAI ins Spiel kommt, taucht nämlich eine neue organisatorische Rolle auf. Nicht Entwickler. Nicht Anwender. Sondern Controller.

Jedes Bild erzeugt Token. Jede Beschreibung erzeugt Token. Jede spätere Story erzeugt weitere Token. Plötzlich beginnt man nicht mehr nur in Klassen und Methoden zu denken, sondern auch in Verbrauchseinheiten.

Genau deshalb entstand früh im Projekt ein Umschalter zwischen lokaler und echter OpenAI-Nutzung. Die Anwendung kann vollständig mit Mock-Daten laufen, ohne einen einzigen API-Aufruf zu erzeugen. Erst wenn die Umgebungsvariable aktiviert wird, spricht das System tatsächlich mit OpenAI.

„Misstraust du der KI?“, fragte Briemma.

„Nein.“

„Den Kosten?“

„Ja.“

Damit war die Diskussion beendet.

Die erste Kostenanalyse fiel überraschend unspektakulär aus. Selbst bei mehreren Bildanalysen pro Tag und automatisierter Story-Erzeugung bewegen sich die erwarteten Kosten aktuell eher im Bereich weniger Euro pro Monat als in dramatischen Cloud-Rechnungen. Trotzdem entstand daraus eine wichtige Projektentscheidung: Jede kostenpflichtige Funktion muss jederzeit abschaltbar bleiben.

Denn Softwareprojekte haben die bemerkenswerte Eigenschaft, zunächst klein zu wirken und später Gewohnheiten zu werden.

Noch spannender wurde die Sicherheitsbetrachtung. Reisebilder enthalten oft deutlich mehr Informationen als man zunächst glaubt. Ortsangaben, Metadaten, Zeitstempel und manchmal sogar personenbezogene Informationen reisen unbemerkt mit. Deshalb wurde von Beginn an darauf geachtet, dass die Bildverarbeitung kontrolliert erfolgt und die eigentliche OpenAI-Nutzung über klar definierte Provider gekapselt bleibt.

Technisch betrachtet war das eine Architekturentscheidung.

Organisatorisch betrachtet war es Risikomanagement.

Der eigentliche Überraschungsmoment lag jedoch an anderer Stelle. Nicht in den Kosten. Nicht in der Sicherheit. Sondern in der Geschwindigkeit.

Was früher ein kleines Wochenendprojekt gewesen wäre, entstand an einem Abend. Nicht weil die Arbeit verschwunden wäre. Sondern weil ein großer Teil der mechanischen Entwicklungsarbeit inzwischen delegierbar geworden ist. Tests schreiben, Interfaces definieren, Konfigurationen ergänzen, Fehler analysieren, GitHub-Pipelines reparieren – all das passiert heute in einem Dialog.

Natürlich verschwinden die Entscheidungen dadurch nicht. Im Gegenteil. Die eigentliche Arbeit verschiebt sich von der Implementierung zur Bewertung.

Welche Architektur ist sinnvoll?

Welcher Provider soll austauschbar bleiben?

Welche Risiken entstehen?

Welche Kosten sind akzeptabel?

Die Tastaturarbeit wird weniger. Die Verantwortung nicht.

Als der letzte GitHub-Workflow schließlich grün wurde, erschien Sokrates noch einmal auf dem Bildschirm.

„Projektstatus?“

„Build erfolgreich. Tests erfolgreich. Pipeline erfolgreich.“

„Ausgezeichnet.“

„Und jetzt?“

„Jetzt beginnt der Teil, den früher niemand automatisieren konnte.“

„Welcher?“

„Herauszufinden, was du als Nächstes bauen möchtest.“

Manchmal sind die schwierigsten Probleme erstaunlich resistent gegen künstliche Intelligenz.