Claude Academy
Wird geladen

Steh zu dem, was du baust

Lektion 815 Min.
In dieser LektionAm Ende kannst du
  • Formuliere, wofür du verantwortlich bist, wenn du etwas veröffentlichst, das mit Hilfe von KI entstanden ist
  • Identifiziere die technischen Realitäten, die beim Veröffentlichen zutage treten, und baue Feedbackschleifen auf, die sie erfassen
  • Triff die Entscheidung: veröffentlichen, reparieren oder stoppen

Diligence (Gewissenhaftigkeit) und das Teilen deiner Arbeit

Wird geladen

Gewissenhaftigkeit und das Teilen deiner Arbeit · 3 min

ZusammenfassungTranskript

Gewissenhaftigkeit im Builder-Modell bedeutet volle Verantwortung: Du bist für das Produkt verantwortlich – von der Frage, ob es existieren sollte, bis zu der Frage, ob es Nutzern nach dem Launch dient. Diese Lektion behandelt, was es bedeutet, etwas zu veröffentlichen, die technischen Realitäten, vor denen KI dich nicht warnt, warum Tests zu deinem Sicherheitsnetz werden, sobald etwas live ist, und die unterschätzte Fähigkeit, deine eigene Arbeit abzukündigen.

Wichtigste Erkenntnisse

  • Du bist verantwortlich für das Ergebnis, nicht für den Output. „KI hat es geschrieben" erklärt nichts und entschuldigt nichts.
  • Veröffentlichen hat sein eigenes technisches Vokabular (Migrationen, Versionierung, Ratenlimits, Feature-Flags), das KI nicht von selbst ansprechen wird, wenn du nicht danach fragst.
  • Tests machen Iterationen nach dem Launch sicher. Die Test-First-Gewohnheit ist der Grund, warum du weiterhin selbstbewusst Dinge ändern kannst.
  • Erstelle Prototypen frei, veröffentliche selektiv. Günstiger Code schafft nur dann Wert, wenn er mit ehrlicher Bewertung einhergeht.
  • Zugang ist eine Designentscheidung. Überprüfe, wen deine Annahmen ausschließen, bevor du etwas als veröffentlicht bezeichnest.

Übung

Veröffentliche die Clinic-App

Beim Veröffentlichen wird Gewissenhaftigkeit real — bevor du deployst, beantworte jede dieser Fragen ehrlich.

Sobald du diese durchgearbeitet hast, deploye deine App oder hoste sie als Prototyp, teile sie mit drei echten Nutzern und nimm eine Iteration basierend auf dem vor, was du lernst – mit Tests, die die Änderung verifizieren.

  • Verständnis — Kannst du erklären, was dein Code tut, nicht nur, was er tun sollte?
  • Testing — Bestehen deine Akzeptanztests noch? Hast du Grenzfälle getestet — geschlossene Klinik, fehlende Daten, Wartezeit null?
  • Zugang — Wem dient dein Build nicht gut?
  • Verantwortung — Könnte dieser Output falsch verstanden oder missbraucht werden? Warst du transparent bezüglich der Rolle der KI?
  • Feedbackschleife — Wie wirst du wissen, ob es funktioniert, nachdem es veröffentlicht wurde?

Reflexion zur Lektion

  • Wie hat sich dein Denken über KI-Integration seit Beginn dieses Kurses verändert?
  • Was wirst du basierend auf dem, was du gelernt hast, in deiner Arbeit mit KI anders machen?

Was kommt als Nächstes

Du hast den Clinic Wait Time Checker gebaut, bewertet und veröffentlicht. In der letzten Lektion bringst du das gesamte 4D-Modell zusammen und gehst mit einer bereits laufenden echten Aufgabe hinaus.