Agentic Development: Von der Assistenz zur Autonomie

Wir bauen das Gerüst, das KI-Agenten führt und prüft. Für Software, die nicht nur schnell geschrieben ist, sondern dauerhaft trägt.
Zwei Bundesportale und unsere eigenen Werkzeuge entwickeln wir bereits agentisch — vom ersten Konzept bis zum Release. Entdecken Sie, wie autonome KI komplexe Aufgaben übernimmt und Entwicklern Zeit für Architektur und Qualitätssicherung gibt.
Der Aufhänger

Der Motor ist nicht Ihr Wettbewerbsvorteil

«Power is nothing without control.»

Werbeclaim von Pirelli, seit 1994
Fünf Wörter aus einer Reifenwerbung sagen, worum es hier geht. Der Motor war nie das Problem. Entscheidend war immer, was davon auf der Strasse ankommt. Bei der Softwareentwicklung mit KI ist der Motor heute für alle gleich. Ihr Mitbewerber nutzt dasselbe Modell wie Sie, zum selben Preis, ab morgen früh. Der Unterschied entsteht erst danach — in dem, was um das Modell herum gebaut ist. Wer dabei am Steuer sitzt, bleibt unverändert: Sie fahren. Wir liefern den Grip — das Gerüst, das aus Motorleistung eine Strecke macht, die Sie auch bei Tempo halten können.
Die Methode

Was Agentic Development konkret heisst

Agentic Development bedeutet, dass Software-Ingenieure ihre Arbeit gemeinsam mit autonomen KI-Agenten erledigen. Diese Werkzeuge lesen selbstständig Code, schlagen Änderungen vor, führen Tests aus und korrigieren sich selbst. Der Mensch führt, prüft und verantwortet die Architektur. Das Tempo entsteht durch die Automatisierung von Routineaufgaben. Die Qualität sichern wir durch ein Gerüst, das keinen Fehler ungeprüft durchlässt. So gewinnen Entwickler wertvolle Zeit für Systemdesign und Nutzerwert. Die Frage ist nicht, ob man damit anfängt, sondern wo. Wir unterscheiden fünf Stufen der Reife:
  1. Stufe 1 · Context Engineering

    Was der Agent weiss und was im Kontextfenster landet.

  2. Stufe 2 · Harness Engineering

    Was Agenten führt und prüft, bevor ein Mensch den Code sieht.

  3. Stufe 3 · Spec-based Development

    Was vorher entschieden ist und wie Abweichungen sichtbar werden.

  4. Stufe 4 · Der agentische Ablauf

    Wie der Ablauf funktioniert und wer die Feder hält.

  5. Stufe 5 · Multi-Agent Development

    Wie viele Agenten gleichzeitig arbeiten und wo die Grenzen liegen.

Die meisten Teams stehen weiter unten, als sie denken. Die nächsten Abschnitte zeigen, was jede Stufe leistet.

Wer macht was

  • Der Agent arbeitet

    Jeder Schritt bleibt einzeln nachweisbar

  • Der Mensch entscheidet

    Beides zusammengehalten vom Harness

  • Das Harness sichert ab

So können mehrere Entwickler gleichzeitig mehrere Agenten führen, ohne sich in die Quere zu kommen — nicht weil alle gut aufpassen, sondern weil das Harness es ausschliesst.

Stufe 1 · Context Engineering

Was der Agent weiss

Was in das Kontextfenster kommt, entscheidet sich pro Schritt: Was kommt herein, was wird verdichtet, was wird bei Bedarf nachgeladen, was bleibt draussen. Die Arbeitseinheit ist das Token-Budget, nicht der Prompt.
Daten-QuelleRepositoryGit-HistorieunstrukturierteDateienContext EngineeringToken-BudgetAktives KontextfensterSpezifische SkillsKompakterCode-AusschnittAktuelle AufgabeAgentpräzise LeistungVolles, ungefiltertes KontextfensterAgentLeistungsabfall

«Context engineering is the natural successor to prompt engineering: the question is no longer which words to use but which configuration of context most reliably produces the behaviour you want.»

