Versteckte Einsparungen im KI-Zeitalter: Der große Leitfaden, wie Sie durch richtiges Schreiben von Code und Daten den Speicher der künstlichen Intelligenz aufpumpen

Mit dem Aufkommen fortschrittlicher KI-Assistenten, die direkt mit unseren Projekten arbeiten (wie Claude Code, Cursor oder lokale Modelle, die auf Ihrem Computer laufen), hat sich die Art und Weise, wie Code durch die Infrastruktur wandert, grundlegend geändert. Wir schreiben Code nicht mehr nur für Menschen und den Computer, damit er ausgeführt wird. Er ist zu Text geworden, den wir ständig über das Internet in die Gehirne großer Sprachmodelle (LLMs) streamen.

In dieser neuen Welt wird die Speicherkapazität, die der KI zur Verfügung steht (das sogenannte Kontextfenster), zur wertvollsten Ware und Token zur Währung. Wenn wir diesen Speicher verschwenden, kostet uns das nicht nur Geld für API-Gebühren. Es ist erwiesen, dass die künstliche Intelligenz unter dem Gewicht langer Texte die Aufmerksamkeit verliert, wichtige Zusammenhänge leichter vergisst und dumme Fehler im Code macht.

Dieser Artikel analysiert im Detail, wie KI Text tatsächlich liest, wo überall im Code und in den Daten unsichtbare Verluste entstehen und wie Sie mit einfachen Gewohnheiten 10 % bis 40 % des Speichers Ihres digitalen Assistenten einsparen können.

1. Wie künstliche Intelligenz die menschliche Ästhetik (nicht) versteht

Um zu verstehen, warum visuell schöner Code unnötig den Speicher der KI auffressen kann, müssen wir uns ansehen, wie KI Text überhaupt verarbeitet. Modelle lesen Text nicht Buchstabe für Buchstabe oder Wort für Wort. Sie verwenden sogenannte Tokenizer – Systeme, die den Text in kleinere logische Stücke, sogenannte Token, zerlegen. Ein Token entspricht in etwa vier Zeichen Text.

Hinweis: Die konkreten Token-Zahlen in den Beispielen unten sind illustrativ. Die genaue Aufteilung unterscheidet sich von Modell zu Modell und Version zu Version — neuere Modelle haben immer besser optimierte Tokenizer und lösen einige der beschriebenen Ineffizienzen möglicherweise bereits teilweise. Die grundlegenden Prinzipien bleiben jedoch gültig.

Das Problem ist, dass diese Systeme anhand von Standardtexten aus dem Internet und fertigem Code aus öffentlichen Repositories trainiert wurden. Untypische Leerzeichen (zusätzliche Leerzeichen) können sie nicht effizient verarbeiten und fangen an, sie mühsam in Fragmente zu zerlegen.

A. Einrückung: Der Kampf zwischen Leerzeichen und Tabulatoren

Viele Programmierhandbücher verlangen strikt die Verwendung von vier Leerzeichen für die Einrückung. KI-Systeme sind zwar so programmiert, dass sie vier aufeinanderfolgende Leerzeichen als ein einziges Stück (Token) wahrnehmen. Sobald Sie jedoch im Code eine tiefere Verschachtelungsebene erreichen (z. B. verschachtelte Schleifen oder Bedingungen), funktioniert diese Magie nicht mehr.

Wenn eine Zeile auf der vierten Verschachtelungsebene eingerückt ist, bedeutet das 16 Leerzeichen hintereinander. Die KI liest diese selten als vier saubere Stücke. Aufgrund statistischer Wahrscheinlichkeiten in ihrem System zerfallen diese 16 Leerzeichen in eine seltsame Kombination (z. B. ein Block aus 4 Leerzeichen + ein Block aus 2 Leerzeichen + 2 einzelne Leerzeichen + ein weiterer Block aus 4 Leerzeichen). Das Ergebnis ist, dass Sie auf jeder solchen Zeile 5 bis 8 Token nur für den leeren Raum am Anfang verschwenden.

