W 1982 roku „The Atlantic Monthly” opublikował tekst, który na dekady trafił do podręczników kryminologii. Jego teza była prosta: jeśli w budynku stłuczona szyba pozostaje niezreperowana, wkrótce polecą wszystkie pozostałe. Nie dlatego, że w okolicy mieszkają wyłącznie wandale — wręcz odwrotnie. Jedna naprawiona szyba to sygnał, że ktoś tu dba, a więc niszczenie kosztuje. Jedna szyba nietknięta to sygnał, że nikogo to nie obchodzi, a więc niszczenie nie kosztuje nic.
Jeff Atwood sięgnął po tę metaforę na swoim blogu Coding Horror już w 2005 roku, przekładając ją na grunt programowania. Przypomniał przy tym słynną radę z „Pragmatic Programmer”: nie zostawiaj w kodzie „zbitych szyb” — błędnych decyzji projektowych, złych wzorców, brudnych fragmentów. Napraw każdą, gdy tylko ją zauważysz. Jeśli nie masz czasu na porządną naprawę, zabezpiecz miejsce: zakomentuj, zwróć komunikat „nie zaimplementowano”, podstaw dane zastępcze. Byle zrobić cokolwiek, co pokaże, że sytuacja jest pod kontrolą.
Kluczowy wniosek Atwooda nie dotyczył jednak samych technicznych usterek, lecz percepcji. Programowanie jest zajęciem obsesyjnie drobiazgowym, a drobiazgi działają jak barometr. Gdy zespół przestaje panować nad szczegółami, pojawia się wrażenie, że projekt wymyka się z rąk — i zwykle nie jest to wrażenie mylne. Zaniedbanie napędza rozkład szybciej niż jakikolwiek inny czynnik, bo uruchamia pętlę sprzężenia zwrotnego: każdy kolejny nieposprzątany fragment obniża próg tego, co jeszcze uchodzi na sucho.
Dokładnie ten mechanizm widać dziś w zespołach, które masowo korzystają z asystentów AI. Wygenerowany kod bywa poprawny, ale anonimowy: nikt go w pełni nie rozumie, nikt nie czuje się jego właścicielem, a tempo powstawania zmian przewyższa tempo ich czytania. Pierwszy nieprzejrzany fragment, pierwsza funkcja „na chwilę”, pierwszy komentarz typu „TODO: poprawić później” — i próg się obniża. Kolejne warstwy generowanego kodu przechodzą już bez oporu, bo przecież nikt nie reagował wcześniej.
Nie chodzi o to, że AI psuje oprogramowanie. Chodzi o to, że skaluje nasze nawyki — również te złe. Jeśli kultura zespołu opiera się na natychmiastowym domykaniu drobnych usterek, asystent przyspieszy porządkowanie. Jeśli opiera się na odkładaniu ich na później, dostaniemy tę samą prowizorkę, tylko w większej ilości i szybciej. Teoria zbitych szyb nie mówi nic o narzędziach; mówi o tym, jak szybko ludzie przestają się przejmować, gdy widzą, że inni też przestali.
Praktyczny wniosek jest więc mniej spektakularny, niż chcieliby zwolennicy rewolucji i jej przeciwnicy. Warto dbać o drobiazgi: recenzować generowane zmiany zamiast je klepać, usuwać martwy kod zamiast go komentować, pilnować spójności nazw i struktur, domykać małe długi techniczne, zanim urosną w legendę. To nie jest walka z AI — to ta sama walka, którą programiści toczą od dekad, tylko rozgrywana na szybszym boisku.
Podsumowanie: Teoria zbitych szyb tłumaczy, dlaczego pozornie błahe zaniedbania potrafią rozłożyć cały projekt. W erze kodu pisanego z pomocą AI mechanizm ten działa mocniej, bo skala i tempo zmian rosną. Odpowiedź pozostaje ta sama: reagować na pierwsze pęknięcie, zanim przestanie robić wrażenie na kimkolwiek.