Die Entscheidungen, die dir der Agent überlässt – Acht Stellen, an denen du führen musst

In der vorherigen Lesson hast du das Gelände kennengelernt. Frontend, Backend, Datenorte, State, APIs, Umgebungen. Du weißt, wo was wohnt und wie die Teile zusammenhängen. Diese Lesson nutzt diese Karte als Arbeitsinstrument.

Der Agent baut für dich. Er übernimmt die Mechanik: tippt den Code, verkabelt die Teile, deployt auf einen Server. An acht Stellen aber hält er entweder inne oder entscheidet still für dich. Diese acht Stellen zu erkennen ist die eigentliche Kompetenz, die du als Nicht-Entwicklerin brauchst.

Wie diese Lesson aufgebaut ist

Acht Entscheidungen, jede mit derselben Struktur. Du siehst, in welcher Situation der Agent still entscheidet. Du verstehst die Frage, die im Raum steht. Du bekommst das Mindestwissen, um qualifiziert zu antworten. Du siehst die typische Fehlentscheidung, die passiert, wenn du nichts sagst. Und du nimmst eine Faustregel mit, die in 80 Prozent der Fälle trägt.

Die acht Entscheidungen im Überblick

1. Was ist das für ein Ding, das ich baue? Die Meta-Entscheidung, aus der alles folgt.
2. Wo leben meine Daten, und wem gehören sie? Standort, Schema, DSGVO.
3. Wo lebt der Zustand? Drei Orte, eine Wahrheit.
4. Wer darf was? Authentifizierung ist nicht Autorisierung.
5. Welche fremden Systeme binde ich an? Jede Anbindung ist eine Ehe.
6. Wie gehe ich mit Geheimnissen um? API-Keys sind Kreditkarten ohne PIN.
7. Dev oder Prod? Wo arbeite ich gerade? Drei Welten, drei Konsequenzen.
8. Wann ist es kein Prototyp mehr? Die Schwelle, ab der du haftest.

Die Situation. Du sagst dem Agenten, was du bauen willst. Er fängt an. Was er nicht fragt: Wer nutzt das später eigentlich? Er nimmt etwas an. Aus dieser einen stillen Annahme folgen alle weiteren Entscheidungen über Architektur, Auth, Hosting, Backups. Die Annahme ist meist die bequemste, nicht die richtige.

Die Frage

Wer nutzt das Tool? Wie viele Leute? Mit welchen Daten? Was passiert, wenn es ausfällt? Wer übernimmt Verantwortung, wenn etwas schiefgeht? Fünf Fragen, die zusammen die Meta-Entscheidung formen.

Das Mindestwissen

Es macht einen großen Unterschied, ob das Tool von dir allein, deinem Team, externen Teilnehmern oder zahlenden Kunden genutzt wird. Jede Stufe verändert die Anforderungen an Auth, Datenschutz und Ausfallsicherheit. Architektur, die für fünf Leute richtig wäre, ist für zweihundert falsch. Sie sieht zwar nach wie vor aus wie Code, deshalb fragt sie niemand mehr nach.

Beispiel: Ein internes Bewerbungs-Tool

Eine HR-Beraterin lässt sich ein Bewerbungs-Tool bauen. Erste Version: Nur sie loggt sich ein. Drei Wochen später: Drei Kolleginnen wollen mitarbeiten. Zwei Monate später: Externe Bewerber sollen sich selbst eintragen können. Ein halbes Jahr später: Mehrere Mandanten wollen ihre eigenen, getrennten Bewerber-Pools. Zwischen Stufe 1 und Stufe 4 liegen Welten an Architektur. Wer in Stufe 1 baut, ohne wenigstens Stufe 2 mitzudenken, baut die App ein zweites Mal von Grund auf.

