Webseiten und Anwendungen mit KI erstellen – meine Arbeitsweise als Nicht-Programmierer

Was ChatGPT, Gemini, Claude & Co. heute ermöglichen – und wie man einer KI richtig sagt, was man eigentlich möchte

Stand·September 2026

Ich bin kein Programmierer. HTML, CSS, PHP, JavaScript, Datenbanken, Serverkonfiguration und all die anderen Dinge, die zu einer Webanwendung gehören, habe ich nicht von Grund auf gelernt.

Und trotzdem kann ich heute Webseiten und kleinere Anwendungen entwickeln, verändern und erweitern.

Dieser Beitrag basiert auf meinen persönlichen Erfahrungen beim Arbeiten mit KI und meinen eigenen Webprojekten. Er ist kein technisches Handbuch und erhebt auch nicht den Anspruch, die einzig richtige Vorgehensweise zu beschreiben. Ich möchte vielmehr zeigen, was sich für mich als Nicht-Programmierer in der Praxis bewährt hat, wo ich Schwierigkeiten erlebt habe und welche Arbeitsweisen mir inzwischen helfen, bessere und vor allem kontrollierbarere Ergebnisse zu bekommen.

Der Grund dafür ist natürlich künstliche Intelligenz.

ChatGPT, Gemini, Claude, GitHub Copilot und spezialisierte Coding-Agenten können inzwischen weit mehr, als nur ein paar Zeilen HTML zu erzeugen. Sie können vorhandene Projekte analysieren, Fehler suchen, Dateien verändern, Funktionen ergänzen, Datenbanken untersuchen, Tests ausführen, Dokumentationen schreiben und bei entsprechender Umgebung sogar größere Aufgaben weitgehend selbstständig bearbeiten.

Trotzdem gibt es keinen KI-Alleskönner. Jedes System hat eigene Stärken und Schwächen, die sich außerdem je nach Aufgabe, Modellversion und Arbeitsweise unterscheiden können. Nach meiner persönlichen Erfahrung ist ChatGPT beim Programmieren deutlich zuverlässiger als Gemini. Bei der Erstellung von SVG-Grafiken stößt ChatGPT dagegen schnell an Grenzen. Für technische Fachberichte liefert Gemini meiner Erfahrung nach häufig die besseren Ergebnisse. Claude ist bei mathematischen Fragen für mich kaum brauchbar und versagt dort teilweise vollständig. Zu GitHub Copilot kann ich keine eigene Einschätzung abgeben, da ich es bisher noch nicht verwendet habe. Codex kann bei Programmieraufgaben unterstützen, produziert meiner Erfahrung nach aber auch viel fehlerhaften oder unbrauchbaren Code. Deshalb sollte man die Ergebnisse jeder KI kritisch prüfen und je nach Aufgabe das passende Werkzeug auswählen.

Das Faszinierende daran ist für mich nicht nur, dass die KI programmieren kann. Viel interessanter ist, dass sich dadurch die Rolle des Menschen verändert.

Ich muss nicht unbedingt selbst wissen, wie eine Funktion programmiert wird. Ich muss möglichst genau beschreiben können, was sie tun soll, was dabei nicht verändert werden darf und woran ich erkenne, dass das Ergebnis richtig ist.

Und genau darum geht es in diesem Beitrag.

Heißt das eigentlich noch „Prompten“?

Ja.

Die Begriffe Prompt und Prompt Engineering sind keineswegs verschwunden.

Ein Prompt ist vereinfacht gesagt die Frage, Anweisung oder Aufgabe, die wir einer KI geben. Prompt Engineering bedeutet, solche Anweisungen so zu formulieren und zu strukturieren, dass die KI möglichst zuverlässig das gewünschte Ergebnis liefert.

Verändert hat sich allerdings die Art, wie wir mit KI arbeiten.

Am Anfang bestand die Nutzung oft aus einem einzelnen Satz:

„Erstelle mir eine Webseite.“

Dann kamen ellenlange sogenannte Masterprompts, in denen möglichst jede denkbare Regel untergebracht wurde.

Heute geht die Entwicklung stärker in Richtung Projektkontext, Projektanweisungen, Dateien, Regeln und spezialisierte Agenten.

ChatGPT kann beispielsweise Projekte mit Chats, Dateien und projektspezifischen Anweisungen zusammenhalten. Gemini bietet mit Gems wiederverwendbare, individuell konfigurierte Assistenten. Coding-Agenten können zusätzlich Anweisungsdateien direkt aus einem Softwareprojekt berücksichtigen.

Der klassische „Masterprompt“ ist deshalb nicht unbedingt falsch oder tot.

Ich würde heute nur unterscheiden zwischen:

Projektbriefing oder Projektanweisung
für Regeln, die dauerhaft gelten,

und

Auftrag oder Task
für die konkrete Änderung, die jetzt erledigt werden soll.

Das macht die Sache wesentlich übersichtlicher.

Was kann ein Laie mit KI überhaupt erstellen?

Erstaunlich viel.

Bei einer normalen Webseite kann eine KI beispielsweise das Grundgerüst erzeugen, Navigation und Layout programmieren, responsive Ansichten für Smartphone und Tablet umsetzen, Formulare erstellen, einen Darkmode ergänzen, Bilder integrieren, Inhalte strukturieren oder SEO-Metadaten vorbereiten.

Bei einer Webanwendung kommen Dinge wie Benutzerverwaltung, Datenbanken, Suchfunktionen, Rollen und Rechte, Datei-Uploads, Exporte, Dashboards, Benachrichtigungen oder Verwaltungsbereiche hinzu.

Noch wichtiger ist aber etwas anderes:

Moderne Coding-Agenten können auch vorhandene Projekte untersuchen.

