27. Okt. 2025·8 Min
Joel Spolskys Software‑Wahrheiten für KI‑unterstützte Entwicklung
Joel Spolskys Software‑Wahrheiten gelten noch, wenn KI schnell Code schreibt. Erfahre, wie Tests, Einstellung und Einfachheit helfen, Korrektheit zu sichern.
Joel Spolskys Software‑Wahrheiten gelten noch, wenn KI schnell Code schreibt. Erfahre, wie Tests, Einstellung und Einfachheit helfen, Korrektheit zu sichern.
KI kann in Minuten „funktionierend aussehenden“ Code liefern. Das verändert das Tempo eines Projekts, aber nicht das, was Software erfolgreich macht. Joel Spolskys Lehren über "Software‑Wahrheiten" drehten sich nie um Tippgeschwindigkeit. Es ging um Urteilsvermögen, Feedback‑Schleifen und das Vermeiden selbstgemachter Komplexität.
Was sich geändert hat, ist die Kostenstruktur des Codens. Du kannst um drei Ansätze, fünf Variationen oder einen kompletten Rewrite bitten und sofort etwas zurückbekommen. Was sich nicht geändert hat, ist die Kosten für die richtige Entscheidung, das Überprüfen und das Leben mit der Lösung über Monate. Zeitersparnis beim Schreiben verschiebt sich oft aufs Entscheiden, Validieren von Randfällen und Sicherstellen, dass der schnelle Gewinn von heute nicht zur Wartungssteuer von morgen wird.
Korrektheit, Sicherheit und Wartbarkeit brauchen immer noch echte Zeit, weil sie Beweise statt nur Vertrauen erfordern. Ein Login‑Flow ist nicht fertig, wenn er kompiliert. Er ist fertig, wenn er zuverlässig schlechte Eingaben ablehnt, seltsame Zustände handhabt und keine Daten leakt. KI kann sich sicher anhören und doch eine entscheidende Prüfung übersehen—zum Beispiel eine Berechtigungsprüfung an einem Endpoint oder eine Race‑Condition bei einem Zahlungsupdate.
KI ist am stärksten, wenn du sie wie eine schnelle Entwurfsmaschine behandelst. Sie glänzt bei Boilerplate, wiederkehrenden Mustern, schnellen Refactors und beim Erkunden von Optionen, die du nebeneinander vergleichen kannst. Richtig eingesetzt komprimiert sie die „leere Seite“‑Phase.
Am meisten schadet KI, wenn du ihr vage Ziele gibst und die Ausgabe kritiklos akzeptierst. Dieselben Fehlermuster tauchen immer wieder auf: versteckte Annahmen (unausgesprochene Geschäftsregeln), ungetestete Pfade (Fehlerbehandlung, Retries, leere Zustände), selbstsichere Fehler (plausibler, aber subtil falscher Code) und „clevere“ Lösungen, die sich später nur schwer erklären lassen.
Wenn Code billig ist, wird Vertrauen zur knappen Ressource. Diese Wahrheiten schützen dieses Vertrauen: gegenüber Nutzern, Teamkollegen und deinem zukünftigen Ich.
Wenn KI ein Feature in Minuten erzeugen kann, ist die Versuchung groß, Tests als langsamen Teil loswerden zu wollen. Spolskys Punkt bleibt: Der langsame Teil ist dort, wo die Wahrheit liegt. Code ist leicht zu produzieren. Korrektes Verhalten nicht.
Eine nützliche Verschiebung ist, Tests als ausführbare Anforderungen zu behandeln. Wenn du das erwartete Verhalten nicht in überprüfbarer Form beschreiben kannst, hast du noch nicht genug nachgedacht. In KI‑unterstützter Arbeit ist das wichtiger denn je, weil das Modell mit Selbstvertrauen etwas produzieren kann, das nur leicht daneben ist.
Beginne Tests mit den Dingen, die am meisten schaden, wenn sie kaputtgehen. Für die meisten Produkte sind das Kernflüsse (Signup, Checkout, Speichern, Export), Berechtigungen (wer darf ansehen, bearbeiten, löschen) und Datenintegrität (keine Duplikate, korrekte Summen, sichere Migrationen). Danach decke die Ecken ab, die zu nächtlichen Incidents führen: leere Eingaben, lange Texte, Zeitzonen, Retries und fehleranfällige externe Grenzen wie Zahlungen, E‑Mails und Datei‑Uploads.
KI ist großartig beim Vorschlagen von Testfällen, aber sie weiß nicht, was du den Nutzern versprochen hast. Nutze sie als Brainstorming‑Partner: Bitte um fehlende Randfälle, Missbrauchsszenarien und Berechtigungskombinationen. Dann mache die menschliche Arbeit: Passe die Abdeckung an deine echten Regeln an und entferne Tests, die nur die Implementierung prüfen statt das Verhalten.
Mache Fehler aussagbar. Ein fehlschlagender Test sollte dir sagen, was gebrochen ist, und dich nicht auf eine Schatzsuche schicken. Halte Tests klein, nenne sie wie Sätze und mache Fehlermeldungen spezifisch.
Angenommen, du baust mit KI‑Hilfe eine einfache "Team Notes"‑App. CRUD‑Bildschirme erscheinen schnell. Das Korrektheitsrisiko ist nicht die Oberfläche. Es sind Zugriffskontrolle und Datenregeln: Ein Nutzer darf nicht die Notizen eines anderen Teams sehen, Änderungen dürfen neuere Änderungen nicht überschreiben und das Löschen einer Notiz darf keine verwaisten Anhänge zurücklassen. Tests, die diese Regeln verankern, fühlen sich zwar wie der Engpass an, sind aber dein Sicherheitsnetz.
Wenn Tests der Engpass sind, erzwingen sie Klarheit. Diese Klarheit verhindert, dass schneller Code zu schnellen Bugs wird.
Eine der dauerhaftesten Wahrheiten ist: einfacher Code gewinnt gegen cleveren Code. KI macht es verlockend, ausgefeilte Abstraktionen zu akzeptieren, weil sie poliert und schnell erscheinen. Die Kosten zeigen sich später: mehr Orte, an denen Bugs sich verstecken können, mehr Dateien zum Durchsuchen und mehr „Was macht das hier eigentlich?“‑Momente.
Wenn Code billig ist, zahlst du mit Komplexität. Ein kleines, langweiliges Design ist leichter zu testen, leichter zu ändern und leichter zu erklären. Das gilt noch mehr, wenn der erste Entwurf von einem Modell stammt, das sich selbstsicher anhören kann und doch subtil falsch ist.
Eine praktische Regel: Halte Funktionen, Komponenten und Module klein genug, dass ein Teamkollege sie in Minuten, nicht in Stunden, reviewen kann. Wenn eine React‑Komponente mehrere Custom‑Hooks, eine lokale Zustandsmaschine und eine generische „Smart Renderer“‑Schicht braucht, halte inne und frage, ob du ein echtes Problem löst oder einfach Architektur akzeptierst, weil die KI sie angeboten hat.
Ein paar "Einfachheits‑Tests" helfen beim Zurückdrängen:
Prompts sind hier wichtig. Wenn du nach „der besten Architektur" fragst, bekommst du oft ein überfrachtetes Modell. Fordere Einschränkungen, die zu weniger beweglichen Teilen drängen. Zum Beispiel: benutze den einfachsten Ansatz mit den wenigsten Dateien; vermeide neue Abstraktionen, es sei denn, sie entfernen Duplikationen an drei oder mehr Stellen; bevorzuge expliziten Code gegenüber generischen Helfern.
Ein konkretes Beispiel: Du bittest die KI, rollenbasierte Zugriffe für eine Admin‑Seite hinzuzufügen. Die clevere Version führt ein Berechtigungsframework, Decorators und ein Konfigurations‑DSL ein. Die einfache Version prüft die Rolle an einer Stelle, sperrt Routen zentral und loggt verweigerten Zugriff. Die einfache Version ist leichter zu reviewen, zu testen und schwerer falsch zu interpretieren.
Wenn du in einem Chat‑basierten Tool wie Koder.ai arbeitest, machen Snapshots und Rollbacks kleine, offensichtliche Änderungen leichter vergleichbar, behalten oder zurücksetzbar.
Wenn Code leicht zu erzeugen ist, wird die knappe Fähigkeit, zu entscheiden, was überhaupt existieren sollte und sicherzustellen, dass es korrekt ist. Der alte Rat "hire great programmers" bleibt gültig, doch die Rolle verschiebt sich. Du stellst niemanden ein, damit er schneller tippt. Du stellst jemanden ein, der urteilt, verfeinert und das Produkt verteidigt.
Die wertvollsten Menschen in KI‑unterstützter Entwicklung teilen meist vier Eigenschaften: Urteilsvermögen (was zählt), Geschmack (wie gute Arbeit aussieht), Debugging‑Fähigkeit (die echte Ursache finden) und Kommunikation (Trade‑offs klar machen). Sie können eine von KI geschriebene Funktion, die "meistens funktioniert", in etwas verwandeln, dem du vertrauen kannst.
Anstatt eine perfekte Lösung von Grund auf zu verlangen, gib Kandidat:innen eine von KI erzeugte Pull‑Request (oder ein eingefügtes Diff) mit ein paar realistischen Problemen: unklare Benennung, ein versteckter Randfall, fehlende Tests und ein kleiner Sicherheitsfehler.
Bitte sie, in einfachem Sprache zu erklären, was der Code tun soll, die risikoreichsten Teile zu finden, Fixes vorzuschlagen und Tests hinzuzufügen (oder zu skizzieren), die Regressionen aufspüren würden. Wenn du ein starkes Signal willst, frag auch, wie sie die Anweisungen ändern würden, damit der nächste KI‑Versuch besser ist.
Das zeigt, wie sie unter realen Bedingungen denken: unvollständiger Code, begrenzte Zeit und die Notwendigkeit, Prioritäten zu setzen.
KI klingt oft selbstsicher. Gute Angestellte können dagegenhalten. Sie sagen nein zu einem Feature, das Komplexität hinzufügt, nein zu einer Änderung, die Sicherheit schwächt, und nein zum Ausliefern ohne Beweis.
Ein konkretes Signal ist ihre Antwort auf „Würdest du das mergen?" Starke Kandidat:innen geben keine vage Einschätzung. Sie treffen eine Entscheidung und liefern eine kurze Liste notwendiger Änderungen.
Beispiel: Du bittest um ein "schnelles" Access‑Control‑Update und die KI schlägt vor, Checks über Handler zu verstreuen. Ein starker Kandidat lehnt das ab und schlägt eine klare Autorisierungsschicht plus Tests für Admin‑ und Nicht‑Admin‑Pfade vor.
Schließlich: Baut gemeinsame Standards, damit das Team KI‑Output auf dieselbe Weise bearbeitet. Halte es einfach: eine Definition of Done, konsistente Review‑Erwartungen und eine Test‑Baseline.
Wenn KI viel Code in Minuten erzeugen kann, ist es verlockend, das Nachdenken zu überspringen und einfach zu iterieren. Das funktioniert für Demos. Es scheitert, wenn du Korrektheit, vorhersehbares Verhalten und weniger Überraschungen brauchst.
Ein guter Prompt ist meist ein verkapptes kurzes Spec. Bevor du nach Code fragst, verwandle das vage Ziel in ein paar Akzeptanzkriterien und klare Nicht‑Ziele. Das verhindert, dass die KI (und dein Team) stillschweigend den Umfang erweitert.
Halte das Spec klein, aber spezifisch. Du schreibst keinen Roman. Du setzt Grenzen für:
Definiere "Done" vor der Generierung, nicht danach. "Done" sollte mehr sein als "es kompiliert" oder "die UI sieht richtig aus". Schließe Test‑Erwartungen, Abwärtskompatibilität und was nach dem Release überwacht wird mit ein.
Beispiel: Du willst "Passwort zurücksetzen" hinzufügen. Ein klareres Spec könnte sagen: Nutzer fordern per E‑Mail Reset an; Links verfallen nach 15 Minuten; dieselbe Nachricht wird angezeigt, unabhängig davon, ob die E‑Mail existiert; Rate‑Limit pro IP; Reset‑Versuche werden geloggt, ohne Tokens im Klartext zu speichern. Nicht‑Ziel: kein Redesign der Login‑Seite. Jetzt hat dein Prompt Leitplanken und Reviews werden einfacher.
Führe ein leichtgewichtiges Änderungsprotokoll. Ein Absatz pro Entscheidung reicht. Notiere, warum du einen Ansatz gewählt und Alternativen verworfen hast. Wenn in zwei Wochen jemand fragt "Warum ist das so?", hast du eine Antwort.
Die größte Verschiebung mit KI ist: Code zu produzieren ist einfach. Die schwierige Aufgabe ist zu entscheiden, was der Code tun soll, und zu beweisen, dass er es tut.
Beginne damit, Ziel und Einschränkungen in einfacher Sprache zu schreiben. Füge hinzu, was niemals passieren darf, was langsam sein kann und was aus dem Umfang fällt. Eine gute Einschränkung ist testbar: "Kein Nutzer darf die Daten eines anderen Nutzers sehen" oder "Summen müssen mit dem Finanz‑Export aufs Cent genau übereinstimmen."
Bevor du nach Code fragst, bitte um ein einfaches Design und die Trade‑offs. Du willst, dass die KI ihre Überlegungen in einer Form zeigt, die du beurteilen kannst: was sie speichern wird, was sie validiert und was sie loggt. Wenn sie etwas Cleveres vorschlägt, dränge auf die einfachste Version, die die Einschränkungen erfüllt.
Ein wiederholbarer Loop sieht so aus:
Hier ein kleines Szenario: Du fügst dem Bestellbildschirm ein "Refund Status" hinzu. Die KI kann die UI schnell erzeugen, aber Korrektheit lebt in den Randfällen. Was, wenn eine Rückerstattung partiell ist? Was, wenn der Payment‑Provider ein Webhook‑Retry sendet? Schreibe diese Fälle zuerst, implementiere dann eine Scheibe (Datenbankspalte plus Validierung) und verifiziere sie mit Tests, bevor du weitermachst.
Wenn du Koder.ai nutzt, passen Planungsmodus, Snapshots und Rollback natürlich in diesen Loop: zuerst planen, in Scheiben generieren und für jede bedeutsame Änderung einen sicheren Wiederherstellungspunkt festhalten.
Wenn Code‑Generierung schnell geht, ist es verlockend, Code als Arbeitsergebnis zu sehen. Das ist er nicht. Das Arbeitsergebnis ist Verhalten: Die App macht das Richtige, auch wenn etwas schiefgeht.
KI klingt oft überzeugt, auch wenn sie rät. Das Versäumnis ist, den langweiligen Teil zu überspringen: Tests ausführen, Randfälle prüfen und reale Eingaben validieren.
Eine einfache Gewohnheit hilft: Bevor du eine Änderung akzeptierst, frag "Woran erkennen wir, dass das korrekt ist?" Wenn die Antwort "es sieht richtig aus" lautet, spielst du mit Risiko.
KI liebt es, Extras hinzuzufügen: Caching, Retries, zusätzliche Einstellungen, mehr Endpoints, hübschere UI. Manche Ideen sind gut, aber sie erhöhen das Risiko. Viele Bugs kommen von "Nice to have"‑Features, die keiner verlangte.
Ziehe eine harte Grenze: Löse genau das Problem, das du angegangen bist, und höre dann auf. Wenn ein Vorschlag wertvoll ist, notiere ihn als eigene Aufgabe mit eigenen Tests.
Ein großer KI‑generierter Commit kann dutzende unzusammenhängende Entscheidungen verbergen. Review wird zu Gummi‑Stempeln, weil niemand alles im Kopf behalten kann.
Behandle Chat‑Output wie einen Entwurf. Zerlege ihn in kleine Änderungen, die du lesen, ausführen und zurücksetzen kannst. Snapshots und Rollbacks helfen nur, wenn du sie an sinnvollen Punkten erstellst.
Ein paar einfache Limits verhindern die meisten Probleme: ein Feature pro Änderungssatz, eine Migration pro Änderungssatz, ein risikoreicher Bereich nach dem anderen (Auth, Zahlungen, Datenlöschung), Tests im selben Change und eine klare "Wie zu verifizieren"‑Notiz.
KI kann Muster aus Trainingsdaten reproduzieren oder Abhängigkeiten vorschlagen, die du nicht kennst. Selbst wenn Lizenzen in Ordnung sind, ist das größere Risiko Sicherheit: hartkodierte Secrets, schwache Tokenbehandlung oder unsichere Datei‑ und Query‑Operationen.
Wenn du nicht erklären kannst, was ein Snippet macht, versende es nicht. Bitte um eine einfachere Version oder schreibe es selbst neu.
Viele "Es lief auf meinem Rechner"‑Bugs sind Daten‑ und Skalierungsprobleme. KI kann Schemaänderungen vorschlagen, ohne an vorhandene Zeilen, große Tabellen oder Downtime zu denken.
Ein realistisches Beispiel: Das Modell fügt einer PostgreSQL‑Tabelle eine neue NOT NULL‑Spalte hinzu und backfilled sie in einer langsamen Schleife. In Produktion kann das die Tabelle sperren und die App lahmlegen. Überlege immer, was bei einer Million Zeilen, einem langsamen Netzwerk oder einem halb durchgeführten Deploy passiert.
Stell dir ein kleines internes Antrags‑Tracker vor: Leute stellen Anträge, Manager genehmigen oder lehnen ab, und Finance markiert Positionen als bezahlt. Klingt simpel, und mit KI‑Hilfe kannst du Bildschirme und Endpoints schnell erzeugen. Was dich verlangsamt, ist dieselbe alte Wahrheit: die Regeln, nicht das Tippen.
Beginne damit, das Minimum aufzuschreiben, das korrekt sein muss. Wenn du es nicht in einfachen Worten erklären kannst, kannst du es nicht testen.
Eine enge Erstversion‑Definition sieht oft so aus: Felder (Titel, Antragsteller, Abteilung, Betrag, Grund, Status, Zeitstempel); Rollen (Antragsteller, Genehmiger, Finance, Admin); Status (Entwurf, eingereicht, genehmigt, abgelehnt, bezahlt). Dann formuliere die Übergänge, die zählen: Nur ein Genehmiger kann von eingereicht zu genehmigt oder abgelehnt wechseln; nur Finance kann genehmigt zu bezahlt ändern.
Nutze KI in einer kontrollierten Reihenfolge, damit du Fehler früh fängst:
Die wertvollsten Tests sind nicht "lädt die Seite?". Es sind Berechtigungsprüfungen und Zustandsübergänge. Beweise zum Beispiel, dass ein Antragsteller nicht seinen eigenen Antrag genehmigen kann, ein Genehmiger nichts als bezahlt markieren kann, abgelehnte Anträge nicht bezahlt werden können und (falls eure Regel) Beträge nach Einreichung nicht mehr bearbeitet werden dürfen.
Was am längsten dauert, ist das Klären von Randfällen. Kann ein Genehmiger seine Meinung nach Ablehnung ändern? Was, wenn zwei Genehmiger gleichzeitig auf "genehmigen" klicken? Was, wenn Finance teilweise zahlt? KI kann Code für jede von dir gewählte Antwort generieren, aber sie kann die Antwort nicht für dich treffen. Korrektheit entsteht daraus, diese Entscheidungen zu treffen und den Code dazu zu zwingen, sich daran zu halten.
KI kann viel Code schnell produzieren, aber die letzte Meile bleibt menschliche Arbeit: nachweisen, dass es das tut, was du meintest, und im Fehlerfall sicher versagen.
Bevor du Häkchen setzt, wähle die kleinste "Done"‑Definition, die zählt. Für ein kleines Feature kann das ein Happy Path, zwei Fehlerpfade und ein kurzer Lesbarkeitscheck sein. Bei Zahlungen oder Auth erhöhe die Anforderungen.
Angenommen, KI fügt "Bulk Invite Users" zu einer Admin‑Seite hinzu. Der Happy Path funktioniert, aber die echten Risiken sind Randfälle: doppelte E‑Mails, partielle Fehler und Rate‑Limits. Eine solide Auslieferungsentscheidung könnte ein automatisierter Test für Duplikate, eine manuelle Prüfung der Partielle‑Fehler‑Meldung und ein Rollback‑Plan sein.
Wenn Code billig ist, verlagert sich das Risiko auf die Entscheidungsqualität: was du angefordert, akzeptiert und ausgeliefert hast. Der schnellste Weg, diese Wahrheiten in KI‑unterstützter Arbeit nutzbar zu machen, ist, Schützzäune einzuziehen, die verhindern, dass "fast richtig" durchrutscht.
Beginne mit einer einseitigen Spec für das nächste Feature. Halte sie einfach: für wen es ist, was es tun soll, was es nicht tun soll und ein paar Akzeptanztests in Alltagssprache. Diese Akzeptanztests werden dein Anker, wenn die KI eine verlockende Abkürzung vorschlägt.
Ein skalierbares Set von Guardrails ohne großen Prozessaufwand:
Prompts sind jetzt Teil deines Prozesses. Einigt euch auf einen Hausstil: welche Bibliotheken erlaubt sind, wie Fehler gehandhabt werden, was "Done" bedeutet und welche Tests bestehen müssen. Wenn ein Prompt nicht von anderen Teammitgliedern wiederverwendet werden kann, ist er wahrscheinlich zu vage.
Wenn du lieber chat‑zentriert Web, Backend und Mobile bauen willst, ist Koder.ai (koder.ai) ein Beispiel für eine vibe‑coding Plattform, bei der Planungsmodus, Snapshots und Source‑Code‑Export diese Guardrails unterstützen können. Das Tool beschleunigt Entwürfe, aber Disziplin sorgt dafür, dass Menschen die Kontrolle über Korrektheit behalten.
Behandle KI‑Output wie einen schnellen Entwurf, nicht wie eine fertige Funktion. Schreibe zuerst 3–5 Pass/Fail‑Akzeptanzkriterien, generiere dann eine kleine Änderung (einen Endpoint, einen Screen, eine Migration) und verifiziere sie mit Tests und Fehlerfall‑Checks, bevor du weitermachst.
Weil Tests zeigen, was der Code tatsächlich tut. KI kann plausibel klingende Logik liefern, die eine zentrale Regel übersieht (Berechtigungen, Retries, Randzustände). Tests verwandeln Erwartungen in ausführbare, wiederholbare und vertrauenswürdige Prüfungen.
Beginne mit dem, was am meisten schadet, wenn es ausfällt:
Erweitere die Abdeckung, nachdem die hochriskanten Bereiche abgesichert sind.
Fordere die einfachste Lösung mit klaren Einschränkungen und entferne zusätzliche Schichten, sofern sie keinen echten Nutzen bieten. Gute Daumenregeln: führe neue Abstraktionen nur ein, wenn sie in mindestens drei Stellen Duplikation beseitigen oder die Korrektheit deutlich erleichtern.
Schreibe ein kurzes Spec: Eingaben, Ausgaben, Fehler, Einschränkungen und Nicht‑Ziele. Füge konkrete Beispiele (Beispiele für Requests/Responses, Randfälle) hinzu. Definiere "Done" im Voraus: erforderliche Tests, Abwärtskompatibilität und eine kurze Prüfanleitung.
Zerlege die Änderung. Halte jede Review in Minuten lesbar:
So wird Review wirklich statt nur gestempelt.
Vertraue nicht auf Sicherheit durch Selbstbewusstsein—vertraue auf Beweise. Führe Tests aus, versuche fehlerhafte Eingaben und prüfe Berechtigungsgrenzen. Achte außerdem auf typische KI‑Fehler: fehlende Auth‑Checks, unsichere Query‑Konstruktionen, schwache Tokenbehandlung und still geschluckte Fehler.
Bevorzuge explizite Transitionsendpunkte statt eines generischen "update anything". Beispiel: submit, approve, reject, pay statt einer allgemeinen Update‑Route. Schreibe Tests, die durchsetzen, wer welche Transition darf und welche verboten sind.
Gib Kandidat:innen einen KI‑generierten Diff mit echten Problemen: unklare Benennungen, fehlende Tests, ein Randfall und ein kleines Sicherheitsproblem. Lass sie die Absicht erklären, die risikoreichsten Teile finden, Fixes vorschlagen und Tests skizzieren. So siehst du, wie sie mit unvollständigem Code und realen Kompromissen umgehen.
Nutze Tool‑Funktionen für einen disziplinierten Loop: zuerst planen, in kleinen Scheiben generieren, vor riskanten Änderungen snapshotten und zurückrollen, wenn die Validierung fehlschlägt. In chatbasierten Plattformen wie Koder.ai passt das gut zu Planungsmodus, Snapshots und Rollback—besonders bei Auth, Zahlungen oder Migrationen.