Die Situation. Der Agent will Daten speichern. Wenn du nichts sagst, nimmt er den bequemsten Ort: eine Cloud-Datenbank irgendwo, ein lokales JSON-File, eine SQLite-Datei. Was er selten fragt: Wo sollen die Daten physisch liegen, wem gehören sie, wie sieht das Schema aus.

Die Frage

Welche Daten fallen hier an? Wer sind die Betroffenen? Wie sensibel ist das Material? Wo soll es physisch liegen, in der EU oder anderswo? Und vor allem: Wie sieht das Schema aus?

Das Mindestwissen

Aus der vorherigen Lesson kennst du die drei Datenorte und das Schema als Fundament-Entscheidung. Neu hier: die DSGVO-Dimension und die Tatsache, dass das Schema die teuerste spätere Änderung ist. Eine Migration des Datenmodells nach drei Wochen produktivem Betrieb ist schmerzhaft. Dann sind echte Daten drin, Beziehungen sind angelegt, Reports laufen. Jede Schema-Änderung muss alles bestehende mitziehen.

Beispiel: Mandanten-Tracking für eine Anwaltskanzlei

Eine kleine Kanzlei lässt sich ein Tool bauen, das Mandanten und Mandate verwaltet. Personenbezogene Daten, teilweise sehr sensibel (Strafsachen, Familienrecht). EU-Hosting ist Pflicht, ein US-Cloud-Anbieter mit Standardvertrag reicht hier nicht. Das Schema sollte vor dem ersten Build stehen: Mandant, Mandat, Kommunikation, Akte, Rechnung. Vier oder fünf Entitäten, drei Beziehungen, drei bis fünf Pflichtfelder pro Entität. Wer das mit dem Agenten klärt, bevor er loslegt, spart sich das Re-Build.

Die Situation. Der Agent baut eine Funktion. Irgendwo muss der Zustand leben. Per Default wählt er den bequemsten Ort. Nicht den richtigen. Erst wenn ein Bug auftritt oder ein Reload alles vergisst, wird sichtbar, dass die Wahl wichtig war.

Die Frage

Muss diese Information über den Reload hinaus bleiben? Muss sie auch für andere Nutzer sichtbar sein? Darf sie verloren gehen?

Das Mindestwissen

Aus der vorherigen Lesson bekannt: drei State-Orte. In zwei Sätzen zusammengefasst. Wahrheit gehört in die Datenbank. Temporäre UI-Zustände gehören in den Browser. Session-Zeug gehört in den Server.

Beispiel: Online-Umfrage-Tool

Du baust ein kleines Umfrage-Tool. Vier Arten von Information, vier verschiedene State-Orte. Das halb ausgefüllte Formular eines Befragten: Browser, in Ordnung. Die abgesendete Antwort: niemals nur Browser, immer Datenbank. Die Login-Sitzung des Admins, der die Auswertung anschaut: Server. Welche Umfragen welchem Account gehören: Datenbank. Wer das einmal pro Information durchspielt, baut keine App, die beim ersten Reload alles vergisst.

Die Situation. Der Agent baut ein Login. Er fragt: Sollen sich Nutzer anmelden können? Du sagst ja. Er baut das Login. Du denkst: fertig. Falsch. Login ist nur die halbe Antwort.

Die Frage

Wenn jemand eingeloggt ist, was darf diese Person sehen und tun? Darf Nutzer A die Daten von Nutzer B sehen? Darf Mitarbeiterin X eine Aufgabe löschen, die nicht ihre ist? Kann ein Kunde nachträglich Bestellungen anderer Kunden einsehen?

Das Mindestwissen

Authentifizierung ist nicht Autorisierung. Eine Flughafen-Metapher hilft. Den Ausweis zeigen klärt: Wer bist du? Das ist Authentifizierung. Die Bordkarte zeigen klärt: Was darfst du, in welche Maschine, in welche Reihe? Das ist Autorisierung. Beides wird gebraucht. Beides ist verschieden. Der Agent baut Authentifizierung typischerweise solide. Bei der Autorisierung liegt die häufigste schwere Sicherheitslücke von Tools, die mit KI-Coding gebaut wurden.