Anthropic, «Effective context engineering for AI agents», September 2025
Die Forschung stützt das: Chroma hat gemessen, dass die Leistung mit wachsender Eingabe fällt — unabhängig von der nominellen Fenstergrösse. Ein grosses Kontextfenster ist ein Budget, keine Kapazität.Woran Sie merken, dass sie fehlt: Agenten, die in der zehnminütigen Demo überzeugen und über eine lange Sitzung verfallen. Der Fehler wird dem Modell zugeschrieben; tatsächlich ist das Aufmerksamkeitsbudget erschöpft und das Fenster voll veralteter Details.Bei uns entsteht daraus etwas Sichtbares: die Skills. Was ein Agent über ein Repository wissen muss — Konventionen, Ablagen, wie hier gebaut wird — steht als wiederverwendbare Arbeitsanweisung da, statt in jedem Auftrag neu erraten zu werden. Sie liegen offen auf GitHub.

Was der Agent weiss, hilft nur, wenn es zum richtigen Zeitpunkt greift. Das ist die nächste Stufe.

Stufe 2 · Harness Engineering

Was Agenten führt und prüft

Ein Agent ist Modell plus Harness. Das Harness hat zwei Richtungen: Guides steuern, bevor der Agent handelt. Sensors prüfen, nachdem er gehandelt hat.
Guides ·FeedforwardKontext (Repo, Skills)Modell / KI-AgentSensors · FeedbackVor dem CommitHooks, Formatierung, LintingminimalSekundentaktTypprüfung, schnelle Unit-TestsgünstigMinutentaktVollständige Testsuite,Review-AgentmittelFortlaufendDrift-Sensoren, Abgleich vonPlan und CodedauerhaftAutomatisierte Korrektur

«Feedback alone gives you an agent that repeats its mistakes; feedforward alone gives you one that encodes rules and never learns whether they held.»

Birgitta Böckeler, Thoughtworks, «Harness Engineering for Coding Agent Users», April 2026
Böckeler ordnet die Kontrollen zusätzlich nach Art und Zeitpunkt: Berechenbare Kontrollen sind schnell und eindeutig — Typprüfung, Linter, strukturelle Tests. Urteilende Kontrollen tragen semantisches Urteil — Konventionen, Skills, Review-Agenten. Verteilt werden sie nach Kosten: billige vor dem Commit, teure nach der Integration, Drift-Sensoren fortlaufend daneben.Woran Sie merken, dass es fehlt: Sie sind der Sensor. Jeder Fehler kommt über ein menschliches Review zurück, derselbe nächste Woche wieder, und die Korrektur steht in einer Chatnachricht, die niemand versionieren kann.Bei uns greifen Guides an definierten Punkten automatisch. Die Sensors bilden eine Kette: Linting, Kompilieren, Unit, Mock, Integration, UI. Vieles davon ist generisch und wiederverwendbar (wie ESLint oder Prettier) und hängt nicht vom fachlichen Kontext ab. Die Reihenfolge ist die Regel: Was eine Maschine eindeutig entscheiden kann, entscheidet eine Maschine. KI kommt erst dort zum Zug, wo ein Urteil nötig ist.

Prüfen kann nur, was vorher jemand als Erwartung formuliert hat. Das ist die nächste Stufe.

Stufe 3 · Spec-based Development

Was vorher entschieden ist

