Was Software eigentlich ist – Das mentale Modell hinter jedem Coding-Agenten

Vor zwei Jahren war das undenkbar. Heute baut eine Marketing-Managerin an einem Nachmittag ein Feedback-Tool. Eine HR-Beraterin prototyped ein Bewerber-Portal. Eine Seminar-Leiterin bastelt eine Auswertungs-App für ihre Kurse. Niemand von ihnen programmiert. Alle liefern etwas, das funktioniert.

KI-Coding-Tools wie Lovable, Cursor, Replit oder Claude Code machen das möglich. Der Agent übernimmt die Mechanik. Er tippt den Code, verkabelt die Teile, deployt auf einen Server. Was er nicht übernimmt, ist der Kontext. Genau dort bleibst du zuständig, auch als Nicht-Entwicklerin.

Der typische Moment

Am Ende deiner ersten Session schreibt der Agent: Fertig. Hier der Link. Du klickst. Weißer Bildschirm. Nichts passiert. Du scrollst zurück, liest die letzten Nachrichten. Der Code sieht nach Code aus. Alles wirkt abgeschlossen. Trotzdem tut sich nichts.

Beide haben recht. Der Code ist fertig. Und trotzdem läuft nichts. Das ist kein Widerspruch. Das ist der blinde Fleck, der fast jede Verwirrung mit einem Coding-Agenten erzeugt. Fast immer lässt sich der Moment in einem Satz auflösen.

Eine App ist zwei Dinge

Eine App ist nicht ein Ding, sondern zwei. Ein Stück Text auf einer Festplatte. Das ist der Code. Und ein laufender Prozess, der diesen Text ausführt. Beides muss da sein, damit eine App existiert. Sonst hast du entweder ein totes Dokument oder einen leeren Computer. Ein Bild, das hilft: Rezept und Kochen. Ein Rezept kann ewig im Buch stehen, ohne dass jemand satt wird. Erst wenn jemand in der Küche steht, das Rezept liest und Gemüse schneidet, entsteht Essen. Der Agent hat das Rezept geschrieben. Das Kochen übernimmt jemand anders: dein Hosting-Dienst, deine lokale Dev-Umgebung, ein Server irgendwo.

Sobald die Unterscheidung sitzt, werden zwei Fragen möglich: Habe ich ein Rezept? Und: Kocht gerade jemand? Die erste beantwortet der Agent normalerweise gut. Die zweite übersieht er, wenn du ihn lässt.

Was du nach dieser Lesson im Kopf hast

Diese Lesson baut ein mentales Bild einer App. Du lernst nicht zu programmieren. Du baust das Gelände, auf dem der Agent für dich arbeitet. Sechs Konzepte, plus eine Karte am Ende, die alles zusammenhält.

1. Frontend und Backend: die Vertrauensgrenze zwischen dem, was der Nutzer sieht, und dem, was entscheidet
2. Wo deine Daten wohnen: drei Orte, drei Qualitäten. Und warum das Schema die teuerste spätere Änderung ist
3. Wo der Zustand lebt: drei Orte gleichzeitig, und warum Bugs entstehen, wenn sie auseinanderlaufen
4. Wie die Teile miteinander reden: API als Vertrag, synchron oder asynchron
5. Wo Software lebt: Dev, Staging, Prod und warum drei und nicht zwei
6. Die Karte: am Ende zieht sich alles zu einem einzigen Bild zusammen

Jede Anwendung hat zwei Seiten. Die eine siehst und berührst du: Buttons, Felder, Texte, Formulare. Das ist das Frontend. Die andere siehst du nie: Sie rechnet, prüft, speichert, entscheidet. Das ist das Backend. Die Trennung zwischen beiden ist kein Design-Einfall. Sie ist eine Vertrauensgrenze.

Die Restaurant-Regel

Stell dir ein Restaurant vor. Der Gast bekommt die Speisekarte in die Hand. Er kann sie anmalen. Er kann „Rechnung: 0 €“ draufschreiben. Er kann Wunschgerichte dazuerfinden. Die Küche rechnet trotzdem nach. Sie kocht nur, was auf ihrer eigenen Bestell-Liste steht. Die Kasse verlangt den echten Betrag.