Ich muss also nicht nur sagen:

„Programmiere mir ein Kontaktformular.“

Ich kann beispielsweise sagen:

„Untersuche zuerst mein vorhandenes Kontaktformular. Die Optik und alle bestehenden Sicherheitsmechanismen müssen erhalten bleiben. Ergänze ausschließlich eine Telefonnummer als optionales Feld.“

Wenn die KI Zugriff auf das tatsächliche Projekt hat, kann sie untersuchen, welche Dateien betroffen sind, welche Funktionen bereits vorhanden sind und wie die bestehende Anwendung aufgebaut ist.

Damit wird KI besonders für Menschen interessant, die eine konkrete Idee haben, aber selbst keine Softwareentwickler sind.

Die wichtigste Erkenntnis: Die KI ist nicht der Bauherr

Ich halte diesen Unterschied für entscheidend.

Die KI sollte nicht bestimmen, was gebaut wird.

Ich bestimme das Ziel.

Die KI hilft bei der technischen Umsetzung.

Man kann sich das ungefähr wie bei einem Bauprojekt vorstellen.

Ich sage einem Handwerker schließlich auch nicht:

„Mach das Haus besser.“

Sondern beispielsweise:

„Die vorhandene Tür bleibt erhalten. Rechts daneben soll eine zusätzliche Steckdose eingebaut werden. Wandfarbe und restliche Elektroinstallation sollen unverändert bleiben.“

Bei Software ist es genauso.

Ein Auftrag wie

„Mach meine Webseite moderner.“

gibt der KI praktisch freie Hand.

Ein Auftrag wie

„Die bestehende Gestaltung bleibt erhalten. Verändere ausschließlich die Darstellung der drei Karten auf Smartphones. Unter 700 Pixel Breite sollen sie untereinander dargestellt werden. Desktop und Tablet dürfen sich nicht verändern.“

ist dagegen ein konkreter Arbeitsauftrag.

Man muss den perfekten Auftrag nicht selbst schreiben

Das ist für mich inzwischen einer der wichtigsten Punkte überhaupt.

Gerade als Nicht-Programmierer weiß ich oft, was ich möchte, aber nicht unbedingt, welche technischen Angaben ein Entwickler benötigt.

Also muss ich den perfekten Prompt gar nicht selbst formulieren.

Ich kann der KI zuerst mein Vorhaben ganz normal erzählen.

Zum Beispiel:

„Ich möchte in meinem Backend eine Möglichkeit haben, Bilder hochzuladen. Ich kenne mich aber mit den Sicherheitsanforderungen bei Uploads nicht aus. Die bisherige Benutzerverwaltung und das Design sollen auf keinen Fall verändert werden. Ich möchte außerdem vermeiden, dass jemand irgendwelche gefährlichen Dateien hochlädt.“

Dann gebe ich der KI zunächst nicht den Auftrag, etwas zu programmieren.

Stattdessen kann ich schreiben:

Ausführung noch nicht beginnen.

Ich bin kein professioneller Entwickler.

Analysiere mein beschriebenes Vorhaben und erstelle daraus zunächst
einen sauberen technischen Arbeitsauftrag.

Der Auftrag soll enthalten:

- Ziel
- vorhandenen Kontext
- benötigte Funktionen
- Bestandsschutz
- Dinge, die ausdrücklich nicht verändert werden dürfen
- technische Rahmenbedingungen
- Sicherheitsanforderungen
- sinnvolle Rand- und Fehlerfälle
- Akzeptanzkriterien
- erforderliche Prüfungen nach der Umsetzung

Ergänze technische Punkte, die ein Nicht-Programmierer leicht
übersehen könnte.

Erfinde aber keine zusätzlichen Funktionen, die ich nicht benötige.

Zeige mir anschließend den fertigen Auftrag zur Prüfung.
Noch nichts programmieren oder verändern.

Das halte ich für eine sehr gute Arbeitsweise.

Die KI übernimmt dabei gewissermaßen zunächst die Rolle desjenigen, der aus meiner Idee ein Pflichtenheft im Kleinformat macht.

Ich kann diesen Auftrag lesen und sagen:

„Ja, genau so.“

oder:

„Nein, den Punkt brauche ich nicht.“

oder:

„Da hast du mich falsch verstanden.“

Erst danach bekommt sie den Auftrag:

„Setze diesen freigegebenen Arbeitsauftrag jetzt um.“

Das hat noch einen weiteren Vorteil:

Ich sehe plötzlich Anforderungen, an die ich selbst vorher möglicherweise gar nicht gedacht habe.

Bei einem Upload wären das beispielsweise Dateigröße, erlaubte Dateitypen, Dateinamen, Speicherort, Benutzerrechte, Fehlerbehandlung und Sicherheitsprüfung.

Ich muss diese Dinge nicht vorher kennen.

Aber ich sollte sie sehen und verstehen können, bevor die KI handelt.

Diese Arbeitsweise könnte man als Prompt Refinement, Requirements Refinement, Spec-first oder vereinfacht als „erst den Auftrag erstellen lassen“ bezeichnen.

Der Name ist letztlich weniger wichtig als das Prinzip:

Idee → gemeinsam präzisieren → Auftrag prüfen → erst dann umsetzen.

Die wahrscheinlich wichtigste Prompt-Formel

Für viele Aufgaben reichen vier Bestandteile:

Ziel – Kontext – Einschränkungen – Fertig, wenn …

Oder etwas ausführlicher:

ZIEL
Was soll erreicht werden?

KONTEXT
Wie sieht der aktuelle Zustand aus?

EINSCHRÄNKUNGEN
Was darf nicht verändert werden?
Welche technischen Grenzen gibt es?

