Zeiterfassung selbst programmieren mit AI: Ein Risiko?
von Alexander Huber
Zeiterfassung selbst programmieren war lange ein Thema für Spezialfälle. Seit moderne AI Coding Tools, Coding Agents und agentische Workflows in kurzer Zeit produktnahe Prototypen erzeugen können, wirkt Eigenentwicklung wieder deutlich attraktiver. GitHub hat im Februar 2026 seinen Coding Agent um Modellauswahl, Self Review, eingebaute Security Scans und CLI Handoff erweitert (GitHub Blog). OpenAI beschreibt seit März 2026 eine Arbeitsweise, bei der Entwickler mehrere Coding Agents parallel steuern und länger laufende Aufgaben delegieren (OpenAI). Und GitHub zeigt seit Februar 2026 mit Agentic Workflows, wie Agents selbst in automatisierten Repository-Prozessen mit Guardrails eingesetzt werden (GitHub Blog).
Genau deshalb liegt die Frage nahe, ob man eine Zeiterfassung heute nicht einfach selbst bauen sollte. Für einen ersten Prototyp funktioniert das oft erstaunlich gut. Die eigentliche Managementfrage lautet aber nicht, ob man eine Zeiterfassung mit AI bauen kann. Die Frage ist, ob man sie auch verlässlich, sicher, pflegbar und wirtschaftlich sinnvoll betreiben will.
AI senkt die Hürde für einen überzeugenden Prototyp deutlich. Sie senkt aber nicht automatisch die Hürde für Governance, Wartbarkeit, Compliance und langfristigen Betrieb.
Warum Zeiterfassung selbst programmieren gerade wieder attraktiv wirkt
Der aktuelle AI-Schub ist nicht nur ein neues User Interface für Code Completion. In den letzten Monaten hat sich sichtbar verschoben, was Teams an Agents delegieren. GitHub zeigt mit Agentic Workflows, dass Agents inzwischen wiederkehrende Repository-Aufgaben wie Triage, Dokumentation und Code-Quality-Prüfungen in automatisierten Abläufen übernehmen können (GitHub Blog). Parallel beschreibt GitHub für seinen Coding Agent Self Review, Security-Scans und CLI Handoff als Teil des aktuellen Produktstands (GitHub Blog). OpenAI spricht von einer Zusammenarbeit mit mehreren Agents über länger laufende Aufgaben hinweg (OpenAI). Anthropic skizziert in seinem aktuellen Agentic Coding Report für 2026 ebenfalls einen Trend zu länger laufenden, zusammenhängenden Entwicklungsaufgaben mit menschlichen Kontrollpunkten (Anthropic).
Aus Managementsicht ist das relevant, weil damit aus einem Spielzeug für Demos ein plausibles Werkzeug für interne Software geworden ist. Die Hürde für Eigenentwicklung sinkt deutlich. Genau das macht die Diskussion spannender: Was vor Kurzem noch wie ein überambitioniertes Nebenprojekt gewirkt hätte, erscheint heute als realistische Option für Fachabteilungen und IT-Teams.
Warum Zeiterfassung komplexer ist, als viele annehmen
Viele unterschätzen Zeiterfassung, weil der sichtbare Teil simpel wirkt: Benutzer anlegen, Projekte anlegen, Stunden erfassen, Berichte anzeigen. In der Praxis hängt daran aber deutlich mehr. Sobald ein System in reale Arbeitsabläufe eingreift, wird es schnell Teil der operativen Infrastruktur und nicht bloß eine elegante Eingabemaske.
Die folgende Übersicht zeigt die Bereiche, die bei einer Eigenentwicklung schnell nach “Details” aussehen, im Produktivbetrieb aber oft über Kosten, Akzeptanz und Risiko entscheiden.
| Bereich | Warum er im Produktivbetrieb relevant wird |
|---|---|
| Arbeitszeit und Verfügbarkeit | Zeiten müssen vollständig, plausibel und für den Alltag der Mitarbeitenden nutzbar sein. |
| Projektabrechnung und Nachkalkulation | Fehlerhafte Buchungen wirken direkt auf Margen, Rechnungen und Steuerung. |
| Abwesenheiten und Stellvertretungen | Urlaub, Krankenstand und Vertretungsregeln dürfen nicht neben dem System herlaufen. |
| Rollen, Berechtigungen und Freigaben | Nicht jeder darf alles sehen, ändern oder freigeben. |
| Korrekturen, Historie und Nachvollziehbarkeit | Buchungen müssen änderbar sein, ohne dass die Historie verloren geht. |
| Schnittstellen zu HR, Buchhaltung oder Projekttools | Der Nutzen steht und fällt oft mit stabilen Integrationen. |
Hinzu kommt, dass Arbeitszeiterfassung in Europa nicht nur eine Komfortfrage ist. Der Europäische Gerichtshof hat am 14. Mai 2019 festgehalten, dass Mitgliedstaaten Arbeitgeber zu einem objektiven, verlässlichen und zugänglichen System zur Erfassung der täglichen Arbeitszeit verpflichten können (Curia). Auch wenn die konkrete Ausgestaltung national unterschiedlich ist, zeigt das sehr klar: Bei Zeiterfassung geht es nicht nur um Eingabemasken, sondern um Verlässlichkeit und Nachvollziehbarkeit.
Der Prototyp ist selten das Problem
Mit AI lässt sich heute schnell ein erster Stand bauen. Genau darin liegt aber auch das Risiko. Eine gute Demo erzeugt leicht den Eindruck, das Thema sei im Wesentlichen gelöst. In Wirklichkeit verschiebt sich die Diskussion nach dem Prototypen erst von der Oberfläche in den Betrieb.
Dann geht es plötzlich nicht mehr darum, ob sich Stunden buchen lassen, sondern ob das System im Alltag zuverlässig geführt, abgesichert und weiterentwickelt werden kann. Typische Fragen tauchen oft erst im zweiten Schritt auf, und sie sind erstaunlich selten spektakulär. Gerade diese unscheinbaren Punkte entscheiden später darüber, ob das System trägt oder zur Dauerbaustelle wird:
- Wer darf welche Buchungen sehen, freigeben oder ändern?
- Wie läuft das Onboarding neuer Mitarbeitender oder externer Partner ab?
- Wie funktioniert sauberes Offboarding, und wer stellt sicher, dass verwaiste Benutzer rechtzeitig gesperrt oder deaktiviert werden?
- Wie werden Feiertage, Teilzeitmodelle oder Sonderregeln abgebildet?
- Wie werden Buchungen korrigiert, ohne Historie zu verlieren?
- Welche Daten müssen für Auswertung, Abrechnung und Projektsteuerung konsistent bleiben?
Keine dieser Fragen klingt nach Innovation. Genau das ist der Punkt. In produktiven Systemen entstehen Risiken oft nicht durch spektakuläre Architekturfehler, sondern durch vergessene Benutzer, zu breite Rechte, unklare Zuständigkeiten oder unsaubere Korrekturprozesse.
Genau an dieser Stelle lohnt sich auch die Brücke zu unserem Beitrag über IT-Sicherheit bei Time Cockpit. Dort wird sehr deutlich, warum Identitäten, Rollen, Offboarding und nachvollziehbare Zugriffe keine Nebensache sind, sondern Teil eines belastbaren Betriebsmodells. Ein vergessener Account, zu breite Rechte oder unklare Zuständigkeiten klingen banal, sind in produktiven Systemen aber genau die Art von Fehlern, die später Sicherheits- und Compliance-Probleme auslösen.
Hinzu kommt ein Punkt, der bei AI-getriebenen Prototypen besonders leicht unterschätzt wird: Software will auch nach dem Go-live gewartet werden. Abhängigkeiten altern, Sicherheitsupdates müssen eingespielt werden, Frameworks ändern sich, Anforderungen aus HR, Projektcontrolling oder Buchhaltung entwickeln sich weiter. Damit landet man schnell bei derselben Grundfrage wie in unserem Artikel zu Make or Buy bei Zeiterfassungssystemen: Will man wirklich nicht nur die erste Version bauen, sondern auch Pflege, Weiterentwicklung, Betrieb und personelle Abhängigkeiten langfristig selbst tragen?
Spätestens an diesem Punkt wird aus einem internen Tool schrittweise ein eigenes Produkt, inklusive Betrieb, Support, Weiterentwicklung und technischem Risiko. Genau hier kippt die Diskussion von “Das konnten wir schon bauen” zu “Wollen wir dieses System auch dauerhaft verantworten?”.
AI-Code beschleunigt, ersetzt aber keine Governance
Gerade weil AI Coding in den letzten Monaten so schnell gereift ist, wird Governance wichtiger, nicht unwichtiger. GitHub führt für seinen Coding Agent inzwischen eingebaute Security Checks an und begründet das sehr direkt: AI-generierter Code kann verwundbare Muster, Geheimnisse oder abhängige Pakete mit bekannten Schwachstellen schneller erzeugen, als Teams sie bemerken (GitHub Blog).
Hinzu kommen neue Fragen rund um Daten und Nachvollziehbarkeit. GitHub hat am 25. März 2026 angekündigt, dass Interaktionsdaten aus Copilot Free, Pro und Pro+ ab dem 24. April 2026 für Training und Verbesserung von Modellen genutzt werden, sofern Nutzer nicht widersprechen (GitHub Blog). Für Business und Enterprise gilt das laut GitHub nicht. Der Punkt ist nicht, dass man AI deshalb nicht nutzen sollte. Der Punkt ist, dass Teams bei produktionsnaher Entwicklung sehr bewusst über Daten, Richtlinien und Toolwahl entscheiden müssen.
Auch unabhängig vom aktuellen Marktzyklus bleibt sichere Softwareentwicklung ein Prozess, nicht nur eine Schreibaufgabe. Das Secure Software Development Framework von NIST betont genau diese Disziplin aus Anforderungen, Reviews, Tests und laufender Verbesserung (NIST). OWASP warnt im GenAI-Kontext zusätzlich vor Overreliance, also davor, Ausgaben von Modellen ohne ausreichende Kontrolle zu übernehmen (OWASP).
Wer Zeiterfassung mit AI entwickelt, entscheidet nicht nur über Codegeschwindigkeit. Man entscheidet zugleich über Review-Prozesse, Datenrichtlinien, Verantwortlichkeiten und den Sicherheitsstandard des späteren Betriebs.
Wann Eigenentwicklung sinnvoll sein kann
Trotzdem wäre es falsch, aus all dem abzuleiten, dass man Zeiterfassung niemals selbst entwickeln sollte. Ein interner Ansatz kann sinnvoll sein, wenn ein sehr enger Sonderfall abgebildet werden muss, wenn ein vorhandenes System gezielt erweitert wird oder wenn ein klar begrenztes Tool für einen abgegrenzten internen Prozess ausreicht.
Die entscheidende Frage ist aber, ob wirklich eine komplette Zeiterfassung gebaut werden soll oder eher eine spezifische Erweiterung, Integration oder Automatisierung. Genau hier sehen wir in vielen IT-Dienstleistungsunternehmen den pragmatischeren Weg: keinen kompletten Neubau, sondern eine anpassbare Standardlösung, die die schwierigen Grundlagen bereits mitbringt und trotzdem Raum für individuelle Prozesse lässt.
Was das für IT-Dienstleister praktisch bedeutet
Wer Projektgeschäft sauber steuern will, braucht mehr als eine schöne Eingabemaske. Entscheidend sind konsistente Daten, stabile Prozesse und belastbare Auswertungen. Sonst wird aus Zeiterfassung schnell ein Thema für Nacharbeit, Rückfragen und Diskussionen über Datenqualität.
Aus unserer Sicht hat sich für viele Teams eine klare Aufgabenteilung bewährt:
- AI für Ideen, Prototypen und schnelle Prozessentwürfe
- Standardsoftware für den belastbaren Kern
- Anpassungen dort, wo das eigene Geschäft wirklich besonders ist
Diese Trennung ist weder besonders glamourös noch maximal technikromantisch, aber sie ist oft wirtschaftlich vernünftig. Wer diese Einordnung vertiefen will, findet dazu bereits passende Hintergründe in unserem Beitrag zu Make or Buy bei Zeiterfassungssystemen und in unserem Artikel über Anpassbarkeit in SaaS-Software. Wer stärker auf Wirtschaftlichkeit und Projektsteuerung schaut, landet außerdem schnell bei Projektzeiterfassung statt bei einer reinen Stundenliste.
Entscheidend ist nicht, ob man mit AI einen ersten lauffähigen Stand erzeugen kann. Entscheidend ist, ob das Ergebnis auch in sechs oder zwölf Monaten noch verlässlich betrieben, angepasst und geprüft werden kann.
Fazit
Zeiterfassung selbst programmieren klingt mit AI heute deutlich realistischer als noch vor kurzer Zeit. Genau deshalb sollte die Entscheidung nicht nur über Entwicklungsgeschwindigkeit getroffen werden. Für eine Demo reicht AI oft erstaunlich weit. Für den produktiven Einsatz beginnt die eigentliche Arbeit aber erst danach: Regeln, Rechte, Sicherheit, Auswertungen, Schnittstellen und laufende Pflege.
Die bessere Managementfrage ist daher nicht: Können wir Zeiterfassung selbst bauen?
Sondern: Wollen wir den langfristigen Betrieb eines solchen Systems wirklich selbst verantworten, oder ist eine anpassbare Standardlösung wirtschaftlich klüger?