01
Kittl Agentic AI
Aktuelle praktische Produktionserfahrung: Verantwortung für das Agentic-AI-Projekt bei Kittl — von Architektur und technischer Leitung bis zur Produktion.
AI ENGINEERING WORKFLOW SPRINT
Sorgen Sie dafür, dass AI-Speed den gesamten Delivery-Workflow überlebt.
Coding Agents können die Implementierung beschleunigen, während das Gesamtsystem genauso teuer bleibt.
Wir nehmen einen realen Production-Workflow, erfassen, wo der Geschwindigkeitsgewinn verloren geht, implementieren die kleinste sinnvolle Engineering-Intervention und testen sie an echten Changes.
PRODUKTIVE AI-ENGINEERING-ERFAHRUNG
Production AI Engineering — keine Prompt-Demos.
02
AI-gestützter Technical Sign-off
Entwicklung eines AI-gestützten Engineering-Sign-off-Workflows, der in etwa fünf Product-Teams und 23 Projekten eingesetzt wurde.
03
AI Change Verification — Open Source
Wir haben einen evidence-accountable Verification-Workflow für AI-assisted Code Changes vor dem Human Review entwickelt und als Open Source veröffentlicht — mit deterministischer Evidenz, expliziter Behandlung ungelöster Risiken und klarer menschlicher Entscheidungshoheit.
AI Change Verification auf GitHubWENN SCHNELLERE IMPLEMENTIERUNG NICHT ZU SCHNELLERER DELIVERY WIRD
Der Bottleneck verschiebt sich oft, statt zu verschwinden.
01
Implementierung wird günstiger, Delivery aber nicht planbarer
Tasks bewegen sich schneller durch Coding, während unklarer Intent, Requirements, Architekturentscheidungen oder Handoffs später weiterhin Zeit kosten.
02
Individuelle AI-Nutzung wird nicht automatisch zum Team-System
Einzelne Engineers haben gute Tools und Workflows, während gemeinsamer Kontext, Checks, Standards und Messung fehlen.
03
Senior Judgment kommt spät und teuer
Architektur, Risiken, Edge Cases und offene Annahmen erscheinen erst im Review oder Rework.
Wenn AI-gestützte Entwicklung die Implementierung noch nicht substanziell verändert, ist dieser Sprint wahrscheinlich noch nicht der richtige Einstieg.
DER SPRINT
Beheben Sie den nächsten Delivery-Bottleneck — nicht „AI Adoption“ im Allgemeinen.
Wir wählen einen Production-Workflow, erfassen die Baseline, identifizieren, wo AI-Speed verloren geht, und implementieren die kleinste sinnvolle Intervention in der bestehenden Engineering-Umgebung.
Der Mechanismus folgt dem Bottleneck. Wir zwingen nicht jedes Team in denselben AI-Prozess.
Ziel ist nicht maximale Automatisierung. Ziel ist ein Delivery-Workflow, in dem AI mehr nützliche Arbeit übernimmt und menschliches Judgment dort eingesetzt wird, wo es den größten Wert schafft.
- 01
Task- und Entscheidungskontext
Erwartetes Ergebnis, Constraints und offene Entscheidungen vor der Implementierung klären.
- 02
Gemeinsame AI-/Agent-Instructions
Teamweite Konsistenz herstellen, wenn individuelle Workflows funktionieren.
- 03
Architektur- und Approval-Checkpoints
Wiederholte spätere Systementscheidungen früher sichtbar machen.
- 04
Deterministische Verifikation
Tests, Linting, Typechecks und strukturelle Regeln vor teurem Review ausführen.
- 05
Review Readiness
Intent, Evidence und offene Risiken vor dem Review verfügbar machen.
- 06
Human Decision Boundaries
Explizit machen, was delegiert werden darf und was menschliche Verantwortung bleibt.
- 07
Before/After-Workflow-Messung
Ein bis drei praktische Messgrößen passend zum Workflow verwenden.
Zehn Arbeitstage von Baseline zu Live Evidence.
- 01
Einen Production-Workflow abgrenzen
Workflow, Team, Primary Repo, aktuelle AI-Nutzung und das Workflow-Ergebnis definieren, das der Sprint verbessern soll.
- 02
Baseline erfassen
Rework, Reviewer-Aufmerksamkeit, Kontextrekonstruktion, Handoffs oder Verifikationskosten messen.
- 03
Den echten Bottleneck identifizieren
Constraint und Symptome trennen und die kleinste Intervention auswählen.
- 04
Intervention implementieren
Den echten Workflow ändern statt ein Empfehlungspaket zu erstellen.
- 05
An echten Changes testen
Den aktualisierten Workflow an echter Engineering-Arbeit ausführen und mit der Baseline vergleichen.
- 06
Handoff und Entscheidung
Intervention, Ergebnis-Memo, offene Punkte und Empfehlung für Roll out, Iterate oder Stop übergeben.
FIT
Für Teams, bei denen AI die Implementierung bereits verändert, aber noch nicht das gesamte Delivery-System.
Der Sprint wird bewusst durch Workflow-Reife und Bottleneck bestimmt, nicht durch Unternehmensgröße.
GOOD FIT
- AI-assisted implementation wird bereits substanziell genutzt.
- Ein Production-Workflow hat sichtbare Friktion.
- Engineering Leadership kann menschliche Kosten benennen.
- Die Intervention kann an echter Arbeit getestet werden.
- Ein bounded Workflow-Change ist sinnvoller als ein breites Transformationsprogramm.
NOT A FIT
- generisches AI-Training oder Tool-Rollout
- kein konkreter Workflow
- company-wide Transformation in zehn Tagen
- Problem vollständig außerhalb von Software Delivery
DIREKT MIT DEN ENGINEERS ARBEITEN
Die Engineers, die die Arbeit umsetzen
AI & Software Engineering Lead
Yaroslava Suspitsina
Senior Software Engineer mit Fokus auf produktive AI-Systeme, agentische Architektur und Engineering-Workflows. Sie arbeitet derzeit bei Kittl und hat dort das Agentic-AI-Projekt von Architektur und technischer Leitung bis zur Produktion verantwortet. Außerdem entwickelte sie AI-gestützte Review-, Testing- und Quality-Workflows für mehrere Product-Teams.
- Aktuelle Verantwortung für das Kittl-Agentic-AI-Projekt und dessen Produktionseinführung.
- AI-gestützter Technical-Sign-off-Workflow für etwa fünf Product-Teams und 23 Projekte.
- Agentische Architektur, Testing, CI-Quality-Automation, Playwright, Debugging und Engineering Enablement.
AI/ML Engineer
Valerii Safonov
AI/ML Engineer mit Erfahrung in Machine Learning, quantitativer Modellierung, NLP/RAG, Computer Vision und produktionsnahen AI-Systemen. MSc in Computer Science mit Schwerpunkt Machine Learning und praktische AI-Engineering-Erfahrung seit mindestens 2020.
- MSc in Computer Science mit Schwerpunkt Machine Learning.
- Praxis in quantitativer Modellierung, NLP/RAG, Computer Vision und Production Engineering.
- Frühere angewandte Arbeit zur Erkennung und Bewertung von Technologietrends mit Verantwortung für Daten, Architektur und Engineering-Methoden.
Kein Handoff von Sales an ein Junior-Delivery-Team. Die hier gezeigten Personen arbeiten am Engagement.
FIXED-SCOPE SPRINT
Ein Team. Ein Production-Workflow. Zehn Arbeitstage.
€6.500 fix
+ VAT, falls anwendbar
10 Arbeitstage · 1 Team · 1 Production-Workflow · 1 Primary Repo · Baseline + Implementierung + Live Trial + Before/After-Evidence + Handoff.
Wir fixieren den Workflow vor Beginn. Wenn das Problem zu breit, zu klein oder innerhalb des Scopes nicht ehrlich testbar ist, sollten wir es nicht in den Sprint zwingen.
Kein laufender Retainer erforderlich. Der Sprint endet mit Handoff; jeder weitere Workflow oder größere Rollout wird separat vereinbart.
Fragen vor dem Sprint
Ist das ein AI-Adoption- oder Trainingsprogramm?
01Nein. Der Sprint setzt voraus, dass AI-gestützte Entwicklung bereits substanziell genutzt wird, und konzentriert sich auf einen realen Software-Delivery-Workflow.
Welche Bottlenecks kann der Sprint bearbeiten?
02Typische Beispiele sind fehlender Task-Kontext, Architektur-Iterationen, uneinheitliche Agent-Praktiken, Rework, Verifikationsaufwand, Review Readiness, Handoffs und unklare menschliche Entscheidungsgrenzen. Die konkrete Intervention folgt dem ausgewählten Workflow.
Müssen wir einen bestimmten Coding Agent verwenden?
03Nein. Der Sprint ist tool-neutral und arbeitet mit der Engineering-Umgebung, die bereits im Einsatz ist.
Müssen wir Plattformen migrieren?
04Nein. Eine Plattformmigration ist kein Ziel. Bestehende Tools bleiben bestehen, sofern eine Änderung nicht konkret durch den Workflow begründet ist.
Ist der Sprint nur für eine bestimmte Teamgröße gedacht?
05Nein. Der Fit wird durch Workflow-Reife und Bottleneck bestimmt, nicht durch Headcount.
Garantieren Sie einen bestimmten Produktivitätsgewinn?
06Nein. Es wird kein fixer Prozentsatz versprochen. Ziel des begrenzten Sprints ist, eine reale Intervention umzusetzen und mit beobachtbarer Before/After-Evidence zu bewerten.
Was, wenn unser Problem nur Review und Verifikation betrifft?
07Dann ist der engere AI Engineering Review & Verification Sprint wahrscheinlich der bessere Fit.
Was, wenn wir nur wenige Personen sind und unser Hauptproblem die wiederholte Steuerung unserer Agents ist?
08Für genau diese Situation ist der AI-Native Delivery System Sprint gedacht.
Was passiert nach zehn Arbeitstagen?
09Der Sprint endet mit Handoff und einer Ergebnisentscheidung. Es entsteht kein automatisches laufendes Consulting-Verhältnis.
Kontakt
Zeigen Sie uns, wo AI-gestützter Speed verloren geht.
Beschreiben Sie kurz Team, bereits genutzte AI-/Coding-Tools und einen Production-Workflow, in dem die Implementierung schneller geworden ist, Delivery aber weiterhin teuer oder unvorhersehbar bleibt.