Cursors Always-on-Coding-Agenten sind da. Sind Ihre Teams bereit?

Die Neuigkeit

Cursor hat am Donnerstag ein Feature namens Automations veröffentlicht. Kurz zusammengefasst: Statt dass ein Entwickler einen KI-Agenten jedes Mal manuell anstößt, ermöglicht Automations das Definieren von Auslösern – ein neuer Commit, eine Slack-Nachricht, ein PagerDuty-Alert, ein Timer –, die Agenten selbstständig starten. Die Agenten erledigen ihre Arbeit und ziehen einen Menschen nur dann hinzu, wenn sie auf etwas stoßen, das menschliches Urteilsvermögen erfordert.

Cursors Engineering-Lead Jonas Nelle brachte es auf den Punkt: Ingenieure „initiieren nicht immer selbst. Sie werden an den richtigen Stellen dieses Fließbands hinzugezogen." Das Unternehmen gibt an, bereits Hunderte dieser Automations pro Stunde im eigenen Codebase zu betreiben – von der Fehlererkennung über die Incident-Response bis hin zu wöchentlichen Changelog-Zusammenfassungen, die automatisch in Slack gepostet werden.

Die Zahlen dahinter sind kaum zu ignorieren. Bloomberg berichtete diese Woche, dass Cursors annualisierter Umsatz die 2-Milliarden-Dollar-Marke überschritten hat – eine Verdopplung in rund drei Monaten. Das Unternehmen hält etwa 25 % Marktanteil unter den Abonnenten generativer KI-Tools.

Warum das mehr bedeutet, als es klingt

Auf den ersten Blick wirkt das wie eine Workflow-Optimierung. Auslöser festlegen, Agent übernimmt den Rest. Praktisch. Aber wenn man einen Schritt zurücktritt, wird klar: Cursor verwandelt den KI-Coding-Assistenten in Infrastruktur. Kein Tool, das man öffnet und benutzt. Ein System, das immer läuft.

Das ist eine bedeutende Verschiebung. In rund zwei Jahren sind wir von „Autovervollständigung im Editor" zu „Hintergrundprozessen, die Code committen, PRs reviewen, Sicherheitslücken scannen und auf Produktionsvorfälle reagieren, während Sie schlafen" gelangt.

Mich beschäftigt dabei immer wieder das Aufmerksamkeitsproblem. Ein Entwickler, der gleichzeitig Dutzende von Agenten überwacht, prüft nichts wirklich sorgfältig. Er stempelt ab. Automations versucht das zu lösen, indem es selektiv entscheidet, wann menschlicher Input nötig ist. Das ist ein guter Designansatz – bedeutet aber auch, dass die Urteilsqualität der Automation entscheidend wird. Wenn sie entscheidet, dass etwas kein menschliches Review braucht, und dabei falsch liegt, bemerkt es niemand.

Was wir in der Praxis beobachten

In unserer Web- und API-Entwicklungsarbeit haben wir verfolgt, wie sich das Gespräch rund um KI-Tools im letzten Jahr verändert hat. Anfangs wollten Kunden wissen, ob KI die Feature-Entwicklung beschleunigen kann. Heute sind die Fragen andere: Wie kontrollieren wir, was KI-Agenten in unseren Repos tun? Wer trägt die Verantwortung, wenn ein automatisierter PR eine Regression einführt? Wie prüfen wir das nach?

Das sind keine hypothetischen Fragen. In der Arbeit mit Enterprise-Kunden – besonders solchen unter Schweizer Compliance-Anforderungen – ist „ein KI-Agent hat es getan" keine akzeptable Antwort, wenn etwas schiefläuft. Sie brauchen Nachvollziehbarkeit. Sie müssen wissen, welcher Agent gelaufen ist, was er geändert hat, warum, und wer es genehmigt hat.

Cursors Automations-Framework scheint das zumindest teilweise zu verstehen. Die PagerDuty-Integration beispielsweise fragt Logs über MCP-Verbindungen ab und erstellt eine Zeitleiste, bevor sie eine Lösung vorschlägt. Das ist so etwas wie ein Audit-Trail. Aber „so etwas wie" reicht für regulierte Umgebungen nicht aus.

Der Sicherheitsaspekt, über den niemand spricht

Hier liegt meine eigentliche Sorge. In unseren Penetrationstests mit Gaming-Studios und Enterprise-Plattformen ist einer der häufigsten Angriffsvektoren, den wir finden, automatisierte Prozesse mit übermäßigen Berechtigungen. CI/CD-Pipelines, die in die Produktion deployen können. Service-Accounts mit Adminzugriff, den seit zwei Jahren niemand mehr überprüft hat.

