Wie Kronos die Reaktion auf Produktionsvorfälle automatisiert

“Andere Modelle wiesen immer wieder auf dieselbe Stelle hin, selbst nachdem wir sie bereits behoben hatten. Als wir Enter Pro ausprobierten, fand es die tatsächliche Ursache heraus.”

WhyVenv hat Kronos entwickelt, einen autonomen Incident-Response-Agenten für den Quackathon, um Entwicklern zu helfen, schneller von Produktionsfehlern zur Fehlerursache zu gelangen.

---

Der Pager ist erst der Anfang

Wenn in der Produktion etwas schiefgeht, ist die Benachrichtigung selten der schwierige Teil.

Grafana kann Ihnen mitteilen, dass etwas ausgefallen ist. Logs können Ihnen sagen, dass etwas fehlgeschlagen ist. Ein Dashboard kann so laut rot blinken, dass jemand um 2 Uhr morgens aufgeweckt wird.

Aber danach beginnt die eigentliche Arbeit.

Ein Entwickler muss immer noch die Logs öffnen, den Fehler verstehen, die Codebasis durchsuchen, raten, welche Funktion wichtig ist, entscheiden, ob das Problem dringend ist, und herausfinden, ob der richtige nächste Schritt ein GitHub-Issue, ein Patch oder eine vollständige Eskalation ist.

Diese Lücke zwischen dem Wissen, dass etwas kaputt ist, und dem Verständnis, was kaputt ist, macht die Reaktion auf Vorfälle so schmerzhaft.

In genau dieser Lücke fand Dawood Khan die Idee für Kronos.

Dawood studierte KI, wandte sich nach dem College jedoch mehr der Systemtechnik zu. Sein Interesse war nicht abstrakt. Er hatte gesehen, wie Produktionssysteme ausfallen, wie Teams reagieren und wie viel manuelle Untersuchung immer noch zwischen einer Warnung und einer Behebung liegt.

Bei einer Grafana-Veranstaltung in Hyderabad wurde das Problem noch deutlicher. Entwickler beschrieben dasselbe Muster: Das System fällt aus, jemand erhält den Anruf, und dann beginnt das Team mit der vertrauten Arbeit, den Fehler manuell zurückzuverfolgen.

Der Quackathon wurde zum Moment, um etwas anderes zu bauen. Entwickelt von WhyVenv, belegte Kronos den zweiten Platz beim Quackathon, und stach in der Challenge „Track 01: Software - The Sentient Workspace“ hervor, indem es die Reaktion auf Produktionsvorfälle in einen agentenbasierten Workflow verwandelte.

---

Was WhyVenv gebaut hat

Das Projekt von WhyVenv war Kronos, ein autonomer Incident-Response-Agent, der für den Sentient Workspace-Track des Quackathons entwickelt wurde.

Die Idee war einfach, aber ehrgeizig:

Kronos empfängt Produktionsfehler, liest die Logs, ruft den relevanten Code ab, bittet ein KI-Modell, die wahrscheinliche Ursache zu diagnostizieren, und entscheidet dann, was als Nächstes geschehen soll.

Manchmal bedeutet das, ein GitHub-Issue zu öffnen.

Manchmal, je nach Schweregrad des Problems, bedeutet es, eine Behebung zu versuchen.

Der Punkt ist nicht nur, den Entwickler darüber zu informieren, dass die Produktion fehlerhaft ist. Der Punkt ist, dem Entwickler einen Vorsprung bei der Arbeit zu verschaffen, die normalerweise auf die Warnung folgt.

In Dawoods Worten während des Interviews machten es Grafana-Warnungen einfach zu wissen, wann etwas ausgefallen war. Das Problem war alles danach: herauszufinden, was das Problem verursacht hat, wo der Fehler lag und welche Maßnahmen das Team ergreifen sollte.

Kronos wurde entwickelt, um diese mittlere Ebene zu automatisieren.

---

Die technische Erkenntnis hinter Kronos

