Visual Studio Code, der weit verbreitete Code-Editor von Microsoft, hat in Version 1.137 eine Funktion erhalten, die auf den ersten Blick unspektakulär klingt und im Projektalltag doch einiges verändert: Aufgaben, die von einem KI-Agenten im Editor erledigt werden, lassen sich nun nach einem festen Zeitplan starten. Möglich sind laut Ankündigung etwa stündliche oder tägliche Durchläufe.

Bisher galt für solche Agenten dasselbe Prinzip wie für jede andere Interaktion mit einem Assistenzsystem: Jemand muss den Anstoß geben. Ein Prompt, ein Klick, ein Kommando. Mit geplanten Agent Tasks entfällt dieser Anstoß. Die Aufgabe liegt hinterlegt vor und läuft, wenn der Zeitpunkt erreicht ist.

Was ein Agent Task ist

Ein Agent ist in diesem Zusammenhang mehr als eine Autovervollständigung. Er arbeitet mehrschrittig: Er liest Dateien, führt Befehle aus, prüft Ergebnisse und nimmt Änderungen vor. Ein Agent Task fasst so eine mehrschrittige Aufgabe in wiederverwendbarer Form zusammen — vergleichbar mit einem hinterlegten Arbeitsauftrag, der immer gleich abläuft.

Die Neuerung besteht darin, diesen Auftrag mit einem Zeitplan zu verknüpfen. Damit rückt der Editor näher an das Modell, das aus der Automatisierung von Build- und Test-Prozessen bekannt ist: Etwas passiert, weil eine Uhrzeit erreicht ist, nicht weil jemand daran gedacht hat.

Wofür sich das anbietet

Die Meldung nennt keine feste Liste von Anwendungsfällen. Naheliegend sind allerdings genau jene Tätigkeiten, die in Projekten regelmäßig anfallen und regelmäßig liegen bleiben:

  • eine erste Durchsicht offener Änderungen, bevor ein Mensch das Review übernimmt
  • das Prüfen von Abhängigkeiten auf neue Versionen und bekannte Sicherheitsprobleme
  • wiederkehrende Test-Läufe und das Zusammenfassen von Fehlermeldungen
  • das Aufspüren von Inkonsistenzen in Dokumentation, Konfiguration oder Übersetzungsdateien

Gemeinsam ist diesen Aufgaben, dass sie wenig Kreativität und viel Regelmäßigkeit verlangen. Sie sind selten dringend, bis sie plötzlich dringend sind. Genau deshalb verschwinden sie im Tagesgeschäft — und genau deshalb profitieren sie von einem Zeitplan.

Warum das im Wartungsbudget sichtbar wird

In Wartungsverträgen steckt ein erheblicher Anteil an Routine. Jemand schaut nach, ob Pakete veraltet sind. Jemand liest ein Änderungsprotokoll. Jemand startet einen Testlauf und interpretiert das Ergebnis. Diese Arbeit ist notwendig, sie ist aber selten der Grund, aus dem ein Unternehmen ein Digitalprojekt beauftragt.

Wenn ein Teil dieser Vorarbeit außerhalb der Arbeitszeit passiert und morgens als aufbereiteter Befund vorliegt, verschiebt sich das Verhältnis. Das Team beginnt nicht mit der Suche, sondern mit der Entscheidung. Für Auftraggeber bedeutet das im günstigen Fall kürzere Wartungszyklen und mehr Spielraum für Funktionen, die tatsächlich am Geschäftsmodell arbeiten.

Realistisch bleibt allerdings: Ein Agent liefert Vorschläge und Befunde, nicht Gewissheit. Die fachliche Bewertung, ob ein Update eingespielt werden darf, ob ein Testfehler ein echtes Problem beschreibt oder ob eine vorgeschlagene Änderung zur Architektur passt, bleibt beim Team.

Was vorher geklärt sein muss

Automatisierung, die ohne menschlichen Auslöser startet, braucht klare Grenzen. Drei Punkte sind vor der Einführung zu klären.

  1. Rechte und Reichweite. Was darf der Agent lesen, was darf er ausführen, was darf er verändern? Ein Lauf, der Befunde sammelt, ist etwas anderes als ein Lauf, der Änderungen einreicht.
  2. Nachvollziehbarkeit. Jeder Durchlauf sollte dokumentiert sein: Was wurde geprüft, was wurde vorgeschlagen, was hat der Mensch daraus gemacht? Ohne Protokoll entsteht Automatisierung, die niemand mehr erklären kann.
  3. Zuständigkeit für die Ergebnisse. Ein Zeitplan produziert verlässlich Output. Wenn diesen Output niemand liest, entsteht statt Entlastung eine zweite Warteschlange.

Der letzte Punkt ist der häufigste Stolperstein. Automatisierte Berichte, die ins Leere laufen, sind kein Fortschritt gegenüber Aufgaben, die niemand erledigt — sie erzeugen nur zusätzlich das Gefühl, es sei etwas passiert.

Sinnvoll starten

Empfehlenswert ist ein enger Einstieg: eine einzige wiederkehrende Aufgabe, ein klar definierter Zeitpunkt, reine Befundsammlung ohne schreibende Zugriffe. Nach einigen Wochen lässt sich beurteilen, ob die Ergebnisse belastbar sind und ob sie im Team wirklich verwendet werden. Erst dann lohnt es sich, die Reichweite auszuweiten oder weitere Aufgaben aufzunehmen.

Für Web- und Softwareprojekte ist die Neuerung weniger eine technische Sensation als eine organisatorische Einladung. Sie verschiebt Routinearbeit dorthin, wo sie ohne Aufmerksamkeit erledigt werden kann, und macht damit sichtbar, wie viel Wartungsbudget bislang in Suche und Prüfung statt in Weiterentwicklung geflossen ist. Den Nutzen zieht daraus jedoch nur, wer vorher festlegt, wer die Ergebnisse liest, entscheidet und verantwortet — die Technik plant Termine, nicht Zuständigkeiten.

Quellen