FERTIG, WENN
Woran lässt sich objektiv erkennen, dass die Aufgabe erledigt ist?

Ein Beispiel:

ZIEL

Ergänze im Backend eine Suchfunktion für Beiträge.

KONTEXT

Die bestehende Beitragsverwaltung funktioniert bereits.
Nutze die vorhandene Datenbankstruktur und das bestehende Design.

EINSCHRÄNKUNGEN

Keine Datenbanktabellen verändern.
Keine bestehenden Funktionen umbauen.
Keine neuen Frameworks oder Bibliotheken installieren.
Desktop- und Mobilansicht müssen erhalten bleiben.

FERTIG, WENN

Nach Titel und Inhalt gesucht werden kann.
Leere Suchanfragen verursachen keinen Fehler.
Alle bisherigen Funktionen funktionieren weiterhin.

Das ist bereits ein ziemlich guter Auftrag.

Es braucht dafür keine magischen Wörter.

Vom Masterprompt zur Projektanweisung

Bei einem länger laufenden Projekt würde ich heute nicht bei jeder Aufgabe erneut sämtliche Informationen schreiben.

Stattdessen bekommt die KI einmal grundlegende Projektregeln.

Eine einfache Vorlage könnte beispielsweise so aussehen:

# Rolle

Du unterstützt mich bei der Entwicklung dieser Anwendung.

Ich bin kein professioneller Softwareentwickler.
Erkläre wichtige technische Entscheidungen deshalb verständlich.

# Projektziel

Beschreibe hier in wenigen Sätzen, was die Anwendung macht
und für wen sie gedacht ist.

# Bestehendes System

Technik:
- PHP
- MariaDB
- HTML
- CSS
- JavaScript

Server:
- ...

Wichtige Verzeichnisse:
- ...

# Bestandsschutz

Bestehende und funktionierende Funktionen dürfen nicht ohne
Notwendigkeit verändert werden.

Keine Refactorings, Designänderungen oder zusätzlichen Funktionen,
wenn sie für die konkrete Aufgabe nicht erforderlich sind.

# Arbeitsweise

Untersuche vor Änderungen zuerst die vorhandene Implementierung.

Prüfe, ob eine benötigte Funktion bereits vorhanden ist und
wiederverwendet werden kann.

Ändere möglichst wenige Dateien.

Erfinde keine vorhandenen Funktionen, Dateien, Tabellen oder APIs.
Prüfe sie tatsächlich.

# Sicherheit

Keine Passwörter, Zugangsdaten oder API-Schlüssel in Quellcode schreiben.

Keine Datenbanken löschen oder zurücksetzen.

Keine produktiven Daten verändern, wenn dies nicht ausdrücklich verlangt wird.

Destruktive oder schwer rückgängig zu machende Aktionen nicht ohne
ausdrückliche Freigabe durchführen.

# Gestaltung

Bestehende Farben, Abstände, Schriftarten und Bedienelemente
grundsätzlich beibehalten.

Neue Elemente sollen sich optisch in das bestehende Design einfügen.

# Qualität

Nach Änderungen prüfen:
- Funktioniert die gewünschte Funktion?
- Funktionieren bestehende Funktionen weiterhin?
- Gibt es PHP-, JavaScript- oder Datenbankfehler?
- Funktioniert die Mobilansicht?
- Sind Eingaben ausreichend abgesichert?

# Abschluss

Nenne mir anschließend:
- was geändert wurde,
- welche Dateien geändert wurden,
- welche Tests durchgeführt wurden,
- welche offenen Risiken oder Punkte bestehen.

Das ist für mich die moderne Form eines Masterprompts.

Nicht bei jedem Auftrag zehn Seiten Regeln kopieren, sondern dem Projekt eine dauerhafte Betriebsanleitung geben.

Codex kann für solche Projektinformationen beispielsweise AGENTS.md verwenden. Bei Claude Code übernimmt CLAUDE.md diese Rolle. Claude empfiehlt dabei ausdrücklich konkrete und möglichst kurze Anweisungen, weil überladene Anweisungsdateien schlechter befolgt werden können.

Gibt es geheime Befehle oder „Cheatcodes“ für KI?

Wer sich etwas länger mit KI beschäftigt, stößt irgendwann auf angebliche Geheimtipps: „Developer Mode“, „God Mode“, „DAN“, „ignore all previous instructions“ oder andere vermeintliche Befehle, mit denen sich eine KI plötzlich in einen besonderen Modus versetzen lassen soll.

Einen echten universellen „Cheatcode“ wie früher bei Computerspielen – etwa IDDQD – gibt es bei ChatGPT, Gemini, Claude & Co. allerdings nicht. 😉

Viele solcher Begriffe stammen aus Internetforen, sozialen Netzwerken oder sogenannten Jailbreak-Versuchen. Sie sind keine offiziellen Zauberbefehle und funktionieren, wenn überhaupt, nur situationsabhängig oder vorübergehend.

Was es dagegen tatsächlich gibt, sind zwei andere Dinge:

Produktspezifische Befehle

Bestimmte Programme und Coding-Agenten besitzen echte Kommandos.

Codex oder Claude Code können beispielsweise eigene Slash-Befehle wie /init oder andere Werkzeugbefehle anbieten. Diese gehören aber immer zum jeweiligen Produkt und funktionieren nicht automatisch bei einer anderen KI.

Solche Befehle können sich außerdem mit neuen Versionen ändern. Deshalb sollte man bei produktspezifischen Kommandos im Zweifel die aktuelle Dokumentation des jeweiligen Anbieters prüfen.

Kurze Prompt-Bausteine

Viel interessanter für den normalen Alltag sind kurze Formulierungen und verbreitete Kürzel, die einer KI sehr schnell mitteilen, wie eine Antwort aussehen soll.