Der Plan ist keine flüchtige Chatnachricht mehr, sondern ein versioniertes Artefakt im Repository. Diese Arbeitsweise heisst Spec-based Development: erst die Spezifikation, dann die Implementierung. Wir setzen das mit unserem eigenen Werkzeug Plot um. Pläne werden vorgeschlagen, geprüft, freigegeben und geliefert — mit derselben Sorgfalt wie Code. Weil Plan und Ergebnis beide in Git liegen, werden Abweichungen sofort sichtbar.
Der Plot-Workflow · Spec-based Development in GitPlanvorgeschlagenSpezifikation alsPlanReview undFreigabeFreigabe mitApproverUmsetzung durchAgentenUmsetzung als PullRequestLieferung undMergeUmgesetzter Planmit Changelog!Ohne Spezifikation · unkontrollierter Pfad!Umfang wandert!Sitzung bricht ab!Wissen gehtverlorenPlanung ist das Gegengewicht zur Komplexität
Das ist der Punkt, an dem Absicht überprüfbar wird. Und es ist die Antwort auf die Lücke aus Stufe 2: Der funktionale Spec ist der Feedforward-Kontrollpunkt für Verhalten — die eine Kategorie, für die es keinen vertrauenswürdigen Sensor gibt. Wer nie klar gesagt hat, was er wollte, kann von keinem Test erfahren, ob er es bekommen hat.Woran Sie merken, dass er fehlt: Der Umfang wandert unbemerkt. Niemand kann rekonstruieren, warum vor drei Sprints so entschieden wurde. Eine unterbrochene Sitzung lässt sich nicht fortsetzen, und die Erkundung des Agenten ist durch nichts begrenzt ausser dadurch, wie viel er zufällig gelesen hat.Bei uns heisst das Plot — quelloffen unter CC0. Pläne liegen als Markdown im Repository, Pull Requests sind die Ablaufdaten, Git ist die einzige Quelle der Wahrheit. Der stärkste Beleg: Wir planen diese Website damit. Das ist zugleich die Bedingung dafür, dass viele Aufgaben überhaupt gleichzeitig laufen können. Ein unklarer Auftrag kostete früher eine Entwicklerwoche; parallel geführt kostet er so viele Zweige, Pull Requests und Reviews, wie Agenten daran hängen. Was vorne unentschieden bleibt, vervielfacht sich hinten.
Einordnung: Thoughtworks führt spec-driven development im Technology Radar unter «Assess», nicht unter «Adopt» — mit dem Hinweis, dass die Abläufe aufwendig sind und manche Werkzeuge Spec-Dateien erzeugen, die niemand mehr prüfen mag. Kritiker nennen es «Wasserfall in neuen Kleidern». Die Gegenrechnung ist empirisch: Eine Untersuchung von 806 Repositories fand nach Cursor-Einführung einen grossen, aber vorübergehenden Tempogewinn — und einen bleibenden Anstieg von Warnungen und Komplexität.

Ein freigegebener Plan ist die Bedingung dafür, dass eine Schleife überhaupt eine Abbruchbedingung hat.

Stufe 4 · Der agentische Ablauf

Wie der Ablauf funktioniert

Jede Phase endet mit einem Artefakt, das jemand verantwortet — nicht mit einer formlosen Übergabe. So überlebt die Arbeit die einzelne Session.
Phase 1DiscoveryFreigegebene StoryDer Mensch schreibt,Agenten beratenUnterschrift 1Freigegebene StoryPhase 2DesignFreigegebene Pläne, inPakete geschnittenDer Mensch entscheidet,der Agent formuliertUnterschrift 2Freigegebener PlanPhase 3DevelopmentUmsetzung in getrenntenArbeitsbereichenhandelnSensoren lesenkorrigierenDer Agent baut, der Menschführt zusammenUnterschrift 3PR mit grünem CIPhase 4TestingGeprüfte FreigabeDer Agent schreibt dasSkript, das Team arbeitetes abUnterschrift 4Gelieferter Plan ohneDrift, Endgame-ProtokollUnit, Integration,E2E — automatischFreigabe mit Name und Datum im Artefakt
  1. Discovery

    human-led

    Eine freigegebene Story: dieses Problem wird gelöst, an dieser Stelle im System

    Der Mensch schreibt, Agenten beraten

  2. Design

    human-led

    Freigegebene Pläne, geschnitten in Pakete, die wirklich parallel laufen

    Der Mensch entscheidet, der Agent formuliert

  3. Development

    agent-led

    Umsetzung in getrennten Arbeitsbereichen

    Der Agent baut, der Mensch führt zusammen

  4. Testing

    agent-led

    Eine geprüfte Freigabe

    Der Agent schreibt das Skript, das Team arbeitet es ab

Zwei Stellen tragen eine Unterschrift mit Namen und Datum: die freigegebene Story und der freigegebene Plan. Beide stehen im Artefakt selbst — wer, wann, über welchen Weg.

Das Endgame

So nennen wir den Teil, in dem wir unser eigenes Ergebnis spielen — nicht um zu bestätigen, dass der Hauptweg funktioniert, sondern um zu finden, was rechts und links davon schiefgeht. Automatisierte Tests decken, was vorher als Erwartung formuliert war. Was dahinter liegt, schreibt der Agent als Skript; das Team arbeitet es ab, dort wo nur ein Mensch urteilen kann: Brauchbarkeit, Bedienbarkeit, was im Ablauf fehlt. Fokussierte Arbeit am richtigen Ort, statt Suchen im Ganzen.