So funktioniert Frontend und Backend. Das Frontend ist die Speisekarte in der Hand des Gastes: schön, veränderbar, manipulierbar. Das Backend ist die Küche und die Kasse: sie glaubt nichts, was von außen kommt. Sie prüft alles noch einmal selbst.

Die Kurzformel

Die typische Fehlentscheidung

Beispiel: Online-Banking

Du loggst dich in dein Online-Banking ein. Auf der Seite siehst du Konto und Überweisungs-Formular. Beides ist Frontend, beides läuft in deinem Browser. Theoretisch kannst du den angezeigten Kontostand mit der Entwicklerkonsole auf eine Million Euro setzen. Die Anzeige ändert sich, dein Konto nicht. Du kannst auch eine Überweisung mit dem Betrag 0 € abschicken, indem du die Browser-Anfrage manipulierst. Die Bank lehnt ab. Das Backend prüft alles selbst: Beträge, Empfänger, Limits, Identität. Es vertraut deinem Browser kein Stück.

Merke: Nicht jede Regel muss beide Seiten durchsetzen. Aber jede Sicherheits-Regel muss es. Wer darf was einreichen, welche Rollen welche Endpunkte aufrufen, welche Felder verpflichtend sind. All das entscheidet das Backend, nicht der Button im Browser.

Jede Anwendung braucht Daten. Namen, Inhalte, Uhrzeiten, Einstellungen, Verknüpfungen. Diese Daten müssen irgendwo wohnen. Drei Orte stehen zur Wahl, und sie unterscheiden sich grundlegend in dem, was sie leisten.

Die drei Datenorte

Was eine Datenbank mehr kann als eine Datei

Eine Datei ist wie ein einziges langes Dokument. Eine Datenbank ist wie ein strukturiertes Archiv mit Karteikarten, Register und Regeln. Drei Dinge kann die Datenbank, die eine Datei nicht kann. In Alltagssprache:

• Queries: Du kannst fragen statt alles zu lesen. „Gib mir alle Notizen mit dem Tag Roadmap aus dem letzten Monat.“ Sofort. Ohne durch alles durchzulesen.
• Concurrency: Zwei Leute können gleichzeitig schreiben, ohne sich gegenseitig zu überschreiben. Bei einer Datei wird die letzte Speicherung gewinnen, und die andere Arbeit ist weg.
• Transaktionen: Mehrere Schritte als Einheit. Entweder alles oder nichts. Wenn in der Mitte etwas schiefgeht, wird alles zurückgedreht.

Das Schema ist die Fundament-Entscheidung

Ein Schema beschreibt: Welche Entitäten gibt es in deiner Welt, und wie hängen sie zusammen. Bei einer Notiz-App zum Beispiel: Notiz, Tag, Autorin, Workspace. Eine Notiz gehört zu einer Autorin. Eine Notiz hat mehrere Tags. Ein Workspace enthält viele Notizen. Vier Entitäten, drei Beziehungen, fertig.

Das kannst du in fünf Minuten auf Papier skizzieren. Und diese fünf Minuten entscheiden darüber, wie deine App in sechs Wochen dasteht. Ein Schema nachträglich zu ändern, wenn schon produktive Daten drin sind, ist der teuerste Moment im ganzen Prozess.

Die typische Fehlentscheidung

Beispiel: Eine Notiz-App fürs Team

Stell dir vor, du baust eine Notiz-App für ein Team. Erste Frage: Wo wohnen die Notizen? In einem Word-Dokument auf einem geteilten Laufwerk: schnell gebaut, aber nur eine Person kann gleichzeitig schreiben, niemand kann gezielt nach Tags suchen, und wer abspeichert, kann das Speichern eines anderen überschreiben. Oder in einer Datenbank: etwas mehr Aufwand, aber alle drei Probleme verschwinden.

Schema: Notiz, Tag, Autorin, Workspace. Vier Entitäten. Eine Notiz gehört zu einer Autorin. Eine Notiz hat mehrere Tags. Jeder Workspace enthält viele Notizen. Das skizzierst du in fünf Minuten auf Papier und gibst es dem Agenten als Vorgabe, nicht als Frage.