Beispiel: Eine Aufgaben-App für mehrere Teams

Stell dir eine schlanke Aufgaben-App vor, mit der mehrere Teams arbeiten. Team A soll die Aufgaben von Team B nicht sehen. Innerhalb Team A soll die Team-Leiterin alle Aufgaben sehen, ein Mitglied nur die eigenen. Mitglieder dürfen löschen, was sie selbst angelegt haben, sonst nichts. Diese vier Regeln müssen explizit formuliert und durchgesetzt werden, pro Tabelle und pro Aktion. Der Agent macht das nicht von allein richtig. Erst wenn du es ihm sagst.

Die Situation. Der Agent schlägt vor: „Lass uns einen Mail-Dienst nehmen, um die Einladungen zu verschicken.“ Oder: „Wir binden ein Formular-Tool ein.“ Oder: „Für die Auswertung nutzen wir die Claude-API.“ Du sagst ja, weil du es nicht besser weißt. Der Agent verkabelt.

Die Frage

Was passiert, wenn dieses fremde System wegfällt, langsamer wird, seine Preise ändert? Welche meiner Daten gebe ich an wen? Wie binde ich es an, synchron oder asynchron? Webhook oder Polling?

Das Mindestwissen

Aus der vorherigen Lesson bekannt: API als Vertrag, synchron versus asynchron, Webhooks versus Polling. Neu hier: Jede Anbindung ist eine Ehe. Du übergibst Vertrauen, Daten, eine Abhängigkeit. Der Agent vergleicht keine Anbieter, er nimmt den, den er aus seinen Trainingsdaten kennt. Er denkt auch nicht darüber nach, was passiert, wenn der Anbieter ausfällt oder seine Bedingungen ändert.

Beispiel: Newsletter-Tool für ein kleines Unternehmen

Du baust ein Newsletter-Tool. Erste Frage: Welcher Mail-Anbieter? Mailchimp ist bekannt, aber teuer ab einer gewissen Empfänger-Zahl. Brevo ist günstiger, hat andere Vertragsbedingungen. Beide sitzen außerhalb der EU, beide bekommen die E-Mail-Adressen deiner Empfänger. Zweite Frage: Was, wenn der Anbieter eine Stunde lang Probleme hat? Verschickt das Tool später automatisch nach, oder gehen die Mails verloren? Dritte Frage: Welche zusätzlichen Daten landen beim Anbieter (Vor- und Nachname, Tags, Klick-Verhalten)? Das ist DSGVO-relevant. Drei Fragen, eine Anbindung. Wer sie nicht stellt, bemerkt die Antworten erst, wenn etwas schiefgeht.

Die Situation. Der Agent braucht einen API-Key. Für den Mail-Dienst, für die KI, für den Hosting-Anbieter. Du pastest den Key in den Chat. Der Agent schreibt ihn direkt in den Code. Du deployst. Auf den ersten Blick funktioniert alles.

Die Frage

Wohin mit dem Key?

Das Mindestwissen

Niemals im Code. Niemals in Git. Immer in Umgebungsvariablen: lokal in einer .env-Datei, beim Hosting in den Environment-Variablen des Anbieters. Der einfache Satz: Der Code liest den Key aus der Umgebung, er enthält ihn nicht. Auch nicht in privaten Repositories, denn auch private Repos können geteilt werden, gebackupt werden, Forks bekommen, neue Mitarbeitende hinzubekommen.

Beispiel: Eine kleine Wetter-App

Du baust dir eine kleine Wetter-App, die OpenWeatherMap für die Daten nutzt. Du brauchst einen API-Key. Default des Agenten: in den Code, ein Wert in Anführungszeichen, fertig. Richtig: in eine .env-Datei lokal und in die Environment-Variablen beim Hosting-Anbieter. Der Code liest den Key beim Start aus der Umgebung. Wer den Quelltext liest, sieht nur den Verweis, nicht den Key selbst. Wer das Repo klont, bekommt keinen funktionierenden Zugang, sondern muss seinen eigenen Key eintragen.