Diese vier Stufen tragen einen Agenten. Die fünfte fragt, was passiert, wenn es mehrere sind.

Stufe 5 · Multi-Agent Development

Wie viele gleichzeitig

Diese Stufe ist freiwillig. Viele Teams stoppen nach der vierten Stufe. Was sie dabei aufgeben, ist Durchsatz bei Aufgaben, die sich parallelisieren lassen.
IsolationsgrenzeOrchestriert · AnthropicOrchestratorIsolierte Aufgabenkontrollierte SyntheseSubagentFrischesKontextfenster(Token-Budget)SubagentFrischesKontextfenster(Token-Budget)SubagentFrischesKontextfenster(Token-Budget)SubagentFrischesKontextfenster(Token-Budget)Getrennte SyntheseCodebasisKonfliktfall · CognitionCodebasis!Widersprüchlicher Codez. B.unvereinbare KonventionenScharfe Isolationsgrenze? Parallelität zahlt sich aus. Überlappende Entscheidungen? Ein Agent mit mehr Denkzeit.

«An orchestrator plans, spins up three to five subagents with fresh context windows, then synthesises with a separate citation pass. Workers never talk to each other.»

Anthropic, «How we built our multi-agent research system», Juni 2025
Anthropic misst damit bessere Ergebnisse als mit einem einzelnen Agenten — und einen erheblich höheren Token-Verbrauch. Cognition widerspricht, und zwar ausdrücklich für das Programmieren:

«Parallel agents make independent decisions on a shared problem, and independent decisions produce conflicting output.»

Cognition, «Don't build multi-agents», Juni 2025
Der nüchterne Zusatz: Mehrere Studien aus 2026 relativieren beide Seiten. Bei gleichem Token-Budget erreicht ein einzelner Agent oft dieselben Ergebnisse. Ein Teil des vermeintlichen Koordinationsgewinns ist schlicht ein Gewinn durch mehr Rechenzeit.
Was daraus folgt: Die Koordination beginnt bereits bei der Planung. Mit Plot wird die Arbeit so geschnitten und im Plan markiert, dass sie parallel implementiert werden kann. Wo Aufgaben scharf getrennt sind, zahlt sich Parallelität aus. Wo jede Entscheidung die nächste einschränkt, ist ein zweiter Agent nur ein zweiter Autor, der die Gedanken des ersten nicht kennt.
Die Abgrenzung

Das Drei-Stufen-Modell

Die Entwicklung mit KI verläuft in Stufen. Während klassisches Coden und einfache Code-Vervollständigung (Copilot) den Entwickler bei einzelnen Zeilen unterstützen, übernimmt Agentic Development komplexe Aufgaben eigenständig. Das schafft Freiraum für Architektur und Qualitätssicherung.
  • Arbeitsweise

    Klassisches Coden: Entwickler schreibt jede Zeile Code selbst

    Assistiertes Coden (Copilot): KI schlägt Code-Schnipsel oder Zeilen vor

    Agentic Development: KI übernimmt komplexe Tasks und ganze Features eigenständig

  • Autonomie

    Klassisches Coden: Keine (vollständig manuell)

    Assistiertes Coden (Copilot): Gering (reagiert auf direkten Kontext)

    Agentic Development: Hoch (plant, führt aus und korrigiert sich selbst)

  • Kontext

    Klassisches Coden: Im Kopf des Entwicklers

    Assistiertes Coden (Copilot): Lokale Datei und offene Tabs

    Agentic Development: Spezifiziert: Repo-Konventionen, Architektur, Skills

  • Verifikation

    Klassisches Coden: Manuelles Testen und Review

    Assistiertes Coden (Copilot): Entwickler prüft jeden Vorschlag sofort

    Agentic Development: Automatisierte Tests, Typen, CI und Review-Gates

  • Rolle des Menschen

    Klassisches Coden: Handwerker (schreibt Code)

    Assistiertes Coden (Copilot): Pilot (steuert und korrigiert)

    Agentic Development: Architekt und Reviewer (plant und prüft)

  • Zeitgewinn

    Klassisches Coden: Keiner

    Assistiertes Coden (Copilot): Schnelleres Tippen von Routine-Code

    Agentic Development: Fokus auf Systemdesign, Sicherheit und Nutzerwert