Sie sind keine technischen Befehle. Moderne Sprachmodelle verstehen sie aber meistens sehr gut.

Dabei ist wichtig:

TL;DR oder ELI5 sind keine eingebauten Spezialfunktionen von ChatGPT.

Die KI erkennt einfach, was mit diesen weit verbreiteten Abkürzungen gemeint ist.

Man könnte genauso gut schreiben:

„Fasse das bitte in fünf Sätzen zusammen.“

statt:

TL;DR

Oder:

„Erkläre mir das so einfach, dass ich keinerlei Vorwissen benötige.“

statt:

ELI5

Der Vorteil solcher Kurzformen ist vor allem, dass sie schnell geschrieben sind.

Noch nützlicher als Abkürzungen sind klare Arbeitsanweisungen

Beim Erstellen von Webseiten und Anwendungen sind kurze Arbeitsanweisungen meiner Meinung nach noch wesentlich wertvoller:

Analysiere zuerst. Ändere noch nichts.

oder:

Ändere ausschließlich das beschriebene Problem.

oder:

Prüfe zuerst, ob diese Funktion bereits vorhanden ist und wiederverwendet werden kann.

oder:

Behebe die Ursache und nicht nur das sichtbare Symptom.

oder:

Prüfe anschließend, ob bestehende Funktionen weiterhin funktionieren.

Solche Sätze wirken unspektakulär, können bei einem Coding-Agenten aber den Unterschied zwischen einer kleinen kontrollierten Änderung und einem unnötigen Umbau der halben Anwendung ausmachen.

Mein persönlicher „Anti-KI-Chaos-Befehl“

Wenn ich eine bestehende Anwendung verändern lasse, würde ich inzwischen fast immer etwas in dieser Art mitgeben:

Ändere ausschließlich, was für diese Aufgabe erforderlich ist.

Funktionierende bestehende Bereiche bleiben unverändert.

Keine Refactorings, Designänderungen, Optimierungen oder zusätzlichen
Funktionen außerhalb des beschriebenen Auftrags.

Prüfe zuerst die vorhandene Umsetzung und verwende bestehende
Funktionen, wenn dies sinnvoll möglich ist.

Mein großer Prompt-Werkzeugkasten

Die folgenden Formulierungen lassen sich einzeln verwenden oder miteinander kombinieren.

Diese kleinen Formulierungen sind häufig wertvoller als ein komplizierter Superprompt.

Eine meiner wichtigsten Regeln: Bestandsschutz

Gerade wenn man selbst nicht programmieren kann, ist dieser Block Gold wert:

Ändere ausschließlich, was für diese Aufgabe erforderlich ist.

Funktionierende bestehende Bereiche bleiben unverändert.

Keine Refactorings, Designänderungen, Optimierungen oder zusätzlichen
Funktionen außerhalb des beschriebenen Auftrags.

Warum?

Weil leistungsfähige KI-Systeme manchmal zu hilfreich sein wollen.

Ein kleines Problem wird erkannt und bei dieser Gelegenheit wird gleich noch eine Datei umgebaut, eine Funktion „verbessert“, das CSS aufgeräumt oder eine neue Architektur eingeführt.

Technisch kann das gut gemeint sein.

Für eine funktionierende Anwendung kann es trotzdem katastrophal sein.

Ein schlechter und ein guter Auftrag

Schlecht:

Mach mein Backend besser.

Die KI muss praktisch alles selbst interpretieren.

Besser:

Analysiere zuerst das vorhandene Backend.

ZIEL

Auf der Benutzerseite soll oberhalb der Tabelle eine Suche ergänzt werden.

BESTANDSSCHUTZ

Navigation, Tabelle, Rollenverwaltung und bestehendes Design
bleiben unverändert.

FUNKTION

Gesucht werden soll nach Name und E-Mail-Adresse.

Die Suche soll nicht zwischen Groß- und Kleinschreibung unterscheiden.

TECHNIK

Nutze die vorhandene Datenbankverbindung und Tabellenstruktur.

Keine neue Bibliothek.

FERTIG, WENN

- Suche funktioniert.
- Leere Suche zeigt wieder alle Benutzer.
- Bestehende Filter funktionieren weiterhin.
- Mobilansicht bleibt nutzbar.
- Keine PHP- oder JavaScript-Fehler entstehen.

ABSCHLUSS

Nenne anschließend die geänderten Dateien und die
durchgeführten Prüfungen.

Dafür muss ich kein PHP können.

Ich muss wissen, welches Ergebnis ich möchte.

Noch besser: Erst untersuchen, dann ändern

Bei bestehenden Anwendungen würde ich häufig einen separaten Analyseauftrag verwenden:

Analysiere diese Funktion und die dafür relevanten Dateien.

Ändere noch nichts.

Erkläre mir:

1. wie die Funktion momentan arbeitet,
2. welche Dateien beteiligt sind,
3. wo die beste Stelle für meine gewünschte Änderung ist,
4. welche bestehenden Funktionen wiederverwendet werden können,
5. welche Risiken die Änderung hat.

Schlage anschließend die kleinstmögliche Umsetzung vor.

Danach kann ich entscheiden, ob die Änderung tatsächlich durchgeführt werden soll.

Gerade bei produktiven Anwendungen ist diese Trennung zwischen Analyse und Ausführung enorm wertvoll.

„Mach es schön“ funktioniert – präzise ist trotzdem besser

KI-Systeme sind inzwischen erstaunlich gut darin geworden, Benutzeroberflächen zu gestalten.

Trotzdem bleibt „modern“, „schön“ oder „professionell“ subjektiv.

Statt:

Mach die Seite moderner.

kann ich beispielsweise schreiben:

Die vorhandene Seitenstruktur bleibt erhalten.

Ich möchte die Oberfläche ruhiger und hochwertiger wirken lassen.

BEIBEHALTEN

- bestehende Hauptfarbe
- Logo
- Navigation
- Inhalte

ÄNDERN

- mehr Weißraum zwischen größeren Bereichen
- einheitliche Kartenhöhen
- ruhigere Schatten
- deutlichere Überschriftenhierarchie
- Buttons einheitlich gestalten

NICHT GEWÜNSCHT

- Glaseffekte
- Neonfarben
- starke Animationen
- übermäßig große Überschriften
- typischer generischer KI-Look

Erstelle zuerst einen Gestaltungsvorschlag.

Ändere noch keinen Code.

Auch Screenshots können dabei enorm helfen.

Statt eine Gestaltung mühsam zu beschreiben, kann ich der KI zeigen:

„Diese Ansicht gefällt mir. Meine Navigation soll aber erhalten bleiben. Übernimm nur die Art der Karten und die Abstände.“

Ich muss also nicht jedes Detail mit Fachbegriffen beschreiben können.

Beispiele sind mächtiger als viele Adjektive

Eine sehr hilfreiche Technik besteht darin, der KI nicht nur zu erklären, was man möchte, sondern ein Beispiel zu zeigen.

Statt:

„Der Button soll hochwertiger aussehen.“

kann ich schreiben:

„Dieser vorhandene Button gefällt mir. Der neue Button soll dieselbe Höhe, Rundung, Schriftgröße und Hover-Wirkung verwenden.“

Oder bei Text:

„Hier sind zwei ältere Texte von mir. Der neue Beitrag soll sprachlich ähnlich wirken.“

Beispiele reduzieren Interpretationsspielraum.

Das gilt für Layout, Code, Texte, Tabellen und praktisch alle anderen KI-Aufgaben.

Dateien sind Kontext – und Kontext ist entscheidend

Eine KI kann nur zuverlässig mit dem arbeiten, was sie tatsächlich kennt.

Wenn ich frage:

„Warum funktioniert meine Anmeldung nicht?“

ohne den betreffenden Code bereitzustellen, muss sie Vermutungen anstellen.

Wenn ein Coding-Agent dagegen die tatsächlichen Dateien untersuchen kann, sieht die Situation völlig anders aus.

Deshalb gehört zu meinen Lieblingsanweisungen:

Keine Vermutungen über Code, den du nicht geprüft hast.

Öffne zuerst die relevanten Dateien.

Auch GitHub empfiehlt für Copilot ausdrücklich, relevanten Code und Kontext bereitzustellen und größere Aufgaben in kleinere Teilaufgaben zu zerlegen.

Ein Chat ist nicht automatisch ein Projekt

Für eine kleine Frage reicht ein normaler Chat.

Bei einer Webseite oder Anwendung, an der über Wochen oder Monate gearbeitet wird, sollte möglichst ein eigener Projektbereich oder eine vergleichbare dauerhafte Struktur genutzt werden.

Dort können beispielsweise hinterlegt werden:

Projektbeschreibung
Technischer Aufbau
Ordnerstruktur
Datenbankschema
Gestaltungsregeln
Sicherheitsregeln
wichtige Entscheidungen
Screenshots
Beispieldateien
offene Aufgaben

ChatGPT-Projekte können Chats, Dateien und Projektanweisungen gemeinsam als Kontext halten. Gemini bietet mit Gems eine ähnliche Möglichkeit für wiederverwendbare Anweisungen und zusätzlichen Dateikontext.

Das Grundprinzip ist wichtiger als der Produktname:

Die KI sollte bei einem länger laufenden Projekt nicht bei jeder Aufgabe wieder bei null anfangen müssen.

Bei Coding-Agenten kommen Projektdateien hinzu

Besonders interessant wird es bei Werkzeugen, die direkt mit einem Softwareprojekt arbeiten.

Codex kann Regeln über AGENTS.md berücksichtigen.

Claude Code verwendet CLAUDE.md.

Darin können beispielsweise stehen:

Die Anwendung verwendet PHP 8.2.

Datenbankzugriffe erfolgen ausschließlich über die vorhandene
Database-Klasse.

Neue Styles gehören in assets/css/app.css.

Keine Inline-Styles.

Vor Änderungen an Datenbanktabellen immer Rückfrage halten.

Nach PHP-Änderungen Syntaxprüfung durchführen.

Bestehende öffentliche URLs dürfen nicht verändert werden.

Der große Vorteil:

Ich muss diese Regeln nicht bei jeder Aufgabe erneut schreiben.

Codex beschreibt AGENTS.md ausdrücklich als Möglichkeit, dem Agenten Informationen über Codeorganisation, Konventionen und Tests mitzugeben. Claude Code nutzt CLAUDE.md als dauerhaften Projektkontext und empfiehlt konkrete, überprüfbare Anweisungen.

Das ist für mich der eigentliche Nachfolger eines riesigen Masterprompts.

„Fertig“ muss definiert werden

Einer der größten Fehler bei KI-Aufträgen ist ein fehlendes Ende.

Wenn ich sage:

„Baue eine Anmeldung.“

Wann ist die Aufgabe fertig?

Wenn das Formular sichtbar ist?

Wenn ein Benutzer sich anmelden kann?

Wenn falsche Passwörter abgefangen werden?

Wenn Logout funktioniert?

Wenn geschützte Seiten wirklich geschützt sind?

Wenn die Mobilansicht funktioniert?

Deshalb gehört in größere Aufträge ein Abschnitt:

FERTIG, WENN

Zum Beispiel:

FERTIG, WENN

