Sodala: Ein Projektbrowser für Entwickler und Projektmanager

Wie aus einer abendlichen KI-Spielerei ein internes Werkzeug wurde – gebaut von jemandem, der keine Zeile C++ schreibt

Ein Ticket liegt im Jira des einen Kunden, das nächste im System des anderen, das dritte in unserem eigenen. Wer hat kommentiert? Was hat sich seit gestern an der Priorität geändert? Wo war ich stehen geblieben? Als Entwickler jongliert man da schon mit einer Handvoll Browser-Tabs. Für unsere Projektmanager-Kollegen, die die Aufgaben mehrerer Entwickler im Blick behalten müssen, wird daraus ein Vollzeitjob.

Unser Kollege Martin wollte sich damit nicht abfinden und hat sich ein eigenes Werkzeug gebaut: Sodala – einen spezialisierten Browser, der Jira-Tickets aus mehreren Systemen zusammenführt. Bemerkenswert ist dabei nicht nur die App. Martin ist bei uns für Frontend und Templates verantwortlich; eine vollständige eigene Anwendung zu bauen, war für ihn Neuland, Backend-Architektur und native Desktop-Entwicklung erst recht. Trotzdem läuft Sodala heute als native C++-Anwendung – und wird bei uns täglich benutzt.

Was Sodala kann

Tickets werden übersichtlich aufgelistet und dargestellt, bei Bedarf aus mehreren Jira-Instanzen gleichzeitig. Ändert sich etwas, gibt es eine Desktop-Benachrichtigung. Dazu kommen etliche Produktivitäts-Features, die im Alltag den Unterschied machen:

• Filter, Sortierung und verschiedene Sichten – die eigenen Tickets, die des Teams, die eines Projekts.
• Ticket-Tabs – parallel geöffnete Vorgänge, ohne dass man den Überblick verliert.
• Anbindung an die Zeiterfassung – gebuchte Zeit landet dort, wo sie hingehört, ohne Systemwechsel.
• Claude-Integration – Rückfragen zu einem Ticket direkt aus dem Kontext heraus.
• Notizblock – für all das, was in kein Ticketfeld passt.

1.0: Die Fingerübung

Angefangen hat alles im August 2025 als Übungsprojekt in React, abends, nebenher – Martins erste eigene Anwendung überhaupt. Die Daten von Jira abzurufen und in einer hübsch formatierten Liste anzuzeigen, war schnell erledigt. Dann setzte der übliche Feature Creep ein: Filtern und Sortieren, To-do-Liste, Ticket-Tabs, Benachrichtigungen, unterschiedliche Sichten. Der Rahmen einer beiläufigen Fingerübung war bald gesprengt – und Kundenprojekte haben nun mal Vorrang.

2.0: „Claude, mach mal …”

Wenn man die Weiterentwicklung an eine KI abgeben kann, sieht die Rechnung anders aus. Vibe Coding war damals noch recht neu, und hier bot sich eine gute Gelegenheit, es auszuprobieren: „Mach aus meinem Code eine Electron-App, baue Desktop-Benachrichtigungen ein, kümmere dich um die Tab-Verwaltung.”

Das Ergebnis war eine praktisch brauchbare App – bis zu dem Punkt, an dem der wachsende Umfang an die Grenzen der Wartbarkeit stieß. Die unstrukturierte Vorgeschichte und die aus spontanen Ideen entstandenen Erweiterungen hatten einen gordischen Code-Knoten erzeugt. Jeder Bugfix produzierte zwei neue Probleme.

Das ist die Erkenntnis, die viele gerade selbst machen: Nicht das Modell ist der Engpass, sondern die Struktur, in der es arbeitet. Ohne Plan vorher und Prüfung hinterher entsteht Code, den niemand mehr anfassen will – die KI selbst am allerwenigsten.

3.0: Nochmal von vorne, diesmal mit Struktur

Version 1 war konventionell von Hand entwickelt. Die Erweiterungen für Version 2 entstanden mit KI-Hilfe, aber der Code wurde noch kontrolliert und überarbeitet. Für Version 3 bot sich eine native App an, auf Basis von C++, CEF (Chromium Embedded Framework) und Qt – ein Stack, mit dem Martin vorher nie gearbeitet hatte.