“Der Teil, auf den ich am meisten stolz war, war die Phase des Informationsabrufs. Anstatt nur ASTs oder Embeddings zu verwenden, haben wir mit den Trace-Logs gearbeitet, weil Entwickler das Problem normalerweise so finden.”

Der Teil, auf den Dawood am meisten stolz war, war nicht das Dashboard, die GitHub-Integration oder gar die KI-Diagnose.

Es war die Phase des Informationsabrufs (Retrieval).

Viele KI-Codierungssysteme versuchen, eine Codebasis durch Embeddings, AST-Parsing oder breites Laden von Kontexten zu verstehen. Kronos wählte einen für Entwickler natürlicheren Weg: bei den Trace-Logs anfangen und diese nutzen, um die Suche einzugrenzen.

Diese Entscheidung ist wichtig.

Wenn Entwickler Produktionsfehler beheben, bitten sie selten als Erstes ein KI-Modell, das gesamte Repository zu lesen. Sie schauen sich den Fehler an. Sie folgen dem Stack-Trace. Sie durchsuchen den Code mit grep. Sie bewegen sich vom Symptom zur Quelle.

Kronos wurde genau um diesen Instinkt herum entwickelt.

Das System nutzt Logs als Einstiegspunkt, ruft den Code ab, der am relevantesten erscheint, und bringt erst dann das KI-Modell in den Workflow ein. Das macht das Modell weniger zu einem allwissenden Orakel und mehr zu einem Prüfer, der mit einem gezielten Beweispaket arbeitet.

Dawood stellte klar, dass dieser Ansatz noch verfeinert werden muss, bevor man ihm in großem Maßstab vertrauen kann. Aber für die Demo hat es funktioniert. Vor allem spiegelte es einen ernsthaften Produktinstinkt wider: Die besten KI-Systeme ersetzen den Entwickler-Workflow nicht blind. Sie lernen davon, wie Entwickler bereits Probleme lösen.

---

Aufbau des Observability-Stacks mit Enter Pro

Kronos musste mit Tools funktionieren, die das Team zuvor noch nicht intensiv genutzt hatte.

Grafana. Prometheus. Loki. Dashboards. Logs. Metriken. Warnungen.

Für ein Hackathon-Team ist das eine Menge Infrastruktur, die man verstehen muss, bevor das eigentliche Produkt überhaupt anfangen kann zu arbeiten.

Hier wurde Enter Pro für WhyVenv nützlich.

Das Team nutzte Enter Pro während des gesamten Projekts für Recherchen, Ideenfindung und Debugging. Dawood und seine Teamkollegen nutzten es, um den Observability-Stack zu verstehen, herauszufinden, wie die Komponenten zusammenpassen, und Integrationsprobleme zu überwinden, wenn sich das System nicht wie erwartet verhielt.

Ein Moment stach besonders hervor.

Das Team kam nicht weiter, warum ihre Datenwarnungen nicht korrekt durchkamen. Sie hatten andere KI-Modelle ausprobiert, aber Dawood hatte das Gefühl, dass sich einige von ihnen immer wieder im Kreis drehten, selbst nachdem das Team den Fehler bereits behoben hatte.

Als sie Enter Pro ausprobierten, half es ihnen, die tatsächliche Ursache direkter zu identifizieren.

Das ist die Art von Moment, die in einem Build-Sprint zählt. Keine polierte Demo-Antwort. Kein allgemeiner Vorschlag. Ein konkreter Anstoß durch ein echtes Hindernis.

Für WhyVenv war Enter Pro nicht nur ein Ort, um Code zu generieren. Es war eine Möglichkeit, sich schnell genug in unbekannte Systeme hineinzudenken, um weiterbauen zu können.

---

Zwei Tage voller Fokus

Dawood hatte das Projekt geplant, bevor das Team mit der ernsthaften Entwicklung begann.

Er wusste, was sie bauen wollten. Er hatte die grundlegende Architektur durchdacht. Er hatte eine grobe Vorstellung davon, wie die Arbeit aufgeteilt werden sollte.

Dann übernahm der eigentliche Hackathon-Rhythmus.

