Vibe Coding macht Spaß - bis Sie es pflegen müssen

Wir kennen das alle - Sie geben GitHub Copilot ein paar vage Sätze vor, es spuckt einen funktionierenden Prototyp aus und Sie fühlen sich wie ein 10-facher Entwickler... bis Sie den Code eine Woche später öffnen.

Hinweis: In diesem Artikel werden wir Visual Studio Code 1.104 für unsere Beispiele verwenden. Andere IDEs unterstützen möglicherweise nicht alle Funktionen von Visual Studio Code.

Einführung - Was ist Vibe Coding?

Vibe Coding ist ein Begriff, der Anfang des Jahres 2025 populär wurde. Wikipedia beschreibt ihn wie folgt:

"Vibe Coding" beschreibt einen Chatbot-basierten Ansatz zur Erstellung von Software, bei dem der Entwickler ein Projekt oder eine Aufgabe einem großen Sprachmodell (LLM) beschreibt, das auf der Grundlage der Eingabeaufforderung Code generiert. Der Entwickler überprüft oder bearbeitet den Code nicht, sondern nutzt lediglich Tools und Ausführungsergebnisse, um ihn zu bewerten und das LLM um Verbesserungen zu bitten. Anders als bei der traditionellen KI-gestützten Programmierung oder der Paarprogrammierung vermeidet der menschliche Entwickler die Prüfung des Codes, akzeptiert die von der KI vorgeschlagenen Ergänzungen ohne menschliche Überprüfung und konzentriert sich mehr auf das iterative Experimentieren als auf die Korrektheit oder Struktur des Codes." (Quelle: https://en.wikipedia.org/wiki/Vibe_coding).

Die Verwendung von GitHub Copilot im Agentenmodus unterstützt lebendige Coding-Szenarien. Viele Menschen nutzen ihn, um fantastische Ideen in Prototypen zu verwandeln, die tatsächlich funktionieren. Es fördert die Kreativität, beseitigt Hindernisse und beschleunigt die Entwicklung. Sie setzen es in der Produktion ein, nehmen noch ein paar Änderungen vor und sind zufrieden - so denken sie zumindest. Einen Monat später finden sie sich auf der Suche nach mysteriösen Problemen wieder. Was ist passiert?

Technische Schulden - Das alte Problem in neuem Gewand

Das ist es, was passiert ist, etwas, das wir schon seit Jahren kennen: technische Schulden! Einige Beispiele dafür, was ich in vibe-codierten Projekten gesehen habe, sind:

LLMs werden auf von Menschen geschriebenen Code trainiert. Obwohl die Hersteller von LLMs versuchen, so viele qualitativ hochwertige Inhalte wie möglich in ihren Modellen zu sammeln, gehören technische Schulden einfach zu dem, was wir erstellen. Die LLMs, die GitHub Copilot verwendet, führen also auch technische Schulden ein. Es handelt sich dabei nicht um eine neue Art von technischen Schulden, aber durch die Verwendung von GitHub Copilot häufen sie sich viel schneller an. Technische Schulden entstehen durch übereilte Entscheidungen und Abkürzungen, übermäßiges Vertrauen in den generierten Code und andere Gründe. Diese Faktoren gelten auch bei der Verwendung von GitHub Copilot. Vor der KI-Ära gab es verschiedene Muster, Praktiken und Technologien, um technische Schulden zu vermeiden. Es ist wichtig, diese Elemente beizubehalten, wenn Sie Tools wie GitHub Copilot verwenden.

Klarer Kontext - Die Voraussetzungen für eine bessere KI-Leistung

