Also ich kann deine Skepsis auf jeden Fall gut nachvollziehen. In einem Umfeld mit hohen Anforderungen an Verfügbarkeit und Safety ist es nun mal ein reales Delikt, da kann man „vibe coden“ nicht einfach als ein Kavaliersdelikt einstufen.

Genau deswegen rächt sich das später im Feld, wenn Entwickler Code, welchen sie nicht vollständig durchdrungen haben, integrieren. Und ja, die Verantwortung verschiebt sich in solchen Fällen.

KI-Tools sind nicht definitiv nicht als Ersatz für Architekturverständnis anzusehen, sondern eher als Beschleuniger für Routine. In anderen Worten: für Boilerplate, Testskelett, Refactoring-Vorschläge kann man sie auf jeden Fall anwenden. Aber für sicherheitskritische Systeme und deren Kernlogik? Jeder muss hier verstehen, was passiert, und das Bit für Bit. Sonst debuggt man am Ende auch Annahmen und somit nicht ausschließlich die Bugs.

Aber was ich noch dazu loswerden möchte, es hapert meines Wissens weniger am Tool als am nach wie vor fehlenden Regelwerk. Und es wird denke ich schnell unübersichtlich, wenn man es ohne klare Leitplanken angeht.

Wie geht ihr aktuell mit Ownership um? Muss derjenige, der den Code committet, ihn auch vollständig erklären können – unabhängig davon, wer oder was ihn vorgeschlagen hat?