Wirkliche Beschleunigung entsteht nicht durch schnelleres Tippen, sondern durch Autonomie. Ein Team, das Agenten führt und prüft, produziert verlässliche Software in einem Bruchteil der Zeit.

Der Mechanismus

Keine Überraschungen

Dass das Ergebnis trägt — das ist leicht gesagt. Wodurch, ist die Frage. Bei uns durch drei Entscheidungen, die alle in dieselbe Richtung zeigen.
  • Der Agent baut das System. Er ist nicht Teil davon.

    Wir lassen keine Agenten unkontrolliert überwachen und steuern. Wir nutzen sie, um die Systeme zu bauen und zu betreiben, die genau das tun — Automatisierung, Pipelines, Metriken, Dashboards, Release-Engineering. Was danach in Produktion läuft, ist deterministisch: gleiche Eingabe, gleiches Ergebnis. Der Agent hat es gebaut, er entscheidet nicht darin mit.

  • Weniger Code, nicht mehr

    Jede Zeile Code hat Fehler. Ein Agent schreibt zehnmal so schnell — das ist nur dann ein Gewinn, wenn am Ende nicht zehnmal so viel Code steht. Wir messen nicht, wie viel entstanden ist, sondern wie wenig nötig war.

  • Schneller heisst mehr Sicherheitsnetz, nicht weniger

    Wenn Änderungen schneller landen, braucht es mehr Metriken, mehr Monitoring, schnellere Review- und Deploy-Prozesse — um mitzuhalten und um Fehler schnell zu korrigieren. Das agentische Setup selbst ist eine Investition, damit es vorhersagbare Ergebnisse liefert. Es reicht nicht, dasselbe schneller zu tun; es muss besser werden.

Wo das Gerüst an seine Grenze kommt

Ein Ticket aus unserem eigenen Plattform-Projekt: rund 600 Zeilen über drei Schichten, saubere Tests, grüner Build, ordentlich dokumentiert. Jede Prüfung war grün — und das Ergebnis wollte trotzdem niemand haben. Kein Sensor der Welt beantwortet die Frage, ob das Gebaute das Gemeinte ist.

Deshalb verschiebt sich die Arbeit nach vorn. Bei uns heisst das konkret: rund vier Stunden am Tag mit Markdown statt mit Code. Ist der Plan präzise genug, überrascht der Pull Request nicht mehr — und der Aufwand für die Prüfung fällt in sich zusammen.

In der Praxis

Was sich im Handwerk ändert, wenn Agenten mitarbeiten

Steht das Gerüst, tippen wir nicht einfach schneller. Es ändert sich grundlegend, welche Arbeit überhaupt anfällt. Drei Dinge machen wir heute anders als vor zwei Jahren.
  1. Wir bauen den Prototyp statt des Entwurfs

    Früher entstand die Idee in Figma oder Miro und wurde danach nachgebaut. Heute ist der interaktive Prototyp schneller fertig als das Bild davon — und man kann ihn benutzen, statt ihn sich vorzustellen. Diskussionen über Zwischenstände werden dadurch kürzer und ehrlicher.

  2. Wir jagen keine 100 % Testabdeckung

    Ein Agent schreibt Tests fast gratis, und genau das ist die Falle: Wer alles testet, testet nichts richtig — man bekommt Prüfungen, die nur noch Aufwand binden. Das Definition of Done sagt, was geprüft gehört. Und wo ein Agent urteilt statt rechnet, misst eine Zeilenabdeckung ohnehin die falsche Sache; dort prüfen Evals, ob das Urteil taugt.

  3. Wir führen Agenten, statt Aufgaben abzuarbeiten

    Die Arbeit verschiebt sich vom Schreiben zum Schneiden, Prüfen und Entscheiden. Das ist anspruchsvoller, nicht bequemer — und es ist der Grund, warum Erfahrung wichtiger wird statt unwichtiger.

Wann der Agent führt — und wann der Mensch

Agent-led — der Agent führt

  • Gleichartige Änderungen über viele Dateien
  • Testabdeckung dort nachziehen, wo sie fehlt
  • Eine Migration Schritt für Schritt
  • Eine fremde Codebasis erkunden
  • Einen Prototyp bauen, um eine Frage zu klären

