Fix-It Sprint
1–2 Wochen
- Schnelle Analyse, dringende Fixes
- Intensiv, ein Problem
Leistungen · 15 Wege über eine Lücke
Alle LeistungenReferenzen · Belege statt Versprechen
Alle Case StudiesZuletzt geliefert Beispieldaten
Versicherung · DACHSchadentriage-Agent40 % der Eingänge automatisiertFintechKYC-PrüfagentNur noch AusnahmenMedienArchivsuche & Tagging1,2 Mio. Assets, auffindbarKonzernAgent-Security-Audit2 kritisch → 0Uns vertrauen
Wissen · Straßenton, aufgeschrieben
MagazinUnternehmen · KI-Expertise seit 2011
Über VoidgapWer wir sind
Wir schließen die Lücke nicht. Wir ziehen ein.
DACH · --:--:-- · läuft
So arbeitet ihr mit uns
Hands-on · für echte Systeme unter Druck
Eure KI scheitert nicht an Strategie-Decks. Sie scheitert, weil echte Systeme chaotisch sind.
Eine Strategiefolie wird durchgestrichen. An ihrer Stelle: die Logs des Systems, die Ursachen, die wir darin finden, die Fixes und die Zahlen vorher und nachher.
01 · Wann Teams uns rufen
Anti-Beratung heißt: Wir öffnen die Logs, bevor wir ein Foliendeck öffnen.
Das KI-System ist live, und etwas stimmt nicht. Die Antworten sind inkonsistent, die API-Rechnung hat sich verdoppelt, die Nutzer vertrauen ihm nicht mehr, oder die Security blockiert das nächste Release. Das Team ist zu nah dran, zu beschäftigt oder hat die naheliegenden Fixes schon probiert.
Wir lesen, was wirklich da ist: Code, Prompts, Retrieval-Setup, Daten, Logs, Kosten. Die meisten Probleme haben wenige Ursachen: Retrieval, das den falschen Kontext liefert, Prompts, die immer weiter gewuchert sind, keine Evals, das falsche Modell für die Aufgabe oder fehlende Guardrails. Wir finden die Fixes mit dem größten Hebel und setzen sie um, mit Zahlen vorher und nachher.
Tiefere Änderungen, wo sie nötig sind, und Wissenstransfer, damit das Team ohne uns weitermachen kann: Schulung dazu, was wir geändert haben und warum, und Runbooks für den nächsten Incident. Als monatlicher Retainer, in Teilzeit eingebettet in euer Team oder als Fix-it-Sprint von ein bis zwei Wochen.
Inkonsistente oder falsche Outputs, und niemand kann sagen, wie oft.
Die API-Kosten wachsen schneller als der Nutzen, und die Nutzung steigt weiter.
Nutzer umgehen es. Stakeholder fragen, ob man es abschalten sollte.
Das nächste Release ist blockiert, und auf die Fragen gibt es keine schriftlichen Antworten.
Zwei Lager, zwei Ansätze, und nichts bewegt sich, solange sie streiten.
Es macht jede Woche etwas anderes, und niemand weiß, warum.
Keine Folien. Keine Buzzwords. Echte Fixes in echten Systemen.
02 · Wo es bricht
Die meisten Probleme gehen auf eine Handvoll Ursachen zurück. Wählt eine aus und seht, worauf wir achten und was wir ändern.
RAG, Embeddings, Suche
03 · Ablauf
Erst die Quick Wins, damit der Druck sinkt. Dann die tiefere Arbeit. Dann geht das Wissen an euer Team.
Wir lesen Code, Prompts, Daten, Retrieval, Logs und Kosten und ordnen, was wir finden, nach Wirkung.
Die Fixes mit dem größten Hebel, umgesetzt und gemessen, damit alle den Unterschied sehen.
Die tieferen Änderungen: Architektur, Evals, Monitoring, was immer die Ursachen verlangen.
Was wir geändert haben und warum, damit euer Team weitermachen und den nächsten Incident selbst lösen kann.
04 · Modelle der Zusammenarbeit
Dieselben Leute, dieselbe Arbeitsweise. Was sich ändert: wie oft wir in eurem System sind.
1–2 Wochen
Teilzeit
monatlich
Die Streifen zeigen einen illustrativen Rhythmus. Der echte wird pro Auftrag vereinbart.
05 · Selbstcheck
Vier Fragen. Das Ergebnis ist das Modell, das passt, und das ist oft das kleinste.
Ein bis zwei Wochen an einem Problem, mit Zahlen vorher und nachher.
Monatliche Beratung für Entscheidungen und Reviews, während euer Team baut.
In Teilzeit in eurem Team und eurem Repo, so lange das System es braucht.
01Was tut am meisten weh?
02Hat euer Team Kapazität für die Umsetzung?
03Wie stark wird sich das System weiter verändern?
04Wie oft müsst ihr Entscheidungen durchsprechen?
06 · Passt es?
Beratung beginnt, wo ein System schon live ist. Davor passt anderes besser.
07 · Fragen
Wir lesen das System, bevor wir über Strategie reden: Code, Prompts, Retrieval, Daten, Logs und Kosten. Das Ergebnis sind Fixes mit Zahlen vorher und nachher, kein Foliendeck.
Beides. Wir setzen die Fixes in eurem Repository um, messen den Effekt und erklären, was wir geändert haben. Im Embedded-Modell arbeiten wir im Pairing mit euren Engineers.
Zum Start: Lesezugriff auf Code, Prompts, das Retrieval-Setup, Logs und Kostendaten. Wo wir Fixes umsetzen, Schreibzugriff zu euren Bedingungen, über euren normalen Review-Prozess.
Retrieval und Wissenssysteme, Tool Calling und Agenten-Design, Evaluation-Harnesses, Prompting und Output-Kontrolle, Deployment und Monitoring sowie Training für das Team. Die Systemkarte oben zeigt, wo was sitzt.
Dann passt KI-Strategie besser. Beratung beginnt, wo ein System schon live ist und wehtut.
08 · So arbeitet ihr mit uns
Wählt danach, wo ihr steht: vor einer Entscheidung, festgefahren mit einem Live-System oder bereit zum Bauen.
Halber oder ganzer Tag. Endet mit Entscheidungen, Verantwortlichen und nächsten Schritten.
Wenn ihr entscheiden müsst
Retainer, Fix-it-Sprints, Hilfe direkt im Team. Für Systeme, die live sind und wehtun.
Wenn ein Live-System wehtut
Builds von zwei bis acht Wochen. Von der validierten Idee zu echten Nutzern.
Wenn ihr bereit zum Bauen seid
Was bricht gerade in Produktion?
Ein Call. Ihr bringt die Symptome, wir bringen die Fragen. Wenn es nicht passt, hört ihr das auch.