- Anmeldung mit gültigem Benutzer funktioniert.
- Falsches Passwort zeigt eine verständliche Fehlermeldung.
- Gesperrte Benutzer können sich nicht anmelden.
- Sitzung wird korrekt erstellt.
- Logout beendet die Sitzung.
- Geschützte Seiten können ohne Anmeldung nicht geöffnet werden.
- Mobilansicht funktioniert.
- Keine PHP- oder JavaScript-Fehler vorhanden sind.

Damit weiß nicht nur die KI, was sie tun soll.

Auch ich weiß anschließend, was ich prüfen muss.

Die KI sollte sich selbst kontrollieren

Sehr nützlich sind Abschlussanweisungen wie:

Prüfe deine Lösung anschließend noch einmal gegen meine Anforderungen.

oder:

Welche meiner Anforderungen hast du möglicherweise nicht vollständig erfüllt?

oder:

Suche vor Abschluss nach möglichen Seiteneffekten deiner Änderung.

oder:

Nenne mir alle Punkte, die du nicht sicher prüfen konntest.

oder:

Versuche jetzt selbst, deine Lösung kaputtzumachen.

Welche Randfälle könnten noch Probleme verursachen?

Das ist selbstverständlich keine Garantie gegen Fehler.

Aber es zwingt die KI zu einer zusätzlichen Kontrollrunde.

Sicherheit: Hier sollte ein Laie besonders vorsichtig sein

KI kann Code sehr schnell verändern.

Genau deshalb kann sie auch sehr schnell Schaden anrichten.

Bei produktiven Systemen würde ich einem Coding-Agenten dauerhaft Regeln wie diese geben:

Keine Daten löschen.

Keine Datenbanktabellen löschen, leeren oder zurücksetzen.

Keine produktiven Daten verändern, wenn dies nicht ausdrücklich
Teil des Auftrags ist.

Keine Passwörter, API-Schlüssel oder Zugangsdaten offen speichern.

Keine Sicherheitsmechanismen abschalten, um ein Problem einfacher
zu lösen.

Keine Dateiberechtigungen pauschal erweitern.

Keine vorhandenen Backups überschreiben.

Keine irreversiblen oder schwer rückgängig zu machenden Aktionen
ohne ausdrückliche Bestätigung durchführen.

Und ganz wichtig:

Ein Backup ist kein Prompt.

Vor größeren Änderungen sollte tatsächlich eine Sicherung oder Versionsverwaltung vorhanden sein.

Kein noch so guter Satz im Prompt ersetzt ein Backup.

Ein guter Prompt ersetzt keine Kontrolle

Moderne KI wirkt manchmal erschreckend überzeugend.

Das ist praktisch – und gefährlich.

Eine falsche Erklärung kann genauso selbstbewusst formuliert sein wie eine richtige.

Deshalb verwende ich Formulierungen wie:

Wenn du etwas nicht sicher weißt, sage es ausdrücklich.

Trenne geprüfte Tatsachen von Vermutungen.

Erfinde keine Funktionen, Dateien, Tabellen, APIs oder Einstellungen.

Wenn aktuelle Informationen entscheidend sind, prüfe aktuelle Quellen.

Besonders bei Sicherheit, Recht, Finanzen oder produktiven Daten sollte KI niemals die einzige Kontrollinstanz sein.

Die KI darf mir widersprechen

Auch das gehört für mich zu einem guten Projekt.

Ich möchte keinen Assistenten, der jede Idee begeistert bestätigt.

Eine nützliche Anweisung lautet deshalb:

Wenn meine gewünschte Lösung technisch problematisch, unsicher oder
unnötig kompliziert ist, sage mir das verständlich und schlage eine
bessere Alternative vor.

Noch besser:

Unterscheide zwischen:

- technisch unmöglich,
- technisch möglich aber riskant,
- möglich aber unnötig kompliziert,
- sinnvoll.

Damit kann auch ein Nicht-Programmierer Entscheidungen besser einschätzen.

Man muss nicht wissen, wie etwas heißt

Das ist vielleicht eine der angenehmsten Eigenschaften heutiger KI.

Ich muss nicht unbedingt wissen, wie ein bestimmtes Bedienelement technisch heißt.

Ich kann schreiben:

„Ich möchte rechts unten diesen kleinen runden Knopf, auf den man klickt und dann wieder nach oben kommt.“

Die KI wird vermutlich erkennen, dass ein Scroll-to-Top-Button gemeint ist.

Oder:

„Beim Anklicken soll sich kein neues Fenster öffnen, sondern so eine kleine Box über der Seite.“

Dann kann die KI erklären, dass vermutlich ein Modal oder Dialog gemeint ist.

Das bedeutet:

Ich muss nicht die Fachsprache kennen, um eine Idee beschreiben zu können.

Wenn mir ein Begriff fehlt, kann ich schlicht fragen:

Wie nennt man das technisch?

Oder:

Ich kenne den Fachbegriff dafür nicht.

Ich beschreibe dir, was ich möchte.
Sage mir anschließend, wie man diese Funktion üblicherweise nennt.

Mein Auftragsgenerator für Laien

Wenn ich nur eine Idee habe, aber noch keinen guten Prompt, würde ich diese Vorlage verwenden:

Ich möchte dir zunächst nur mein Vorhaben beschreiben.

Ich bin kein professioneller Entwickler und kenne möglicherweise
nicht alle technischen Anforderungen und Fachbegriffe.

MEINE IDEE

[Hier ganz normal beschreiben, was man möchte.]

Deine Aufgabe ist zunächst NICHT die Umsetzung.

Erstelle aus meiner Beschreibung einen professionellen,
aber für mich verständlichen Arbeitsauftrag.

Strukturiere ihn in:

