Wie du ein LLM jedes Projekt an dein System anpassen lässt

Jedes offene Projekt — ein GitHub-Repo, ein Zip von der Tools & Downloads-Seite dieser Website — lässt sich von einem KI-Assistenten an deinen Rechner anpassen, ganz ohne dass du selbst eine Zeile Code schreibst. Hier ist das Rezept.

Was am Ende dabei rauskommt

Die Fähigkeit, die gesamte Open-Source-Welt als Ersatzteillager zu behandeln. Die Projekte auf dieser Seite wurden alle für meine eigenen Maschinen gebaut — der RGB-Tastatur-Controller für ein bestimmtes ASUS-Notebook, die ArkVault-Backup-GUI für meine eigenen Laufwerke — und beide lassen sich als Zip herunterladen: genau die Art von Projekt, die dieses Rezept in einer einzigen LLM-Unterhaltung an deine Maschine anpasst.

Das Rezept besteht immer aus denselben vier Schritten:

Schritt 1: Dein LLM wählen (sie funktionieren alle)

Jedes hinreichend fähige LLM kann das. Der Unterschied liegt nur darin, wie viel du selbst tippen musst.

Agentische CLIs (am wenigsten Aufwand). Tools wie Claude Code, OpenAIs Codex CLI oder Open-Source-Alternativen (Aider und andere) laufen im Terminal, lesen selbst die Projektdateien, führen Befehle aus und korrigieren ihre eigenen Fehler. Du beschreibst das Ziel, sie erledigen die Arbeit und zeigen dir, was sie getan haben. Wenn du bereit bist, ein Tool zu installieren, ist das der Weg.

Chat + Copy-Paste (keine Installation nötig). Claude.ai, ChatGPT oder ein beliebiger Web-Chat. Du fügst die README und die wichtigsten Dateien des Projekts ein, das LLM sagt dir, welche Befehle du ausführen sollst, und du fügst die Ausgabe (einschließlich Fehlermeldungen) zurück ein. Langsamer und manueller, funktioniert aber überall — selbst ein kostenloser Account reicht für die meisten Projekte.

Lokale Modelle (privat und kostenlos). Wenn du Modelle lokal betreibst (Ollama, LM Studio — siehe meine 4-Schritte-Anleitung für DeepSeek lokal), bewältigt ein gutes, coding-fähiges Modell den Copy-Paste-Workflow problemlos, und manche lokalen Setups können auch agentische Tools antreiben. Nichts verlässt deinen Rechner.

Wähl eins aus. Der Rest des Rezepts bleibt identisch.

Schritt 2: Die Dateien lokal besorgen

Das LLM braucht die tatsächlichen Projektdateien auf deinem Rechner. Zwei typische Fälle:

Fall A — ein GitHub-Repo. git clone lädt die Dateien eines Repos in einen Ordner herunter. Am Beispiel eines bekannten öffentlichen Projekts:

# install git first if you don't have it (git-scm.com, or your package manager)
cd ~/Downloads
git clone https://github.com/pallets/flask.git
cd flask
ls

Das ist der ganze Trick — git clone <url> funktioniert für jedes öffentliche Repository, und die URL ist genau die, die in der Adresszeile deines Browsers steht, wenn du auf der Repo-Seite bist.

Fall B — ein Zip von dieser Seite. Jedes Tool auf der Tools & Downloads-Seite hat einen Download-Kasten. Zum Beispiel den RGB-Tastatur-Controller herunterladen, dann:

cd ~/Downloads
unzip rgb-keyboard-2026-07.zip -d rgb-keyboard
cd rgb-keyboard
ls

(Unter Windows: Rechtsklick → Alle extrahieren. Unter macOS: Doppelklick auf das Zip.)

So oder so hast du jetzt einen Ordner voller Dateien.

Schritt 3: Dem LLM sagen, was du wirklich willst

Sag nicht einfach nur “installier das”. Gib ihm drei Dinge mit:

1. Dein System. Betriebssystem und Version, bei Bedarf auch die Hardware (“Windows 11”, “Ubuntu 24.04 auf einem alten ThinkPad”, “Mac mini M2”). Dieser eine Satz verhindert den häufigsten Fehlschlag.
2. Dein Ziel. Was es tun soll, nicht wie (“Ich will, dass diese Backup-GUI meinen Dokumente-Ordner auf meine externe Festplatte sichert”).
3. Deine Einschränkungen. Dinge, die es nicht tun darf oder umgehen muss (“meine bestehende Python-Installation nicht anfassen”, “ich habe keine Admin-Rechte”, “alles in diesem einen Ordner belassen”).

