Если код генерит ИИ, кто будет вносить новые паттерны и бэст практис?

Периодически встречал озадаченность: разработчики перестанут писать код руками - и развитие подходов встанет. Ведь якобы именно во время кодинга и рождается всё новое.

Но многие практики появляются из задач, которые людям приходится решать вместе.

Как организовать проект, чтобы несколько команд могли спокойно в него коммитить? Как сделать правки понятными на ревью? Как не положить соседнюю фичу? Как держать нагрузку и при этом не превратить каждую доработку в раскопки?

Бизнесовые требования, перформанс, баги и командная работа заставляют искать решения. Кодинг помогает их обкатать, но сама потребность в новых подходах, стандартах возникает гораздо раньше.

Когда значительную часть кода генерит ИИ, эти задачи остаются. Кто-то всё равно должен разобраться в проблеме, предложить подход, проверить его в деле и объяснить, где он вообще уместен.

Мне кажется, дальше большую роль в этом может играть опенсорс-сообщество. По аналогии с сообществом вокруг Linux: люди предлагают изменения, обсуждают, ревьюят и допиливают вместе.

Представляю это как открытый репозиторий с проверенными решениями: примерами кода, паттернами, бэст практис, ограничениями и объяснениями, почему сделали именно так.

Кто-то приносит решение из реального проекта. Другие находят слабые места, предлагают фиксы, обкатывают на своих задачах. Постепенно удачные подходы приживаются, а часть становится стандартами.

И уже от таких репозиториев могут «кормиться» нейронки и инструменты для разработки: получать актуальные примеры, правила и доку. Не обязательно ждать, пока новый подход попадёт в очередное обучение модели: его можно подкинуть инструменту как контекст проекта.

Это моя гипотеза о том, как может быть устроен процесс. При этом вполне могут существовать разные сообщества и наборы практик под разные задачи. Энтузиасты, которым нравится писать код руками и экспериментировать, тоже никуда не денутся. Как и разработчики, которые будут проверять новые идеи с помощью ИИ.

А ответственность за конкретную систему останется у тех, кто её разрабатывает и выкатывает в прод.

Поэтому архитектура, KISS и DRY сохраняют смысл. Даже если модель способна работать с огромным файлом, команде всё равно нужно понимать, как устроена система и что изменится после очередного мержа.

В два часа ночи, когда лежит прод, хочется быстро найти причину и починить. Особенно если вообще-то у тебя нормированный рабочий день.

С перформансом та же история. Можно попросить ИИ переписать проблемный кусок, но сначала нужно понять, почему он тормозит. А потом проверить, помогли ли изменения. Единый кодстайл сам по себе этого не гарантирует.

Поэтому умение генерить код не отменяет необходимости понимать базу. Чем проще получить реализацию, тем важнее уметь оценить её качество. И здесь вспоминается знакомое: «Зачем это спрашивают на собесе? В работе это не нужно».

Не каждый вопрос на собесе полезен. Но и «я с этим не сталкивался» ещё не означает, что знание бесполезно. Привычка забивать на базу может стать уязвимостью, когда твоя работа всё больше связана с проверкой чужих решений - в том числе сгенерированных.

Как раз о тех, кто отмахивается от основ со словами «в работе это не нужно», и поговорим в ближайшем посте.