1. Ziel
2. Ausgangssituation
3. gewünschte Funktionen
4. Bestandsschutz
5. ausdrücklich nicht gewünschte Änderungen
6. technische Rahmenbedingungen
7. Sicherheitsanforderungen
8. Rand- und Fehlerfälle
9. Akzeptanzkriterien
10. erforderliche Tests

Ergänze wichtige Punkte, die ich als Laie möglicherweise übersehen habe.

Füge keine zusätzlichen Komfortfunktionen hinzu, die für mein
eigentliches Ziel nicht erforderlich sind.

Kennzeichne Annahmen deutlich.

Zeige mir den fertigen Auftrag zuerst zur Prüfung.

Noch nichts programmieren oder verändern.

Das ist vermutlich einer der nützlichsten „Prompts“ im gesamten Beitrag.

Denn damit muss ich nicht lernen, perfekte Prompts zu schreiben.

Ich kann mir beim Schreiben helfen lassen.

Mein Universalprompt für Änderungen

Für viele kleinere Arbeiten reicht diese Vorlage:

Analysiere zuerst die bestehende Umsetzung.

ZIEL

[Was soll anschließend anders funktionieren?]

BESTANDSSCHUTZ

Alles, was nicht für dieses Ziel geändert werden muss,
bleibt unverändert.

VORGABEN

[Technische oder gestalterische Wünsche]

NICHT VERÄNDERN

[Besonders wichtige bestehende Funktionen]

ARBEITSWEISE

Prüfe zuerst, ob vorhandene Funktionen wiederverwendet werden können.

Vermeide unnötige neue Dateien, Abhängigkeiten und Refactorings.

Erfinde keine Bestandteile des Projekts, sondern prüfe sie tatsächlich.

FERTIG, WENN

[Konkrete und prüfbare Kriterien]

ABSCHLUSS

Prüfe deine Änderung.

Nenne anschließend:
- geänderte Dateien,
- durchgeführte Tests,
- offene Punkte,
- mögliche Risiken.

Damit kommt man erstaunlich weit.

Mein Universalprompt für Fehler

Untersuche diesen Fehler.

Ändere zunächst noch nichts.

1. Reproduziere bzw. lokalisiere das Problem.
2. Ermittle die eigentliche Ursache.
3. Prüfe die dafür relevanten Dateien und Abhängigkeiten.
4. Erkläre mir die Ursache verständlich.
5. Schlage die kleinstmögliche sichere Korrektur vor.
6. Prüfe mögliche Seiteneffekte.

Keine Refactorings oder sonstigen Verbesserungen außerhalb dieses Fehlers.

Nach der Korrektur:

- ursprünglichen Fehler erneut testen,
- betroffene bestehende Funktionen prüfen,
- geänderte Dateien nennen,
- verbleibende Risiken nennen.

Gerade der Satz

„Behebe die Ursache, nicht nur das Symptom.“

gehört inzwischen zu meinen Favoriten.

Mein Universalprompt für eine neue Funktion

Ich möchte folgende Funktion ergänzen:

[BESCHREIBUNG]

Analysiere zuerst die bestehende Anwendung und prüfe,
wo diese Funktion am sinnvollsten integriert wird.

Nutze vorhandene Architektur, Komponenten, Datenquellen
und Gestaltungsmuster.

Erstelle zunächst einen kurzen Umsetzungsplan.

Berücksichtige:

- Desktop
- Smartphone
- Fehlerfälle
- Eingabevalidierung
- Sicherheit
- bestehende Benutzerrechte
- bestehendes Design

Verändere keine nicht betroffenen Funktionen.

Definiere vor der Umsetzung klare Akzeptanzkriterien
und prüfe die fertige Funktion anschließend dagegen.

Mein Prompt für „Ich weiß eigentlich noch gar nicht genau, was ich brauche“

Auch das kommt vor.

Dann würde ich gar keinen technischen Auftrag formulieren.

Stattdessen:

Ich habe folgende Idee:

[Idee beschreiben]

Ich bin noch nicht sicher, wie daraus eine sinnvolle Funktion
oder Anwendung werden sollte.

Programmiere noch nichts.

Hilf mir zuerst dabei, die Idee zu strukturieren.

Trenne dabei:

- unbedingt erforderlich,
- sinnvoll,
- optional,
- unnötig kompliziert.

Zeige mir anschließend die kleinstmögliche sinnvolle erste Version.

Ich möchte zunächst keinen Funktionsumfang auf Vorrat entwickeln.

Gerade für neue Projekte kann das vor viel unnötiger Arbeit schützen.

Was ich inzwischen vermeiden würde

Ein riesiger Prompt mit hundert Regeln ist nicht automatisch besser.

Im Gegenteil.

Je mehr Regeln gleichzeitig enthalten sind, desto größer wird die Wahrscheinlichkeit, dass wichtige Informationen zwischen unwichtigen Dingen untergehen oder sich Regeln sogar widersprechen.

Claude Code empfiehlt beispielsweise ausdrücklich kurze, konkrete und strukturierte Projektanweisungen und weist darauf hin, dass lange Anweisungsdateien zusätzlichen Kontext verbrauchen und schlechter befolgt werden können.

Also nicht alles in einen gigantischen Masterprompt stopfen.

Lieber sauber trennen:

dauerhafte Projektregeln
+
relevante Projektdokumentation
+
aktueller Kontext
+
konkreter Auftrag
+
prüfbare Akzeptanzkriterien

Das ist für mich die deutlich bessere Arbeitsweise.

Was ChatGPT, Gemini, Claude und Copilot gemeinsam haben

Interessanterweise ähneln sich die Empfehlungen der verschiedenen Anbieter.

Google empfiehlt für Gems unter anderem Persona, Aufgabe, Kontext und Format und bietet sogar an, kurze eigene Anweisungen automatisch ausführlicher formulieren zu lassen.