Mit einer agentischen CLI startest du sie im Projektordner und sagst etwa:

Das ist ein Projekt, das ich von LaserLloyd.com heruntergeladen habe. Ich bin auf Ubuntu 24.04. Lies den Code und bring es auf meiner Maschine zum Laufen — installier, was gebraucht wird, pass alles an, was speziell auf die Umgebung des ursprünglichen Autors zugeschnitten ist, und zeig mir am Ende, wie ich es starte.

Bei einer Chat-Oberfläche funktioniert dieselbe Nachricht — nur fängst du damit an, die README (und jede weitere angefragte Datei) einzufügen, führst dann die vorgeschlagenen Befehle aus und fügst die vollständige Ausgabe, besonders Fehlermeldungen, zurück ein. Fehlermeldungen sind die Augen des LLM; niemals zusammenfassen, immer komplett einfügen.

Rechne mit ein bisschen Hin und Her.

Schritt 4: Prüfen, was es gemacht hat

Vertrauen, aber prüfen — genauso, wie du die Arbeit eines Handwerkers kontrollierst, ohne selbst vom Fach zu sein:

• Läuft es? Der einzige Test, der zählt. Starten und für den tatsächlichen Zweck benutzen.
• Nach einer Zusammenfassung fragen. “Liste jede Änderung auf, die du gemacht hast, und jedes Paket, das du installiert hast.” Ein LLM kann seine eigene Arbeit immer in einfachen Worten erklären. Wenn dich etwas in der Liste überrascht, frag nach dem Warum.
• Den Wirkungsbereich beobachten. Gute Anpassungen bleiben innerhalb des Projektordners plus üblicher Paketinstallationen. Sei misstrauisch bei allem, das Systemdateien bearbeiten, Sicherheitsfunktionen deaktivieren oder mit sudo/Administratorrechten laufen will, die es nicht begründen kann — lass dir das erklären oder einen anderen Weg finden.
• Deinen Rückweg kennen. Bei einem geklonten Repo zeigt git diff jede vom LLM geänderte Datei, und git checkout . macht sie rückgängig. Bei einem Zip einfach das Original behalten — Ordner löschen und neu entpacken, um von vorn zu beginnen.
• Zweite Meinung (optional). Die Zusammenfassung der Änderungen in ein anderes LLM einfügen und fragen: “Irgendwas Bedenkliches dabei?” Billig, und überraschend wirksam.

Stolperfallen

• Vage Prompts liefern generische Ergebnisse. “Bring das zum Laufen” ohne genanntes Betriebssystem heißt: Das LLM rät — und es rät auf die Umgebung des ursprünglichen Autors. Immer zuerst dein System nennen.
• Abgeschnittene Fehlermeldungen. Wer im Copy-Paste-Modus nur die letzte Zeile eines Fehlers einfügt, nimmt dem LLM den Kontext, den es braucht. Alles einfügen.
• Veraltete Anweisungen in der README. LLMs folgen der README eines Projekts auch dann, wenn sie längst überholt ist. Schlägt ein dokumentierter Schritt fehl, sag dem LLM “die README sagt X, aber das ist mit Y fehlgeschlagen” und lass es einen Weg drumherum finden.
• Kontextgrenzen im Chat. Riesige Projekte passen nicht in ein Chatfenster. Erst README und Verzeichnisauflistung einfügen, dann nur die Dateien, die das LLM anfragt. (Agentische CLIs übernehmen das für dich automatisch.)
• Lizenzen. Prüfe die Lizenz eines Repos, bevor du es für mehr als den persönlichen Gebrauch anpasst. Alles, was von LaserLloyd.com herunterladbar ist, ist für die private Nutzung kostenlos — klonen, anpassen, für Ersatzteile ausschlachten. Dafür ist es da.

Jedes Projekt auf der Tools & Downloads-Seite ist ein gutes erstes Ziel: klein, in sich geschlossen und so geschrieben, dass LLMs sie gut lesen können. Wähl eins aus und probier das Rezept.