Mit KI programmieren – VS Code, Codex, GitHub und automatisierte Tests

Im ersten Teil wurde aus einer Projektidee eine strukturierte Projektbeschreibung mit Anforderungen, Lösungsvarianten und Roadmap entwickelt.

Jetzt beginnt die eigentliche Umsetzung.

Dabei soll KI nicht einfach möglichst viel Code erzeugen. Ziel ist vielmehr ein nachvollziehbarer Entwicklungsprozess:

Aufgabe definieren → Code analysieren → kleine Änderung durchführen → Tests → Dokumentation → Commit

1. Visual Studio Code als Entwicklungszentrale

Plakat vergrößern

Visual Studio Code kann bei solchen Projekten mehrere Aufgaben gleichzeitig übernehmen:

• Quellcode bearbeiten

• Projektstruktur verwalten

• Terminal verwenden

• Git bedienen

• Tests starten

• Markdown-Dokumentation bearbeiten

• KI-Agenten einsetzen

Dadurch befinden sich Code und Projektdokumentation im selben Arbeitsumfeld.

2. Codex als Projekt-Agent

Plakat vergrößern

Der entscheidende Unterschied zu einem einfachen Chat besteht darin, dass ein Agent im Projektkontext arbeiten kann.

Er kann beispielsweise:

• vorhandenen Code untersuchen

• Abhängigkeiten zwischen Dateien erkennen

• Funktionen ergänzen

• Tests erzeugen

• Dokumentation aktualisieren

• Änderungen über mehrere Dateien hinweg durchführen

Dafür muss der Agent aber klare Regeln erhalten.

3. Eine grundlegende Agentenanweisung

Du arbeitest als technischer Entwicklungsassistent für dieses Projekt.

Bevor du Änderungen durchführst:

1. Lies README und Projektdokumentation.
2. Prüfe die aktuelle Version.
3. Prüfe die Roadmap.
4. Analysiere den bestehenden Code.
5. Ermittle Auswirkungen der geplanten Änderung.

Bei Änderungen:

6. Implementiere nur den vereinbarten Funktionsumfang.
7. Ergänze passende Tests.
8. Aktualisiere notwendige Dokumentation.
9. Aktualisiere den Changelog.
10. Prüfe, ob eine Versionsänderung notwendig ist.

Nach der Änderung:

11. Führe Tests aus.
12. Dokumentiere bekannte Einschränkungen.
13. Nenne sinnvolle nächste Schritte.

Verändere keine Funktionen außerhalb des aktuellen Arbeitsauftrages,
wenn dies nicht technisch notwendig ist.

Diese Anweisung verhindert zwar nicht jeden Fehler, reduziert aber die Wahrscheinlichkeit unkontrollierter Änderungen.

4. Kleine Arbeitspakete statt Komplettlösungen

Ein schlechter Auftrag lautet:

Programmiere die komplette Steuerung.

Ein wesentlich besserer Auftrag wäre:

Implementiere zunächst ausschließlich die Steuerung einer einzelnen
Stepper-Achse.

Anforderungen:

- STEP/DIR-Treiber
- einstellbare Geschwindigkeit
- einstellbare Schrittzahl
- sauberes Stoppen
- keine Referenzfahrt
- keine Mehrfachachsen
- keine Kommunikation

Erstelle zusätzlich passende Tests und dokumentiere die öffentliche API.

Damit ist eindeutig definiert:

• was umgesetzt werden soll

• was noch nicht umgesetzt werden soll

Diese Begrenzung ist bei Agenten besonders wichtig.

5. Git und GitHub als Sicherheitsnetz

Plakat vergrößern

Plakat vergrößern

Git übernimmt nicht nur die Sicherung des Codes.

Es dokumentiert gleichzeitig die Entwicklung.

Typische Bestandteile:

README.md
.gitignore
LICENSE
CHANGELOG.md
version.py
docs/
src/
tests/

Mit Git kann jederzeit nachvollzogen werden:

• welche Datei verändert wurde

• wann eine Änderung erfolgte

• warum sie durchgeführt wurde

• welche Version davon betroffen ist

6. .gitignore automatisch überprüfen

