An meiner selbst gebauten Uhr habe ich ungefähr vier Jahre gearbeitet. Immer wieder abends, neben dem Beruf. Ein schwarzer Punkt auf dem E-Ink-Display, eine leuchtende LED, ein funktionierender Sensor: Das waren kleine Erfolge, über die ich mich sehr gefreut habe.

Vor Kurzem habe ich den über Jahre gewachsenen Quellcode einem KI-Agenten gegeben. Die Aufgabe: nach Fehlern und Problemen suchen. Nach ungefähr einer halben Minute lag eine Liste mit rund 15 Punkten vor. Beim Nachprüfen musste ich zugeben: Da waren berechtigte Funde dabei. Einige Stellen hatte ich tatsächlich unsauber programmiert.

Das war beeindruckend. Und ein bisschen ernüchternd.

Ich komme aus der IT und arbeite heute im Finanzbereich mit Reporting und Data Analytics. Seit ich ChatGPT zum ersten Mal ausprobiert habe, beschäftige ich mich intensiv mit den Möglichkeiten von KI. Trotzdem haben mich meine eigenen Projekte noch einmal anders überrascht als jede Produktvorführung.

Ich wollte herausfinden, was KI schon kann. Dabei habe ich neu verstanden, wofür ich meine eigene Erfahrung brauche.

Drei Projekte, die meine Erwartungen verändert haben

Mein erstes größeres Experiment hieß „Before We AI“. Ich wollte prüfen, ob Daten für eine bestimmte Analyse überhaupt geeignet sind: Sind die Begriffe klar? Passen die Tabellen zusammen? Fehlen Informationen, ohne die eine Antwort nur geraten wäre?

Meine Idee war ein möglichst deterministisches Regelwerk. Erst die Voraussetzungen prüfen, dann die KI arbeiten lassen. Auch wenn KI beim Erkennen von Beziehungen zwischen Tabellen half, sollten feste Regeln das Ergebnis validieren.

Bei meinen Vergleichen entstand allerdings kein klarer Sieger. Sowohl die Regeln als auch die direkte KI-Analyse übersahen Fehler und erkannten vieles richtig. Das Regelwerk erforderte außerdem zahlreiche manuelle Bestätigungen. Ich hatte unterschätzt, wie gut eine KI mit ausreichendem Kontext auch Zusammenhänge und Prüfbedingungen erkennen konnte.

Das waren begrenzte eigene Versuche. Für mich reichten sie aber, um das Projekt zunächst zurückzustellen und meine Annahmen zu hinterfragen.

Danach entstand „Have I Been Here?“. Die Android-App schaut anhand der Ortsinformationen meiner Fotos nach, ob ich irgendwo schon einmal gewesen bin. Einen ersten Stand hatte ich mit Claude Code innerhalb von zwei Tagen gebaut. Dabei lernte ich viel über Kotlin, Android, Benutzeroberflächen, Tests und die Veröffentlichung einer App.

Dann kam Tirol.

Ich nutze Komoot seit vielen Jahren gern. Auf einer Wanderung war plötzlich meine geplante Route weg, und ohne Empfang konnte ich nicht neu planen. Da dachte ich: Kann ich mit KI-Unterstützung eine App bauen, die solche Situationen so löst, wie ich es mir wünsche?

So entstand OnPath. Bereits im Urlaub konnte ich damit wandern und die Navigation ausprobieren. Zu Hause kamen weitere Funktionen und die Vorbereitung für andere Nutzer dazu. Inzwischen läuft ein erster Test über Google Play.

Die Umsetzung war oft leichter als die Entscheidung, was richtig ist

Überrascht hat mich, wie viel Unterstützung über das Schreiben einzelner Funktionen hinaus möglich war. Die KI schlug eine Architektur vor, berücksichtigte Sonderfälle und fand Lösungen, auf die ich selbst nicht gekommen wäre.

Ein Beispiel ist BRouter, die offene Software für die Routenberechnung. OnPath nutzt sie auf dem Handy. Auch die Browserplanung baut auf derselben Routing-Grundlage auf. Ich musste dafür kein zweites Routingsystem entwerfen.

Als ich später einen 3D-Flug entlang einer geplanten Strecke wollte, war eine erste funktionierende Umsetzung nach ungefähr einer halben Stunde da. Früher hätte ich allein für die Einarbeitung deutlich länger gebraucht.

Die Benutzeroberfläche war dagegen eine hartnäckige Aufgabe. Wann ist ein Knopf verständlich? Was darf sich während der Navigation verändern? Wie verhindert man versehentliche Eingaben in der Tasche? Dass eine Funktion technisch läuft, beantwortet diese Fragen noch nicht.

Auch mein Arbeitsablauf veränderte sich. Anfangs ließ ich einzelne Codeabschnitte in einer Entwicklungsumgebung schreiben. Später gab ich einem Agenten größere Aufgaben im Terminal. Schließlich arbeiteten mehrere Agenten an App, Browserplaner, Website und Marketing, koordiniert über GitHub.

Das fühlte sich zeitweise an wie ein eigenes Entwicklerteam. Ich konnte große Änderungen beauftragen und gleichzeitig an kleinen Details arbeiten. Während der Wanderungen sprach ich Beobachtungen ins Handy. Später ließ ich eine neue Version bauen und installierte sie über die Update-Funktion der Test-App.

Zwischen einer Idee unterwegs und einer ausprobierbaren Änderung lagen manchmal nur wenige Minuten.

