KI schreibt ständig falschen Code? 5 Prompt-Techniken für 50 % mehr Effizienz

Freitag, 16:30 Uhr – der gerade von Cursor generierte Code, und man ist einfach nur fertig.

Eigentlich sollte nur ein Login-Endpunkt entstehen. Stattdessen ein 300-Zeilen-Monster: falsche Parametertypen, fest verdrahtete DB-Verbindung, drei verschiedene Fehlerbehandlungs-Stile durcheinander. Tief durchatmen, alles löschen, von vorn. Beim zweiten Versuch wurden Config-Dateien umgeschrieben, die gar nicht an der Reihe waren.

In dem Moment wurde klar: Das Problem ist nicht die KI – sondern dass man ihr nie gesagt hat, was zu tun ist und was nicht.

KI-Programmiertools sind installiert, die Begeisterung ist da – aber nach einer Weile merkt man: Der Code passt nicht, oder sieht gut aus und bricht in Produktion. Nach mehreren Runden ist Handarbeit schneller.

Ein Kollege mit demselben Cursor, dieselbe Funktion – zehn Minuten statt einer Stunde. Der Unterschied? Strukturierte Prompts, vollständiger Kontext, klare Grenzen.

Dieser Artikel zeigt 5 sofort wirksame Cursor-Prompt-Techniken – keine abstrakte Theorie, sondern Praxis aus dem Alltag. Danach versteht die KI Anforderungen besser und liefert brauchbaren Code.

Warum Ihre Prompts immer „versagen“

KI liest keine Gedanken – sie „sieht“ nur, was Sie liefern

Viele glauben, KI sei so schlau, dass sie errät, was gemeint ist. Falsch. Auch die stärkste KI ist im Kern ein fortgeschrittener Text-Vervollständiger – sie schließt nur aus dem, was Sie geben. Fehlt etwas, muss sie raten.

Wie beim Anruf: „Hol mir einen Kaffee.“ In der Bar: Americano oder Latte? Groß oder mittel? Zucker? Am Ende eine zufällige Wahl. Bei der KI genauso.

In großen Projekten fällt das Kontextlimit stärker auf. Die KI kann nicht die ganze Codebasis „im Kopf“ haben. Sie ändern eine Funktion – sie weiß nicht, dass 20 andere Stellen sie aufrufen. Ein Griff, und alles bricht.

Drei typische Prompt-Desaster

Desaster 1: Zu vage

❌ „Implementiere mir eine Sortierung“

Wie GPS mit „Ich will nach Peking“ – wohin genau? Womit? Wann? Die KI improvisiert: Bubble Sort oder eine Bibliothek, die im Projekt gar nicht existiert.

✅ „Füge in utils/array.ts eine Funktion hinzu, die die Benutzerliste nach Registrierungszeit absteigend sortiert, mit nativem Array.sort(), ohne neue Abhängigkeiten“

Unterschied: Datei, Daten, Methode, Grenzen – alles klar.

Desaster 2: Fehlender Kontext

❌ „Füge Fehlerbehandlung hinzu“

KI: Wo? Welche Fehler? try-catch oder Error Codes? Welches Response-Format?

Wie beim Arzt: „Es tut weh“ – ohne Ort keine Diagnose.

✅ „Füge in api/login.ts in handleLogin Fehlerbehandlung hinzu:

• Netzwerkfehler per try-catch abfangen
• Einheitliches Format { success: false, error: string }
• Analog zu api/register.ts“

Desaster 3: Keine Einschränkungen

❌ „Optimiere die Performance dieser Komponente“

Die KI refactored alles: neue Bibliotheken, neues State Management, kompletter Umbau. Sie wollten nur React.memo – sie liefert eine OP.

✅ „Optimiere UserList.tsx:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

• Nur React.memo oder useMemo
• Props-Schnittstelle nicht ändern
• Keine neuen Drittanbieter-Bibliotheken“

Die Wahrheit über KI-„Halluzinationen“

Code, der nicht existierende Funktionen aufruft? Variablen, die es im Projekt nicht gibt? Das sind Halluzinationen.

Laut Cursor-Best-Practices reduziert klarer Kontext etwa 70 % der Halluzinationen. Warum?

Bei unvollständigen Infos ergänzt die KI. Ohne Beispielcode rät sie nach „üblichen Mustern“. Login-Feature → vielleicht authService.login() – existiert bei Ihnen gar nicht.