State ist ein abstraktes Wort für eine konkrete Frage: Wie sieht die Welt gerade aus? Wer ist eingeloggt. Was liegt im Warenkorb. Welcher Filter ist aktiv. Ob das Formular schon abgesendet wurde. State ist der Zustand deiner App im Moment.

Drei Notizbücher für dieselbe Information

State lebt an drei Orten gleichzeitig. Nicht einer davon, sondern alle drei. Stell dir drei Notizbücher vor, in denen jemand dieselben Informationen notieren kann: eins in der Hosentasche, eins auf dem Schreibtisch, eins im Aktenschrank.

Bugs entstehen, wenn die drei Notizbücher unterschiedliche Dinge enthalten. Der Browser denkt, du bist eingeloggt. Der Server denkt, deine Session ist abgelaufen. Die Datenbank hat deinen Account gesperrt. Jeder hat seine eigene Wahrheit. Die App verhält sich seltsam.

Die Kernregel

Der Reload-Test

Die einfachste Frage, die du dir pro Information stellen kannst: Stell dir vor, der Nutzer schließt den Tab. Was darf verloren gehen, was nicht? Halbausgefülltes Formular? Vermutlich ok. Abgesendete Antwort? Niemals. Login-Session? Ist gewollt, dass sie nach Schließen endet, oder soll der Nutzer eingeloggt bleiben?

Die typische Fehlentscheidung

Beispiel: Google Docs

Du tippst gerade einen Satz in ein Google Doc. Wo lebt diese Information? Erst nur in deinem Browser, das ist Client-State. Nach ein, zwei Sekunden wandert sie zum Server, das ist Server-State. Erst wenn der Server sie in seiner Datenbank gespeichert hat, ist sie wirklich sicher, das ist Persistent State. Wenn dein Internet abreißt, bevor das letzte Stück bei der Datenbank angekommen ist, sieht jemand auf einem anderen Tab eine ältere Version als du selbst. Das ist State, der auseinandergelaufen ist. Genau dort entstehen die meisten Bugs. Die Frage pro Information: Wo lebt diese Wahrheit wirklich?

Kaum eine App läuft für sich allein. Sie schickt E-Mails, bindet einen Kalender an, liest Zahlungen ein, nutzt eine KI für Textzusammenfassungen. Überall, wo zwei Systeme miteinander reden, tun sie das über einen Vertrag: „Wenn du mir X in diesem Format schickst, gebe ich dir Y in diesem Format zurück.“ Dieser Vertrag heißt API.

Der Bestellzettel

Bleiben wir beim Restaurant. Dein Backend ist die Küche. Ein externer Lieferant bringt Zutaten. Die Küche bestellt über einen Bestellzettel: Empfänger, Position, Menge, Lieferzeit. So lange beide Seiten mit demselben Zettel arbeiten, kommt die richtige Zutat an. Wenn der Lieferant heimlich das Formular ändert (zum Beispiel plötzlich Mengen in Gramm statt Kilo erwartet), kommen falsche Mengen oder gar nichts an. Der Vertrag war gebrochen.

Warten oder nicht warten

Fragen oder benachrichtigt werden

Auch wie zwei Systeme in Kontakt bleiben, hat zwei Denkrichtungen: Polling ist das Kind auf der Autofahrt. „Sind wir schon da? Sind wir schon da?“ Du fragst wiederholt, meistens kommt nichts Neues. Webhook ist der Kumpel, der anruft: „Ich bin da.“ Du wirst einmal benachrichtigt, wenn es relevant ist.

Die typische Fehlentscheidung

Beispiel: Online-Shop bindet PayPal an

Stell dir einen Online-Shop vor, der PayPal als Zahlungs-Dienst anbindet. Drei Entscheidungen werden auf einmal sichtbar:

1. Der Vertrag. PayPal erwartet bestimmte Felder: Betrag, Währung, Empfänger, eine eindeutige Bestell-ID. Wenn du falsche Felder schickst, kommt nichts an. Wenn PayPal das Format ändert, brichst du mit.
2. Synchron oder asynchron. Eine Kreditkartenzahlung ist in 200 Millisekunden zurück, das geht synchron. Eine SEPA-Überweisung dauert Stunden, das geht nur asynchron. Sonst friert dein Shop ein.
3. Der Rückkanal. Wenn das Geld eingegangen ist, soll dein Shop sofort Bescheid wissen. Webhook ist Standard: PayPal ruft deinen Shop an, sobald die Zahlung gebucht ist. Polling, also alle paar Minuten nachfragen, würde auch funktionieren, kostet aber unnötig Anfragen.

