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:

  1. Anforderungserfassung (vorgelagert): Ein speziell entwickelter Prompt erfasste systematisch die Anforderungen des Fachbereichs – Problemstellung, Funktionsanforderungen, technische Rahmenbedingungen.

  2. Spezifikationsdiskussion (50 Minuten): Intensive Abstimmung von Architektur, Datenflüssen, Workflows und UI-Konzept. Erst als alle Aspekte geklärt waren, wurde die Spezifikation finalisiert.

  3. 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#

AspektWert
Codeumfang5700 Zeilen
Dateien29 Python-Dateien
Spezifikationszeit50 Minuten
Implementierungszeitca. 40 Minuten
Hauptiterationen1 + Nachbesserung
Sessions1

Dieser Beitrag ist Teil einer Serie zur Dokumentation methodischer Erkenntnisse aus LLM-gestützten Entwicklungsprojekten.