GitHub empfiehlt bei Copilot, zunächst das allgemeine Ziel zu beschreiben, danach konkreter zu werden, Beispiele zu geben, große Aufgaben zu zerlegen, Zweideutigkeiten zu vermeiden und relevanten Code als Kontext bereitzustellen.

ChatGPT-Projekte kombinieren dauerhafte Projektanweisungen mit Dateien und Chats.

Codex und Claude Code gehen bei Softwareprojekten noch einen Schritt weiter und können dauerhafte Anweisungen direkt aus Projektdateien berücksichtigen.

Die Produkte unterscheiden sich.

Die Grundidee guten Arbeitens mit KI erstaunlich wenig:

Ziel erklären, Kontext liefern, Grenzen setzen, Ergebnis definieren und anschließend prüfen.

Die eigentliche Superkraft ist nicht der perfekte Prompt

Am Anfang habe ich gedacht, man müsse irgendwann den perfekten Prompt kennen.

Inzwischen sehe ich das anders.

Ein guter Arbeitsablauf ist wichtiger.

Ich beschreibe zunächst meine Idee.

Wenn ich selbst noch keinen guten Auftrag formulieren kann, lasse ich die KI daraus zunächst einen Vorschlag erstellen.

Ich lese diesen Auftrag.

Ich korrigiere Missverständnisse.

Dann lasse ich die KI das vorhandene System untersuchen.

Wir grenzen die Aufgabe ein.

Wir definieren, was unverändert bleiben muss.

Wir legen fest, wann die Aufgabe als erledigt gilt.

Erst dann wird umgesetzt.

Anschließend wird geprüft.

Wenn etwas nicht stimmt, wird nicht gleich die halbe Anwendung neu geschrieben, sondern der konkrete Fehler untersucht.

Das ist wesentlich unspektakulärer als ein angeblicher geheimer „Superprompt“.

Aber es funktioniert.

Mein vielleicht wichtigster Satz für Nicht-Programmierer

Wenn ich nur einen einzigen Prompt-Tipp behalten dürfte, wäre es vermutlich dieser:

Ich bin kein professioneller Entwickler.

Triff technische Detailentscheidungen sinnvoll selbst,
aber erkläre mir Entscheidungen, bei denen mehrere relevante
Möglichkeiten bestehen oder Risiken entstehen.

Ändere nichts außerhalb meines eigentlichen Ziels.

Wenn du etwas nicht sicher weißt, prüfe es oder sage offen,
dass du es nicht weißt.

Denn genau darin liegt für mich die Stärke dieser neuen Werkzeuge.

Ich muss nicht plötzlich selbst Programmierer werden.

Aber ich kann lernen, gute Anforderungen zu stellen, Ergebnisse kritisch zu prüfen und einer KI klare Grenzen zu setzen.

Mein persönlicher Ablauf in Kurzform

Für ein neues Vorhaben würde ich heute ungefähr so vorgehen:

1. Idee beschreiben

Ganz normal, ohne krampfhaft technische Begriffe zu suchen.

2. KI daraus einen Auftrag erstellen lassen

Noch nichts programmieren.

3. Auftrag selbst lesen

Hat die KI mich wirklich richtig verstanden?

4. Bestehendes Projekt untersuchen lassen

Welche Dateien, Funktionen und Abhängigkeiten sind tatsächlich betroffen?

5. Bestandsschutz festlegen

Was darf auf keinen Fall verändert werden?

6. Akzeptanzkriterien definieren

Woran erkenne ich, dass die Aufgabe funktioniert?

7. Umsetzen

Möglichst mit kleinem, klar begrenztem Umfang.

8. Testen

Neue Funktion und bestehende Funktionen prüfen.

9. KI ihre eigene Arbeit kritisieren lassen

Seiteneffekte, Randfälle und nicht geprüfte Punkte suchen lassen.

10. Selbst ausprobieren

Am Ende zählt nicht, dass die KI sagt:

„Die Implementierung wurde erfolgreich abgeschlossen.“

Entscheidend ist:

Funktioniert sie tatsächlich?

Fazit

Noch vor wenigen Jahren wäre die Vorstellung ziemlich absurd gewesen, dass jemand ohne klassische Programmierausbildung eine eigene Webseite oder Webanwendung entwickelt und dabei mit einer KI über Datenbanken, Benutzerrechte, responsive Layouts oder Serverfehler diskutiert.

Heute ist das möglich.

Nicht automatisch.

Nicht fehlerfrei.

Und schon gar nicht ohne Verantwortung.

Aber die Einstiegshürde ist dramatisch gesunken.

Dabei muss ich nicht einmal lernen, den perfekten Prompt zu schreiben.

Ich kann der KI zunächst einfach erklären, was ich vorhabe.

Dann kann ich sie bitten:

„Hilf mir zuerst dabei, daraus einen vernünftigen Auftrag zu machen.“

Vielleicht ist genau das der größte Unterschied zur früheren Vorstellung von Prompt Engineering.

Es geht weniger darum, einen geheimen Satz zu kennen, der plötzlich perfekte Ergebnisse erzeugt.

Es geht darum, mit der KI gemeinsam aus einer Idee eine eindeutige Aufgabe zu entwickeln.

Aus

„Mach mir eine Webseite.“

wird dann irgendwann:

„Das ist mein Ziel. Das ist mein bestehendes System. Das darfst du verändern. Das darfst du nicht verändern. Daran erkennen wir, ob es funktioniert. Prüfe den Auftrag mit mir – und erst danach fangen wir an.“

Und für jemanden wie mich, der selbst kein Programmierer ist, ist das wahrscheinlich die spannendste Entwicklung überhaupt.