Die Situation. Der Agent ist bereit, Änderungen anzuwenden. Worauf? Auf deine lokale Test-Datenbank oder auf die echte, in der schon produktive Daten liegen? Der Agent fragt das nicht zuverlässig. Er macht, was du sagst.

Die Frage

Bin ich gerade an Testdaten oder an echten Daten? Was passiert, wenn ich diese Aktion unwiderruflich mache?

Das Mindestwissen

Aus der vorherigen Lesson bekannt: drei Welten (Dev, Staging, Prod). Neu hier: Der Agent kennt diesen Unterschied oft nicht von allein. Er führt aus, was du befiehlst, auch wenn das bedeutet, dass er in Prod experimentiert. Außerdem: Git als Minimum-Versionierung. Du musst nicht Git-Profi sein, aber wissen, dass dein Tool (Replit, Cursor, Lovable) Checkpoints unterstützt, und sie nutzen.

Eine Analogie, die hilft: Umbau am bewohnten Haus. Entweder du ziehst aus und der Bagger darf rein. Oder du bleibst drin, und niemand mit einem Vorschlaghammer darf über die Schwelle. Prod ist das bewohnte Haus.

Beispiel: Eine Buchhaltungs-App im laufenden Betrieb

Eine Selbständige hat sich vor sechs Monaten eine kleine Buchhaltungs-App bauen lassen. Inzwischen liegen darin echte Rechnungen, der Steuerberater hat Zugriff, das Finanzamt hat im November alles für die Erklärung gesehen. „Mal eben“ das Datenmodell anpassen, weil ein Feld besser anders heißen sollte? Geht nicht ohne Migrations-Plan. „Mal eben“ eine Test-Tabelle leeren? Niemals, ohne vorher zu prüfen, ob es nicht doch die echte ist.

Die Situation. Du hast dein Tool gebaut. Es funktioniert. Du zeigst es einer Kollegin. Sie nutzt es. Eine zweite nutzt es. Du gibst den Link an einen externen Bekannten, der es ausprobieren will. Erste echte Runde mit fremden Menschen.

Die Frage

Ab wann ist das Ding kein Experiment mehr, sondern ein System, für das du Verantwortung trägst?

Das Mindestwissen

Der Code ändert sich nicht beim Übergang. Deine Verantwortung schon. Vier Schwellen, die du erkennen können musst:

• Erste echte Daten (statt Test-Daten) → Backup-Frage stellen
• Erster fremder Nutzer (statt nur du) → Auth und Autorisierung schärfen
• Erste rechtlich relevante Transaktion (Bezahlung, Vertrag, Anmeldung) → DSGVO und Haftung klären
• Erster Ausfall, den jemand merkt → Monitoring und Erreichbarkeit einrichten

Jeder dieser Punkte ist eine stille Grenze. Der Agent merkt sie nicht. Er baut weiter, als wäre noch alles Experiment.

Beispiel: Eine Webapp, die du im Demo-Termin zeigst

Du hast eine kleine Webapp gebaut und sie im internen Demo-Termin gezeigt. Sie funktioniert. Drei Kolleginnen wollen sie nutzen. Du gibst den Link weiter. Ist sie jetzt noch ein Prototyp oder schon ein internes Tool? Sobald die Kolleginnen sich auf das Tool verlassen, hat es Verantwortung. Spätestens dann gehören dazu: ein Backup, eine geklärte Autorisierung, eine Person, die ansprechbar ist, wenn etwas nicht funktioniert.

Acht Entscheidungen durchgearbeitet. Du hast keine Programmiersprache gelernt, kein Framework, kein Tool. Du hast die acht Stellen kennengelernt, an denen ein Coding-Agent stillhält oder still für dich entscheidet. Genau dort bleibst du zuständig, auch in zwei Jahren noch, wenn die Agenten viel besser geworden sein werden.