Im Gegensatz dazu wird ein tatsächliches Tabulatorzeichen (\t) im System der KI als ein einziges, eigenständiges Stück registriert.

Einrückung auf der 4. Verschachtelungsebene:
[Mit Leerzeichen]  --> [    ] [    ] [  ] [ ] [ ] [    ]  --> 6 Token (ineffizient)
[Mit Tabulator]    --> [\t] [\t] [\t] [\t]                --> 4 Token (immer 1:1)

Bei einer durchschnittlichen Datei mit 500 Zeilen sparen Sie durch den Wechsel zu reinen Tabulatoren hunderte von Token. Wenn Ihr KI-Assistent Ihren gesamten Projektordner durchscannt, sprechen wir von einer Ersparnis von zehntausenden Token an einem einzigen Nachmittag.

B. Ausrichtung in Spalten: Schönheit, die schadet

Viele Programmierer richten Gleichheitszeichen oder Werte gerne vertikal untereinander aus, damit der Code wie eine ordentliche Tabelle aussieht:

const shortName      = "low";
const mediumName     = "medium";
const reallyLongName = "high";

Für das menschliche Auge ist das großartig, aber für die KI ist es reine Verschwendung. Zwischen dem Text shortName und = sind sechs leere Leerzeichen entstanden. Die KI kann diese nicht effizient zusammenfassen und erstellt dadurch mehrere überflüssige Token extra.

Noch schlimmer ist jedoch der Domino-Effekt in der Code-Historie. Wenn Sie diesem Block in Zukunft eine neue Variable mit einem sehr langen Namen hinzufügen, müssen Sie aus Gründen der Ästhetik die Ausrichtung aller umliegenden Zeilen um weitere zwanzig Leerzeichen nach rechts verschieben.

1. Für Sie: Eine Änderung von wenigen Sekunden.
2. Für das Versionsverwaltungssystem (Git): Eine Änderung in jeder einzelnen Zeile. Das System meldet, dass sich der gesamte Codeblock geändert hat.
3. Für die KI: Ein völliger Zusammenbruch des Speichers. Moderne KI-Modelle verwenden ein cleveres Caching (Zwischenspeicher). Wenn sie feststellen, dass sich der Text des Codes nicht geändert hat, laden sie ihn blitzschnell und mit einem großen Rabatt. Sobald Sie jedoch die Leerzeichen in fünf umliegenden Zeilen verschieben, wird dieser Cache ungültig und Sie zahlen erneut für die Analyse des gesamten Blocks.

2. Sprachen unter der Lupe: Python, HTML und Markdown-Tabellen

Dieses Prinzip der Platzverschwendung zeigt sich über alle Technologien hinweg, oft mit unerwarteten Nebenwirkungen.

Python: Wenn Leerzeichen Fehler verursachen

Die Sprache Python ist einzigartig, da sie Codeblöcke nicht durch Klammern, sondern durch die genaue Anzahl von Leerzeichen am Anfang einer Zeile trennt. Wenn die KI ein längeres Python-Skript generiert, kommt es vor, dass sie sich beim Ausgeben von Dutzenden von Leerzeichen schlichtweg „verzählt“. Es reicht schon, wenn sie auf einer Zeile statt acht Leerzeichen nur sieben generiert, und der resultierende Code wird auf dem Computer nicht ausgeführt (es wird ein IndentationError geworfen).

Wenn Sie der KI beibringen, im Projekt Tabulatoren zu verwenden, verschwindet dieses Problem fast vollständig. Für das Modell ist es viel einfacher zu berechnen „generiere 2 Tabulatoren“ als „generiere 8 Leerzeichen“. Der Code wird sicherer und die KI generiert ihn schneller.

Markdown-Tabellen: Riesige Speicherfresser

Wenn Sie von einer KI in einem Chat eine Tabelle anfordern oder ihr selbst eine Tabelle im Textformat Markdown senden, neigen Menschen dazu, diese visuell auszurichten, damit die Spalten perfekt fluchten:

| Name       | Stadt       | Alter |
|------------|-------------|-------|
| Jan        | Prag        | 26    |
| Franz      | Bratislava  | 34    |

All diese zusätzlichen Bindestriche und Leerzeichen, die die Spalten untereinander halten, sind für die Anzeige im Texteditor schön, aber für den Speicher der KI ist es eine Katastrophe. Markdown ist es dabei völlig egal, ob die Spalten visuell fluchten. Folgende Schreibweise reicht völlig aus:

| Name | Stadt | Alter |
|---|---|---|
| Jan | Prag | 26 |
| Franz | Bratislava | 34 |

Die resultierende Tabelle wird auf dem Bildschirm exakt gleich dargestellt, aber Sie sparen locker die Hälfte der Token. Wenn Sie die KI eine umfangreiche Übersicht erstellen lassen, sparen Sie eine Menge Zeit und Speicher, wenn Sie ihr verbieten, Tabellen visuell mit Leerzeichen aufzufüllen.

HTML und XML: Die schlimmste Kombination

Formate zur Erstellung von Webseiten (HTML) oder zur Datenübertragung (XML) sind für den KI-Speicher am anspruchsvollsten. Sie kombinieren zwei Probleme: Sie sind sehr geschwätzig (jedes Element muss einen Anfang und ein Ende haben, z. B. <benutzer></benutzer>) und sie sind meist sehr tief verschachtelt. Auf der fünften Verschachtelungsebene senden Sie mit Standard-Leerzeichen bereits zwanzig leere Zeichen vor jedem einzelnen Wort.

Wenn Sie eine KI eine heruntergeladene Webseite analysieren lassen, lohnt es sich immer, diese vor dem Senden von unnötigen Zeilenumbrüchen und Leerzeichen zu bereinigen.

3. GROSSBUCHSTABEN: Der unterschätzte Geldfresser

Der Unterschied darin, wie eine KI die Wörter select, SELECT und Select wahrnimmt, ist für die meisten Menschen schockierend. Da Texte im Internet primär in Kleinbuchstaben geschrieben werden, hat die künstliche Intelligenz für gängige Wörter (wie Programmierbefehle oder Funktionsnamen) günstige, einteilige Stücke parat.

Sobald Sie jedoch die Feststelltaste aktivieren und ein Wort in Großbuchstaben schreiben, kann das System es in seinem Wörterbuch nicht finden und muss es mühsam aus kleineren Fragmenten zusammensetzen.

Wie KI die Groß- und Kleinschreibung wahrnimmt:

• select → 1 Stück: [select]
• SELECT → 2 Stücke: [SE] + [LECT]
• migration → 1 Stück: [migration]
• MIGRATION → 3 Stücke: [M] + [IGR] + [ATION]

Wenn Sie Datenbankskripte im traditionellen Stil schreiben, bei dem alle Schlüsselwörter strikt großgeschrieben werden (CREATE TABLE USERS), verbrauchen Sie für diese Wörter die doppelte Menge an Speicher, als wenn Sie alles in Kleinbuchstaben umwandeln würden (create table users).

Bei zusammengesetzten Variablennamen (wie der wechselnden Groß- und Kleinschreibung in transactionId) ist die Situation ähnlich. Ein Großbuchstabe mitten im Wort wirkt wie ein Schnitt, und das System teilt das Wort in zwei Teile. Wenn möglich, ist es aus Sicht der Token-Ersparnis am stabilsten, Kleinbuchstaben getrennt durch Unterstriche (transaction_id) oder Abkürzungen (tx_id) in Datenbanken, Code und Konfigurationen zu verwenden.

4. Fallstudie: Datenbankbeschreibung (SQL vs. DBML)

Wenn Sie Datenbankanwendungen entwickeln (beispielsweise mit modernen Tools, die eine API direkt über der Datenbank aufbauen), muss Ihr KI-Assistent Ihre Tabellenstruktur im Detail kennen, um Ihnen helfen zu können. Ihm einen kompletten Export in rohem SQL (CREATE TABLE…) vorzuwerfen, ist der schnellste Weg, seinen Speicher zu verstopfen.

