1000 Issues, 6 Produkte, ein halbes Jahr

Vor ein paar Tagen ist in meinem eigenen Werkzeug ein unscheinbarer Zähler auf eine runde Zahl gesprungen: das tausendste Issue. Angelegt habe ich das erste am 24. Januar 2026. Heute, gut ein halbes Jahr später, steht der Zähler bei tausend – und ich will kurz innehalten, bevor die nächsten kommen.

Runde Zahlen sind für sich genommen belanglos. Interessant ist, was dahintersteht. Also habe ich mir angeschaut, was diese tausend Einträge eigentlich bewegt haben. Die ehrliche Antwort hat mich selbst überrascht.

Der Ausgangspunkt

Ich arbeite gern strukturiert, aber ich hasse Struktur, die sich selbst zum Zweck wird. Über Jahre hatte ich das Gefühl, dass zwischen „Idee" und „läuft in Produktion" zu viele Stationen liegen: Tickets, die niemand liest, Boards, die niemand pflegt, Kontext, der zwischen Werkzeugen verloren geht. Mein Leitgedanke war simpel – ich nenne ihn für mich das Kigil-Prinzip: Der Weg von Idee über Umsetzung bis zum Deployment soll so kurz, klar und nachvollziehbar wie möglich sein.

Aus diesem Gedanken ist zuerst das Werkzeug entstanden, mit dem ich seither alles andere baue. Und dann sind mit diesem Werkzeug sechs Produkte entstanden – nicht als Prototypen, die in einer Schublade verschwinden, sondern als Systeme, die heute produktiv laufen und die ich (oder andere) täglich nutzen.

Das Werkzeug: Agira

Agira ist ein pragmatisches Projekt-, Change- und Arbeitsmanagement-System für die Softwareentwicklung. Kein Multi-Tenant-Monster, sondern bewusst schlank, mit drei Schwerpunkten: Nachvollziehbarkeit, Integration und KI-Unterstützung. Jede Idee wird zu einem Issue, jedes Issue trägt seinen Kontext, jede Entscheidung bleibt auffindbar. GitHub, E-Mail, ein Vektor-Index für Kontext, eine Reporting-Schicht – alles hängt an derselben zentralen Arbeitseinheit.

Das eigentlich Neue daran ist eine Warteschlange, in die ich Issues geben kann, die dann weitgehend autonom umgesetzt werden: Ein Lauf legt einen Branch an, öffnet einen Pull Request, arbeitet die Aufgabe im Repository ab und schreibt am Ende sauber zusammen, was er getan und warum er sich so entschieden hat. Ich bleibe der, der entscheidet, prüft und mergt – aber die mechanische Arbeit dazwischen erledigt das System.

Genau diese Schleife ist der Grund, warum aus einer Person in einem halben Jahr sechs Produkte werden konnten.

Agira hat sich mit Agira gebaut

Die schönste Pointe steckt schon im allerersten Ausschlag der Statistik. Bevor Agira irgendetwas aufzeichnen konnte, musste ein winziger Kern von Hand entstehen: Projekt, Issue, „an GitHub senden". Mehr nicht. Sobald diese Minimalschleife lief – Mitte Januar –, habe ich Agira ab da mit Agira weitergebaut. Jede weitere Funktion kam als Issue ins eigene System, wanderte nach GitHub und wurde umgesetzt. Der Peak in den ersten Wochen ist genau das: ein Werkzeug, das sich an den eigenen Bootstraps aus dem Sumpf zieht.

Zwei Dinge daran finde ich bemerkenswert.

Erstens: Das Tool hat sich mit sich selbst entwickelt. Der einzige Teil, der nicht durch Agira entstanden ist, ist der kleine Keim, der Agira überhaupt erst aufzeichnungsfähig gemacht hat. Von Issue #1 an baute es sich selbst weiter – ein Compiler, der sich selbst kompiliert.

Zweitens, und das ist mir fast wichtiger: Ich habe die Basisprozesse nicht in einer Sandbox mit Fake-Issues evaluiert und gehärtet, sondern im Produktivbetrieb, an echten Aufgaben. Jede Rauheit im Ablauf zeigte sich sofort an realer Arbeit, nicht an einer Attrappe. Das ist der Unterschied zwischen „getestet" und „erprobt" – ein Prozess, der so entsteht, ist am Tag seiner „Fertigstellung" bereits kampferprobt. Genau deshalb hat das Fundament so früh getragen.