Always-on-Coding-Agenten gehören in dieselbe Risikokategorie – mit noch mehr Autonomie. Ein Agent, der Ihren Codebase lesen, Produktionslogs via Datadog abfragen, PRs öffnen und Deployments auslösen kann, ist ein äußerst attraktives Angriffsziel. Wenn ein Angreifer den Auslösemechanismus kompromittiert – etwa durch eine manipulierte Slack-Nachricht –, erhält er potenziell agentenseitigen Zugriff auf Ihren gesamten Entwicklungs-Workflow.

Cursors Automations wird aktuell durch Slack-Nachrichten, Code-Änderungen und PagerDuty-Alerts ausgelöst. Jedes davon ist eine Angriffsfläche. Wenn wir Tools wie Cloudflare oder Akamai für DDoS-Schutz konfigurieren, kartieren wir stets die vollständige Kette automatisierter Systeme, die den Produktionsstatus verändern können. KI-Coding-Agenten gehören jetzt auf diese Karte.

Was Sie jetzt konkret tun sollten

Wenn Ihr Team KI-Coding-Tools mit Automatisierungsfunktionen einsetzt oder evaluiert, sind das konkrete Punkte, die Sie diese Woche angehen sollten:

1. Inventarisieren Sie die Berechtigungen Ihrer Agenten. Was kann jeder Agent lesen, schreiben und ausführen? Behandeln Sie das genauso wie ein Service-Account-Audit. Wenn ein Agent PRs öffnen und Produktionslogs abfragen kann, braucht er dieselbe Sicherheitsprüfung wie jedes andere automatisierte Deployment-Tool.

2. Legen Sie Ihre Human-in-the-Loop-Richtlinie fest, bevor Sie sie brauchen. Überlassen Sie dem Tool nicht die Entscheidung, was wichtig genug für einen Menschen ist. Ihr Team sollte diese Schwelle risikobasiert definieren: Alles, was Authentifizierung, Zahlungen, Infrastrukturkonfiguration oder Nutzerdaten berührt, bekommt ein menschliches Review. Punkt.

3. Loggen Sie alles. Wenn Sie Agenten einsetzen, die eigenständig Änderungen vornehmen, brauchen Sie unveränderliche Logs darüber, was ausgelöst wurde, was sich geändert hat und was genehmigt wurde – und von wem. In unserer Arbeit beim Aufbau von Cloud-nativen Anwendungen für Enterprise-Kunden verdrahten wir das vom ersten Tag an in die CI/CD-Pipeline. Wer es nachträglich einbaut, wird Lücken übersehen.

4. Behandeln Sie Agentenintegrationen als Teil Ihres Bedrohungsmodells. Bei Security-Reviews oder Pentests sollten Sie Ihre KI-Agenten-Konfigurationen einbeziehen. In unseren nativen iOS- und Android-Projekten haben wir Teams erlebt, die ihre Mobile-App-Sicherheit sorgfältig absicherten, während sie ihre Entwicklungs-Toolchain weit offen ließen. Dasselbe Prinzip gilt hier.

Das große Bild

Der Bereich der agentischen Coding-Tools entwickelt sich rasant. Beide großen KI-Labore haben im letzten Monat konkurrierende Features veröffentlicht, und die Richtung ist klar: Coding-Tools wollen always-on, autonom und tief in Ihren Stack integriert sein.

Das ist wahrscheinlich, wohin die Reise geht. Ich empfehle Teams nicht, diese Tools zu meiden. Wir setzen KI-gestützte Entwicklung selbst ein, und die Produktivitätsgewinne bei Boilerplate-Code, Test-Scaffolding und Routine-Refactoring sind real.

Aber es gibt einen Unterschied zwischen dem Einsatz von KI-Tools und dem unbeaufsichtigten Steuern des Entwicklungsprozesses durch KI-Tools. Die Grenze zwischen beidem ist gerade unschärfer geworden. Teams, die ihre KI-Agenten mit derselben Sorgfalt behandeln wie jedes andere automatisierte System mit Produktionszugriff, werden gut aufgestellt sein. Teams, die das nicht tun, werden es auf die harte Tour lernen.

Wir haben dieses Muster schon einmal gesehen. Als CI/CD-Pipelines erstmals weit verbreitet wurden, haben die Teams, die sie von Anfang an als sicherheitskritische Infrastruktur behandelten, die Sicherheitsverletzungen vermieden, die ein paar Jahre später alle anderen trafen. KI-Coding-Agenten befinden sich gerade an genau diesem Wendepunkt.

Wenn die Governance von KI-Tools in Ihrem Entwicklungsteam Ihr aktuelles Problem ist, sprechen wir darüber.