Lernpfad
Mit KI programmieren
Du zerlegst Coding-Aufgaben, prüfst Änderungen und führst erzeugten Code kontrolliert aus.
Für wen: Für Einsteiger:innen und Entwickler:innen mit prüfbarem Arbeitsablauf
Voraussetzungen: Ein kleiner Übungsordner; Git für die Versionskontroll-Aufgabe empfohlen.
Zeit: Etwa 3–4 Stunden
Am Ende kannst du: Du zerlegst Coding-Aufgaben, prüfst Änderungen und führst erzeugten Code kontrolliert aus.
Mit Einheit 1 startenDeine fünf Einheiten.
Alle Schritte direkt erreichbarModell, Editor und Agent getrennt wählen
Lernziel: Du benennst Modell-ID, Werkzeug und deren Grenzen.
Erklärung
Ein Coding-Assistent besteht aus Modell, Editor oder Agent, Kontextzufuhr und Werkzeugen. Der Agent kann Dateien lesen oder ändern, während das Modell die nächste Aktion vorschlägt.
Ein Editor zeigt und bearbeitet deinen Code. Ein Modell erzeugt Vorschläge. Ein Agent kann mithilfe angebotener Werkzeuge weitere Schritte ausführen, etwa Dateien lesen oder Tests starten. Welche dieser Möglichkeiten dein Produkt anbietet und welche Rechte bestehen, sind separate Angaben. Ein Modellname allein beschreibt noch keinen vollständigen Arbeitsablauf.
Beginne im eigenen Übungsordner mit einer kleinen Aufgabe. Lass dir zuerst die betroffenen Dateien und den vorgesehenen Prüfschritt zeigen. Ein vorgeschlagener Test ist noch kein ausgeführter Test. Prüfe nach einer tatsächlichen Änderung den Unterschied zur Ausgangsfassung und das beobachtete Ergebnis.
Beispiel
Prüfe in einem Coding-Tool, welche Änderungen es vor dem Speichern zeigt und welche Dateien es lesen kann.
Vom Lesen zum eigenen Versuch
So beginnst du.
Verwende einen eigenen leeren Übungsordner. Lass den Agenten zunächst nur erklären und einen Plan vorschlagen.
- 01
Die Komponenten notieren
Schreibe Editor, verwendetes Modell und Agent als getrennte Einträge auf.
Erkennbar an: Die Oberfläche wird nicht mit dem Modell gleichgesetzt.
- 02
Den Auftrag begrenzen
Gib nur den Übungsordner und ein kleines Ziel frei.
Erkennbar an: Fremde Projekte und private Dateien gehören nicht zum Versuch.
- 03
Den ersten Vorschlag lesen
Lass dir geplante Dateien und Schritte nennen, bevor du eine Änderung übernimmst.
Erkennbar an: Du kannst Vorschlag und tatsächliche Ausführung auseinanderhalten.
Eigenes fiktives Lernbeispiel
Deine Vorlage und Aufgabe.
Übungsmaterial
TextGeplanter Ablauf: Editor zeigt Änderungen; Agent kann Dateien bearbeiten; Modell erzeugt einen Vorschlag. Datei- und Netzwerkrechte sind noch offen.Ordne jeder Komponente ihre Rolle zu und notiere fehlende Zugriffsangaben.
Mögliche Lösung prüfen
Vorschlag, Bedienoberfläche und Ausführung sind getrennte Ebenen. Vor einem echten Versuch müssen die verfügbaren Rechte und die Prüfung der Änderungen geklärt werden.
Die Installation und ein echter Modelllauf wurden für dieses Lernmaterial nicht auf deinem Gerät ausgeführt. Die Grafiken erklären den Ablauf; sie sind keine Screenshots oder Leistungsmessungen.
Deine Aufgabe
Erstelle eine kurze Liste aus Modell, Werkzeug, Zugriffsrechten und Review-Schritt.
Lösungshinweis anzeigen
Werkzeugfunktionen aus der konkreten Produktdokumentation entnehmen.
Häufiger Denkfehler: Dem Modell Änderungen zuzuschreiben, die tatsächlich vom Agenten ausgeführt werden.
Du bist fertig, wenn: Du kannst jeden Teil des Coding-Workflows erklären.
Quelle: learn.chatgpt.com
Weiter: Änderungen in kleine Aufgaben teilen →Änderungen in kleine Aufgaben teilen
Lernziel: Du formulierst eine Aufgabe mit klaren Grenzen und Abnahmekriterien.
Erklärung
Kleine Aufgaben machen Fehlersuche einfacher. Beschreibe betroffene Dateien, gewünschtes Ergebnis, Dinge, die unverändert bleiben sollen, und einen Prüfschritt.
Ein Abnahmekriterium ist eine vorher festgelegte Bedingung, an der du das Ergebnis prüfst. Bei verdoppeln(x) lautet sie beispielsweise: Für 2 kommt 4 heraus und für 0 kommt 0 heraus. So bleibt der Auftrag überprüfbar, ohne gleich ein ganzes Programm umzubauen oder neue Pakete zu installieren.
Beschreibe zusätzlich die Grenze: nur diese Funktion und ihre passenden Tests. Wenn der Vorschlag weitere Dateien ändert, musst du diese Änderungen einzeln begründen können. Teile größere Vorhaben in kleine Schritte und prüfe jeden erreichten Zustand. Die Beispiele sind Lernfälle, keine vollständige Testsammlung für jede mögliche Eingabe.
Beispiel
Ergänze einen Test für eine bestehende Funktion; ändere die Implementierung erst, wenn der Test das gewünschte Verhalten zeigt.
Vom Lesen zum eigenen Versuch
So beginnst du.
Öffne einen Texteditor und schreibe eine kleine Funktion. Du brauchst für die Aufgabenformulierung noch keine Agentenrechte.
- 01
Die Aufgabe klein halten
Beschränke den Auftrag auf verdoppeln(x).
Erkennbar an: Kein zusätzliches Paket oder fremdes Modul ist Teil des Auftrags.
- 02
Beispiele vorgeben
Lege 2 → 4 und 0 → 0 als erwartete Ergebnisse fest.
Erkennbar an: Die Abnahme ist vor der Änderung bekannt.
- 03
Die Änderung gegenprüfen
Vergleiche die Funktion und die passenden Tests mit dem Auftrag.
Erkennbar an: Nur begründete Änderungen gehören in den Versuch.
Eigenes fiktives Lernbeispiel
Deine Vorlage und Aufgabe.
Übungsmaterial
TextEigene Übungsfunktion: verdoppeln(x) soll x×2 liefern. Nur diese Funktion und ihre vorhandenen Tests gehören zum Auftrag.Schreibe einen kleinen Änderungsauftrag mit Umfang und zwei Beispielen zur Abnahme.
Mögliche Lösung prüfen
Beispiele:2 → 4 und0 → 0. Begrenze den Auftrag auf die Funktion und passende Tests; fremde Dateien oder zusätzliche Pakete benötigen eine separate Begründung.
Kleine Änderungsaufgabe
PromptBearbeite nur verdoppeln(x). Die Funktion soll x * 2 zurückgeben.
Prüffälle: verdoppeln(2) == 4; verdoppeln(0) == 0.
Füge keine Abhängigkeit hinzu und ändere keine fremde Datei.
Zeige den Diff und trenne ausgeführte von nur geplanten Tests.Die Installation und ein echter Modelllauf wurden für dieses Lernmaterial nicht auf deinem Gerät ausgeführt. Die Grafiken erklären den Ablauf; sie sind keine Screenshots oder Leistungsmessungen.
Deine Aufgabe
Schreibe eine Coding-Anweisung mit Ausgangszustand, Ziel, Umfang und Testbefehl.
Lösungshinweis anzeigen
Verwende reale Dateien und überprüfbare Befehle.
Häufiger Denkfehler: In einem Prompt gleichzeitig Architektur, UI und Datenmodell umzubauen.
Du bist fertig, wenn: Die Aufgabe lässt sich an einem kleinen Diff abnehmen.
Quelle: learn.chatgpt.com
Weiter: Diffs und Git-Sicherung nutzen →Diffs und Git-Sicherung nutzen
Lernziel: Du kannst Änderungen vor dem Commit als Diff prüfen.
Erklärung
Versionskontrolle zeigt, welche Dateien verändert wurden und ermöglicht Rückkehr zu einem bekannten Stand. Vor dem Commit gehören Diff, Dateiliste und unerwartete Dateien in die Prüfung.
Ein Diff zeigt Unterschiede zwischen zwei Dateiständen. Git unterscheidet dabei unter anderem noch nicht vorgemerkte Änderungen und bereits für einen Commit vorgemerkte Änderungen. Das Vormerken heißt Staging. Ein gewöhnliches git diff zeigt nicht automatisch beide Bereiche. Auch der Inhalt ganz neuer, noch nicht verfolgter Dateien muss gesondert gelesen werden.
Beginne mit git status --short für die Dateiliste. Lies danach git diff und git diff --cached. Neue Dateien öffnest du zusätzlich im Editor. In unserem Beispiel reicht die angepasste Funktion nicht als Abnahme, weil daneben eine Konfigurationsdatei gelöscht wurde. Diese Löschung bleibt ein offener Punkt, bis ihr Zweck geklärt ist.
Beispiel
Nutze einen sauberen Ausgangscommit, ändere eine Sache und lies den vollständigen Diff.
Vom Lesen zum eigenen Versuch
So beginnst du.
Nutze Git in einem eigenen Übungsprojekt. Die hier kopierbaren Prüfkommandos ändern keine Projektdateien.
- 01
Den Umfang ansehen
Nutze git status --short, um die betroffenen Dateien zu sehen.
Erkennbar an: Auch unerwartete Löschungen werden sichtbar.
- 02
Den Unterschied lesen
Lies git diff für noch nicht vorgemerkte Änderungen und git diff --cached für die bereits zur Übernahme vorgemerkten Änderungen. Neue unversionierte Dateien aus git status --short öffnest du zusätzlich im Editor; ihr Inhalt steht nicht in diesen Diffs.
Erkennbar an: Arbeitsstand, vorgemerkte Änderungen und neue Dateien sind geprüft; eine fremde Löschung bleibt ungeklärt.
- 03
Erst danach übernehmen
Übernimm nur verstandene Änderungen. Eine erfolgreiche Funktion hebt eine fremde Löschung nicht auf.
Erkennbar an: Dein vollständiger Änderungsumfang ist geprüft.
Eigenes fiktives Lernbeispiel
Deine Vorlage und Aufgabe.
Übungsmaterial
TextFiktiver Änderungsbericht: Funktion angepasst, Test ergänzt und zusätzlich eine unangeforderte Konfigurationsdatei gelöscht.Markiere, welche Änderung vor einer Übernahme geklärt werden muss.
Mögliche Lösung prüfen
Die gelöschte Konfiguration liegt außerhalb des beschriebenen Auftrags. Prüfe den vollständigen Änderungsumfang statt nur den erfolgreichen Funktionstest.
Änderungen ansehen
Terminal im eigenen Git-ProjektDiese Prüfungen verändern keine Dateien und erstellen keinen Commit. --check meldet bestimmte Leerraumfehler und Konfliktmarker, beweist aber keine korrekte Funktion. Unversionierte Dateien aus dem Status zusätzlich im Editor lesen.
git status --short
git diff
git diff --cached
git diff --check
git diff --cached --checkDie Installation und ein echter Modelllauf wurden für dieses Lernmaterial nicht auf deinem Gerät ausgeführt. Die Grafiken erklären den Ablauf; sie sind keine Screenshots oder Leistungsmessungen.
Deine Aufgabe
Erstelle eine Übungsänderung und notiere, welche Dateien sie verändert hat.
Lösungshinweis anzeigen
Dateien mit Zugangsdaten und generierte Build-Artefakte besonders kontrollieren.
Häufiger Denkfehler: Einen erfolgreichen Build mit sicherem oder korrektem Code gleichzusetzen.
Du bist fertig, wenn: Du kannst den Änderungsumfang erklären und unerwartete Dateien erkennen.
Quelle: git-scm.com
Weiter: Tests, Sicherheit und Laufzeit prüfen →Tests, Sicherheit und Laufzeit prüfen
Lernziel: Du validierst Code vor seiner Ausführung.
Erklärung
Tests prüfen bekannte Erwartungen, aber nicht alle Sicherheitsrisiken. Lies den Code, prüfe Paketquellen, Berechtigungen und Datei-/Netzwerkzugriff; führe unbekannte Befehle nicht blind aus.
Ein Test beantwortet eine bestimmte Frage an den Code: Kommt bei einer festgelegten Eingabe das erwartete Ergebnis heraus? Das ist nützlich, aber enger als die Frage, ob das ganze Programm sicher und geeignet ist. Ein Installationsskript kann beispielsweise zusätzliche Dateien oder Netzwerkzugriffe betreffen, die ein Funktionstest gar nicht untersucht.
Lies daher zuerst, was der vorgeschlagene Befehl tun soll, aus welcher Quelle er stammt und welche Rechte er benötigt. Verwende für den Versuch einen begrenzten Übungsbereich. Halte erfolgreiche, fehlgeschlagene und nicht ausgeführte Prüfungen getrennt fest. Ein überzeugend formulierter Testbericht ist kein Ersatz für beobachtete Ergebnisse.
Beispiel
Vor einem Installationsbefehl: Paketname, Quelle, Versionsbereich und ausgeführte Skripte prüfen.
Vom Lesen zum eigenen Versuch
So beginnst du.
Behandle erzeugten Code zuerst wie einen fremden Vorschlag. Starte nicht mit dem Herunterladen und Ausführen unbekannter Skripte.
- 01
Den Code lesen
Prüfe Dateizugriffe, Netzaufrufe und benötigte Berechtigungen.
Erkennbar an: Du kennst die geplanten Auswirkungen.
- 02
Kleine Testfälle festlegen
Definiere normale Eingabe, leere Eingabe und einen Fehlerfall passend zur Funktion.
Erkennbar an: Das erwartete Ergebnis steht vor der Ausführung fest.
- 03
Im Übungsbereich prüfen
Führe nur verstandenen Code in der vorgesehenen Umgebung aus und dokumentiere das Ergebnis.
Erkennbar an: Ein Codevorschlag wird nicht als bereits bestandener Test ausgegeben.
Eigenes fiktives Lernbeispiel
Deine Vorlage und Aufgabe.
Übungsmaterial
TextGenerierter Plan: ein unbekanntes Skript laden und direkt ausführen. Quelle, Inhalt und Rechte sind nicht geprüft.Schreibe eine Vorab-Prüfliste und markiere den Ausführungsschritt als offen.
Mögliche Lösung prüfen
Quelle und Skriptinhalt lesen, erforderliche Rechte und Auswirkungen klären, Testbereich und Rückweg festlegen. Ein plausibler Plan ist noch keine Freigabe zur Ausführung.
Deine Aufgabe
Erstelle eine Vorab-Checkliste für einen generierten Shell- oder Python-Befehl.
Lösungshinweis anzeigen
Secrets gehören in Umgebungsvariablen einer sicheren lokalen Umgebung, nie in Repository oder Website.
Häufiger Denkfehler: Einen automatisch erzeugten Test als vollständigen Sicherheitsnachweis zu behandeln.
Du bist fertig, wenn: Du kannst Testabdeckung und verbleibende Risiken benennen.
Quelle: owasp.org
Weiter: Fehler anhand des Ergebnisses eingrenzen →Fehler anhand des Ergebnisses eingrenzen
Lernziel: Du gibst dem Modell die konkrete Fehlermeldung und begrenzt die nächste Änderung.
Erklärung
Ein sinnvoller Debug-Schritt nennt erwartetes und tatsächliches Verhalten, die Fehlermeldung, den betroffenen Ausschnitt und bereits erfolgte Versuche. Prüfe den Folge-Diff und führe denselben Test erneut aus.
Eine Hypothese ist eine Erklärung, die du noch prüfen musst. ‚Die Funktion addiert vielleicht 2, statt mit 2 zu multiplizieren‘ passt zum erfundenen Befund 3 → 5. Für die Eingabe 2 würden beide Rechenwege zufällig 4 liefern. Ein weiterer gezielter Fall kann deshalb eine andere Aussagekraft haben als die bloße Wiederholung eines bereits passenden Beispiels.
Notiere Sollwert, beobachteten Wert und betroffene Stelle, bevor du eine Änderung verlangst. Bitte um eine kleine begründete Korrektur und führe anschließend denselben Test erneut aus. Bewahre auch den ursprünglichen Fehlerfall. Wenn du mehrere unabhängige Änderungen gleichzeitig übernimmst, lässt sich die Ursache später schwerer nachvollziehen.
Beispiel
Wenn ein Test fehlschlägt, ändere zuerst nur die Ursache, die der Fehler belegt.
Vom Lesen zum eigenen Versuch
So beginnst du.
Kopiere nur den relevanten Fehler und die kleine betroffene Funktion. Entferne Zugangsdaten aus Protokollen.
- 01
Soll und Ist trennen
Notiere für verdoppeln(3) den erwarteten und beobachteten Wert.
Erkennbar an: 6 und 5 stehen ausdrücklich nebeneinander.
- 02
Die Änderung eingrenzen
Bitte um eine Erklärung nur für die betroffene Berechnung.
Erkennbar an: Der Auftrag umfasst nicht das ganze Projekt.
- 03
Die Hypothese prüfen
Teste eine weitere bekannte Eingabe und ändere nur den begründeten Schritt.
Erkennbar an: Der neue Befund ist der einen Änderung zugeordnet.
Eigenes fiktives Lernbeispiel
Deine Vorlage und Aufgabe.
Übungsmaterial
TextFiktiver Test: verdoppeln(3) erwartet 6, beobachtet 5. Der übrige Ablauf wurde nicht untersucht.Formuliere eine begrenzte Hypothese und einen isolierten nächsten Test.
Mögliche Lösung prüfen
Prüfe die Berechnung dieser Funktion mit bekannten Eingaben. Der einzelne Befund rechtfertigt nicht, das ganze Projekt oder mehrere Abhängigkeiten umzubauen.
Die Installation und ein echter Modelllauf wurden für dieses Lernmaterial nicht auf deinem Gerät ausgeführt. Die Grafiken erklären den Ablauf; sie sind keine Screenshots oder Leistungsmessungen.
Deine Aufgabe
Schreibe ein Debugging-Protokoll mit Fehler, Hypothese und einem isolierten Test.
Lösungshinweis anzeigen
Fehlertext und Projektdateien vor dem Teilen auf Tokens und private Pfade prüfen.
Häufiger Denkfehler: Mehrere unabhängige Änderungen anzufordern, bevor die erste verifiziert ist.
Du bist fertig, wenn: Der nächste Schritt ist klein, begründet und überprüfbar.
Quelle: learn.chatgpt.com
Optional · nur dieser Browser
An deiner Stelle weiterlernen.
Die Einheiten bleiben ohne Anmeldung nutzbar. Erst nach deinem Klick merkt sich dieser Browser deine Häkchen. Du kannst sie jederzeit löschen. Quizantworten werden nicht gespeichert oder versendet.
Fortschritt wird aktuell nicht gespeichert.
Häufige Fragen
Was lernst du im Lernpfad „Mit KI programmieren“?
Du zerlegst Coding-Aufgaben, prüfst Änderungen und führst erzeugten Code kontrolliert aus.
Für wen ist dieser Lernpfad gedacht?
Für Einsteiger:innen und Entwickler:innen mit prüfbarem Arbeitsablauf
Welche Voraussetzungen brauchst du?
Ein kleiner Übungsordner; Git für die Versionskontroll-Aufgabe empfohlen.
Wie viel Zeit solltest du einplanen?
Etwa 3–4 Stunden
Kannst du den Fortschritt speichern?
Optional kannst du erledigte Einheiten nach einem Klick auf deinem Gerät merken. Ohne Aktivierung werden keine Lernstände gespeichert.