Human-led — der Mensch führt

  • Wenn die Anforderung noch unklar ist
  • Wenn eine Architekturentscheidung Erfahrung braucht
  • Wenn ein Fehler teuer wäre
  • Wenn zu entscheiden ist, was «fertig» heisst
  • Und das soll auch so bleiben
Der Beweis

Zwei Bundesportale auf einer Plattform — und unser eigenes Werkzeug

Agentic Development ist bei uns keine Theorie. Naturgefahren.ch und MeteoSchweiz laufen auf einer Multi-Tenant-Plattform — eine Datenpipeline, ein CMS, dieselben Qualitätstore: was für das eine Portal gilt, gilt für das andere. Beide tragen im Ernstfall Menschen. Dazu unser eigenes Werkzeug, an dem wir zuerst herausgefunden haben, ob das Gerüst trägt.
  • Naturgefahren.ch

    Das Naturgefahrenportal führt Gefahrendaten aus mehreren Quellen zusammen und erzeugt daraus Warnungen fürs Web — barrierefrei, nach WCAG 2.1 AA zertifiziert.

    Seit Projektstart entsteht jede Änderung über den agentischen Ablauf.

    Bei einer Unwetterlage greifen alle gleichzeitig zu — deshalb ist das Qualitätstor davor nicht verhandelbar.

    naturgefahren.ch öffnen
  • MeteoSchweiz

    137 Wetterprodukte, ein eigenes Karten-Framework — für das Bundesamt für Meteorologie und Klimatologie.

    Ebenfalls seit Januar 2026: keine Änderung mehr ausserhalb des agentischen Ablaufs.

    Die automatisierten Qualitätstore dieser Anwendung sind kein Nebenprodukt — sie sind das Gerüst, das genau das zulässt.

    Was wir für MeteoSchweiz gebaut haben
  • Offerten-Generator

    Unser eigenes Produkt, in zwei Stufen: Mit dem Prototyp pitchen wir beim Kunden — fünf Varianten laufen öffentlich. Wird daraus ein Auftrag, entsteht daraus die produktive Anwendung auf der CDS-Plattform, mit Zugangskontrolle und weiteren Generatoren.

    Beide Stufen entstehen über den agentischen Ablauf — der erste Prototyp lief im März 2026, an einem einzigen Vormittag.

    Der Prototyp aus dem Pitch ist die Grundlage der produktiven Anwendung — nicht ein Wegwerfstück daneben. Hier haben wir angefangen, an uns selbst, bevor wir es Kunden empfohlen haben.

    Zum Offerten-Generator
Hybride Teams

Wer in einem solchen Projekt eigentlich schreibt

«Der Agent arbeitet, der Mensch entscheidet» ist oben ein Schaubild. In einem laufenden Kundenprojekt — dem Portal-Rebuild für ein Schweizer Treuhandunternehmen, seit Sommer 2026 — kann man nachsehen, ob es stimmt: Das Commit-Log ist das Diagramm, nur als Liste.
  • Fast die Hälfte der Beiträge kommt nicht aus der Entwicklung

    Vertrieb, Finanzen und die Produktverantwortung schreiben mit — nicht als Reviewer am Rand, sondern als Autoren im Log. Wer Anforderungen kennt, kann sie einbringen, ohne sie zu übersetzen.

  • Die Freigaben stehen namentlich im Log

    Wo ein Mensch entschieden hat, steht ein Eintrag mit seinem Namen: Plan freigegeben, Zusammenführung freigegeben. Diese Einträge tragen keine Agenten-Signatur — sie sind die Stellen, an denen jemand die Verantwortung übernommen hat.

  • Ein Agent ist Teammitglied mit eigenem Konto

    In unserem eigenen Firmen-Repository arbeitet Qubert unter eigener Adresse mit — unser erster autonom mitarbeitender Agent. Man sieht in der Historie, wer was geschrieben hat, weil er nicht unter fremdem Namen committet.

Das ist der Punkt: Nicht dass Agenten schneller tippen, sondern dass ein Team breiter wird. Wer die Fachlichkeit kennt, kommt näher an das Ergebnis heran.

Welche Stufe fehlt Ihnen?

Fünf Stufen, und jede trägt schon für sich. Die darunter fehlt selten aus Absicht — meist hat sie nur nie jemand benannt.
Max

Lieber persönlich?

MaxRufen Sie an oder schreiben Sie eine E-Mail — was Ihnen lieber ist.