Die acht Faustregeln auf einen Blick

Was du jetzt hast

Du bist nicht Architektin geworden. Du bist eine Auftraggeberin geworden, die die richtigen Fragen stellt. Wenn du diese acht Stellen erkennst, sobald der Agent dorthin kommt, und wenn du eine Faustregel pro Stelle im Kopf hast, reicht das erstaunlich weit. Tools, die so entstehen, halten länger als sechs Wochen. Sie tragen auch dann noch, wenn aus zwei Nutzerinnen zehn werden.

Begriffe aus dieser Lesson

• API — Ein Vertrag zwischen zwei Systemen. Sie beschreibt, welche Anfragen in welchem Format geschickt werden dürfen und welche Antworten zurückkommen. Ändert eine Seite den Vertrag, bricht die andere.
• API-Key — Ein geheimer Schlüssel, der gegenüber einer fremden API belegt, wer du bist und dass du zahlen darfst. Gehört niemals in den Code oder ins Repository. Immer in Umgebungsvariablen. Ein API-Key im öffentlichen Repo ist eine Kreditkarte ohne PIN.
• Authentifizierung und Autorisierung — Zwei Konzepte, die ständig verwechselt werden. Authentifizierung klärt „Wer bist du" (Login, Ausweis zeigen). Autorisierung klärt „Was darfst du" (welche Daten sehen, welche Aktionen ausführen). Beide sind nötig, beide sind verschieden.
• Backend — Der Teil einer Anwendung, der entscheidet, speichert und rechnet. Läuft auf einem Server, nicht im Browser. Der Nutzer kann ihn nicht direkt manipulieren. Hier liegen Sicherheit, Wahrheit und die Verbindung zur Datenbank.
• Datenbank — Ein strukturierter Ort für dauerhafte Daten. Anders als eine einzelne Datei kann eine Datenbank gezielt abgefragt werden, erlaubt gleichzeitiges Schreiben mehrerer Nutzer und fasst mehrere Schritte zu einer Einheit zusammen.
• Dev, Staging, Prod — Drei Welten, in denen dieselbe Anwendung gleichzeitig lebt. Dev zum Experimentieren, Staging als Generalprobe, Prod für echte Nutzer mit echten Daten. Gleicher Code, unterschiedliche Konfiguration, grundverschiedene Konsequenzen bei Fehlern.
• Frontend — Der Teil einer Anwendung, den der Nutzer sieht und bedient. Buttons, Formulare, Navigation. Läuft im Browser und ist für den Nutzer lesbar und veränderbar. Alles, was dort passiert, muss das Backend noch einmal prüfen.
• IDOR — IDOR (Insecure Direct Object Reference) ist eine Sicherheitslücke, bei der ein eingeloggter Nutzer fremde Daten abrufen kann, indem er einfach eine andere ID in die Anfrage setzt. Die App prüft, DASS jemand eingeloggt ist, aber nicht, ob ihm die Daten GEHÖREN.
• Migration — Eine kontrollierte Änderung am Datenbank-Schema, die bestehende Daten mitnimmt. Neues Feld, umbenannte Tabelle, geänderte Beziehung. Migrationen werden als Schritt-für-Schritt-Skripte geschrieben und sind der teuerste Moment im Datenbank-Leben.
• Schema — Die Struktur einer Datenbank. Sie legt fest, welche Entitäten es gibt (zum Beispiel Kunde, Bestellung, Produkt), welche Felder sie haben und wie sie zusammenhängen. Das Schema nachträglich zu ändern ist der teuerste Moment im Lebenszyklus.
• State — Wie die Welt einer Anwendung gerade aussieht. Wer eingeloggt ist, was im Warenkorb liegt, welcher Filter aktiv ist. State lebt an drei Orten gleichzeitig (Browser, Server, Datenbank). Bugs entstehen, wenn die drei auseinanderlaufen.
• Umgebungsvariable — Ein Konfigurationswert, der nicht im Code steht, sondern aus der Umgebung des laufenden Prozesses gelesen wird. Typischer Ort für Secrets wie API-Keys und Datenbank-Zugangsdaten. Lokal in einer .env-Datei, beim Hosting in den Environment-Variablen des Anbieters.
• Webhook — Ein Rückkanal von einem fremden System zu deiner App. Das fremde System ruft dich an, sobald ein Ereignis eingetreten ist, statt dass du wiederholt nachfragen musst. Spart Anfragen und liefert Informationen schneller als klassisches Polling.