Die Zahlen, die etwas bedeuten

Ich bin kein Freund von Vanity-Metriken, deshalb nur die, die wirklich etwas aussagen.

Die Issue-Nummern laufen bis zur Tausend – so weit ist der Zähler in gut sechs Monaten gekommen. Tatsächlich umgesetzt wurden davon rund 890 Items; die Differenz von etwa 110 sind verworfene Issues – und die sind kein Ausschuss, sondern einer der unterschätzten Gewinne. Sie wurden in Agira ganz normal bearbeitet, und erst im Verlauf zeigte sich, dass sie unsinnig, nicht zu Ende gedacht oder längst anderweitig gelöst waren. Keines davon ging je in eine KI-Umsetzung. Anders gesagt: Der Prozess – und in den meisten Fällen die KI – hat mich rechtzeitig vor Arbeit bewahrt, die umsonst gewesen wäre. Der größte Wert war hier manchmal, etwas nicht zu bauen. Von den 890 sind heute nur 21 offen, alles andere ist abgeschlossen: eine Abschlussquote von 98 %, und keine Schönung, denn ein Issue gilt erst als erledigt, wenn die Änderung tatsächlich in Produktion ist. Über 191 Tage sind das im Schnitt knapp fünf erledigte Items pro Tag.

Am meisten sagt aber der Median der Cycle-Time: 0,3 Tage. Die Hälfte aller Items ist am selben oder nächsten Tag durch – von der Idee bis zum Abschluss. Das ist das Kigil-Prinzip nicht als Anspruch, sondern als Messwert.

Das Entscheidende dabei: Umgesetzt wurde praktisch alles autonom. Ich habe in diesem halben Jahr kaum eine Zeile selbst getippt – meine Rolle war entscheiden, prüfen, mergen. Anfangs lief das über GitHub Copilot mit einer eigenen Anbindung, seit Anfang Juli fast ausschließlich über Claude Code. Nur die neuere Strecke hängt an einer Warteschlange, die mitzählt; die frühere Phase lief genauso autonom, nur ohne Zähler. Wenn also eine Kennzahl „15 % über die Claude-Queue" sagt, ist das nicht der Grad der Autonomie, sondern nur der sauber messbare Teil davon – der Rest ist nicht weniger autonom entstanden, bloß früher und mit anderem Werkzeug.

Was mich beim Nachrechnen am meisten gefreut hat, ist die Effizienz dieser Läufe. Von den automatisiert bearbeiteten Aufgaben ist praktisch keine im Sinne von „Geld verbrannt, nichts geliefert" gescheitert – es gab genau einen echten Fehlläufer. Die Kosten pro autonom umgesetztem Pull Request liegen in einer Größenordnung, die ich vor einem Jahr nicht für realistisch gehalten hätte: erstaunlich niedrig für vollständige, geprüfte Codeänderungen, und den ganz überwiegenden Teil erledigt das günstigere Modell, nicht das teuerste. Für die wenigen wirklich anspruchsvollen Aufgaben darf es dann mehr sein – aber das ist die Ausnahme, nicht die Regel.

Die interessante Erkenntnis dahinter: Nicht die Modellwahl treibt die Kosten, sondern schlicht die Menge und Tiefe der Arbeit. Und das ist genau richtig so – man bezahlt für Ergebnis, nicht für Verschwendung.

Was tatsächlich entstanden ist

Sechs Produkte, alle heute im produktiven Einsatz, alle in diesem Zeitraum von Grund auf neu gebaut. Bewusst ganz unterschiedliche Domänen – das ist mir wichtig, weil es zeigt, dass die Methode trägt, nicht nur ein Glückstreffer war.

Agira – das Werkzeug selbst. Es baut sich inzwischen zu einem guten Teil mit sich selbst weiter, und dieser Artikel ist ein direktes Nebenprodukt davon.

GIS ERP v4.0 – Immo-Edition – eine modulare Vermietungs- und Verwaltungsplattform für beliebige Mietobjekte: Immobilien ebenso wie bewegliche Güter – Gebäude, Büros, Räume, Container, Stellplätze, Lagerflächen, Equipment. Mit Verträgen, Verfügbarkeiten, Dokumenten und einem wachsenden Finanz- und Reporting-Teil.

TradingControlCenter – eine Schaltzentrale fürs Trading: Signale von TradingView per Webhook, Anbindung an Broker und Konten, Echtzeit-Kurse und Alarme, gebündelt in einem Dashboard. Aus vielen verstreuten Einzelquellen wird ein Ort, an dem man den Überblick behält.

