Die Oberfläche ist nur die Spitze. Darunter liegen Regeln, Fristen, Ausnahmen, historische Entscheidungen und das Vertrauen professioneller Nutzer.
Blueprint, keine Kundenreferenz
Dieses Szenario zeigt, wie ein eintägiger Agentic Engineering Hackathon im Feld Steuer-, Kanzlei- und Business-Software aussehen kann. Es beschreibt keinen durchgeführten Kundenauftrag und behauptet keine erzielten Kennzahlen. Der Blueprint übersetzt typische Branchenbedingungen in einen realistischen, sicheren Build Day.
Die stärkste Besetzung verbindet Software Engineering, Tax- oder Accounting-Fachlichkeit, Product, Support, Quality und Governance. Diese Rollen betrachten denselben Workflow aus unterschiedlichen Richtungen: tatsächlicher Nutzerbedarf, technische Machbarkeit, Datenlage, Risiko und Anschlussfähigkeit. Der Hackathon verdichtet diese Perspektiven auf eine überprüfbare Demo.
Der operative Engpass
Business-Software bildet langlebige Regeln und anspruchsvolle Ausnahmen ab. Änderungen müssen fachlich korrekt, technisch kompatibel und für Nutzer erklärbar sein. Gleichzeitig bremsen gewachsene Codebasen, verteilte Dokumentation und komplexe Supportfälle die Weiterentwicklung.
Coding Agents können Regel- und Codekontext verbinden, Testfälle vorbereiten, Supportinformationen strukturieren und begrenzte Modernisierungsschritte unterstützen. Der Wert entsteht nur, wenn Quellen und Annahmen sichtbar bleiben und fachliche Freigabe nicht durch Modellplausibilität ersetzt wird.
DATEV veröffentlicht Forschung und Praxis zur Nutzung von KI in Softwareentwicklung und Qualität. Das zeigt die Relevanz des Feldes bei einem anspruchsvollen deutschen Softwareanbieter; der Blueprint beschreibt ausdrücklich kein ALL-IN-AGI-Projekt bei DATEV. [1]
Fünf geeignete Challenges
Eine gute Challenge besitzt einen konkreten Nutzer, einen begrenzten Eingang, einen sichtbaren Ablauf und eine Demo, die am selben Tag geprüft werden kann. Sie versucht nicht, einen gesamten Kernprozess zu automatisieren. Sie beantwortet eine relevante Machbarkeitsfrage.
Die folgenden Beispiele sind Startpunkte für das Challenge Design. Im Sponsor Call werden sie an vorhandene Systeme, strategische Prioritäten und die Fähigkeiten der Teilnehmenden angepasst.
- Ein Regel-Navigator über freigegebene Fachinformationen mit Quellen, Gültigkeitsstand und offenen Fragen.
- Ein Supportfall-zu-Testfall-Workflow, der einen anonymisierten Nutzerfall technisch reproduzierbar macht.
- Ein Legacy-Modul-Explorer, der fachliche Abhängigkeiten und vorhandene Tests für eine kleine Änderung darstellt.
- Ein Migrations-Prototyp für eine klar begrenzte Schnittstelle mit Regressionstests und Review-Notiz.
- Ein Onboarding-Assistent, der neue Engineers durch System, Domänenbegriffe und erste sichere Aufgabe führt.
Daten und Security werden vorbereitet
Synthetische Mandanten, fiktive Belege, anonymisierte Supportfälle und klar datierte Regelausschnitte schaffen einen realistischen, aber sicheren Arbeitsraum. Für den Prototype reicht häufig ein begrenzter, repräsentativer Ausschnitt. Entscheidend ist nicht Datenmenge, sondern ob die Beispiele den Nutzerfluss und die schwierigen Ausnahmen glaubwürdig abbilden.
Personenbezogene Finanz- und Mandantendaten bleiben ausgeschlossen; Ergebnisse markieren Quellen, Gültigkeitsstände und jede Stelle, die fachliche Prüfung verlangt. Der Event umgeht keine Freigabe. Er macht den erlaubten Pfad praktisch nutzbar und dokumentiert offen, welche Annahmen, Simulationen und menschlichen Entscheidungen im Prototype stecken.
So läuft der Build Day
Vor dem Termin wählen Sponsor und Challenge Owner drei bis acht Aufgaben aus. Ein Setup-Check prüft Accounts, Geräte, Repositories, Beispielinformationen und Startbefehle. Am Morgen erhalten die Teams einen kurzen Tool-Impuls und schneiden danach Nutzerfluss, Eingaben und Demo-Ziel endgültig zu.
Mindestens siebzig Prozent des Tages wird gebaut. Facilitator helfen bei Scope, Agenten-Workflow und Blockaden; Fachpersonen validieren Annahmen. Am Nachmittag stabilisieren die Teams den wichtigsten Pfad und zeigen beim Demo Day Funktion, Grenzen, verwendete Daten und einen sinnvollen nächsten Schritt.
Was nach einem Tag belastbar ist
Nach einem Tag lässt sich beurteilen, ob ein eng geschnittener Wissens- oder Engineering-Workflow schneller und nachvollziehbarer wird, ohne fachliche Verantwortung zu verschieben. Belastbar bedeutet dabei nicht produktionsreif. Ein guter Prototype belegt einen Nutzerfluss, macht technischen und organisatorischen Aufwand sichtbar und erlaubt eine bessere Entscheidung über Weiterarbeit.
Jedes Ergebnis wird mit Funktionsstand, Nutzenhypothese, Risiken, Tool-Reibung und einem nächsten Eigentümer festgehalten. So wird aus dem Branchen-Blueprint keine Show, sondern ein kleiner Activation Pilot, der Capability und konkrete Chancen gleichzeitig sichtbar macht.
Für Steuer-, Kanzlei- und Business-Software ist auch ein negatives Ergebnis wertvoll. Wenn Quellen nicht verlässlich verbunden werden können, eine Ausnahme zu viel Domänenurteil verlangt oder die Integration den Nutzen übersteigt, weiß der Sponsor das nach einem begrenzten Versuch statt nach einem langen Projekt.
Weitergeführt wird nur, was einen erkennbaren Nutzerwert, einen verantwortlichen Owner und einen realistischen technischen Pfad besitzt. Alles andere bleibt dokumentiertes Lernen. Diese Konsequenz schützt das Unternehmen davor, einen überzeugenden Demo-Moment mit einer belastbaren Produktentscheidung zu verwechseln.