Die Lösung: Relevanten bestehenden Code explizit zeigen.

Vor jedem Prompt drei Fragen:

1. Weiß die KI, in welcher Datei ich arbeite?
2. Kennt sie die bestehende Struktur?
3. Weiß sie, was geändert werden darf und was nicht?

Wenn Sie eine Frage nicht beantworten können – noch nicht senden.

Die goldene Formel für strukturierte Prompts

5W1H: Damit die KI sofort versteht

Journalisten nutzen 5W1H (Who, What, When, Where, Why, How). Prompts auch.

• What (Was): Was soll die KI tun?
• Why (Warum): Wozu? (Intent verstehen)
• Where (Wo): Welche Datei/Modul?
• When (Wann): Unter welcher Bedingung?
• Who (Wer/Was): Welches Datenobjekt?
• How (Wie): Welcher Stack/Bibliothek?

Nicht jedes Mal alles – Kern: Die KI soll nicht raten müssen.

Beispiel Validierung:

❌ Vage:

Benutzereingabe validieren

✅ 5W1H:

**What**: Eingabevalidierung im Registrierungsformular
**Where**: src/components/RegisterForm.tsx
**Who**: Benutzername, E-Mail, Passwort
**How**: Vorhandene Yup-Bibliothek (installiert)
**When**: Beim Klick auf Absenden
**Why**: Ungültige Daten sollen nicht ans Backend

Cursor-Vorlage (offiziell empfohlen)

## Goal (Ziel)
[Ein Satz: Was soll erreicht werden?]

## Context (Kontext)
[Aktuelle Datei, relevanter Code, Tech-Stack]

## Current Behavior (aktuelles Verhalten)
[Jetziger Zustand]

## Desired Behavior (gewünschtes Verhalten)
[Gewünschtes Ergebnis]

## Acceptance Criteria (Akzeptanzkriterien)
[Wann ist es fertig?]

## Constraints (Einschränkungen)
[Was nicht ändern, welche Regeln gelten]

Besonders wichtig: Constraints. Viele sagen nur, was zu tun ist – nicht, was tabu ist. Dann improvisiert die KI zu viel.

Praxis: React-Login

❌ Vager Prompt (Anfänger):

Implementiere Benutzer-Login

200 Zeilen, unnötige Bibliotheken, erfundene APIs.

✅ Strukturierter Prompt (Fortgeschritten):

## Goal
Benutzer-Login in React-Projekt

## Context
- React 18 + TypeScript
- State: Redux Toolkit
- API: src/services/authService.ts (login-Methode vorhanden)
- UI: Ant Design 5.x

## Current Behavior
Login-Seite (src/pages/Login.tsx) nur statisches UI

## Desired Behavior
1. Benutzername/Passwort eingeben, „Anmelden“ klicken
2. authService.login() aufrufen
3. Erfolg: Token in Redux, Navigation zu /dashboard
4. Fehler: message.error (Ant Design)

## Acceptance Criteria
- [ ] Validierung: Felder nicht leer
- [ ] Loading während Login
- [ ] Passwortfeld type="password"
- [ ] ESLint + TypeScript OK

## Constraints
- **authService.ts nicht ändern**
- **Keine neuen Bibliotheken**
- **Redux slice src/store/authSlice.ts verwenden**

Vergleich der Ergebnisse:

Erster Prompt – KI improvisiert:

// ❌ Freestyle
import { useState } from 'react';
import axios from 'axios'; // nicht angefordert

function Login() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');

  const handleLogin = async () => {
    const res = await axios.post('/api/auth/login', { username, password });
    localStorage.setItem('token', res.data.token); // kein Redux
  };

  // ... 150 Zeilen unnötiger Code
}

Zweiter Prompt – strukturiert:

// ✅ Strukturierter Prompt
import { useState } from 'react';
import { Form, Input, Button, message } from 'antd';
import { useDispatch } from 'react-redux';
import { login } from '@/services/authService';
import { setToken } from '@/store/authSlice';
import { useNavigate } from 'react-router-dom';

