Was früher als schlechte Idee galt, funktioniert heute plötzlich

Bad ideas that aren't bad anymore

15 Jahre Softwareentwicklung haben Devon C. Estes ein feines Gespür dafür gegeben, was in der Praxis schiefgeht. Doch plötzlich funktionieren Dinge, die sein Bauchgefühl als schlechte Idee abtut: Niemand reviewt mehr die PRs anderer, das Team arbeitet in getrennten Strömen, und tiefes Fachwissen in einer Technologie verliert an Wert. Der Grund: Claude und Greptile übernehmen das Review, Kontextwechsel kostet kaum noch Zeit, und Urteilsvermögen schlägt Detailwissen.

Was sich wirklich geändert hat, ist, dass die Kosten für den Kontextwechsel dramatisch gesunken sind, weil wir eine Ebene höher arbeiten als früher.
  1. sn

    Ich bin Principal Engineer. Code Reviews sind für Produktionssoftware immer noch wichtig.

    Vielleicht ist deine Meinung, dass ich nicht hart genug vibe-code, und wenn ich KI besser einsetzen würde, bräuchten wir keine Code Reviews. Ich widerspreche – sowohl Ingenieure als auch LLMs fügen immer noch unnötige Komplexität hinzu oder wählen die falschen Abstraktionen, was später Probleme verursachen wird, denken nicht an alle Randfälle und wählen die falsche Behandlung für Fehlerbedingungen. Sie fügen Dinge hinzu, die ihnen wie eine gute Idee erscheinen, und halten sich nicht an die Spezifikation.

    Wenn mein Unternehmen aufhört, Code Reviews für die Software durchzuführen, auf die es ankommt, kündige ich.

    Ingenieure, die nicht im Startup-Engpass stecken, sollten darauf abzielen, LLMs zum besseren, nicht zum schnelleren Programmieren zu nutzen. Schneller schafft nur technische Schulden und erhöht die langfristigen Kosten.

  2. xg15

    Das gemeinsame Thema dieser verschiedenen Beispiele scheint zu sein:

    "Früher mussten wir darauf achten, jedem Teammitglied zu ermöglichen, Erfahrung und Expertise mit unserer Codebasis aufzubauen, und Dynamiken vermeiden, die Wissenssilos bilden könnten. Jetzt spielt das keine Rolle mehr, weil jeder einfach Claude bitten kann, ihm alles zu erklären."

    Ich bin mir da ehrlich gesagt nicht so sicher. Kurzfristig funktioniert es, ja. Aber langfristig könnte es sein, als hätte man einige sehr gute Bücher, aber null praktische Erfahrung mit einer Sache. Wir alle wissen, dass Buchwissen anders ist als erlernte Erfahrung.

  3. ro_sharp

    Warum denken so viele Leute, dass es bei Code Reviews in erster Linie um Misstrauen oder das Finden von Fehlern geht?

    Meiner Meinung nach geht es in erster Linie darum, gemeinsames Verständnis und Übereinstimmung sicherzustellen – nicht nur darüber, wie sich die Dinge jetzt ändern, sondern auch darüber, wie sie sich in Zukunft ändern werden.

  4. kbiessy

    Ich werde über den Punkt auf dieser Liste sprechen, den ich am besten kenne. Das "Bauen statt Kaufen" ist derjenige, den ich in Frage stellen würde.

    Die Kosten für das Schreiben des Tools sind größtenteils weggefallen, da stimme ich zu. Die Kosten für den Besitz haben sich meiner Meinung nach nicht so sehr verändert. Wenn ich mir den Software-Stack einiger kleiner Unternehmen ansehe, die ich kenne, sind es die maßgeschneiderten Tools, die am meisten wehtun. Niemand erinnert sich, dass es maßgeschneidert war, bis der API-Aufruf fehlschlägt oder die Person, die es gebaut hat, geht. Ich denke, die Wartungskosten sind besonders hoch.

    Ein Nachmittag Bauen behebt keine langfristige Wartung und vermittelt kein funktionales Wissen. Ich denke, Generalisten können stark von KI profitieren, aber es wird auch weiterhin eine große Rolle für Experten geben, die Software in Zukunft anleiten und warten.

  5. ahartmetz

    >Eine Sprache oder ein Tool einführen, das niemand im Team kennt [ist keine schlechte Idee mehr]

    OK, jetzt bin ich sicher, dass der Typ völlig daneben ist.

Mehr von diesem Tag

2026-11-12