ilert stellt mithilfe unserer vorgefertigten Integrationen oder per E-Mail eine nahtlose Verbindung zu Ihren Tools her. Ilert lässt sich in Überwachungs-, Ticketing-, Chat- und Kollaborationstools integrieren.
So erreichen führende Unternehmen mit ilert eine Uptime von 99,9 %
Unternehmen weltweit vertrauen auf ilert, um ihr Incident-Management zu optimieren, die Zuverlässigkeit zu steigern und Ausfallzeiten zu minimieren. Lesen Sie, was unsere Kunden über ihre Erfahrungen mit unserer Plattform sagen.
Wenn es um IT-Services und -Betrieb geht, stehen wir oft zwischen ITIL und DevOps – zwei völlig unterschiedliche Ansätze mit verschiedenen Philosophien. Während ITIL auf strukturierte Prozesse und Stabilität setzt, dreht sich bei DevOps alles um Geschwindigkeit, Zusammenarbeit und Automatisierung. Doch wie findet man den richtigen Ansatz für das eigene Unternehmen?
ilert ist darauf spezialisiert, die Lücke zwischen strukturiertem Incident-Management und agilen Reaktionsstrategien zu schließen. Egal, ob Ihr Team ITIL-Best Practices folgt, eine ausgeprägte DevOps-Kultur lebt oder eine Mischung aus beidem nutzt – ilert sorgt dafür, dass Ihre Incident-Response-Prozesse effizient, automatisiert und zuverlässig bleiben.
In diesem Artikel zeigen wir Ihnen die wichtigsten Unterschiede zwischen ITIL und DevOps, damit Sie die beste Strategie für Ihr Unternehmen wählen können.
Was ist ITIL?
ITIL ist ein Rahmenwerk für das IT-Servicemanagement, das Best Practices für die Ausrichtung von IT-Services auf die Anforderungen des Unternehmens bereitstellt. Es wurde in den 1980er-Jahren von der britischen Regierung entwickelt und wird seitdem von Organisationen auf der ganzen Welt übernommen.
ITIL bietet einen strukturierten Ansatz für das Servicemanagement mit genau definierten Prozessen und Verfahren. Es hilft Organisationen dabei, ihre Servicequalität zu verbessern, ihre Ressourcen zu optimieren und Risiken zu managen. ITIL kann zur Unterstützung einer breiten Palette von IT-Diensten eingesetzt werden, einschließlich derer, die von Cloud-Anbietern bereitgestellt werden.
Wofür wird ITIL eingesetzt?
ITIL basiert auf einem prozessorientierten Ansatz, der sich auf die Identifizierung und das Management der einzelnen Schritte konzentriert, die zur Erbringung hochwertiger IT-Dienstleistungen erforderlich sind. Dies umfasst alles von der Entwicklung und Bereitstellung neuer Dienste bis hin zur Überwachung und Optimierung der Servicequalität.
ITIL kann auch für Unternehmen hilfreich sein, die auf die Cloud umsteigen, denn es bietet Anleitungen, wie man IT-Dienste an die entsprechenden Geschäftsanforderungen ausrichtet.
Außerdem kann ITIL genutzt werden, um die Kommunikation zwischen der IT-Abteilung und den Geschäftsbereichen zu verbessern und ein kollaboratives Umfeld innerhalb einer Organisation zu schaffen. ITIL kann Organisationen auch helfen, Risiken zu managen und die Einhaltung gesetzlicher Vorschriften zu gewährleisten.
Der Hauptvorteil von ITIL ist dabei, dass es Sie unterstützt, Ihren IT-Betrieb zu standardisieren. Dies kann die Verwaltung komplexer Umgebungen erleichtern und die Effizienz Ihrer IT-Abteilung verbessern. ITIL kann Ihnen auch helfen, Änderungen an Ihrer IT-Infrastruktur zu dokumentieren und zu verfolgen, sodass Sie Probleme schneller erkennen und beheben können. Einer der Nachteile von ITIL ist jedoch, dass es unflexibel sein kann und sich nur langsam an Veränderungen anpasst.
Wie relevant ist ITIL aktuell noch?
Many companies struggle to implement ITIL because the framework is complex and difficult to follow. Therefore, some experts argue that ITIL is no longer relevant in today's fast-paced digital world.However, modern ITSM practices increasingly integrate ITIL with Agile and DevOps methodologies, allowing organizations to combine structured service management with faster and more collaborative software delivery.
One reason ITIL is perceived as complex and difficult to follow is that the framework offers a comprehensive approach to ITSM . It is non-prescriptive, meaning organizations have flexibility in how they implement ITIL. This can make it difficult for companies to understand where to begin and how best to leverage the framework to meet their specific needs.
The latest version, ITIL 4, was released in 2019 and introduced a more flexible and modernized approach to service management. Rather than following the rigid lifecycle stages of its predecessor, ITIL 4 is built around the Service Value System (SVS) and a Service Value Chain; a shift designed to make the framework more adaptable to Agile and DevOps ways of working. This makes it better suited to organizations looking to retain structured service management practices without sacrificing speed or collaboration.
Was ist DevOps?
DevOps ist eine Methodik, die Entwicklungs- und Betriebsteams um gemeinsame Ziele, Prozesse und Verantwortlichkeiten vereint. Einer der Hauptvorteile von DevOps ist die Möglichkeit, die Bereitstellung neuer Funktionen und Updates zu beschleunigen. Dies liegt daran, dass DevOps auf dem Prinzip „Automatisierung zuerst “ basiert – was bedeutet, dass manuelle Prozesse so weit wie möglich automatisiert werden, beispielsweise die Bereitstellung von Servern und die Implementierung von Codeänderungen. Moderne DevOps-Praktiken legen außerdem Wert auf kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD), Infrastrukturautomatisierung und starke Beobachtbarkeit, um zuverlässige und häufige Software-Releases zu unterstützen. Darüber hinaus fügt DevOps das „menschliche Element“ hinzu und zeigt, wie Teams zusammenarbeiten können, um mehr zu erreichen als mit ihren individuellen Bemühungen allein.
Da DevOps eine Kultur der Zusammenarbeit zwischen Entwicklungs- und Betriebsteams fördert, können Probleme schneller identifiziert und gelöst werden. DevOps eignet sich besonders gut zum Aufbrechen von Informationssilos. Einer der Nachteile von DevOps ist jedoch, dass die Implementierung insbesondere in großen Unternehmen schwierig sein kann.
ITIL vs. DevOps
Einer der Hauptunterschiede zwischen ITIL und DevOps ist der Schwerpunkt auf Geschwindigkeit. ITIL konzentriert sich auf die Verwaltung und Verbesserung bestehender Dienste, während DevOps darauf ausgerichtet ist, neue Funktionen und Updates so schnell wie möglich bereitzustellen. Ein weiterer Unterschied ist der Umfang des jeweiligen Ansatzes. ITIL ist ein Rahmenwerk für die Verwaltung aller Aspekte von IT-Diensten, während DevOps sich in erster Linie mit dem Lebenszyklus der Softwareentwicklung befasst.
Welcher Ansatz ist also der richtige für Ihr Unternehmen? Wenn Sie die Effizienz Ihrer bestehenden IT-Abläufe verbessern wollen, dann ist ITIL die richtige Wahl. Wenn Sie die Bereitstellung neuer Funktionen und Updates beschleunigen möchten, ist DevOps der richtige Ansatz. Aber wenn Sie das Beste aus beiden Ansätzen herausholen wollen, können Sie sie auch zusammen verwenden. Viele denken bei ITIL und DevOps an eine Entweder-oder-Entscheidung, aber in Wirklichkeit handelt es sich um ergänzende Ansätze.
Wie kann man ITIL und DevOps erfolgreich kombinieren?
ITIL und DevOps können hervorragend miteinander vereint werden. Wenn Sie ITIL und DevOps erfolgreich kombinieren möchten, sollten Sie zunächst überlegen, wie Sie die beiden Konzepte am besten integrieren können. Nehmen Sie Ihr Problem als Grundlage hierfür. Dabei ist es wichtig, einen gemeinsamen Rahmen für die Zusammenarbeit der Teams zu etablieren. Außerdem sollten Sie DevOps-Prinzipien in Ihre ITIL-Prozesse integrieren und umgekehrt. So können Sie sicherstellen, dass beide Konzepte optimal funktionieren.
Zu den Vorteilen einer gelungenen Integration gehören:
Verbesserte Qualität der IT-Services
Schnellere Bereitstellung neuer Funktionen und Updates
Verminderte Risiken
Höhere Flexibilität bei der Anpassung an sich ändernde Geschäftsanforderungen.
Schnellere Reaktion auf Change Requests
Bessere Qualität der Software
Reduzierte Komplexität in der IT-Umgebung
Verringerter Aufwand für das Change Management
Fazit
ITIL ist auch heute noch relevant, weil es einen Rahmen für das ITSM bietet. Das Rahmenwerk legt Best Practices für die Erbringung hochwertiger IT-Services und die Ausrichtung der IT-Services auf die Geschäftsziele fest. Es hilft Organisationen auch dabei, ihre Prozesse zur Erbringung von IT-Dienstleistungen zu verbessern. Außerdem gibt ITIL Hinweise, wie eine IT-Service-Organisation effektiv geführt und betrieben werden kann.
DevOps ist kein Ersatz für das ITIL-Framework, sondern kann als Ergänzung betrachtet werden. DevOps in Kombination mit dem ITIL Framework ermöglicht es Unternehmen, schneller auf Änderungen zu reagieren und die Qualität der Software zu verbessern. Durch die Reduzierung der Komplexität in der IT-Umgebung und den Aufwand für das Change Management können DevOps-Teams ihre Arbeit effektiver gestalten. Insgesamt kann durch die Kombination das ITSM qualitativ verbessert werden.
Stellen Sie sich vor, es ist 2 Uhr morgens und ein kritisches System fällt ohne Vorwarnung aus. Ein übermüdeter Techniker in Bereitschaft arbeitet daran, den Dienst wiederherzustellen, um seinen Kunden vor einem größeren Ausfall zu schützen, der die nächste Service-Level-Überprüfung zunichte machen könnte. Am Tag darauf findet dann die altbekannte Diskussion über die faire Vergütung für Bereitschaftsdienste statt: Was ist eine „angemessene“ Bezahlung für schlaflose Nächte, unvorhersehbare Anrufe und schnelle Reaktionen auf Incidents?
Was gilt als Bereitschaftsdienst?
Bereitschaftsdienst ist eine besondere Arbeitszeitregelung im Arbeitsrecht. Sie tritt in Kraft, wenn der Arbeitnehmer verpflichtet ist, zumindest telefonisch erreichbar zu sein, damit er im Notfall seine Arbeit aufnehmen kann. Bereitschaftsdienst wird in der Regel als Zeit gezählt, die speziell für Arbeitszwecke vorgesehen ist.
In der Praxis bedeutet dies, dass Arbeitnehmer während des Bereitschaftsdienstes normalerweise nicht arbeiten dürfen. Es gibt jedoch Ausnahmen. Beispielsweise können Mitarbeiter während ihres Bereitschaftsdienstes auch von zu Hause aus arbeiten, wenn sie über ihr Arbeitsgerät erreichbar sind.
Was ist der Unterschied zwischen Rufbereitschaft und Bereitschaftsdienst?
Es gibt einen zeitlichen und örtlichen Unterschied zwischen den beiden Modellen:
Bereitschaftsdienst – Mitarbeiter bleiben erreichbar (Telefon, Pager oder Bereitschaftsdienst-App) und können sich im Fall einer Alarmierung von überall aus einloggen.
Rufbereitschaft – Die Mitarbeiter müssen physisch vor Ort sein und sofort einsatzbereit sein. Das deutsche Arbeitsrecht stuft diesenBereitschaftsdienst als Arbeitszeit ein und behandelt ihn entsprechend.
Im IT-Betrieb wird in der Regel der Remote-Bereitschaftsdienst bevorzugt, da die meisten Incidents (zum Beispiel Code-Rollbacks, Konfigurationsänderungen) über VPN gelöst werden können. Der Bereitschaftsdienst ist nach wie vor wichtig für latenzkritische Umgebungen, z. B. Handelsplattformen oder industrielle Steuerungssysteme, bei denen ein Techniker die Hardware überwachen und innerhalb von Sekunden eingreifen muss, um strenge Service-Level-Vereinbarungen einzuhalten.
Zählt Bereitschaftsdienst zur Arbeitszeit?
Ob Bereitschaftsdienst als Arbeitszeit gilt, ist nicht so eindeutig, wie es scheint. Nach den meisten arbeitsrechtlichen Rahmenbedingungen – einschließlich der Leitlinien für Sicherheit und Gesundheitsschutz am Arbeitsplatz und dem US-amerikanischen FLSA Fact Sheet #22 – wird passive Bereitschaftszeit als Ruhezeit behandelt, solange keine Alarmierung eingeht. Sobald Mitarbeiter jedoch kontaktiert werden und mit der Fehlerbehebung beginnen, gelten diese Minuten als aktive Arbeitszeit. In Grenzfällen entscheiden Gerichte (z. B. das deutsche BAG, Urteil vom Oktober 2023, 6 AZR 210/22) (Quelle auf Deutsch verfügbar), welche Zeiträume als solche gelten, sodass die Definitionen oft je nach Gerichtsbarkeit und Unternehmenspolitik variieren.
Auch für die Bezahlung gibt es keine allgemeingültige Regel. Viele Arbeitgeber behandeln Bereitschaftsdienst als abrechnungsfähige Arbeit und vergüten ihn entsprechend; andere stufen passive Bereitschaft als unbezahlte Verfügbarkeit ein. Wenn Ihr Unternehmen das letztere Modell anwendet, denken Sie daran, dass Sie nicht dafür vergütet werden, einfach nur erreichbar zu sein.
Fazit: Bereitschaftszeit ist nicht immer gleichbedeutend mit Arbeitszeit – sie hängt von der Vergütungspolitik des Unternehmens ab. Einige große US-Technologieunternehmen (Airbnb, Apple, Netflix) bezahlen keine passive Bereitschaft, während viele europäische Technologieunternehmen dies tun.
Zeiten der Rufbereitschaft
Rufbereitschaft wird in der Regel auf bestimmte Nächte oder Wochenenden beschränkt, die vorab vereinbart und im Arbeitsvertrag festgehalten sind. Da zu diesen Zeiten weniger Personal vor Ort ist, ist eine verlässliche Abdeckung während der Nacht und am Wochenende wichtig.
In Deutschland empfiehlt der IT-Branchenverband Bitkom, Rufbereitschaft auf maximal 56 Tage pro Kalenderjahr zu begrenzen und pro Schicht mindestens 8 Stunden ununterbrochene Ruhezeit zu garantieren (Bitkom-Leitfaden “Rufbereitschaft im IT-Betrieb”). Da Rufbereitschaft grundsätzlich als arbeitsfreie Zeit gilt, greift die gesetzlich vorgeschriebene Ruhepause von 11 Stunden nach §5 (1) des Arbeitszeitgesetzes erst dann, wenn der Techniker tatsächlich an einem Incident arbeitet.
Bereitschaftsdienstzeiten
Der Bereitschaftsdienst beschränkt sich in der Regel auf bestimmte Nächte oder Wochenenden, die im Voraus vereinbart und im Arbeitsvertrag festgehalten werden. Da während dieser Zeiten weniger Mitarbeiter vor Ort sind, ist einezuverlässige Abdeckung in der Nacht und an Wochenenden unerlässlich.
In Deutschland empfiehlt der IKT-Branchenverband Bitkom, Bereitschaftsdienste auf 56 Tage pro Kalenderjahr zu begrenzen und mindestens 8 aufeinanderfolgende Stunden Ruhezeit pro Schicht zu garantieren. Ähnliche Ruhezeitgrundsätze spiegeln sich in europäischen Arbeitsvorschriften wie der EU-Arbeitszeitrichtlinie wider. Bereitschaftsdienst wird in der Regel als Nicht-Arbeitszeit eingestuft, sodass die übliche 11-stündige Ruhepause gemäß § 5 (1) des Arbeitszeitgesetzes erst dann gilt, wenn der Techniker aktiv an einem Incident gearbeitet hat.
Sie suchen nach einer einfachen Möglichkeit, diese Grenzen im Blick zu behalten? Die Dienstplanverwaltung von ilert zeigt alle geplanten Rotationen und tatsächlichen Schichten auf einen Blick, sodass Teams ohne veraltete Tabellen die Vorschriften einhalten können.
Wie werden Bereitschaftsdienste in IT-Unternehmen vergütet?
Die Bezahlung variiert weiterhin je nach Unternehmensgröße, Branche und Risikoprofil. Der Tarifvertrag für den öffentlichen Dienst (TVöD) legt in § 8 Abs. 3 folgende Zuschläge fest:
Bereitschaftsdienste ab 12 Stunden
Wochentage (Mo – Fr): Vergütung mit dem 2-fachen des Stundenlohns für den gesamten Tag.
Wochenenden und Feiertage: Vergütung mit dem 4-fachen des Stundenlohns für den gesamten Tag.
Kürzere Bereitschaftsfenster (unter 12 Stunden)
Hier fallen zusätzlich 12,5 % des Stundenlohns pro Stunde Rufbereitschaft an.
In großen Konzernen oder erfolgreichen Start-ups können Arbeitnehmer mit etwa 1.000 € pro Woche für Rufbereitschaft rechnen. Bei Zalando liegt die Vergütung bei rund 1.050 €, bei dem Start-up HelloFresh bei 1.000 €, und bei Amazon Deutschland etwa bei 800 €.
Aktuelle Beiträge aus Engineer-Foren und Communities liefern weitere Vergleichswerte:
Google - SRE-Rotation Tier 1 (fünf Minuten Reaktionszeit): Vergütung für 40 Minuten jeder On-Call-Stunde außerhalb der Bürozeiten (66 % des Basisstundenlohns). Tier 2 (30 Minuten Reaktionszeit): 20 Minuten pro Stunde (33 %).
AWS - (EU-Tier-0-Services): 25 % des Basisgehalts pro On-Call-Stunde außerhalb der regulären Arbeitszeit, plus einen halben Tag bezahlten Urlaub für jede nächtliche oder samstägliche Alarmierung.
Mehr als Bezahlung: Mitarbeitergesundheit schützen
Geld ist nicht alles. Rufbereitschaft stört den Schlafrhythmus und beeinträchtigt das Privatleben, deshalb ist der Schutz der Mitarbeitergesundheit entscheidend. Diese fünf Punkte sind für Zufriedenheit und Wohlbefinden von IT-Teams wichtig:
Erwartungen klar definieren: Reaktionszeiten und Eskalationspfade müssen klar definiert sein.
Fair rotieren: Schichten gerecht verteilen, mit Primär- und Sekundär-Rollen. Ein automatisierter Bereitschaftsplan sorgt für Transparenz.
Workload im Blick behalten: Zeiten je Techniker tracken, nächtliche Bereitschaftsdienste begrenzen. Mit den ilert-Berichten können zum Beispiel Muster erkannt werden.
Tools richtig nutzen: Deduplizierung von Alarmierungen und smarte Eskalationen reduzieren dank ilert die Alarmflut und verkürzen die Time-to-Sleep.
Training & Support anbieten: Vierteljährliche Notfallübungen oder Übungstage halten das Team einsatzbereit und sicher im Umgang mit kritischen Störungen.
Zusammenfassung
Rufbereitschaft im IT-Bereich bedeutet, außerhalb der regulären Arbeitszeiten für eventuelle Notfälle erreichbar zu sein, meist remote. Sie unterscheidet sich vom Bereitschaftsdienst, der die Anwesenheit vor Ort erfordert und immer als Arbeitszeit gilt. Im Gesetz gibt es keine Regelung, dass Rufbereitschaft automatisch vergütet wird, nur die aktive Reaktion auf Incidents zählt eindeutig als Arbeitszeit.
Die Bezahlung für Rufbereitschaft variiert: Manche Unternehmen zahlen einen Zuschlag auf den Stundenlohn oder bieten Freizeitausgleich an, andere – etwa Apple oder Airbnb – vergüten passive Rufbereitschaft gar nicht. Bitkom empfiehlt in Deutschland maximal 56 Einsatztage pro Jahr mit mindestens 8 Stunden Ruhezeit pro Schicht.
Wöchentliche Pauschalen liegen bei Firmen wie Zalando, HelloFresh und SumUp zwischen 800 € und 1.050 €. Best Practices zum Schutz der Mitarbeiter umfassen eine faire Regelung für Rotationen, klare Eskalationspfade, Tools zur Verringerung von Alarmflut und regelmäßige Trainings.
KI-gestütztes Programmieren hat sich von einer Neuheit zum Standard entwickelt. Bei ilert haben wir Mitte 2023 mit KI-gestützter Programmierung begonnen und schnell erkannt, dass der Erfolg stark vom richtigen Kontext und den richtigen Arbeitsabläufen abhängt. Dies gilt insbesondere für Rust. Obwohl die Sprache für unsere Backend-Infrastruktur von zentraler Bedeutung ist, machen es ihre strengen Compiler-Regeln und ausgeprägten idiomatischen Ansätze für moderne LLMs bekanntermaßen schwierig, sie zu beherrschen.
Daher haben wir viel Zeit in die Optimierung unserer AI-First-Entwicklungspraktiken investiert – eine Investition, die Entwicklungsprobleme erfolgreich beseitigt und unser Onboarding deutlich vereinfacht hat.
In diesem Artikel beschreiben wir unseren Weg von lokalen Code-Bearbeitungen zu einem strukturierten, kontextbasierten Workflow mit Cursor. Wir stellen die genauen Strategien, Rule-Files und Planungsworkflows vor, die die KI von einem Spielzeug zu einem zuverlässigen Mitwirkenden gemacht haben.
Unser Weg von Code-Snippets zu Multi-Agent-Workflows
Wir sind immer offen für neue Technologien und beobachten aktiv alle Trends, um die besten Lösungen in unsere Arbeitsprozesse zu integrieren. Die KI war keine Ausnahme. Zunächst betrachteten wir KI als „besseres Stack Overflow”. Anfänglich nutzten wir ChatGPT zum Schreiben von Code-Snippets. Wir erstellten mehrere Custom-GPTs zum Schreiben von Unit-Tests und Dokumentationen. Dann abonnierten wir GitHub Copilot für die intelligente Autovervollständigung. Und dann kam Cursor. Zunächst waren wir ziemlich skeptisch, da das Tool ziemlich viele Fehler hatte und das Ergebnis weit von dem entfernt war, was wir uns vorgestellt hatten. Aber seine Fähigkeit, den Index der Codebasis zu nutzen, war vielversprechend.
Phase 1: Isolierte Aufgaben
Anfangs haben wir Cursor für isolierte Aufgaben verwendet. Ein Entwickler beauftragte ChatGPT zum Beispiel damit, „einen POST-Endpunkt für die Incident-Entität zu implementieren”. Der Umfang der Aufgaben war gering und die Ergebnisse waren oft unzuverlässig. In Rust führte dies oft zu Code, der zwar funktionierte, aber nicht idiomatisch war oder unsere bestehende Architektur verletzte.
Phase 2: Lebendige Dokumentation und Rule files
Wir erkannten, dass die KI nur so gut war wie der Kontext, den sie „sehen“ konnte. Anstatt jedoch den Kontext in jeden Chat einzufügen, wählten wir einen anderen Ansatz: Wir behandelten Dokumentation und Regeln als erstklassige Code-Artefakte.
Wir führten zwei wichtige Praktiken ein:
.cursor/rules/: Projektspezifische Regeldateien (wie rust-coding.mdc), die Cursor automatisch in jede Interaktion lädt. Diese Regeln kodieren unsere technischen Standards – Fehlerbehandlungsmuster, Parallelitätsmodelle, bevorzugte Crates –, sodass die KI jede Aufgabe bereits mit dem „Wissen“ um unsere Konventionen beginnt.
Lebendige Dokumentation: Dateien wie ARCHITECTURE.md, die Entscheidungen dokumentieren, nicht Implementierungsdetails.
Diese Phase brachte den Durchbruch, da der Kontext persistent verfügbar war und automatisch eingebunden wurde. Kein Kopieren und Einfügen mehr. Die KI übernahm einfach unsere Engineering-Kultur aus dem Repository selbst. Die genauen Regeldefinitionen und Dateistrukturen, die das ermöglichten, werden wir später in diesem Artikel vorstellen.
Phase 3: Plan Mode – Architektur vor Implementierung
Die Einführung von Plan Mode war der nächste Entwicklungsschritt in unserem Prozess und verlagerte unseren Workflow von „Code generieren und iterieren” zu „zuerst entwerfen, dann gezielt implementieren”.
Selbst mit geeigneten Regeln führt das sofortige Wechseln in die Code-Generierung oft zu Lösungen, die technisch korrekt, aber architektonisch fragwürdig sind – Tech Debt garantiert.
Um dem entgegenzuwirken, haben wir eine Strategie implementiert, die wir als „Dreierregel“ bezeichnen: Bei jeder wesentlichen Änderung beginnen wir mit Plan Mode und formulieren den Prompt wie folgt:
Goal: Implement JWT middleware for the HTTP service.
1. Scan ARCHITECTURE.md and README.md for related parts of the service
2. Scan the codebase to fill gaps in understanding
3. Propose 3 distinct architectural approaches
4. For each, list pros/cons and impact on maintainability and performance
In Kombination mit unseren Rule Files stellt der Plan Mode sicher, dass die KI Code generiert, der mit unserer langfristigen Vision übereinstimmt. Die Spezifikation und die Implementierung bleiben im gleichen Kontext, sodass wir die Architektur überprüfen können, bevor auch nur eine einzige Zeile Code geschrieben wird.
Ein Hinweis zur Kontext-Entropie im Plan Mode: Wir haben eine bestimmte Einschränkung in der aktuellen Version von Cursor festgestellt: Wenn man einen generierten Plan zu oft iteriert, neigt das Modell dazu, Einschränkungen und nützliche Lösungen, die in der ersten Version festgelegt wurden, zu „vergessen”.
Um diese Kontextverschiebung zu verhindern, nutzen wir für komplexe Aufgaben zuerst den Ask Mode, bevor wir in Plan Mode wechseln. So können wir Anforderungen und Randfälle im Voraus klären, was zu einem robusten Anfangsplan führt, der weniger Nachbearbeitungen erfordert.
Phase 4: Multi-Agent-Orchestrierung
Die neueste Entwicklung geht über einen einzelnen KI-Assistenten hinaus und hin zu orchestrierten Multi-Agenten-Systemen. Anstatt dass ein einzelner Agent alles übernimmt, orchestrieren wir nun spezialisierte Unteragenten, die jeweils über spezifische Tools und Fachkenntnisse verfügen.
Das allgemeine Muster sieht wie folgt aus: Der Orchestrator-Agent auf oberster Ebene koordiniert die Sub-Agenten:
Architekt-Agent: Betrachtet das Problem aus einer übergeordneten Perspektive, bewertet mehrere Lösungen und schlägt möglicherweise vor, einen POC zu erstellen, bevor eine Entscheidung getroffen wird.
Implementierungs-Agenten: Die Entwickler, die die geplanten Änderungen ausführen.
Review-Agenten: Qualitätsprüfer, die architektonische Standards, SOLID-Regeln, saubere Tests usw. sicherstellen.
Die Stärke liegt in der Parallelisierung und Spezialisierung, wodurch der Kontext und Fokus der LLMs effektiv verwaltet werden können. Unsere ersten Ergebnisse zeigen eine bis zu doppelt so hohe Iterationsgeschwindigkeit bei komplexen Aufgaben. Wir werden diesen Ansatz in zukünftigen Artikeln ausführlich erklären. Starten wir zunächst mit den Grundlagen der AI-First-Entwicklung.
Context Engineering: Warum Dokumentation der neue Code ist
Bevor es KI gab, war die Dokumentation oft das Letzte, was geschrieben wurde, und das Erste, was veraltet war. Ein menschlicher Entwickler konnte die Lücke zwischen einer veralteten README-Datei und dem tatsächlichen Code überbrücken. Der KI fehlt diese Intuition. Wenn Ihre Dokumentation Ihrem Code widerspricht, wird die KI eine Brücke zwischen beiden konstruieren, was zu Code führt, der korrekt erscheint, aber stillschweigend fehlschlägt.
Wir erkannten, dass wir, um Cursor effektiv zu machen, unsere Denkweise auf „AI-First-Dokumentation” umstellen mussten.
Das Kontextfenster sauber halten
Sobald man ein Repository in Cursor öffnet, indexiert es den Code, um den Projektkontext zu verstehen. Wenn dieser Index mit veralteten Architekturentscheidungen gefüllt ist, verschlechtert sich die Vorhersagequalität des Modells.
Um dem entgegenzuwirken, haben wir ein strenges Protokoll eingeführt: Dokumentation ist eine Compile-Time-Dependency.
Die Datei ARCHITECTURE.md: Jeder Dienst enthält diese Datei. Sie listet keine Endpunkte auf (die sich häufig ändern), sondern Entscheidungen. Dadurch erhalten die KI und neue Entwickler ein Verständnis für das „Warum” hinter dem Code.
Standardisierte Ordnerstruktur: Wir setzen ein einheitliches Layout für alle Rust-Dienste durch (src/domain, src/infrastructure, src/api). Da jedes Projekt identisch aussieht, kann die KI mit nahezu hundertprozentiger Genauigkeit vorhersagen, wo eine neue Datei hingehört, sodass wir weniger Pfade in Eingabeaufforderungen angeben müssen.
Der „Fix the Rule“-Loop
Eine unserer effektivsten Produktivitätsänderungen betraf den Umgang mit KI-Fehlern. Wenn Cursor zuvor Code generierte, der gegen unsere Muster verstieß, haben wir den Code einfach mit Folgebefehlen umgeschrieben. Jetzt behandeln wir einen KI-Fehler als Dokumentationsfehler.
Wenn Cursor Code generiert, der Probleme mit dem Borrow Checker verursacht oder zu einem Deadlock führt, korrigieren wir nicht nur den Code, sondern patchen auch die Rule File oder andere Kontextdokumentationen. Wir fragen: „Welche Anweisung fehlte, die diesen Fehler ermöglicht hat?“ So führt jeder Fehler zu einer dauerhaften Verbesserung für das gesamte Team.
Der Erfolgsfaktor: unsere Rust-Regeln
Die Dokumentation liefert den Kontext, aber Rulesliefern die Einschränkungen. Anfangs nutzten wir eine einzelne .cursorrules-Datei im Stammverzeichnis des Repositorys. Jetzt verwenden wir mehrere RULE-Files in .cursor/rules/:
Sprachspezifische Regeln
Allgemeine Best Practices für die Programmierung
Refactoring-Regeln
Regeln für die Sicherheitsanalyse
Die Trennung der Dateien erleichtert ihre Wartung, reduziert den LLM-Kontext und erleichtert ihre Wiederverwendung in verschiedenen Projekten. Für Rust verwenden wir eine spezielle Regeldatei rust-coding.mdc (siehe Anhang). Hier gehen wir auf einige wichtige Punkte ein.
Wichtige Einschränkungen, die wir durchsetzen
1. Modularität
Die Regel: main.rs so klein wie möglich halten – nur main(), das die Konfiguration lädt und runtime.block_on(run(...)) aufruft. Der asynchrone Einstiegspunkt soll in einer eigenen Datei run.rs stehen. In lib.rs und mod.rs sollen nur Module aufgelistet werden. Module sollten nach Domänen gruppiert werden (z. B. src/http, src/config, src/use_case_xx).
Der Grund: Die schlanken Haupt- und Lib-Module erleichtern die Testbarkeit und die Lebenszyklusanalyse. Domänenordner und optionale umfangreiche Abhängigkeiten (z. B. Kafka) vereinfachen die Integrationsprüfung, ohne dass die gesamte Infrastruktur hochgefahren werden muss.
2. Das „Sync main”-Muster
Eine der größten Herausforderungen für Cursor mit Rust ist die Handhabung von Rust-Lifetimes in asynchronem Code. Dies führt dazu, dass viele unnötige Klone oder Mutexe erzeugt werden, was zu unbeabsichtigter Komplexität führt.
Die Regel: „Starte main() im Sync-Modus, konfiguriere die Anwendung und starte dann am Ende die Tokio-Laufzeitumgebung.”
Der Grund dafür: Dadurch wird die KI gezwungen, langlebige Ressourcen (wie Datenbankpools oder Konfigurationsobjekte) im Stack-Frame der main-Funktion zuzuweisen, bevor die Tokio-Laufzeitumgebung gestartet wird. Cursor kann einen Trick mit Box::leak(Box::new(some_global)) anwenden, um 'static Referenzen zu erhalten, was die Laufzeitverwaltung weiter vereinfacht.
3. Datenmodellierung und Konfiguration
Die Regel: Newtype-IDs, serde für DTOs mit camelCase, derive_builder für komplexe Konstruktionen, validator für eingehende DTOs. Die config-Crate mit YAML und Umgebungsüberschreibungen verwenden, damit alle Einstellungen beim Start validiert werden.
Der Grund: Eine konsistente DTO-Darstellung und -Validierung an der Grenze stärkt APIs, liefert klare Fehlermeldungen und sorgt dafür, dass die KI jedes Mal die gleichen Muster generiert.
4. Fehlerbehandlung
Die Regel: „Definiere eine thiserror-Enumeration für Businesslogik über alle Anwendungsfälle und verwende anyhow für generische Fehler.“
Der Grund: Dies verhindert, dass die KI zu viele benutzerdefinierte Fehler-Enumerationen erstellt, und stellt gleichzeitig sicher, dass die Geschäftslogik von abgleichbaren Fehlern profitieren kann. Wir bevorzugen die From-Trait-Implementierung gegenüber map_err() und verbieten unwrap() im Produktionscode, um sauberen und idiomatischen Rust-Code zu ermöglichen.
5. Verhindern von Async-Problemen
Die Regel: „Das Halten von std::sync::Mutex über einen .await hinweg ist strengstens verboten.“
Der Grund: Dies ist ein klassischer Rust-Fehler, der die Tokio-Laufzeit blockiert. Syntaktisch sieht es korrekt aus und lässt sich kompilieren.
6. Beobachtbarkeit und externe Kommunikation
Die Regel: Verwende tracing mit strukturierten Feldern; verwende impl FromRequest for Claims für Actix-Authentifizierung; nutze reqwest mit Wiederholungsversuchen und Beobachtbarkeits-Middleware für ausgehende HTTP-Anfragen.
Der Grund: Manchmal entscheidet sich Cursor für die Verwendung von awc::Client, aber er ist nicht Send, was beispielsweise die Übergabe an tokio::spawn erschwert. Daher setzen wir einen reqwest-basierten Client zusammen mit seinen Middlewares für produktionstaugliche Fehlertoleranz und Beobachtbarkeit durch.
Die vollständige Rules-File finden Sie im Anhang am Ende dieses Artikels. Sie können sie in .cursor/rules/rust-coding.md ablegen und an Ihren Stack anpassen.
Experiment: Keine Regeln vs. Regeln vs. Planung
Um die jeweiligen Auswirkungen auf unseren Workflow bestimmen zu können, haben wir einen kontrollierten Versuch durchgeführt, indem wir Cursor in drei Konfigurationen denselben Befehl gaben:
Hinweis zur Verzerrung: Wir mussten den „Naked”-Versuch auf einem neuen Cursor-Konto durchführen. Wir haben festgestellt, dass die in der Cloud gespeicherten Einbettungen von Cursor „hartnäckig” sind; auch ohne Regeldateien „erinnerte” es sich an unsere früheren Muster aus anderen Sitzungen. Ein neues Konto war notwendig, um die tatsächliche Basisleistung zu sehen. Und hier ist eine weitere Implikation: Wenn Cursor Code mit schlechten Mustern in Kontakt kommt, kann es sein, dass es diese in dem neuen Code wiederholt. Seien Sie also vorsichtig, womit Sie Cursor „füttern”.
Der Prompt ist absichtlich recht vage gehalten, um die Verzerrung in Cursor zu untersuchen:
Implement the service in Rust:
- HTTP server based on Actix with JWT authentication
- Consume each Kafka topic defined in the YAML configuration
- On each message, make a POST call to /forward on the downstream service with hostname configured via environment variable
- Expose Kafka producer statistics at /stats
Szenario Nr. 1: "Naked" Cursor (keine Rules-Datei)
Das generierte Projekt ließ sich nicht kompilieren. Wir stellten fest, dass der Kafka-Consumer mit tokio::spawn gestartet wurde, wobei ein gemeinsam genutzter awc::Client übergeben wurde. awc::Client implementiert das Trait Send nicht, da er auf den Single-Thread-Typen von Actix (z. B. Rc) basiert. tokio::spawn verlangt jedoch, dass das Future das Send implementiert. Daher lehnt der Compiler diese Variable ab.
Das problematische Snippet:
pub fn spawn_consumers(config: Config, stats: SharedStats, client: awc::Client, downstream_host: String) {
for topic in config.topics {
let client = client.clone();
tokio::spawn(async move {
if let Err(e) = run_topic_consumer(..., client, ...).await {
// handle error
}
});
}
}
Der Code fördert weder Wartbarkeit noch Erweiterbarkeit:
Die Module bestehen aus einer flachen Sammlung von Dateien im Verzeichnis /src ohne domänenspezifische Gruppierung.
Viele Module vermischen unterschiedliche Verantwortlichkeiten, etwa Nachrichtenverarbeitung und HTTP-Aufrufe in kafka.rs oder das Laden von Umgebungsvariablen und das Einrichten von Server-Routen in main.rs.
Szenario Nr. 2: Mit einer Rule-Datei, kein Plan Mode
Mit aktivierter Rule-Datei kompiliert das Projekt erfolgreich. Cursor wählt einen Send-sicheren HTTP-Client auf Basis von reqwest, inklusive einer separaten Fassade für den HTTP-Client.
Allerdings konnten wir feststellen, dass die Modularity-Regeln nicht vollständig umgesetzt wurden. Es gab beispielsweise keine modulare Gruppierung nach Scope und Funktionalität; sämtliche Source-Files lagen in einem einzigen Ordner. Noch gravierender: Es gab zu viele Error-Enums – eines in kafka.rs, ein weiteres in config.rs usw. Offensichtlich hatte Cursor unsere Rule hier missverstanden.
Auf diese Weise erhält man zwar einen funktionierenden, kompilierbaren Service, architektonisch bleibt jedoch Optimierungspotenzial. In diesem Fall scheint Cursor kein projektweites Architekturdenken zu verfolgen. Und genau hier kommt der Plan Mode ins Spiel.
Szenario Nr. 3: Mit Rule-Datei und Plan Mode
Mit aktivierter Rule-Datei und Start im Plan Mode von Cursor folgt der generierte Service den meisten Regeln konsistent: Der HTTP-Client und die Konfiguration befinden sich in dedizierten Modulen, die modulare Struktur mit http/, forwarding/, server/ und shared/ ist klar umgesetzt – gut geeignet für Tests und Erweiterungen.
Die main.rs ist entsprechend schlank und übersichtlich:
fn main() -> anyhow::Result<()> {
tracing_subscriber::fmt()
.with_env_filter(EnvFilter::from_default_env())
.init();
let config_path = std::env::var("CONFIG_PATH").unwrap_or_else(|_| "config.yaml".into());
let path = PathBuf::from(&config_path);
let config = AppConfig::load(&path).context("load config")?;
let runtime = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.context("create runtime")?;
runtime.block_on(run(config))?;
Ok(())
}
Ergebnisse: Von Autoren zu Reviewern
Nach jahrelanger Optimierung unserer Cursor-Workflows hat sich der Einfluss auf unsere Engineering-Geschwindigkeit deutlich gezeigt:
1. Optimierte Einarbeitung
Der größte Überraschungseffekt einer strikten Rule-Datei und „AI-First Documentation“ zeigte sich beim Onboarding. Wenn ein neuer Engineer zu ilert kommt, muss er nicht zunächst alle unsere Coding-Guides auswendig lernen, bevor er produktiv beitragen kann. Cursor fungiert als Pair-Programmer, der unsere Konventionen bereits kennt.
2. Von Syntax zu Architektur
Unsere Engineers verbringen heute deutlich weniger Zeit mit Boilerplate-Code, mit dem Rust-Borrow-Checker oder mit dem Debugging schwer nachvollziehbarer Async-Runtime-Fehler. Die AI übernimmt das „Plumbing“. Dadurch gewinnt unser Team Freiraum, um sich stärker auf komplexe Business-Logik zu konzentrieren und mehr Aufmerksamkeit auf entscheidende Details zu legen.
Wir haben uns faktisch vom „Code Writer“ zum „Code Reviewer und Architekten“ entwickelt.
3. Vorhersagbarkeit im großen Maßstab
Indem wir Prompts und Regeln wie Code behandeln, haben wir ein Maß an Konsistenz erreicht, das in wachsenden Teams schwer aufrechtzuerhalten ist. Das Aufsetzen neuer Microservices und deren Integration in unsere Infrastruktur-Landschaft wurde zur Routine. Die Anzahl der Code-Review-Iterationen ist drastisch gesunken.
Fazit
Wenn Sie Rust-Entwickler oder Engineering Leader sind und Ihre Produktivität steigern möchten, sollten Sie KI nicht wie einen Chatbot behandeln. Betrachten Sie sie vielmehr wie einen Junior Engineer. Geben Sie ihr ein Handbuch (.cursor/rules/), liefern Sie Kontext (ARCHITECTURE.md) und zwingen Sie sie, erst zu denken, bevor sie Code schreibt.
Aus unserer Erfahrung ergibt sich folgende Checkliste für eine effektive Entwicklung mit Cursor:
1. Design iterieren, einmal implementieren: Starten Sie größere Änderungen im Plan Mode und lassen Sie sich von der KI verschiedene Lösungsansätze vorschlagen. Nutzen Sie in komplexen Fällen zunächst den Ask Mode, bevor Sie in den Plan Mode wechseln.
2. Dokumentation als Dependency behandeln: Pflegen Sie eine KI-optimierte Dokumentation (kompakt, strukturiert und widerspruchsfrei), die zentrale Entscheidungen und Constraints klar festhält.
3. Der „Fix-the-Rules“-Loop: Wenn die KI einen Fehler macht, korrigieren Sie nicht nur den Code. Aktualisieren Sie Ihre Rules so, dass diese Fehlerklasse künftig systematisch vermieden wird.
4. Kontext bewusst steuern: Achten Sie darauf, welche Inhalte Sie indexieren. Verwenden Sie .cursorignore, um irrelevante Informationen auszuschließen. Wenn Sie Cursor eine Legacy-Codebase mit schlechten Patterns geben, wird sie diese reproduzieren.
Die Tools sind bereit. Jetzt liegt es an uns, mit ihnen die Zukunft zu gestalten.
Anhang: Unsere Rust-Rules
Hier finden Sie unsere vollständige rust-coding.mdc. Sie können diese kopieren und an Ihre Bedürfnisse anpassen.
---
description: "ilert's Rust coding rules"
globs: ["src/**/*.rs"]
alwaysApply: true
---
# Modularity
- Group modules by business functionality: `src/payments`, users. Common utilities go into `src/shared`
- In lib.rs or mod.rs only list modules
- Keep main.rs concise: it should contain only main() that calls configuration functions from other modules and launches the runtime
- Define run.rs with run() that is the entry point of the async runtime
- Heavy dependencies like Kafka producers should be optional, optimized for testing
- Separate boundaries under facades like Client classes for downstream HTTP services
# Data Modeling
- Newtype Pattern: Wrap primitive types for entity IDs (e.g., `#[derive(PartialEq, Eq, Hash, Copy, Clone)] struct UserId(u64);`)
- Annotate DTO structs for JSON requests and responses with `#[derive(Debug, Clone, Deserialize, Serialize)]`, `#[serde(rename_all = "camelCase")]`
- Annotate enums with `#[strum(serialize_all = "SCREAMING_SNAKE_CASE")]` and `#[derive(Clone, Display, Debug)]`, `#[serde(rename_all = "SCREAMING_SNAKE_CASE")]`
- For complex object construction, utilize `derive_builder` with `#[builder(setter(into))]`
- Use `validator` (`#[derive(Validate)]`) on incoming DTOs
## Concurrency
- Start the main() in sync mode (no #[actix_web::main]), configure the application, then launch the async runtime at the end with `runtime.block_on(run(...))`
- Pass complex variables initialized in main() as 'static obtaining the reference with `Box::leak(Box::new(something))`
- Wrap shared writable state with `tokio::sync::RwLock` (`Arc<RwLock>`), locking for the shortest period of time
- If the shared writable state requires change notification, use `tokio::sync::watch`
- Strictly forbid holding `std::sync::Mutex` or `std::sync::RwLock` across an `.await` point
- Handle graceful job cancellation and timeouts using `tokio::select!`
- For long-term async background jobs, like message consumers, use `&'static self` and initialize the instance before the launch of the async runtime
# Error Handling
- Use descriptive error types using `thiserror` v2, preserving source via `#[from]` or `#[source]`. Fall back to `anyhow` for short-scoped generic errors that are later mapped to `thiserror`; use `.context()`
- Avoid `map_err()` — instead, implement the `From` trait for the target error type
- Strictly avoid unwrap() in production code. But `.context()` for critical errors during application launch is fine
# Observability
- Use `tracing` for logging and tracing, attaching key-value pairs with important context
- Check the log level before dumping complex debug data with `if tracing::enabled!(tracing::Level::DEBUG)`
# External Communication
- For authentication in Actix use `impl FromRequest for Claims`
- Use middlewares for observability (`reqwest-tracing` for clients, custom for servers)
- Utilize timeouts and retries with backoff for outgoing requests (`reqwest-retry`)
# Config and Utilities
- Use `config` v0.15 and YAML configurations, with flexible environment overrides by `.add_source(Environment::default()).set_override_option("some.deep.key", std::env::var("CUSTOM_VAR").ok())`
- Use `itertools` to ease iterator transformations (`use itertools::Itertools; iter.join(", "); iter.chunks(10); iter.unique()`)
- Avoid adding comments, keep existing
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.
Unsere Cookie-Richtlinie
Wir verwenden Cookies, um Ihre Erfahrung zu verbessern, den Seitenverkehr zu verbessern und für Marketingzwecke. Erfahren Sie mehr in unserem Datenschutzrichtlinie.
.avif)
.avif)
.avif)
.avif)