Zenico – eine Plattform für Projekt-, Aufgaben- und Meilensteinverwaltung mit einem sauberen Organisationsmodell (Teams, Projekte, Aufgaben, Sichtbarkeiten). Dort, wo Agira mein Entwickler-Werkzeug ist, ist Zenico das Werkzeug für die Arbeit drumherum.

MoneyPlan – eine schlanke Finanzplanungs-App für den Einzelnutzer: Kategorien, Buchungen, Serienbuchungen, Zeiterfassung. Selbst gehostet, ohne Cloud-Abhängigkeit, im ruhigen Dark-Look.

PropScope – der Ausreißer im schönsten Sinn: ein Analyse-Tool für den Amateurfunk. Es wertet WSJT-X-Logs aus, erkennt CQ-Rufe, berechnet Entfernungen über Maidenhead-Locator und macht Bandöffnungen und Ausbreitungsbedingungen sichtbar. Ein Hobby, das plötzlich sein eigenes Werkzeug bekam – weil es eben ging.

Ein ERP, ein Trading-System, eine Projektplattform, eine Finanz-App, ein Funk-Analyzer und das Werkzeug, das sie alle hervorgebracht hat. Diese Bandbreite ist für mich der eigentliche Beweis.

Vom „Läuft es überhaupt?" zum „Ist es stimmig?"

Am deutlichsten merke ich die Reife an den Fragen, die ich mir heute stelle. Vor einem halben Jahr ging es um das Existenzielle: Hält die Integration? Bleibt nichts liegen? Funktioniert die Kernschleife von Idee bis Pull Request überhaupt?

Heute rede ich mit dem System über die Schriftgrößen im UI, über eine einheitliche Hintergrundfarbe, über die Frage, ob eine Kostenkennzahl plausibel ist – und ob das Verhältnis von Aufwand und Nutzen stimmt. Solche Fragen stellt man sich erst, wenn das Fundament nicht mehr zur Debatte steht. Man poliert und hinterfragt nur, was einen ohnehin trägt.

Bezeichnend fand ich einen Moment aus dieser Woche: Ich konnte das System dazu bringen, seine eigene Automatik kritisch zu prüfen – die Kosten aus dem eigenen Verlauf herauszuziehen, ihre Plausibilität zu hinterfragen und sogar einen Lauf zu entlarven, der einen makellosen Abschlussbericht geschrieben, aber keine einzige Zeile Code geliefert hatte. Ein MVP kann das nicht; ihm fehlt die Selbstauskunft. Dass Agira das kann, ist selbst schon ein Reifezeichen.

Was ich mitnehme

Vier Dinge.

Erstens: Nachvollziehbarkeit ist kein Bürokratie-Aufschlag, sondern ein Beschleuniger. Weil jede Idee, jede Entscheidung und jeder Change an einem Ort mit Kontext liegt, konnte ich zwischen sechs völlig verschiedenen Domänen wechseln, ohne den Faden zu verlieren.

Zweitens: KI-Unterstützung entfaltet ihren Wert nicht als Gimmick, sondern als verlässlicher Teil der Arbeitsschleife – als Assistenz, nicht als Gatekeeper. Ich entscheide und prüfe weiterhin selbst; die mechanische Strecke dazwischen ist einfach kürzer geworden.

Drittens: Kurze Wege sind eine Entscheidung, keine Glückssache. Das Kigil-Prinzip klingt banal, aber es diszipliniert jede Designfrage: Macht das den Weg von Idee zu Produktion kürzer und klarer – oder länger?

Viertens: Der unterschätzte Nutzen von KI ist nicht nur, Arbeit zu erledigen, sondern Arbeit zu verhindern. Ein spürbarer Teil meiner Ideen hat sich beim Durchdenken mit dem System als überflüssig erwiesen – als unsinnig, unausgegoren oder längst gelöst –, bevor auch nur eine Zeile Code dafür entstand. Was nie gebaut werden musste, taucht in keiner Erfolgsstatistik auf, ist aber vielleicht der ehrlichste Effizienzgewinn von allen.

Tausend Issues sind kein Ziel, sondern ein Wegpunkt. Aber es ist ein guter Moment, kurz stehenzubleiben und festzustellen: Das Ding hat den Sprung von „gebaut" zu „verlässlich" geschafft. Und das nächste tausend beginnt schon.