Dafür stand inzwischen Etzala zur Verfügung, unser Kanban Command Center für KI-gestützte Entwicklung, zusammen mit einem mittlerweile sehr ausgefeilten Bündel an Skills. Die perfekte Gelegenheit für ein Experiment mit einer klaren Frage: Kann jemand, der beruflich Templates und Frontends baut, eine komplexe, produktiv einsetzbare native App liefern – wenn er den Code weder schreibt noch liest, sondern ausschließlich die Rolle des Projektmanagers einnimmt?

Der Ablauf war für den Rewrite wie für jedes spätere Feature derselbe:

• Vor der Implementierung wurde über die entsprechenden Skills mehrstufig geplant und geprüft: Brainstorming, Product Owner, Impact Analysis.
• Nach der Implementierung folgten systematische Tests und ein unabhängiges Code Review durch einen separaten Agenten.
• Die menschliche Entscheidung blieb an den Übergängen: Ist die Spezifikation wirklich das, was gewünscht war? Ist das Review-Ergebnis akzeptabel? Geht das Feature so live?

Das Experiment ist aufgegangen: Nicht der fehlende C++-Hintergrund war der begrenzende Faktor, sondern die Frage, wie sauber jede Änderung vorher spezifiziert und hinterher geprüft wurde. Aus dem gewucherten Bastelprojekt wurde eine Codebasis, die sich seither ohne neue Verhedderungen erweitern und warten lässt – und die deshalb um viele weitere nützliche Features gewachsen ist.

Was wir für Kundenprojekte mitnehmen

Sodala ist ein internes Werkzeug, aber die Erkenntnisse fließen direkt in unsere Arbeit an individuellen Softwareprojekten ein:

• Struktur schlägt Modell. Der Unterschied zwischen Version 2 und Version 3 war nicht die KI, sondern der Prozess drumherum. Mehrstufige Planung und unabhängige Reviews sind das, was aus einem beeindruckenden Prototypen wartbare Software macht.
• Der Stack ist nicht mehr die erste Hürde. Dass eine native C++-Anwendung aus einem Frontend-Arbeitsplatz heraus entsteht, wäre vor zwei Jahren undenkbar gewesen. Mit dem passenden Workflow wird der Einstieg in eine unbekannte Technologie machbar – vorausgesetzt, man plant und prüft dafür umso sorgfältiger.
• Die Rolle verschiebt sich. Weniger Zeile-für-Zeile-Umsetzung, mehr Anforderungsklärung, Priorisierung und Abnahme. Für uns ist das kein Verlust, sondern genau die Arbeit, die Projekte erfolgreich macht.
• Und die Grenze bleibt. Kundenprojekte setzen wir bewusst nicht so um. Wir müssen und wollen für Qualität und Sicherheit garantieren können, und Verantwortung für Code übernimmt man nur guten Gewissens, wenn kompetente Entwickler ihn geprüft und verstanden haben. KI ist ein wichtiges Werkzeug geworden – die Verantwortung delegiert sie nicht mit.

Fazit

Sodala war ein doppeltes Experiment: technisch, was KI-gestützte Entwicklung heute leisten kann, und persönlich, weil man dabei die Perspektive wechselt – weniger Entwickler, mehr Product Owner. In gut einem Jahr und über drei Versionen ist daraus ein reifes, nützliches internes Werkzeug geworden, das den Arbeitsalltag spürbar erleichtert. Und der Nebeneffekt gefällt uns fast am besten: Eine gute Idee scheitert bei uns nicht mehr daran, dass sie im falschen Stack liegt.

Wer wissen will, wie unsere Skills und der Workflow drumherum funktionieren: Wir haben das in den Beiträgen zu Etzala und zu GitLab CLI, Claude Code und unserem VS-Code-Plugin im Detail beschrieben. Und wenn ihr KI-gestützte Workflows in eurer eigenen Entwicklung etablieren wollt oder eine individuelle Softwarelösung braucht – meldet euch gerne bei uns.