Kann das jetzt jeder?

Ich muss immer weniger selbst programmieren – und immer genauer verstehen, was ich eigentlich bauen will.

Ich musste wissen, was ich erreichen wollte. Anforderungen formulieren, Architekturvorschläge beurteilen, Widersprüche erkennen und Ergebnisse testen. Manchmal musste ich einen Ansatz stoppen, weil sich der Agent in einer Lösung verrannte, die am eigentlichen Problem vorbeiging.

Besonders anspruchsvoll war die richtige Detailtiefe: genug Vorgaben, damit das Ergebnis passt, und genug Freiraum, damit bessere Vorschläge entstehen können.

Dafür brauchte ich Fachwissen, IT-Erfahrung, Vorstellungsvermögen und Durchhaltevermögen. Ich musste allerdings längst nicht mehr jeden technischen Umsetzungsschritt selbst kennen.

Auch meine anspruchsvollsten Architekturdiskussionen führte ich teilweise mit einer KI. Dafür musste ich ihr meine Anforderungen, Begriffe und bisherigen Entscheidungen zur Verfügung stellen. Je besser dieser Kontext war, desto hilfreicher wurde das Gespräch.

Für mich gehört das zur menschlichen Seite des „Harness“: dem Rahmen, in dem ein Agent arbeitet. Dazu zählen neben Werkzeugen und Tests auch klare Ziele, zugängliche Dokumentation und jemand, der aufpasst, wenn die Arbeit langsam vom Ziel abdriftet.

Was das für Finance und Analytics bedeuten könnte

 

Diese Erfahrung beschäftigt mich auch beruflich.

Eine Analyse kann technisch funktionieren und trotzdem fachlich falsch sein. Ein Begriff kann in zwei Bereichen etwas anderes bedeuten. Eine Tabelle kann vollständig aussehen und trotzdem die falsche Grundgesamtheit enthalten. Bei Buchungen, Forecasts oder Intercompany-Abstimmungen haben solche Unterschiede Folgen.

Menschen machen ebenfalls Fehler, wenn sie Anforderungen beschreiben oder Software entwickeln. Deshalb überzeugt mich die pauschale Gegenüberstellung von fehlerhafter KI und verlässlicher menschlicher Arbeit nicht. Mich interessiert, wie sich die Ergebnisse prüfen lassen und welche Kontrollen tatsächlich greifen.

Ich erwarte, dass Fachbereiche wesentlich mehr selbst gestalten können: Analysen, individuelle Auswertungen und irgendwann auch klar begrenzte agentische Abläufe. Bei Entscheidungen und Buchungen gehören Berechtigungen, Freigaben und nachvollziehbare Prüfungen von Anfang an dazu.

Meine Aufmerksamkeit verschiebt sich deshalb. Ich beschäftige mich stärker damit, welche Daten und Regeln gebraucht werden, wie Zusammenhänge beschrieben sind und woran sich ein korrektes Ergebnis erkennen lässt. Die technische Umsetzung ist weiterhin wichtig. Sie bindet aber weniger meiner eigenen Arbeit als früher.

Die Kosten sinken. Das Erfolgserlebnis verändert sich.

Für die intensive Entwicklungsphase von OnPath lagen meine zusätzlichen KI-Abo-Ausgaben ungefähr bei 300 bis 400 Euro. Das sind keine vollständigen Projektkosten: Meine Zeit, Erfahrung, vorhandene Hardware und die verwendeten Open-Source-Projekte gehören ebenfalls dazu. Betrieb und Wartung stehen weiterhin an.

Trotzdem hat sich für mich die Schwelle deutlich gesenkt, eine größere Idee tatsächlich auszuprobieren.

Das hat auch eine persönliche Kehrseite. Wenn ich früher nach vielen Versuchen einen Fehler fand und mein Programm endlich lief, war ich stolz. Heute warte ich manchmal ein paar Minuten, prüfe das Ergebnis, hake die Aufgabe ab und gehe zur nächsten.

Ich kann heute viel mehr bauen. Ob es mich auch zufriedener macht, ist eine andere Frage.

Ich möchte deshalb meine Neugier behalten und bewusst Aufgaben suchen, an denen ich selbst weiterlerne. Meine Freude an Softwareentwicklung ist noch da. Sie verändert sich gerade, und ich weiß noch nicht genau, wohin.

OnPath ist für mich damit eine nützliche App und zugleich ein sehr praktischer Lernprozess geworden. Diese Erfahrungen möchte ich auch in meine Arbeit mit Finance, Analytics und KI einbringen.

Wer gern wandert oder Rad fährt und ein Android-Handy hat, kann sich auf onpath.earth einen Eindruck verschaffen und für den Test melden. Zum Projekt gehört für mich auch der Weg vom eigenen Versuch über eingeladene Tester bis zu einer öffentlich verfügbaren App.

OnPath soll kostenlos nutzbar bleiben. Für zusätzliche, optionale Online-Dienste könnte ich mir später einen fairen Kostenbeitrag vorstellen, aus dem auch etwas für Spenden weitergegeben werden kann. KI und Server verbrauchen Ressourcen; auch deshalb möchte ich bewusst mit ihrem Einsatz umgehen. Über das genaue Modell ist noch nicht entschieden.

Wenn aus diesem Experiment eine hilfreiche App entsteht, ich dabei weiterlerne und sich später auch etwas an andere zurückgeben lässt, wäre das für mich ein guter Grund, weiterzumachen.