export default function Login() {
  const [loading, setLoading] = useState(false);
  const dispatch = useDispatch();
  const navigate = useNavigate();

  const handleSubmit = async (values: { username: string; password: string }) => {
    setLoading(true);
    try {
      const { token } = await login(values.username, values.password);
      dispatch(setToken(token));
      navigate('/dashboard');
    } catch (error) {
      message.error('Anmeldung fehlgeschlagen – Benutzername oder Passwort prüfen');
    } finally {
      setLoading(false);
    }
  };

  return (
    <Form onFinish={handleSubmit}>
      <Form.Item name="username" rules={[{ required: true, message: 'Benutzername eingeben' }]}>
        <Input placeholder="Benutzername" />
      </Form.Item>
      <Form.Item name="password" rules={[{ required: true, message: 'Passwort eingeben' }]}>
        <Input.Password placeholder="Passwort" />
      </Form.Item>
      <Button type="primary" htmlType="submit" loading={loading}>
        Anmelden
      </Button>
    </Form>
  );
}

Unterschied:

• Ant Design wie vorgegeben
• authService statt erfundener API
• Redux statt localStorage
• Validierung + Loading
• Keine neuen Dependencies

So wirkt strukturiertes Prompting.

5 sofort wirksame Prompt-Techniken

Technik 1: Erst planen, dann coden (Plan Mode)

Eine der überzeugendsten Funktionen.

Früher: KI sofort coden lassen – falsche Dateien, gelöschter Code, chaotische Logik. Plan Mode (Shift+Tab) hat den Workflow geändert.

Logik: KI denkt zuerst, handelt danach.

Ablauf:

1. Anforderung beschreiben
2. KI analysiert Codebasis, stellt Fragen („Bestehende Fehlerbehandlung beibehalten?“)
3. Aktionsplan (Dateien, Features)
4. Plan prüfen und anpassen
5. Erst dann Code

Vorteil: Eine zweite Chance, bevor etwas Unwiderrufliches passiert.

Beispiel i18n – Plan:

Plan:
1. i18next und react-i18next installieren
2. src/i18n/locales/ anlegen
3. App.tsx: I18nProvider
4. Hardcoded Texte in ~30 Komponenten

Schritt 4 stoppen: „Nur 3 Seiten zuerst.“ Plan anpassen, dann ausführen.

Ohne Plan Mode: 30 Dateien geändert, Rollback mühsam.

Wert: Besonders bei großen Refactorings und neuen Features.

Technik 2: Konkrete Codebeispiele

KI imitiert Muster. Few-shot Prompting.

Szenario: API-Endpunkt im eigenen Stil.

❌ Ohne Beispiel:

API-Endpunkt für Benutzerliste

app.get('/users', (req, res) => {
  const users = db.getUsers();
  res.json(users);
});

✅ Mit Beispiel:

Benutzerliste-API im Stil bestehender Endpunkte:

