Für $0.99 starten

20 Coding-Prompts, bei denen die KI nicht mehr rät

Schlechter KI-Code entsteht meist dort, wo das Modell Lücken füllt, die du offen gelassen hast. Jeder Prompt hier schließt eine davon: Das Modell liest, bevor es schreibt, testet, bevor es repariert, und ordnet seine Vermutungen offen nach Wahrscheinlichkeit.

Ersetze alles in [Klammern] durch dein eigener Code, Fehler oder Ziel.

01. Den Wirkungsradius kartieren, bevor du etwas anfasst

Bevor du Code änderst, den du nicht selbst geschrieben hast.

Lies den folgenden Code. Schreibe oder ändere noch keinen Code.

Sag mir:
1. Was er tut, in höchstens drei Sätzen.
2. Jede Annahme, die er über seine Eingaben, seine Aufrufer und seine Umgebung trifft.
3. Was kaputtgehen würde, wenn ich [beschreibe die gewünschte Änderung], und wo.

Wenn du eine weitere Datei sehen musst, um zu antworten, nenne die Datei und höre auf.

[Code einfügen]

02. Die Ursachen ordnen, bevor jemand einen Fix schreibt

Ein Bug, den du dir noch nicht erklären kannst.

Hier ist ein Fehler und der Code drumherum.

Nenne die drei wahrscheinlichsten Ursachen, die wahrscheinlichste zuerst. Gib mir zu jeder die eine Logzeile oder den einen Test, der sie bestätigt oder ausschließt.

Schlage keinen Fix vor. Ich führe die Prüfungen aus und sage dir, welche Ursache es war.

Fehler und Stacktrace:
[Fehler einfügen]

Code:
[relevanten Code einfügen]

03. Die fehlschlagenden Tests schreiben, dann aufhören

Bevor du neuen Code oder einen Fix anforderst.

Schreibe Tests für [Funktion oder Feature] mit [Test-Framework].

Decke den Normalfall ab, diese Randfälle: [nenne die, die du schon kennst], und mindestens zwei Fälle, an die ich deiner Meinung nach nicht gedacht habe. Sag in einer Zeile, warum jeder dieser beiden wichtig ist.

Jeder Test soll gegen den aktuellen Code oder eine fehlende Implementierung fehlschlagen. Schreibe nicht die Implementierung.

Die übrigen 17 Prompts gratis: einfach den Newsletter abonnieren

Melde dich für den Whizi-Newsletter an und lies den Rest dieses Pakets.

  1. Den Diff prüfen wie die Person, die nachts angepiept wird
  2. Refactoring, ohne ein einziges Verhalten zu ändern
  3. Die fünf Dateien auswählen, die du zuerst liest
  4. Die Query gegen dein echtes Schema schreiben
  5. Einen Regex mit den Fällen bekommen, die ihn beweisen
  6. Code so portieren, dass er wie von Muttersprachlern geschrieben klingt
  7. Anhand eines echten Profils finden, wo die Zeit bleibt
  8. Nicht vertrauenswürdige Eingaben von der Quelle bis zur Senke verfolgen
  9. Die README schreiben, mit der Fremde arbeiten können
  10. Die Commit-Nachricht aus dem Diff schreiben
  11. Ein Konzept mit deinem eigenen Code lernen
  12. Die API entwerfen und den Entwurf dann angreifen
  13. Eine Migration planen, die die Seite nie lahmlegt
  14. Das Modell die Fragen stellen lassen
  15. Die Eingaben auflisten, die ihn kaputtmachen
  16. Herausfinden, was ein Dependency-Upgrade in deinem Code kaputtmacht
  17. Ein zweites Modell bitten, das erste zu benoten