Dieselbe App existiert nicht einmal, sondern dreimal. Drei Welten, in denen sie lebt. Und diese drei Welten sind keine Tools, sondern drei Rollen mit jeweils anderen Konsequenzen, wenn etwas schiefgeht.

Die drei Welten

Drei Werkstätten, ein Auto

In der ersten Werkstatt schraubst du wild herum, testest, machst kaputt. In der zweiten baust du das Auto zusammen, das du morgen dem Kunden zeigst. In der dritten steht das Auto des Kunden, das täglich fährt. Gleiche Werkzeuge, gleicher Bauplan, grundverschiedene Konsequenzen bei Fehlern.

Was sich zwischen den Welten unterscheidet

Nicht der Code. Der ist in allen drei Welten gleich. Was sich unterscheidet, ist die Konfiguration: welche Datenbank angebunden ist, welche API-Keys greifen, welcher Mail-Dienst-Account benutzt wird, welche Domain bedient wird. Dieselbe App, aber sie spricht in jeder Welt mit anderen Partnern.

Echte Daten gehören nicht nach Dev

Software ist ein Garten, kein Gebäude

Noch eine Wahrheit, die beim Thema „Wo lebt Software“ passt: Sie altert. Ihre Bausteine werden gewartet, aktualisiert, manchmal abgeschaltet, von anderen Menschen an anderen Orten. Das passiert auch dann, wenn du an deiner App nichts mehr änderst. Software ist ein Garten, kein Gebäude. Wer das vergisst, wundert sich, warum ein Tool nach zwei Jahren einfach aufhört zu funktionieren.

Die typische Fehlentscheidung

Beispiel: Update einer Website

Stell dir vor, du willst auf deiner Firmen-Website das Kontaktformular ändern. Dev ist deine lokale Kopie, wo du die Änderung baust und ausprobierst, ohne dass irgendwer es merkt. Staging ist eine zweite Version unter einer Test-URL, die nur du und deine Kolleginnen kennen. Dort siehst du, wie das neue Formular zwischen allen anderen Seiten wirkt, mit echten Testdaten in einer Test-Datenbank. Erst wenn das passt, geht die Änderung live, in die Prod, die jeder Besucher sieht. Wenn du den Schritt überspringst und direkt auf Prod änderst, merken die ersten zehn Besucher den Bug.

Sechs Konzepte, ein Bild. Die Karte zeigt, wie die Teile zusammenhängen, die du in den letzten Abschnitten einzeln kennengelernt hast. Links steht der Nutzer. Er tippt ins Frontend. Das Frontend redet mit dem Backend. Das Backend redet mit der Datenbank. Manchmal redet das Backend auch mit einem externen System: Mail-Dienst, Kalender, KI-API. State lebt an drei der Stationen. Und die ganze Karte existiert dreimal, weil Software in drei Welten gleichzeitig lebt: Dev, Staging, Prod.

Die Architektur auf einen Blick

Die drei Welten als Parallele

Dieselbe Karte existiert dreimal: als Dev, als Staging, als Prod. Die Stationen sind identisch. Was sich unterscheidet, ist wohin jeder Pfeil zeigt: welche konkrete Datenbank, welcher konkrete Mail-Dienst-Account, welche API-Keys.

Was diese Karte dir gibt

Wenn der Agent das nächste Mal entscheidet, wo eine Information hinsoll, welcher Dienst angebunden wird, welche Umgebung gerade läuft, zeigt seine Entscheidung auf einen Punkt dieser Karte. Du kannst fragen: Welche Station gerade? Welcher Pfeil? Welche Welt?

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.
• 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.
• 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.
• 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

• 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 Frontend und Backend?
  Frontend ist, was der Nutzer sieht und bedient. Es läuft im Browser und ist manipulierbar. Backend ist, was entscheidet, speichert und rechnet. Es läuft auf einem Server und ist nicht direkt vom Nutzer erreichbar. Sicherheits-Prüfungen gehören immer ins Backend.
• 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.