Es gibt mehrere Möglichkeiten, dieses Verhalten zu verbessern und technische Schulden zu vermeiden. Die erste, mit der ich beginnen möchte, ist das Context Engineering. Prompt-Engineering (der Prozess der Strukturierung oder Gestaltung einer Anweisung, um bessere Ergebnisse eines generativen KI-Modells zu erzielen - https://en.wikipedia.org/wiki/Prompt_engineering) ist eine wichtige Praxis, die man bei der Verwendung von Tools wie GitHub Copilot erlernen sollte, aber heutzutage verwenden immer mehr Leute den Begriff Kontext-Engineering. Warum ist das so?

Kontext ist alles, was GitHub Copilot wissen muss, abgesehen von der Frage, die Sie ihm stellen. Das kann eine zusätzliche Codedatei, eine Readme-Datei, ein Screenshot eines Fehlers oder ein Verweis auf einen bestimmten Abschnitt in Ihrem Code sein. Die Einbeziehung des richtigen Kontexts ist entscheidend für die erwarteten Ergebnisse. GitHub Copilot in Visual Studio Code unterstützt verschiedene Möglichkeiten zur Einbindung von Kontext. Viele dieser Optionen sind als "#"-Variablen implementiert. Unter anderem gibt es folgende Möglichkeiten:

In dem folgenden Beispiel verweisen wir GitHub Copilot speziell auf die Methode UpdateFlightStatus:

‌

Es gibt noch viele weitere #-Variablen, die verwendet werden können. Geben Sie einfach "#" in den Chat ein und Sie werden sehen, was zur Verfügung steht:

‌

Abgesehen von dem, was in Ihrer IDE eingebaut ist, können Sie zusätzliche Erweiterungen installieren, die zusätzliche Funktionen bieten, um den Kontext einzubeziehen (z.B. die Python-Erweiterung in VS Code, die Tools wie configurePythonEnvironment, getPythonEnvironmentInfo und installPythonPackage zur Verfügung stellt) oder indem Sie MCP Server installieren und ausführen. Obwohl es sich hierbei um eine sehr wichtige Funktionalität handelt, lasse ich sie hier weg, um diesen Artikel nicht zu lang werden zu lassen. Wenn Sie mehr zu diesem Thema lesen möchten, besuchen Sie die Website des Entwicklers von MCP, Anthropic: https://modelcontextprotocol.io/.

Benutzerdefinierte Anweisungen - Lehren Sie AI Ihre Standards

Die benutzerdefinierten Anweisungen sind der größte Wert. Indem Sie den Kontext verbessern, helfen Sie GitHub Copilot dabei, bessere Entscheidungen zu treffen, und verringern so das Risiko, dass es zu Problemen bei der Kodierung von Vibe kommt. Der nächste Schritt nach der Verbesserung des Kontexts ist die Festlegung einheitlicher Standards für das Verhalten von GitHub Copilot - hier kommen die benutzerdefinierten Anweisungen ins Spiel.

Der Kontext im vorigen Absatz kann hilfreich sein, wenn Sie sich den Code ansehen wollen, aber echte Vibe-Programmierer sehen sich den Code nicht an. Mit benutzerdefinierten Anweisungen können Sie Leitplanken im Voraus festlegen, noch bevor Sie mit der Erstellung beginnen. Es gibt verschiedene Arten von benutzerdefinierten Anweisungen, und ich werde sie alle kurz vorstellen. Sie sind alle im Markdown-Format. So können Sie einfache Formatierungen (Listen, Überschriften usw.) verwenden, was auch GitHub Copilot hilft. Tolle Beispiele für alle Dateien, die wir im Folgenden besprechen, finden Sie im Awesome Copilot Repository auf GitHub:

https://github.com/github/awesome-copilot (die Beispiele stammen ebenfalls aus diesem Repository). Die Erstellung dieser Dateien ist sehr einfach, und zwar über das Einstellungsmenü des GitHub Copilot Chats;

‌

AGENTEN.md

Agents.md (siehe https://agents.md) ist ein sehr verbreitetes Format, das von vielen verschiedenen KI-Tools unterstützt wird. Das Format ist Markdown und muss sich im Stammverzeichnis des Repositorys befinden. Sie können auch verschachtelte AGENTS.md-Dateien erstellen, die sich auf bestimmte Teile des Projekts beziehen. Die Datei enthält in der Regel Informationen darüber, wie die Anwendung auszuführen ist, wie sie zu testen ist, welchen Codestil sie hat und wie die PR aussehen soll.

Copilot-Anweisungen.md

Die copilot-instructions.md muss sich in dem Ordner .github befinden, der sich im Stammverzeichnis Ihres Repositorys befindet. Sie brauchen GitHub nicht, damit dieser Ordner funktioniert, aber Ihre IDE muss ihn unterstützen. Er funktioniert auch mit anderen Versionskontrollsystemen. Er wird automatisch in jede Chat-Anfrage aufgenommen. Daher ist es ratsam, ihn so kurz wie möglich zu halten, um negative Auswirkungen auf die Leistung von GitHub Copilot zu vermeiden.

Die Datei enthält in der Regel dieselben Informationen wie AGENTS.md, so dass Sie vielleicht erwägen sollten, nur AGENTS.md zu verwenden und copilot-instructions.md ganz zu überspringen. Beachten Sie jedoch, dass AGENTS.md erst ab VS Code 1.104 unterstützt wird. Die Unterstützung für AGENTS.md in anderen IDEs kann variieren.

Andere gute Beispiele für Informationen, die Sie hier einfügen könnten, sind:

Ich habe gute Erfahrungen mit der Einführung von TDD in GitHub Copilot gemacht. Noch mehr, wenn Sie ihn bitten, bei der Ausführung der Tests tatsächlich rot/grün zu zeigen.

Es gibt mehrere Möglichkeiten, dies zu implementieren, aber ich habe dies in meine copilot-instructions.md aufgenommen:

Development for this application should be done in a TDD way. TDD means writing tests before writing the actual game code. This approach helps ensure that the game logic is correct and that we can catch any bugs early in the development process. It is VERY IMPORTANT TO FIRST WRITE THE TESTS, THEN THE CODE. When running tests, run them in the terminal so I can see you're running them and their results. Unit test files should only cover one single class or module. If you have multiple classes or modules, create separate test files for each. Put tests in a /tests subdirectory in the /src directory. 

Anleitungsdateien

Das Awesome Copilot Repository enthält auch einige Informationen zur Durchführung von TDD mit GitHub Copilot: https://github.com/github/awesome-copilot/blob/main/collections/testing-automation.md.

Anleitungsdateien

Anweisungsdateien müssen in den Ordner .github/instructions im Stammverzeichnis Ihres Repositorys abgelegt werden. Ihr Format ist {name}.instructions.md. Sie enthalten einen Frontmatter-Header, in den Sie einen Filter einfügen können, um anzugeben, auf welche Dateitypen er angewendet werden soll. Ein gutes Beispiel ist eine githubactions.instructions.md, die etwas wie das Folgende enthalten könnte:

--- 
applyTo: '.github/workflows/*.yml' 
description: 'Comprehensive guide for building robust, secure, and efficient CI/CD pipelines using GitHub Actions. Covers workflow structure, jobs, steps, environment variables, secret management, caching, matrix strategies, testing, and deployment strategies.' 
--- 
## Security Best Practices in GitHub Actions 
 
### **1. Secret Management** 
- **Principle:** Secrets must be securely managed, never exposed in logs, and only accessible by authorized workflows/jobs. 
[…] 

Diese Anweisungsdateien werden auf der Grundlage des applyTo-Filters in der Kopfzeile ausgewählt. Wenn GitHub Copilot eine neue Datei erzeugt, die mit diesem Filter übereinstimmt, wendet es die Anweisungen auch auf diese Datei an.

Chat-Modi

Standardmäßig kennt der GitHub Copilot drei Chat-Modi:

In VS Code können Sie Ihren eigenen Chat-Modus definieren, indem Sie Ihre Markdown-Datei in .github/chatmodes mit dem Format {chatmode name}.chatmode.md ablegen. Mit Ihrem eigenen Chatmodus können Sie genau festlegen, wie sich GitHub Copilot verhalten soll. Wenn Sie einen benutzerdefinierten Chatmodus erstellen, basiert dieser immer auf einem Agenten, d.h. er wird die Anfrage interaktiv umsetzen. Ein Beispiel für einen benutzerdefinierten Chat-Modus ist der Janitor. Er geht Ihren Code durch und bereinigt jeden unnötigen Code. Sehen Sie sich das Beispiel unten an:

--- 
description: 'Perform janitorial tasks on any codebase including cleanup, simplification, and tech debt remediation.' 
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'microsoft.docs.mcp', 'github'] 
--- 
# Universal Janitor 
 
Clean any codebase by eliminating tech debt. Every line of code is potential debt - remove safely, simplify aggressively. 
 
## Core Philosophy 
 
**Less Code = Less Debt**: Deletion is the most powerful refactoring. Simplicity beats complexity. 

Wenn Sie ihn zum Ordner .github/chatmodes hinzufügen, erscheint er in der Auswahlbox für die Chat-Modi.

‌

In der Kopfzeile der Datei können Sie die Tools auswählen, auf die der Chat-Modus Zugriff hat. Der Agentenmodus verwendet Werkzeuge, um spezielle Aufgaben zu erledigen, während er eine Benutzeranfrage bearbeitet. Beispiele für solche Aufgaben sind das Auflisten der Dateien in einem Verzeichnis, das Bearbeiten einer Datei in Ihrem Arbeitsbereich, das Ausführen eines Terminalbefehls, das Abrufen der Ausgabe aus dem Terminal und mehr. Auch hier sollten Sie mit Bedacht vorgehen, denn mehr Tools können sich negativ auf die Leistung auswirken.

Ich mag auch Chat-Modi, die damit beginnen, mir Fragen zu stellen und mich nach fehlenden Informationen in meiner Eingabeaufforderung fragen. GitHub Copilot geht von Annahmen aus und deckt mit dieser Technik (einen Teil) der Annahmen auf.

Prompt-Dateien

Die letzte Möglichkeit, die Sie haben, um das Ergebnis zu kontrollieren, ist eine Prompt-Datei. Dabei handelt es sich um einen gespeicherten Prompt, der leicht wiederverwendet werden kann. Sie können sie vom Chat aus aufrufen, indem Sie "/{promptfilename}" eingeben. Nehmen wir an, wir erstellen die Datei .github/prompts/editorconfig.prompt.md. Nach der Erstellung wird sie, wie in diesem Screenshot zu sehen, als Schrägstrich-Befehl verfügbar sein:

‌

Wenn er ausgeführt wird, wird der Inhalt der Prompt-Datei zu Beginn des Chats eingefügt. Das macht sie zu einer großartigen Möglichkeit, wiederkehrende Aufgaben zu vereinfachen. Die Datei enthält eine Frontmatter-Kopfzeile, genau wie die anderen benutzerdefinierten Anweisungen. In diesem Fall können Sie den Modus (Fragen, Bearbeiten, Agent) und das verwendete Modell (optional) angeben. Bei der Verwendung wird automatisch zum gewünschten Modus/Modell gewechselt. Dies ist ein Beispiel:

--- 

title: 'Refactoring Java Methods with Extract Method' 

mode: 'agent' 

model: GPT-4.1 (copilot) 

description: 'Refactoring using Extract Methods in Java Language' 

---  

# Refactoring Java Methods with Extract Method 

## Role 

You are an expert in refactoring Java methods. 

Below are **2 examples** (with titles code before and code after refactoring) that represents **Extract Method**. 

[...] 

In diesem Fall sorgt die Prompt-Datei dafür, dass das Refactoring auf strukturierte und wiederholbare Weise durchgeführt wird, so dass mehrere Teammitglieder dasselbe Refactoring durchführen können.
Da wir diese Dateien im Repository speichern können, finde ich es toll, dass wir so einfach leistungsstarke Prompts mit unseren Teamkollegen teilen können.

LLM-Feinabstimmung - Wann man tiefer gehen sollte (und wann nicht)

Wenn Sie über die Konfiguration hinausgehen und GitHub Copilot an Ihren Stil anpassen möchten, bietet sich eine Feinabstimmung an. Die Feinabstimmung eines Modells für Ihre eigene Codebasis kann dafür sorgen, dass es besser mit der Art und Weise übereinstimmt, wie Ihr Team Code schreibt. Allerdings werden dabei auch alte Praktiken übernommen, die bei der neuen Arbeit besser nicht berücksichtigt werden sollten. In vielen Fällen können Sie den gleichen Nutzen erzielen, wenn Sie gute benutzerdefinierte Anweisungen mit einer Kontextabfrage kombinieren - zum Beispiel, indem Sie GitHub Copilot bei der Generierung von neuem Code nach relevantem Code oder Dokumentation suchen lassen. Mit diesem Ansatz erhalten Sie in der Regel etwa 80 % der Ergebnisse der Feinabstimmung, ohne den zusätzlichen Aufwand für das Training und die Pflege eines benutzerdefinierten Modells.

Weitere Informationen finden Sie hier: https://docs.github.com/en/enterprise-cloud@latest/copilot/how-tos/use-ai-models/create-a-custom-model

Deterministische Werkzeuge - Die Rückkehr der technischen Disziplin

Obwohl nicht-deterministische Methoden wie benutzerdefinierte Anweisungen die Ergebnisse von GitHub Copilot sicherlich verbessern können, ersetzt nichts die soliden Tools, die wir schon vor der KI-Ära verwendet haben. Denken Sie an Unit-Tests, statische Code-Analyse, Linting-Tools und Compiler - sie sind immer noch die Leitplanken, die verhindern, dass der generierte Code zu weit abdriftet. Sicherheitsprüfungen wie SAST, automatisierte Testläufe und CI/CD Quality Gates sollten auch weiterhin eine Rolle spielen. Wir sollten auch weiterhin gute Praktiken wie das MVP-Denken (Minimum Viable Product), Pair Programming (nicht nur mit GitHub Copilot, sondern mit einem anderen Entwickler) und die DevOps-Mentalität anwenden, von der wir bereits wissen, dass sie funktioniert. Schließlich entwickeln wir immer noch Software, und unser Name ist mit dem Commit verbunden, den wir machen - auch wenn ein Teil des Codes von Copilot stammt.

Review Overload - Wenn die KI dem Team den Rang abläuft

Obwohl Code-Reviews in der Regel bei der Programmierung von Vibe nicht vorkommen, möchte ich dieses Thema dennoch ansprechen. Viele Entwickler stoßen auf dieses Problem. GitHub Copilot kann manchmal eine Menge Code erzeugen. Das Überprüfen kann schnell zu einer mühsamen Aufgabe werden. Wie können wir diese Überlastung reduzieren und sicherstellen, dass wir mit GitHub Copilot mithalten können?

GitHub Copilot kann schneller schreiben als wir überprüfen können. Ohne die richtigen Leitplanken schafft diese Geschwindigkeit nur noch schneller Probleme.

Fazit - Vibe Coding macht Spaß, aber geben Sie ihm Leitplanken

Vibe Coding ermöglicht es Menschen, Dinge zu erreichen, die sie sich nicht zugetraut hätten, sondern von denen sie nur träumen. Es ist wirklich erstaunlich, wie schnell wir mit GitHub Copilot Kreativität in funktionierende Produkte verwandeln können, die das Leben einfacher machen. Die Kehrseite der Medaille ist, dass die Qualität des Codes nachlässt. Stellen Sie also sicher, dass Sie Leitplanken einrichten, um ein großartiges, funktionierendes Produkt zu haben und gleichzeitig eine wartbare Codebasis zu gewährleisten. Schauen Sie sich unbedingt das Awesome Copilot Repository an, um sich inspirieren zu lassen: https://github.com/github/awesome-copilot.
Viel Spaß beim Programmieren!