KI kann bei technischen Projekten weit mehr leisten als Texte formulieren oder einzelne Programmzeilen erzeugen. Richtig eingesetzt kann sie den gesamten Entwicklungsprozess begleiten:
Idee → Anforderungen → Konzept → Lösungsalternativen → Planung → Umsetzung → Test → Dokumentation
Entscheidend ist dabei die Herangehensweise.
Die Aufgabe lautet nicht:
„Entwickle mein Projekt.“
Sondern:
„Hilf mir, mein Projekt systematisch zu entwickeln.“
KI wird damit zum technischen Assistenten, Sparringspartner und Reviewer. Die Verantwortung für technische Entscheidungen bleibt beim Menschen.
Plakat vergrößern
1. Nicht sofort mit der Lösung beginnen
Eine der größten Gefahren beim Arbeiten mit KI besteht darin, dass sehr schnell eine scheinbar fertige Lösung erzeugt wird.
Ein Beispiel:
Programmiere eine Steuerung für vier Schrittmotoren.
Eine KI kann darauf sofort umfangreichen Code erzeugen.
Aber zu diesem Zeitpunkt fehlen wahrscheinlich noch wichtige Informationen:
-
Welche Hardware wird verwendet?
-
Welche Stepper-Treiber kommen zum Einsatz?
-
Welche Geschwindigkeit wird benötigt?
-
Gibt es Referenzschalter?
-
Müssen Achsen gleichzeitig fahren?
-
Welche Genauigkeit wird benötigt?
-
Was passiert bei einem Fehler?
-
Welche Kommunikationsschnittstellen sind vorgesehen?
Eine bessere Vorgehensweise besteht deshalb darin, die KI zunächst Fragen stellen zu lassen.
Beispiel-Prompt
Ich möchte ein neues technisches Projekt beginnen.
Projektidee:
Firmware für eine Steuerung mit vier Bewegungsachsen.
Bevor wir Lösungen entwickeln oder Code erzeugen, stelle mir zunächst
alle wichtigen technischen und organisatorischen Fragen.
Ordne die Fragen nach:
1. Projektziel
2. Funktionen
3. Hardware
4. Software
5. Schnittstellen
6. Sicherheit
7. Tests
8. Dokumentation
9. zukünftige Erweiterungen
Erstelle noch keine Lösung.
Ziel ist zunächst eine möglichst vollständige Anforderungsanalyse.
Damit verändert sich die Rolle der KI. Sie soll nicht sofort produzieren, sondern zunächst beim Verstehen des Problems helfen.
2. Anforderungen sammeln
Aus einer allgemeinen Projektidee müssen konkrete Anforderungen entstehen.
Typische Fragen sind:
Projektziel
-
Welches Problem soll gelöst werden?
-
Wer soll das System benutzen?
-
Was gehört ausdrücklich nicht zum Projekt?
Hardware
-
Welche Controller werden eingesetzt?
-
Welche Sensoren und Aktoren sind vorhanden?
-
Welche Spannungen und Leistungen werden benötigt?
Software
-
Welche Programmiersprache wird eingesetzt?
-
Welche Bibliotheken oder Frameworks sind vorgesehen?
-
Auf welchen Betriebssystemen soll die Software laufen?
Schnittstellen
-
USB?
-
UART?
-
WLAN?
-
Ethernet?
-
MQTT?
-
REST-API?
Sicherheit
-
Was passiert bei Kommunikationsverlust?
-
Was passiert bei einem defekten Sensor?
-
Welche gefährlichen Zustände können auftreten?
Tests
-
Wie kann eine Funktion überprüft werden?
-
Welche Messwerte müssen erfasst werden?
-
Welche Grenzwerte gelten?
3. Aus Anforderungen entsteht eine Projektbeschreibung
Nach der Fragerunde kann die KI die Informationen in eine strukturierte Projektbeschreibung überführen.
Eine sinnvolle Projektbeschreibung enthält beispielsweise:
Projektname
Ausgangssituation
Problemstellung
Projektziel
Funktionsumfang
Nicht-Ziele
Hardware
Software
Schnittstellen
Randbedingungen
Sicherheit
Tests
Dokumentation
zukünftige Erweiterungen
Diese Projektbeschreibung wird anschließend Teil des Projekt-Repositories.
Beispielsweise:
docs/
└── project-description.md
Damit erhält nicht nur der Entwickler einen Überblick. Auch ein KI-Agent kann später zunächst dieses Dokument lesen und dadurch den Projektkontext besser verstehen.
4. Lastenheft und Pflichtenheft
Gerade bei größeren Projekten lohnt es sich, Anforderungen weiter zu strukturieren.
Lastenheft
Das Lastenheft beschreibt:
Was soll das System können?
Beispiel:
-
vier Bewegungsachsen steuern
-
Referenzschalter auswerten
-
Referenzfahrt ermöglichen
-
definierte Positionen anfahren
-
Fehlerzustände erkennen
-
sicheren Stillstand ermöglichen
Pflichtenheft
Das Pflichtenheft beschreibt:
Wie sollen diese Anforderungen technisch umgesetzt werden?
Beispielsweise:
-
Raspberry Pi Pico 2
-
MicroPython
-
Step/Direction-Schnittstellen
-
digitale Eingänge für Referenzschalter
-
modulare Firmware
-
automatisierte Tests
-
GitHub als Versionsverwaltung
5. Lösungsalternativen mit KI entwickeln
Plakat vergrößern
Ein weiterer häufiger Fehler besteht darin, sofort die erste brauchbare Lösung umzusetzen.
KI eignet sich hervorragend dazu, mehrere Lösungswege zu entwickeln.
Beispiel-Prompt
Für die Bewegungssteuerung eines Mikrocontroller-Projektes werden
mehrere technische Lösungswege gesucht.
Entwickle mindestens vier unterschiedliche Softwarearchitekturen.
Bewerte jede Variante nach:
- Komplexität
- Erweiterbarkeit
- Testbarkeit
- Echtzeitfähigkeit
- Wartbarkeit
- Entwicklungsaufwand
- Fehlerrisiko
Erstelle anschließend eine Vergleichstabelle.
Triff noch keine endgültige Entscheidung.
Damit können beispielsweise folgende Varianten entstehen:
| Variante | Vorteil | Nachteil |
|---|---|---|
| einfache Hauptschleife | leicht verständlich | begrenzt skalierbar |
| objektorientierte Achssteuerung | modular | höherer Aufwand |
| Zustandsautomat | klare Zustände | komplexere Planung |
| Event-/Task-basiert | flexibel | schwieriger zu debuggen |
6. Technische Entscheidungen dokumentieren
Bei längeren Projekten geht schnell verloren, warum eine bestimmte Lösung gewählt wurde.
Dafür eignet sich beispielsweise ein Ordner:
docs/
└── decisions/
├── 001-controller.md
├── 002-stepper-interface.md
└── 003-software-architecture.md
Eine Entscheidungsdokumentation kann enthalten:
-
Problem
-
Randbedingungen
-
untersuchte Alternativen
-
Vor- und Nachteile
-
getroffene Entscheidung
-
Begründung
-
mögliche Konsequenzen
Beispiel-Prompt
Dokumentiere die folgende technische Entscheidung.
Ausgangssituation:
[Beschreibung]
Untersuchte Varianten:
[Varianten]
Entscheidung:
[gewählte Lösung]
Erstelle daraus eine technische Entscheidungsdokumentation mit:
- Problem
- Randbedingungen
- untersuchte Alternativen
- Vor- und Nachteile
- Entscheidung
- Begründung
- mögliche spätere Konsequenzen
7. Beispielprojekt: XYUV-Control
Als Beispiel für den Ablauf verwenden wir eine Firmware mit dem Projektnamen XYUV-Control.
Das Beispiel eignet sich gut, weil darin mehrere typische Themen zusammenkommen:
-
Mikrocontroller
-
Stepper-Treiber
-
Referenzschalter
-
Bewegungssteuerung
-
Softwarearchitektur
-
Tests
-
Versionsverwaltung
-
technische Dokumentation
Wichtig ist dabei nicht die konkrete Maschine, sondern die Vorgehensweise bei der Entwicklung.
Eine mögliche erste Projektstruktur könnte beispielsweise so aussehen:
xyuv-control/
│
├── README.md
├── LICENSE
├── .gitignore
│
├── src/
│ ├── main.py
│ ├── axis.py
│ ├── stepper.py
│ └── homing.py
│
├── tests/
│
├── scripts/
│
├── docs/
│ ├── project-description.md
│ ├── requirements.md
│ ├── architecture.md
│ ├── roadmap.md
│ ├── testing.md
│ └── decisions/
│
├── version.py
└── CHANGELOG.md
8. Roadmap statt ungeplanter Entwicklung
Gerade bei KI-gestützter Entwicklung besteht die Gefahr, dass ständig neue Ideen umgesetzt werden.
Eine Roadmap begrenzt den Funktionsumfang.
Beispiel:
| Version | Schwerpunkt |
|---|---|
| 0.1.0 | Projektstruktur und eine Achse |
| 0.2.0 | Referenzschalter |
| 0.3.0 | Referenzfahrt |
| 0.4.0 | mehrere Achsen |
| 0.5.0 | koordinierte Bewegungen |
| 0.6.0 | Fehlerbehandlung |
| 0.7.0 | Kommunikation |
| 0.8.0 | erweiterte Tests |
| 0.9.0 | Beta |
| 1.0.0 | stabile Version |
Damit weiß auch ein Agent, welche Funktionen jetzt relevant sind und welche erst später umgesetzt werden sollen.
9. Agentenanweisung für die Roadmap
Plakat vergrößern
Pflege für dieses Projekt die Datei docs/roadmap.md.
Sie soll enthalten:
- alle geplanten Versionen
- Ziel jeder Version
- geplante Funktionen
- Abhängigkeiten
- bekannte Risiken
- Status der Umsetzung
Wenn während der Entwicklung neue Anforderungen hinzukommen,
ordne sie einer sinnvollen zukünftigen Version zu.
Ändere abgeschlossene Versionsziele nicht rückwirkend.
Dokumentiere Änderungen nachvollziehbar.
10. Der wichtigste Grundsatz
Der wichtigste Unterschied zwischen klassischer und sinnvoller KI-unterstützter Projektarbeit lautet:
Nicht:
Idee
↓
KI
↓
fertige Lösung
Sondern:
Idee
↓
Fragen
↓
Anforderungen
↓
Alternativen
↓
Entscheidung
↓
Planung
↓
Umsetzung
↓
Tests
↓
Dokumentation
Weiter im nächsten Teil
Im zweiten Teil geht es darum, wie aus dem geplanten Projekt tatsächlich Software entsteht:
-
Visual Studio Code
-
Codex
-
Git und GitHub
-
Agentenanweisungen
-
kleine Arbeitspakete
-
.gitignore -
Secrets
-
automatisierte Tests
-
Versionsverwaltung
Weiter zu Teil 2: Mit KI programmieren – VS Code, Codex, GitHub und automatisierte Tests