Der erste Tag bestand nicht nur aus Code. Das Team verbrachte Zeit miteinander, redete, scherzte und fand sich zusammen. Der eigentliche Build kam danach: ein konzentrierter Sprint, bei dem sie die Arbeit aufteilten, unbekannte Teile recherchierten, den Kern-Workflow implementierten und das Produkt verfeinerten, bis es stabil lief.

Die Architektur begann einfach:

Absturzbericht -> relevanter Code -> LLM-Diagnose -> Issue oder Behebung.

Dann wurde jeder Teil im Zuge des Aufbaus durch das Team präziser.

Diese Einfachheit ist ein Grund, warum Kronos so überzeugend ist. Es beginnt nicht mit einer komplizierten Theorie über agentenbasierte Software. Es beginnt mit einem Workflow, den jeder On-Call-Entwickler versteht: Etwas ist kaputt, finde die Ursache, entscheide, was als Nächstes zu tun ist.

---

Was Kronos über KI-Agenten aussagt

Kronos ist kein Chatbot, der neben einer Codebasis sitzt.

Es ähnelt eher einem Workflow-Agenten: ein System, das ein Signal aus der realen Welt empfängt, die richtigen Beweise sammelt, nur dort nach logischen Schlüssen verlangt, wo diese nützlich sind, und das Ergebnis dann in die Tools leitet, die Entwickler bereits verwenden.

Dieser Unterschied ist wichtig.

Dawood ist sensibel für die Kosten- und Kontrollprobleme rund um KI-Systeme. Im Interview sprach er über Token-Nutzung, teure Modellaufrufe und wie wichtig es ist, einen Agenten nicht alles erledigen zu lassen, wenn deterministische Backend-Logik einen Teil der Arbeit effizienter erledigen kann.

Das ist ein reifer Instinkt für jemanden, der im Jahr 2026 mit KI baut.

Die Zukunft von KI-Agenten wird nicht nur darin bestehen, stärkere Modelle zu verwenden. Es wird auch darum gehen, zu wissen, wann man sie nicht einsetzt. Welche Teile sollten Code sein? Welche Teile sollten Retrieval sein? Welche Teile sollten Modell-Logik sein? Welche Teile sollten unter menschlicher Aufsicht bleiben?

Kronos weist, selbst als Hackathon-Projekt, genau auf diese Frage hin.

---

Was als Nächstes kommt

Das Projekt muss noch Fragen beantworten, bevor es produktionsreif ist:

• Wie gut lässt sich der Retrieval-Ansatz auf größere Codebasen skalieren?

• Wie sollten Schweregrad und Autonomie kalibriert werden?

• Wann sollte ein Agent ein Issue öffnen, anstatt eine Behebung zu versuchen?

• Wie viel Kontext ist genug, damit ein Modell einen echten Vorfall diagnostizieren kann?

• Was sollten Menschen genehmigen, bevor etwas in die Produktion gelangt?

Das sind keine kleinen Fragen. Es sind genau die Fragen, die Kronos so beachtenswert machen.

Denn Produktionsvorfälle werden nicht verschwinden. Die einzige Frage ist, ob jede Reaktion mit manueller Panik beginnen muss.

Kronos stellt sich einen anderen ersten Schritt vor: einen, bei dem das System, das den Fehler sieht, auch damit beginnen kann, ihn zu verstehen.

Genau das will Enter unterstützen.

Nicht nur schnellerer Code. Sondern eine schnellere Bewegung von einem echten Problem zu einem funktionierenden Produkt.

Und für WhyVenv reichte diese Bewegung aus, um ein schmerzhaftes Entwicklungsmuster in eines der Gewinnerprojekte des Quackathons zu verwandeln.

---

Entdecken Sie Kronos.

Diese Geschichte ist Teil unserer Quackathon Builder Series, in der wir uns Projekt für Projekt ansehen, um zu verstehen, was Entwickler mit Enter Pro erschaffen haben, warum sie es gebaut haben und was uns ihre Arbeit über die Zukunft der KI-gestützten Softwareentwicklung verrät. Bleiben Sie dran.