27 Regel-Dateien statt einer CLAUDE.md — was sich dadurch geändert hat

Es gibt einen Moment, in dem eine CLAUDE.md kippt. Dieser Moment steht in keinem Kalender, er zeigt sich im Verhalten: Die Datei wird immer länger, und die Regeln darin werden immer schlechter befolgt. Jede neue Konvention, die man hineinschreibt, verdünnt die vorhandenen. Genau an diesem Punkt stand das Projekt hinter diesem Artikel — und die … Weiterlesen

799 hartkodierte Schriftgrößen — wie KI-gestützte Entwicklung Konsistenz-Drift erzeugt

Der Auslöser war kein Audit, sondern ein Störgefühl: Die Oberfläche wirkte unruhig. Beim ersten Hinsehen fällt so etwas nicht auf, beim zweiten und dritten aber schon — ein Zeitstempel hier eine Spur größer als dort, ein Dialog-Titel minimal kleiner als im Nachbar-Dialog. Von Briefen und Lebensläufen kennt jeder die Disziplin: gleiche Schriftart, gleiche Schriftgröße, gleiche … Weiterlesen

Ein Claude-Code-Projekt mit Entwicklungsworkflow und Datenbank aufsetzen — das offene Starter-Kit im Überblick

Ein leeres Repo und Claude Code, Anthropics Coding-Agent im Terminal — mehr braucht es nicht, um loszulegen. Und genau das ist das Problem: Das Modell schreibt sofort Code, aber von Haus aus sorgt nichts dafür, dass vorher eine Spezifikation entsteht, hinterher ein Review stattfindet oder das Datenbank-Schema reproduzierbar deployt wird. Wer ein Claude-Code-Projekt aufsetzt, entscheidet … Weiterlesen

Maximal-Vorlage statt leeres Repo — ein Claude-Code-Setup, das sich per /init selbst zuschneidet

Jedes neue Projekt beginnt mit demselben Ritual: leeres Repo anlegen, dann Ordnerstruktur, Konventionen und Workflow-Dateien aus dem letzten Projekt zusammensuchen — und die Hälfte vergessen. Eine Claude-Code-Vorlage kann diesen Reflex umdrehen: Statt mit nichts zu starten und mühsam aufzubauen, startet man mit allem — und lässt ein Interview löschen, was das Projekt nicht braucht. Genau … Weiterlesen

Skills vs. Rules in Claude Code — was automatisch lädt, was auf Abruf kommt und was es an Kontext kostet

Im .claude/-Ordner eines Claude-Code-Projekts liegen Rules und Skills nebeneinander: Markdown-Dateien, die fast gleich aussehen — und sich genau gegensätzlich verhalten. Claude Code Rules sind bei jedem Session-Start vollständig im Kontext; ein Skill kostet fast nichts, bis es jemand aufruft. Wer das verwechselt, packt entweder alles in Rules und bezahlt jede Session dafür — oder erwartet von einem Skill, … Weiterlesen

SQL-Schema deployen ohne Migrations-Tool — Verzeichnis-Konvention statt Flyway oder Liquibase

Das Schema steht — und jetzt? Der Reflex heißt Flyway oder Liquibase. Aber ein Migrations-Tool ist für ein kleines, datenbank-zentriertes Projekt oft mehr Apparat, als die Aufgabe verlangt: eine eigene Versions-Tabelle, eine Runtime-Abhängigkeit, ein Format, an das man sich bindet. Es geht auch anders. Ein SQL-Schema deployen ohne Migrations-Tool heißt: ein paar Konventionen, idempotente Skripte und ein … Weiterlesen

PL/pgSQL-Funktionen mit Tabellen-Rückgabe — RETURNS TABLE, SETOF und wann eine View besser ist

Eine View ist die eleganteste Art, eine wiederkehrende Abfrage zu kapseln — bis zu dem Moment, in dem die Abfrage ein Argument von außen braucht. Eine View kennt keine Parameter. Sobald im WHERE ein Wert stehen soll, den der Aufrufer mitgibt, ist die tabellenwertige Funktion das Mittel der Wahl: eine Funktion, die statt eines einzelnen Werts eine ganze Ergebnismenge … Weiterlesen

PL/pgSQL-Funktions-Konventionen — Volatilität, RETURNS und die Grenze zur Prozedur

Eine PL/pgSQL-Funktion ohne Volatilitäts-Marker ist per Default VOLATILE. Das klingt harmlos, kostet aber real: Der Planer ruft die Funktion pro Zeile erneut auf, berechnet sie nie einmalig vorab und schließt sie aus jedem funktionalen Index aus. Der Schaden ist unsichtbar — bis dieselbe Abfrage auf einmal Sekunden statt Millisekunden braucht. Gute PL/pgSQL-Funktions-Konventionen fangen genau hier an: nicht beim … Weiterlesen

Postgres-Tabellen-Konventionen — Naming, Keys und Audit-Spalten für ein konsistentes Schema

Eine Tabelle anzulegen dauert dreißig Sekunden – sich über ihren Namen, ihren Schlüssel und ihre Spaltentypen zu ärgern, dann zwei Jahre. Postgres-Tabellen-Konventionen nehmen diesen Ärger einmal vorne weg: konsistente Namen, ein vorhersehbarer Primärschlüssel, Datentypen ohne Überraschung und Audit-Spalten, die jede Zeile erklären. Ohne sie driftet ein Schema mit jeder neuen Tabelle weiter auseinander – und beim ersten … Weiterlesen