Für mich ist KI am stärksten, wenn ich das Ziel und den fachlichen Kontext kenne, aber nicht jede Syntax, jedes Detail oder jeden möglichen Lösungsweg selbst beherrschen muss.
1. Das Problem kommt zuerst
Ich starte möglichst nicht mit „Schreib mir Code“, sondern mit der Frage: Was soll am Ende funktionieren? Welche Daten habe ich? Was darf sich ändern und was nicht? Wer soll die Lösung später bedienen? Und woran erkenne ich, dass sie wirklich funktioniert?
Ein halber Absatz guter Kontext ist für ein reales Projekt oft wertvoller als ein kunstvoll formulierter Einzeiler.
2. Ein guter Prompt besteht für mich aus Bausteinen
| Baustein | Frage dahinter |
|---|---|
| Ziel | Was soll am Ende konkret funktionieren? |
| Ausgangslage | Welche Dateien, Systeme oder Daten existieren bereits? |
| Grenzen | Was darf nicht verändert werden? Welche Technik soll bewusst vermieden werden? |
| Erwartung | Brauche ich Erklärung, Entwurf, fertigen Code, Prüfschritte oder mehrere Varianten? |
| Prüfung | Wie testen wir anschließend, ob die Lösung wirklich stimmt? |
3. Bei länger laufenden Projekten kommen Grundregeln dazu
Wenn ein Projekt größer wird, möchte ich bestimmte Arbeitsweisen nicht in jedem einzelnen Prompt neu erklären. Deshalb halte ich Grundsätze dauerhaft fest – zum Beispiel in Projektanweisungen, Projektdokumentationen oder einer methodischen Basis.
- Bei aktuellen oder unklaren Themen nicht raten, sondern aktuelle Quellen prüfen.
- Unsicherheiten sichtbar benennen.
- Bei technischen Änderungen immer vom zuletzt bestätigten Quellstand ausgehen.
- Spezifische Projektdokumentation hat Vorrang vor allgemeinen Annahmen.
- Keine Zugangsdaten in normale Arbeitsdialoge übernehmen.
- Bei Code erklären, was wo passiert, statt nur einen Block zum Kopieren hinzustellen.
4. Ich lasse mir nicht nur das Ergebnis geben
Bei VBA, Excel, JavaScript oder Webtechnik möchte ich erklärt bekommen, wo Daten gelesen, verarbeitet, geprüft und geschrieben werden. Ich muss den Code nicht komplett selbst schreiben können. Aber ich möchte ihn so weit verstehen, dass ich bei einem Fehler eine sinnvolle Vermutung habe.
5. Bestehende Lösungen dürfen bleiben – oder besser werden
Eine alte Lösung ist nicht automatisch schlecht. Meine frühere Kickbase-Exceldatei hat funktioniert. Später war aber die spannende Frage: Wenn neue Werkzeuge verfügbar sind, lässt sich dieselbe Aufgabe heute einfacher, robuster oder schneller lösen?
6. Ich teste gegen die Realität
Ein Code kann logisch aussehen und trotzdem auf dem Smartphone schlecht sein. Eine API kann andere Daten liefern als erwartet. Ein Webserver kann eine Konfiguration anders behandeln als gedacht. Und eine KI kann eine Schnittstelle sehr überzeugend falsch beschreiben.
Deshalb gehören echte Tests zum Arbeitsweg. Erst der Test macht aus einer plausiblen Antwort eine belastbare Lösung.
7. Bei größeren Projekten wird dokumentiert
Wenn ein Projekt nach Wochen weitergehen soll, reicht der Chatverlauf nicht als technische Dokumentation. Deshalb entstehen bei größeren Vorhaben ein bestätigter Quellstand und eine Projektdokumentation. So kann ein neuer Chat oder ein anderer Bearbeiter wieder einsteigen, ohne die gesamte Geschichte rekonstruieren zu müssen.
LSD Worringen und PODC sind dafür gute Beispiele: Die Dokumentation ist nicht hübsches Beiwerk, sondern Teil der technischen Lösung.
8. Sensible Daten bleiben draußen
Kennwörter, Tokens und unnötige vertrauliche Informationen gehören nicht in normale Arbeitsdialoge. Wenn echte Daten nötig sind, wird möglichst nur das geteilt, was für die konkrete Aufgabe gebraucht wird.
Wie ich den Überblick über mehrere Projekte behalte
Wenn ich nach ein paar Wochen an einer Website oder einer Excel-Lösung weiterarbeite, möchte ich nicht zuerst herausfinden müssen, welcher von fünf alten Dateiständen der richtige ist. Deshalb nutze ich inzwischen eine zentrale Startdatei. Sie enthält die Wegweiser zu den aktuellen Projektdokumentationen und Dateien.
Die Startdatei erklärt nicht jedes Projekt im Detail. Sie beantwortet zunächst: Woran arbeiten wir? Welche Quelle ist maßgeblich? Wo liegt der zuletzt bestätigte Stand? Die fachlichen Einzelheiten bleiben in der jeweiligen Projektdokumentation.
Aktuell ist wichtiger als bequem erreichbar
Projektdateien und meine zentrale Ablage können unterschiedliche Stände enthalten. Dann lasse ich Datum, Version und Freigabestatus vergleichen. Eine neuere Datei ist nicht automatisch schon produktiv; eine ausdrücklich bestätigte Referenz hat mehr Gewicht als ein ungetesteter Zwischenstand. Wenn sich Quellen widersprechen, muss der Widerspruch geklärt werden.
Wiederkehrende Arbeit bekommt eine feste Methode
Für Dokumentationen und Übergaben verwende ich wiederverwendbare Arbeitsanweisungen, sogenannte Skills. Darin steht beispielsweise, dass eine Dokumentation den aktuellen nutzbaren Stand beschreiben soll und keine Nacherzählung des gesamten Chats. Auch Aufbau, Prüfschritte und Darstellung werden damit einheitlicher.
Der Nutzen ist für mich ganz praktisch: Ich muss dieselben Anforderungen nicht jedes Mal neu erklären. Trotzdem prüfe ich das Ergebnis. Eine feste Methode kann helfen, Fehler zu vermeiden; sie kann nicht garantieren, dass alle Quellen gelesen oder alle Aussagen richtig verstanden wurden.
Ein neuer Chat braucht einen klaren Einstieg
Wenn ein Chat lang geworden ist, halte ich für den nächsten Einstieg Ziel, bestätigten Stand, wichtige Entscheidungen und offene Punkte fest. Dazu kommen die konkreten Referenzdateien. Eine solche Übergabe spart Sucharbeit und verringert das Risiko, dass wir bereits verworfene Lösungen noch einmal verfolgen.
Für mich wird die Zusammenarbeit dadurch verlässlicher: Ich behalte Ziel und Entscheidung in der Hand, die KI hilft beim Umsetzen und Prüfen, und das Ergebnis bleibt auch nach einer Pause nachvollziehbar.
Ein Praxistest darf auch die erste Antwort korrigieren
Bei einer Websiteprüfung wurde das besonders deutlich. Was bei einer ersten Auswertung fehlte, war im echten Browser teilweise vorhanden. Wir mussten einige Befunde korrigieren und andere genauer prüfen. Genau diese Gegenprüfung gehört für mich zur Zusammenarbeit.
Den Ablauf beschreibe ich in „Warum eine Websiteprüfung einen echten Browser braucht“. Ein weiteres Beispiel aus dem Alltag ist die Prüfung externer SharePoint-Freigaben: Eine gesetzte Berechtigung allein sagt noch nicht, ob die betreffende Person ihren Einstieg findet.
Meine typische Arbeitsteilung
| Aufgabe | Typisch |
|---|---|
| Idee, Ziel, fachliche Anforderungen | ich |
| Varianten, Recherche, Syntax, erster Code | häufig KI-unterstützt |
| Abwägen und Prioritäten | gemeinsam, Entscheidung bei mir |
| Praxistest mit echten Daten/Geräten | ich |
| Fehlersuche und Überarbeitung | gemeinsam |
| Dokumentation | gemeinsam, fachlich freigegeben |
Aktueller Produkt-Hinweis zu ChatGPT
Stand September 2026 lassen sich in ChatGPT sowohl benutzerdefinierte Anweisungen als auch projektspezifische Anweisungen verwenden. Das ist praktisch, um Arbeitsweisen dauerhaft festzuhalten. OpenAI weist gleichzeitig selbst darauf hin, dass ChatGPT falsch oder irreführend antworten und dabei trotzdem sehr sicher klingen kann. Wichtige Informationen sollten deshalb anhand verlässlicher Quellen überprüft werden.
Produktfunktionen und Einstellungswege ändern sich. Deshalb beschreibe ich sie hier bewusst nicht als für alle Zeiten gültige Klickanleitung. Wer das aktuell nachsehen möchte, findet die offiziellen Hinweise bei OpenAI zu benutzerdefinierten Anweisungen, Projekten und Projektanweisungen sowie zur Frage „Sagt ChatGPT die Wahrheit?“.
Der ausführlichere Gedanke dahinter steht im Grundsatzartikel „Von der Idee zum Ergebnis“. Warum ein vermeintlich perfekter Prompt nicht reicht, beschreibe ich in „Warum ein guter Prompt allein nicht reicht“.