KI-Agenten und Entwicklungswerkzeuge erzeugen zahlreiche Dateien, die nicht in ein Repository gehören.

Dazu zählen beispielsweise:

• Python-Cache

• virtuelle Umgebungen

• IDE-Einstellungen

• temporäre Dateien

• Logdateien

• Build-Artefakte

• lokale Konfigurationen

Beispiel-Agentenanweisung

Analysiere das Repository und die vorhandene .gitignore.

Ermittle Dateien und Verzeichnisse, die nicht versioniert werden sollten.

Berücksichtige insbesondere:

- Python Cache
- virtuelle Umgebungen
- IDE-Dateien
- Betriebssystem-Dateien
- Logdateien
- temporäre Dateien
- Build-Ausgaben
- lokale Konfigurationsdateien
- Zugangsdaten und Secrets

Ergänze die .gitignore nur dort, wo es sinnvoll ist.

Bestehende projektspezifische Regeln dürfen nicht entfernt werden.

Dokumentiere anschließend kurz alle vorgenommenen Änderungen.

7. Secrets gehören nicht ins Repository

Plakat vergrößern

Besonders wichtig ist der Umgang mit:

• Passwörtern

• API-Schlüsseln

• Tokens

• privaten Schlüsseln

• WLAN-Zugangsdaten

Solche Informationen gehören beispielsweise in:

.env
config.local.json
secrets.py

Diese Dateien müssen wiederum in .gitignore eingetragen werden.

8. Automatische Tests erzeugen

Plakat vergrößern

Tests sind eine der wichtigsten Ergänzungen beim Arbeiten mit KI.

Bei einem Python-Projekt kann beispielsweise pytest eingesetzt werden.

Ein Agent kann zunächst analysieren, welche Funktionen bisher nicht getestet werden.

Beispiel-Agentenanweisung

Analysiere das bestehende Python-Projekt.

Ermittle:

- öffentliche Funktionen
- Klassen
- wichtige Grenzfälle
- Fehlerfälle
- bislang ungetestete Funktionen

Erstelle anschließend passende pytest-Tests.

Vorgaben:

- vorhandenen Anwendungscode nur ändern, wenn zwingend notwendig
- für jeden Fehlerfall einen eigenen Test erstellen
- aussagekräftige Testnamen verwenden
- keine Hardware für Unit-Tests voraussetzen
- Hardwarezugriffe nach Möglichkeit mocken

Dokumentiere zusätzlich, welche Bereiche noch nicht automatisiert
getestet werden können.

9. Hardwarezugriffe testen

Gerade bei Firmware- und Hardwareprojekten ist nicht jede Funktion direkt auf einem normalen Computer testbar.

Deshalb muss zwischen verschiedenen Testarten unterschieden werden:

Unit-Test

Testet einzelne Softwarefunktionen.

Integrationstest

Testet mehrere Komponenten gemeinsam.

Hardwaretest

Testet das reale Gerät.

Beispielsweise kann ein Stepper-Treiber im Unit-Test durch ein Mock-Objekt ersetzt werden.

Damit lässt sich überprüfen:

• ob die richtige Richtung gesetzt wird

• ob die richtige Anzahl Schritte erzeugt wird

• ob ungültige Werte abgefangen werden

ohne tatsächlich einen Motor anzuschließen.

10. Regressionstests

Nach jeder neuen Funktion sollten vorhandene Tests erneut ausgeführt werden.

Der Ablauf lautet:

Änderung
↓
bestehende Tests
↓
neue Tests
↓
Fehleranalyse
↓
Dokumentation
↓
Commit

Dadurch werden sogenannte Regressionen erkannt:

Eine neue Funktion darf keine bereits funktionierende Funktion beschädigen.

11. Versionsnummern automatisch unterstützen

Ein Agent kann auch bei der Versionierung helfen.

Beispielsweise mit:

MAJOR.MINOR.PATCH

Also:

0.3.0
0.4.0
0.4.1

Agentenanweisung

Unterstütze die Versionierung dieses Projektes.

Verwende Semantic Versioning:

MAJOR.MINOR.PATCH

Prüfe bei Änderungen:

1. Welche Funktionen wurden ergänzt?
2. Wurden Schnittstellen verändert?
3. Wurden ausschließlich Fehler korrigiert?
4. Sind Tests vorhanden?
5. Ist die Dokumentation aktuell?

Schlage anschließend eine passende Versionsnummer vor.

Aktualisiere bei Freigabe:

- version.py
- CHANGELOG.md
- gegebenenfalls README.md
- docs/roadmap.md

12. Roadmap und Implementierung vergleichen

Ein Agent kann regelmäßig prüfen, ob Projektplanung und tatsächlicher Entwicklungsstand noch zusammenpassen.

Analysiere den aktuellen Stand des Repositorys.

Vergleiche:

- implementierte Funktionen
- Tests
- Dokumentation
- Roadmap

Erstelle einen Projektstatus mit:

1. abgeschlossen
2. aktuell in Entwicklung
3. noch geplant
4. technische Risiken
5. fehlende Tests
6. fehlende Dokumentation
7. empfohlener nächster Entwicklungsschritt

Diese Analyse ist besonders hilfreich vor einem neuen Entwicklungsschritt oder Release.

13. Changelog automatisch pflegen

Eine mögliche Struktur:

# Changelog

## 0.3.0

### Added

- Referenzfahrt
- Homing-Status

### Changed

- Axis-Klasse erweitert

### Fixed

- fehlerhafte Richtungsumschaltung

Wichtig ist, dass die KI historische Einträge nicht rückwirkend verändert.

14. Technische Dokumentation parallel entwickeln

Plakat vergrößern

Dokumentation sollte nicht erst nach Abschluss des Projektes entstehen.

Typische Dateien sind:

README.md
CHANGELOG.md
docs/
├── architecture.md
├── installation.md
├── testing.md
├── troubleshooting.md
├── roadmap.md
└── decisions/

Agentenanweisung

Prüfe nach jeder größeren Änderung, ob die Projektdokumentation noch
mit dem aktuellen Entwicklungsstand übereinstimmt.

Kontrolliere insbesondere:

- README.md
- CHANGELOG.md
- docs/architecture.md
- docs/roadmap.md
- docs/testing.md
- Installationsanleitung

Dokumentiere nur tatsächlich implementierte Funktionen als vorhanden.

Geplante Funktionen müssen eindeutig als geplant gekennzeichnet sein.

Entferne keine historischen Informationen aus dem Changelog.

15. Lösungswege dokumentieren

Plakat vergrößern

Besonders wertvoll ist es, nicht nur das Endergebnis zu dokumentieren.

Auch gescheiterte Versuche können wichtig sein.

Eine mögliche Struktur:

Problem

Versuch 1

Ergebnis

Versuch 2

Ergebnis

gewählte Lösung

Begründung

Gerade bei später auftretenden Fehlern kann diese Historie sehr hilfreich sein.

16. Troubleshooting automatisch erstellen

Nach einer längeren Fehlersuche kann ein Agent die Erkenntnisse zusammenfassen.

Erstelle aus der bisherigen Fehlersuche einen Troubleshooting-Eintrag.

Dokumentiere:

- Symptom
- Umgebung
- ursprüngliche Annahme
- durchgeführte Tests
- ausgeschlossene Ursachen
- tatsächliche Ursache
- Lösung
- Möglichkeit zur zukünftigen Vermeidung

Damit wird aus einer einmal gelösten Fehlersituation dauerhaft verfügbares Projektwissen.

17. Der Software-Workflow

Der resultierende Ablauf kann beispielsweise so aussehen:

Issue / Aufgabe
      ↓
Projektinformationen lesen
      ↓
Änderung planen
      ↓
Code ändern
      ↓
Tests ergänzen
      ↓
Tests ausführen
      ↓
Dokumentation aktualisieren
      ↓
Version prüfen
      ↓
Commit

Weiter im nächsten Teil

Im dritten Teil verlassen wir die reine Programmierung.

Themen sind unter anderem:

• Proxmox

• Debian-Container

• automatische Setup-Scripts

• Python-Dienste

• Konstruktion

• Festigkeitsberechnung

• FEM

• Fehleranalyse

• FMEA

• Projektdokumentation

• Logos und Icons

• Gesamtworkflow