Warum du deine Commit-Beschreibung selbst schreiben solltest
Commit Description as a Thinking Tool
Vor der Ära des agentischen Codings verfasste der Autor ausführliche Commit-Beschreibungen, um Entscheidungen zu reflektieren. Heute schreiben KI-Agenten den Code und die Beschreibungen, doch sie kennen oft nicht das „Warum“ und erfinden Gründe. Das ist gefährlich, denn nur der Mensch kann prüfen, ob der Code tut, was die Beschreibung verspricht. Die eigene Formulierung der Commit-Nachricht wird so zum Denkwerkzeug, um zu verstehen, was man ausliefert.
Wenn du es nicht erklären kannst, hast du es nicht verstanden.
- WD-42
Schreiben ist in jeder Situation Denken, nicht nur auf Commit-Nachrichten beschränkt. Das ist eine Tatsache, von der ich befürchte, dass die Leute sie vergessen – oder schlimmer noch, nie verstanden haben.
- dkarl
Ich musste schon lange vor KI auf Commit-Nachrichten verzichten, weil andere Leute so schlecht darin waren, dass ich gerne zugestimmt habe, dass alle PRs Commits squashen sollten.
Zumindest waren die gesquashten Nachrichten dann meist ganz ordentlich. Aber dann fingen die Leute an, KI zu benutzen (oder KI fing an, Leute zu benutzen), um absolut riesige Commit-Nachrichten zu erstellen, die man in git blame unmöglich überfliegen kann und die insgesamt sehr schlecht für den menschlichen Konsum sind.
KI hat in praktisch jeder anderen Hinsicht massive Fortschritte gemacht. Warum schreiben sie weiterhin auf eine verschwenderische, menschenfeindliche Weise?
Ich denke, wir müssten sehr naiv sein, um nicht zu vermuten, dass das Absicht ist. KI-Firmen haben das erklärte Ziel, Menschen im Softwareentwicklungsprozess zu ersetzen, und sie machen den Prozess selbst aktiv unwirtlich für Menschen.
Sie injizieren massive Textmengen in den Entwicklungsprozess ihrer Kunden, die dann zu Tokens werden, für deren Verarbeitung ihre Kunden ihnen immer wieder bezahlen. Es ist wie ein CO2-Scrubber, der CO2 ausstößt.
- kccqzy
Vor langer Zeit habe ich die Standard-Commit-Nachricht geändert, um die Überschriften „Warum?“ und „Wie?“ aufzunehmen, um mich daran zu erinnern, dass ich erklären muss, warum eine Änderung vorgenommen wird (worauf dieser Artikel abzielt) und wie sie vorgenommen wird (verschiedene in Betracht gezogene Implementierungsansätze). Ich habe dieses Format lange Zeit befolgt. Ich war in den Top 1 % der Commit-Nachrichtenlänge im Unternehmen.
Exkurs: Ich habe mir einmal Sorgen gemacht, dass Dinge kaputtgehen, wenn Commit-Nachrichten zu lang werden. Ich habe es mit sehr langen Commit-Nachrichten versucht und nichts ging kaputt: https://github.com/kccqzy/long-commit-messages/commit/ccfda4...
- arialdomartini
Darüber hinaus zahlt es sich aus, die Commit-Nachrichten vor dem Code zu schreiben
https://arialdomartini.github.io/pre-emptive-commit-comments
- evnp
> Wenn die KI den „Warum“-Teil nicht kennt, denkt sie sich ihre eigene Begründung aus. Das finde ich gefährlich. Wenn wir das später lesen, ergibt es möglicherweise keinen Sinn, weil der wahre Grund völlig anders war.
Noch gefährlicher: wenn der Text _doch_ Sinn ergibt, obwohl er von der Realität losgelöst ist.