Hier ist ein klarer Vergleich, wie dieselbe Struktur in Standard-SQL und im schlankeren, modernen DBML-Format geschrieben werden kann. Wenn Sie übrigens mit PostgreSQL arbeiten und Schemata nicht manuell umschreiben möchten, können Sie das einfache CLI-Tool pg_dbml nutzen, um Ihre gesamte Struktur automatisch in sauberes DBML zu exportieren.

Version in SQL (Geschwätzig, ca. 45 Token)

CREATE TABLE "users" (
  "id" SERIAL PRIMARY KEY,
  "username" varchar(50) NOT NULL,
  "role_id" integer NOT NULL,
  CONSTRAINT "fk_users_role" FOREIGN KEY ("role_id") REFERENCES "roles" ("id")
);

Version in DBML (Kompakt, ca. 18 Token)

Table users {
  id int [pk, increment]
  username varchar(50)
  role_id int
}
Ref: users.role_id > roles.id

Warum das sparsamere Format (DBML) über 60 % Speicher spart?

1. Reiner Text: Es enthält keine sich ständig wiederholenden Anführungszeichen, die von der KI oft als separate Zeichen abgeschnitten werden.
2. Einfache Beziehungen: Das Schreiben eines Fremdschlüssels in SQL (CONSTRAINT…) verbraucht etwa 15 Token. Im modernen DBML reicht eine einzige kurze Zeile: Ref: users.role_id > roles.id (6 Token).
3. Verständlichkeit: Für die künstliche Intelligenz ist es viel einfacher, die Beziehungen zwischen den Tabellen zu verstehen, wenn sie übersichtlich an einem Ort dokumentiert sind, anstatt sie mühsam aus dem Inneren komplexer SQL-Befehle herauszufiltern.

5. Wie man es automatisiert, damit Ihre Augen nicht leiden

Das Ziel dieser Regeln ist es nicht, Sie dazu zu zwingen, hässlichen oder unleserlichen Code zu schreiben. Das Ziel ist es, Ihre Entwicklungsumgebung so einzurichten, dass der Code im Editor für Sie großartig aussieht, aber beim Speichern auf der Festplatte automatisch von unnötigem Ballast (zusätzliche Leerzeichen) befreit und auf ein Minimum komprimiert wird. Das nennt man Bereinigung auf Zeilenebene – Zeilenumbrüche bleiben erhalten, sodass der Code in der Git-Historie perfekt lesbar bleibt, aber die leere Luft verschwindet.

Schritt 1: Einrichtung eines automatischen Cleaners (SQLFluff für SQL)

Zur Formatierung von Datenbankdateien können Sie das kostenlose Tool SQLFluff verwenden. Die richtige Konfiguration sorgt dafür, dass der Code von überschüssigen Leerzeichen befreit und in Kleinbuchstaben umgewandelt wird. Um das Debuggen von Regeln zu erleichtern, können Sie die gesamte Struktur visuell über SQLFluffUI testen und konfigurieren, was Ihnen Zeit beim manuellen Ändern von Konfigurationstexten spart.

Erstellen Sie einfach eine Konfigurationsdatei in Ihrem Projekt mit diesen Regeln:

[sqlfluff:indentation]
# Wir verwenden Tabulatoren für 100% vorhersehbare Einsparungen
indent_unit = tab
tab_width = 4

[sqlfluff:rules:layout.spacing]
# Erzwingt genau 1 Leerzeichen um Operatoren, löscht visuelle Spalten
force_spacing = true

[sqlfluff:rules:capitalisation.keywords]
# Konvertiert alle SQL-Befehle in effizientere Kleinbuchstaben
capitalisation_policy = lowercase

Schritt 2: Automatische Ausführung beim Speichern