**Beispiel 1**:
\`\`\`typescript
export const getProductById = async (req: Request, res: Response) => {
  try {
    const { id } = req.params;
    const product = await productService.findById(id);

    if (!product) {
      return res.status(404).json({
        success: false,
        error: 'Product not found'
      });
    }

    res.json({ success: true, data: product });
  } catch (error) {
    logger.error('Error fetching product:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};
\`\`\`

getUserList analog:
- async/await
- Einheitliche Fehlerbehandlung
- Format: { success, data/error }
- logger für Fehler

Ergebnis:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

export const getUserList = async (req: Request, res: Response) => {
  try {
    const users = await userService.findAll();
    res.json({ success: true, data: users });
  } catch (error) {
    logger.error('Error fetching users:', error);
    res.status(500).json({
      success: false,
      error: 'Internal server error'
    });
  }
};

Tipp: prompts/templates.md im Projektroot für häufige Beispiele.

Technik 3: Explizit sagen, was nicht zu tun ist

Retter in vielen Situationen.

KI „hilft“ gern zu viel – Bugfix wird zum Refactoring mit neuen Bugs.

Laut Cursor: Klare Constraints reduzieren unerwartete Änderungen um etwa 60 %.

❌ Ohne Constraints:

Pagination-Bug in UserList fixen

Mögliche Folgen:

• Props-Schnittstelle geändert
• Gesamte Pagination neu geschrieben
• Neue Bibliothek

✅ Mit Constraints:

Pagination-Bug in UserList fixen

**Constraints**:
- **Props-Schnittstelle (TypeScript) nicht ändern**
- **Keine neuen Bibliotheken**
- **Nur** Logik in handlePageChange
- **UI/Styling unverändert**

Fortgeschritten: Annahmen vorab listen lassen:

Vor dem Fix Annahmen auflisten:
1. Vermutete Bug-Ursache?
2. Welcher Code wird geändert?
3. Neue Dependencies oder Interface-Änderungen?

Technik 4: Akzeptanzkriterien als Anker

Aus Agile übernommen.

Akzeptanzkriterien am Anfang des Prompts – die KI nutzt sie als Ziel.

❌ Ohne Kriterien:

DataTable-Performance refactoren

Wann fertig? Welche Methode? Welcher Maßstab?

✅ Mit Kriterien:

DataTable-Performance refactoren

**Akzeptanzkriterien** (alle erfüllen):
- [ ] 1000 Zeilen: FPS ≥ 55
- [ ] React.memo + useMemo
- [ ] API (props, callbacks) unverändert
- [ ] Alle Unit-Tests grün
- [ ] ESLint OK

**Aktuelles Problem**:
500 Zeilen → FPS ~20, ruckeliges Scrollen

Die KI orientiert sich daran und meidet Änderungen, die Tests oder API brechen.

Technik 5: Inline Edit vs. Agent Mode

Zwei Modi – richtige Wahl verdoppelt Effizienz.

Inline Edit (Cmd+K):

• Für: Einzeldatei, kleine Änderungen, Bugfixes
• Eigenschaft: Schnell, präzise, kein Cross-File-Chaos
• Beispiel: Funktionsname, Parameter, lokaler Bug

Agent Mode (Cmd+I / Chat):

• Für: Multi-Datei, neue Features, Architektur
• Eigenschaft: Codebasis-Analyse, Pläne, Cross-File
• Beispiel: Neues Feature, Migration, großes Refactoring

Früher alles mit Agent Mode – langsam. Einfach → Inline, komplex → Agent.

Entscheidungsbaum:

Mehrere Dateien?
├─ Ja → Agent Mode
└─ Nein → Komplexer Kontext?
    ├─ Ja → Agent Mode
    └─ Nein → Inline Edit

Szenario 1: getUserData → fetchUserData umbenennen → Inline Edit, Cmd+K, fertig.

Szenario 2: Berechtigungssystem (Model, Controller, View, Config) → Agent Mode.

Falsche Wahl:

• Inline bei Komplexem → fehlende Querverbindungen
• Agent bei Trivial → Wartezeit, Over-Engineering

Tipp: Agent Plan zeigen lassen – bei 1–2 Dateien zurück zu Inline.

Fortgeschritten: Ihre Prompt-Toolbox

Wiederverwendbare Vorlagen

Viele Tasks wiederholen sich: API, Komponente, Tests, Migration …

Ordner prompts/ im Projektroot:

prompts/
├── api-endpoint.md
├── react-component.md
├── unit-test.md
├── migration.md
└── refactor.md

Beispiel api-endpoint.md:

# API-Endpunkt-Vorlage

## Goal
In [Modul] API-Endpunkt für [Funktion]

## Context
- Routes: src/routes/[modul].routes.ts
- Controller: src/controllers/[modul].controller.ts
- Service: src/services/[modul].service.ts
- Model: src/models/[modul].model.ts

## Desired Behavior
**Request**:
- Method: [GET/POST/PUT/DELETE]
- Path: /api/[pfad]
- Body/Query: [Parameter]

**Response**:
- Erfolg: { success: true, data: [...] }
- Fehler: { success: false, error: "..." }

## Acceptance Criteria
- [ ] Fehlerbehandlung wie andere Endpunkte
- [ ] async/await
- [ ] Input-Validierung (Joi/Zod)
- [ ] logger bei Fehlern
- [ ] TypeScript OK

## Constraints
- **Routing-Struktur nicht ändern**
- **Keine neuen Bibliotheken** (außer begründet)
- **Bestehende DB-Verbindung nutzen**

Kopieren, ausfüllen, fertig.

Team: Geteilte Vorlagen → konsistenter Stil, schnelleres Onboarding.

Agent Skills (Trend 2026)

Agent Skills = wiederverwendbare „KI-Anwendungen“. Best Practices als Skill, Aufruf wie eine Funktion.

Beispiel Blog: Skill analysiert Text, findet Bildstellen, generiert Prompts, markiert Einfügepunkte.

Anlegen unter .cursor/skills/:

.cursor/
└── skills/
    ├── code-review.md
    ├── test-generator.md
    └── api-doc.md

Seit Dezember 2025 offener Standard – Cursor, Claude Code, VS Code, Copilot.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Anfangs wirkte das over-engineered – in Teamprojekten mit geteilten Skills merkte man sofort den Qualitäts- und Effizienzgewinn.

Projektstruktur für besseres KI-Verständnis

Klare Struktur → bessere KI-Ergebnisse.

1. /prompts: Vorlagen und Beispiele
2. .cursor/context.md: Stack, Stil, Bibliotheken, Konventionen (z. B. _ für private Methoden)
3. Klare Namen: utils/date-formatter.ts statt utils.ts, helpers.ts, common.ts

Erfahrung: Je chaotischer das Repo, desto mehr Halluzinationen.

Fallstricke und Lösungen

Fehler 1: Informationsüberflutung

Anfangsphase: Alles auf einmal – Spec, drei Dateien, fünf Artikel. Ergebnis: KI überfordert, Timeout, falsche Prioritäten.

Schrittweise Offenlegung:

1. Kernanforderung
2. Bei Fragen Details nachliefern
3. Kontext in Schritten

❌ Überladen:

Auth-Modul refactoren.
[500 Zeilen Code]
[Spec]
[3 Artikel]
Performance, Security, Eleganz ...

✅ Iterativ:

Runde 1:
Auth refactoren, Fokus Security.
JWT ohne Refresh. Was brauchst du?

[KI fragt: Token-Laufzeit? Speicherort?]

Runde 2:
1 h, localStorage. Kernlogik:
[50 Zeilen]

Wie verbessern?

[Plan bestätigen, dann coden]

Fehler 2: KI blind vertrauen

Datenverarbeitungsfunktion – Tests grün, Code „schön“, merged. In Produktion: Edge Case, falsche Daten.

„Sieht korrekt aus“ ist am gefährlichsten.

Nach jedem Generieren:

1. Edge Cases: leer, null, undefined, Extremwerte?
2. Seiteneffekte: andere Module?
3. Performance: Endlosschleifen, Leaks, Redundanz?

KI selbst prüfen lassen:

Prüfe deinen Code:
1. Leeres Array als Input?
2. Performance-Probleme?
3. Welche Annahmen – überall gültig?

Fehler 3: Perfektion beim ersten Mal

KI ist Collaborator, kein Zauberknopf. Iterativer Dialog:

1. Anforderung
2. Entwurf oder Fragen
3. Feedback
4. Optimierung
5. Wiederholen

Beispiel Dialog:

Sie: Suchfunktion für Benutzerliste

KI: Suchfeld, Live-Filter. Welche Felder?

Sie: Name + E-Mail, Filter erst nach Klick

KI: Frontend oder Backend?

Sie: Frontend, kleine Datenmenge

KI: Array.filter(), Plan ...

Show Work in Cursor zeigt Reasoning-Schritte.

Bonus: Nicht zu viel Zeit in Prompt-Tuning

Nicht 30 Minuten Prompt für Code, den Sie in 10 Minuten selbst schreiben.

Prompt-Engineering = Effizienz, nicht Schönwettbewerb.

Lohnt sich:

• ✅ Repetitive Tasks
• ✅ Unbekannte Domänen
• ✅ Komplex, aber musterbasiert

Nicht:

• ❌ Trivialer Code
• ❌ Tiefe Algorithmik
• ❌ Einzigartig ohne Muster

KI ist Werkzeug. Schnelle Problemlösung zählt.

Fazit

Gute Prompts sind keine Rocket Science: Ziel klar, Kontext voll, Grenzen fest.

Die 5 Techniken:

1. Plan Mode – zweite Chance vor dem Code
2. Codebeispiele – Stil vorgeben
3. Constraints – Tabuzonen definieren
4. Akzeptanzkriterien – klares Ziel
5. Richtiger Modus – Inline vs. Agent

Danach ist KI kein „nutzloser Assistent“, sondern echter Effizienzpartner. In der Praxis: deutlich höhere Trefferquote, viele repetitive Tasks in Minuten statt Stunden.

Jetzt Cursor öffnen, strukturierte Vorlage testen – ab dem nächsten Feature „Goal – Context – Desired Behavior – Constraints“. Der Unterschied ist sofort spürbar.

Die Zukunft ist nicht „KI ersetzt Entwickler“, sondern Entwickler mit KI ersetzen die ohne. Der Abstand beginnt beim ersten hochwertigen Prompt.