Passende Fragen

• Ab wann ist mein selbst gebautes Tool kein Prototyp mehr?
  Sobald andere Menschen betroffen sind, wenn es ausfällt, Daten verliert oder geleakt wird. Der Code ändert sich beim Übergang nicht, deine Verantwortung schon. Vier Schwellen markieren den Übergang. Erste echten Daten, erster fremder Nutzer, erste rechtlich relevante Transaktion, erster Ausfall, den jemand merkt.
• Darf ich einen API-Key direkt in meinen Code schreiben?
  Nein, niemals. Auch nicht in privaten Repositories. API-Keys gehören in eine .env-Datei lokal und in die Umgebungsvariablen beim Hosting. Der Code liest den Key, er enthält ihn nicht. Ein Key im öffentlichen Repo ist eine Kreditkarte ohne PIN.
• Kann der KI-Agent meine Produktions-Datenbank löschen?
  Ja. Juli 2025 hat ein KI-Coding-Agent trotz wiederholtem „CODE FREEZE" eine Produktions-Datenbank mit 1.200 realen Einträgen gelöscht (Fall Jason Lemkin). Der Agent kennt den Unterschied zwischen Dev und Prod oft nicht von allein. Saubere Trennung ist Pflicht, nicht Option.
• Kann ich mit KI-Coding-Tools echte Apps bauen, ohne programmieren zu lernen?
  Ja, für kleinere Tools und Prototypen. Aber du brauchst ein mentales Modell des Geländes (Frontend, Backend, Daten, State, APIs, Umgebungen). Ohne dieses Modell trifft der Agent still falsche Entscheidungen, die später teuer werden.
• Warum brauche ich drei Umgebungen (Dev, Staging, Prod) und nicht nur zwei?
  Du brauchst einen Ort, der aussieht wie Prod, aber wo niemand stirbt, wenn du etwas kaputt machst. Das ist Staging. Der Code ist in allen drei Welten gleich, nur die Konfiguration unterscheidet sich. Ohne Staging testest du entweder unrealistisch oder riskant.
• Warum reicht es nicht, ein Formular nur im Frontend zu prüfen?
  Alles, was im Browser läuft, ist manipulierbar. Mit der Entwicklerkonsole oder direkten Requests kann jeder die Prüfung umgehen. Client-Validierung ist Komfort, Server-Validierung ist Sicherheit. Beides kann sinnvoll sein, aber Sicherheit darf nie nur vorne liegen.
• Was ist der Unterschied zwischen Authentifizierung und Autorisierung?
  Authentifizierung klärt „Wer bist du" (Login, Passwort, OAuth). Autorisierung klärt „Was darfst du" (welche Daten siehst du, welche Aktionen darfst du ausführen). Beides ist nötig und verschieden. KI-Coding-Tools bauen den ersten Teil oft solide, den zweiten nicht.
• Was ist eine API, einfach erklärt?
  Ein Vertrag zwischen zwei Systemen. „Wenn du mir X in diesem Format schickst, gebe ich dir Y in diesem Format zurück." APIs stecken überall, von Mail-Versand über Zahlung und KI-Anbieter bis zum Kalender. Ändert einer den Vertrag, bricht der andere.