LLM-Coding-Experiment: Personalkostenkalkulator mit hybrider Architektur#
Ausgangslage#
Eine Anfrage aus einem Fachbereich der Humboldt-Universität Berlin stellte die Frage: Lässt sich ein Tool zur Personalkostenkalkulation für Drittmittelprojekte mit LLM-Unterstützung umsetzen? Die Herausforderung: Präzise Berechnungen nach TV-L-Tarif bei gleichzeitiger natürlichsprachlicher Bedienung – zwei Anforderungen, die sich mit LLMs traditionell schlecht verbinden lassen.
Das Experiment sollte erkunden, ob und wie sich exakte Berechnungen mit der Flexibilität natürlicher Spracheingabe kombinieren lassen.
Das Tool#
Der Personalkostenkalkulator ermöglicht die Eingabe von Projektanforderungen in natürlicher Sprache:
“Wir brauchen 2 Doktoranden E13/2 auf 67% und einen PostDoc E14/4, Laufzeit April 2026 bis März 2029”
Das System extrahiert automatisch die relevanten Parameter (Entgeltgruppen, Stufen, Stellenanteile, Zeiträume), führt die Kalkulation nach TV-L durch und liefert eine strukturierte Kostenübersicht mit Jahresscheiben. Bei unvollständigen Angaben stellt das System gezielt Rückfragen. Ein Excel-Export ermöglicht die direkte Verwendung in Drittmittelanträgen.
Architekturentscheidung#
Die zentrale Erkenntnis der Spezifikationsphase: LLMs und präzise Berechnungen erfordern eine strikte Trennung. Die gewählte Architektur:
LLM-Komponente: Ausschließlich für die Parameterextraktion aus natürlicher Sprache und die Generierung von Rückfragen. Das LLM liefert strukturierte JSON-Daten, führt aber keine Berechnungen durch.
Deterministische Komponente: Sämtliche Kalkulationen erfolgen ohne LLM-Beteiligung mit Python-Decimal für exakte Genauigkeit. Entgelttabellen, Zuwendungssätze und Arbeitgeberanteile sind statisch konfiguriert.
State-Machine: Steuert den Dialogfluss zwischen Parsing, Rückfragen, Berechnung und Fallback.
Fallback-Mechanismus: Nach drei fehlgeschlagenen Parse-Versuchen wird ein manuelles Eingabeformular eingeblendet – von Anfang an eingeplant, da die Zuverlässigkeit der LLM-Extraktion nicht garantiert werden konnte.
Entwicklungsprozess#
Der Prozess folgte einem klaren Ablauf:
Anforderungserfassung (vorgelagert): Ein speziell entwickelter Prompt erfasste systematisch die Anforderungen des Fachbereichs – Problemstellung, Funktionsanforderungen, technische Rahmenbedingungen.
Spezifikationsdiskussion (50 Minuten): Intensive Abstimmung von Architektur, Datenflüssen, Workflows und UI-Konzept. Erst als alle Aspekte geklärt waren, wurde die Spezifikation finalisiert.
Umsetzung (ca. 40 Minuten): Das LLM generierte 5700 Zeilen Code in 29 Python-Dateien in einer Runde. Eine Nachbesserung war erforderlich.
Die Gesamtdauer von unter zwei Stunden für ein funktionsfähiges Tool dieser Komplexität war nur durch die gründliche Vorarbeit möglich.
Methodische Erkenntnisse#
Spezifikation vor Implementation: Die Qualität der Spezifikation bestimmte den Erfolg. Architektur, Datenflüsse, Workflows und UI müssen vollständig geklärt sein, bevor Code generiert wird. Der Fokus auf Architektur verhinderte Overengineering.
Hybride Architektur als Pattern: Nicht alles muss vom LLM erledigt werden. Klassische Programmiertechniken bleiben für viele Aufgaben überlegen – das LLM dient als intelligente Schnittstelle zwischen Nutzer und robustem Code. Dieses Pattern eignet sich für alle Anwendungen, die präzise Berechnungen mit flexibler Eingabe verbinden müssen.
Robustheit einplanen: Der Fallback-Mechanismus war keine nachträgliche Ergänzung, sondern von Beginn an Teil des Konzepts. Bei ungewisser LLM-Zuverlässigkeit sind alternative Eingabewege erforderlich.
JSON-Extraktion als Schnittstelle: Die strukturierte Ausgabe des LLM als JSON mit anschließender Pydantic-Validierung erwies sich als robuste Brücke zwischen natürlichsprachlicher Eingabe und typsicherer Verarbeitung.
Aktueller Stand#
Das Tool befindet sich in der Evaluationsphase und funktioniert nach bisherigen Tests wie geplant. Die Frage, ob LLMs und exakte Berechnungen zusammenpassen, lässt sich differenziert beantworten: Ja – wenn die Architektur die Stärken beider Welten gezielt kombiniert.
Metriken#
| Aspekt | Wert |
|---|---|
| Codeumfang | 5700 Zeilen |
| Dateien | 29 Python-Dateien |
| Spezifikationszeit | 50 Minuten |
| Implementierungszeit | ca. 40 Minuten |
| Hauptiterationen | 1 + Nachbesserung |
| Sessions | 1 |
Dieser Beitrag ist Teil einer Serie zur Dokumentation methodischer Erkenntnisse aus LLM-gestützten Entwicklungsprojekten.