Damit Sie nicht an die Formatierung denken müssen, können Sie in Ihrem Editor (z. B. VS Code) automatische Aktionen beim Speichern einrichten. Der Code bereinigt sich selbst eine Sekunde bevor er in die Historie geschrieben wird. Ihr KI-Assistent sieht im Projekt dann nur noch diese optimierte Version.

Ähnlich funktioniert das auch bei Datendateien (z. B. JSON-Konfigurationen). Anstatt eines über fünfzig Zeilen gedehnten Formats können Sie diese automatisch so komprimieren lassen, dass jeder in sich geschlossene Teil auf einer kompakten Zeile ohne interne Leerzeichen steht.

6. Den KI-Assistenten mit eigenen Regeln zähmen

Wenn Sie Assistenten nutzen, die sich autonom in Ihrem Projekt bewegen, können Sie deren Verhalten über eine Regeldatei anpassen. Die meisten von ihnen lesen beim Start eine Regeldatei im Wurzelverzeichnis Ihres Projekts — der Dateiname hängt vom jeweiligen Tool ab (CLAUDE.md für Claude Code, AGENTS.md für OpenAI Codex und andere). Schauen Sie in die Dokumentation Ihres Assistenten.

In dieser Datei können Sie ihnen klare Anweisungen geben, damit sie ihren eigenen Speicher schonen und Ihnen vor allem keine unnötig langen Antworten senden (Ausgabe-Token von einer KI sind nämlich deutlich teurer als Eingabe-Token).

Hier ist ein einfacher Block von Regeln, den Sie einfach in die Datei kopieren können:

## Regeln zur Token- und Speichereinsparung

Halte dich bei der Arbeit an diesem Projekt strikt an die folgenden Regeln, um das Kontextfenster zu schonen und Antworten zu beschleunigen:

### 1. Strategie zum Lesen von Code und zur Suche
- **Gezieltes Lesen:** Lies niemals ganze große Dateien (>500 Zeilen), wenn du nur eine bestimmte Funktion sehen musst. Verwende stattdessen Werkzeuge, um gezielte Zeilenbereiche zu lesen.
- **Effiziente Suche:** Suche lieber präzise mithilfe von Textfiltern (grep/regex), anstatt Dateien blind zu öffnen, um deren Struktur zu inspizieren.

### 2. Regeln für die Antwort- und Codegenerierung
- **Fasse dich kurz (Keine Floskeln):** Wiederhole nicht meine Aufgabenstellung und verzichte auf Höflichkeitsfloskeln ("Sicher, ich helfe Ihnen gerne dabei..."). Beginne direkt mit der Antwort oder dem Codeblock.
- **Sende nur Änderungen (Verkürzter Code):** Wenn du mir im Chat Codeänderungen zeigst, gib niemals die gesamte Datei erneut aus. Zeige NUR die Zeilen, die sich geändert haben. Ersetze unberührte Teile des Codes durch einen Kommentar wie `// ... restlicher Code ...`.
- **Codestil:** Verwende beim Generieren von Code ausschließlich einen einzigen Tabulator (`\t`) für die Einrückung. Verwende niemals Leerzeichen für die visuelle Spaltenausrichtung.

Ergebnistabelle der Einsparungen

Die folgende Übersicht zeigt die realen Auswirkungen dieser kleinen Änderungen auf die Datenmenge, die Sie an die KI senden müssen:

Fazit

Die Optimierung von Code für künstliche Intelligenz wird zu einer wertvollen neuen Fähigkeit für jeden modernen Entwickler. Sie müssen dafür nicht ändern, wie Sie selbst den Code sehen – es reicht aus, die automatischen Helfer im Editor richtig einzustellen. Ein Entwickler oder Analyst, der sein Projekt mit einem niedrigen „Token-Fußabdruck“ halten kann, erlangt einen enormen Vorteil: Sein KI-Assistent arbeitet schneller, macht weniger Fehler, kann größere Zusammenhänge der Applikation auf einmal erfassen und der Betrieb des gesamten Systems kostet einen Bruchteil des ursprünglichen Preises.