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

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

А теперь — кажется — начинается новый виток. Благодаря вайб-кодингу требование к читаемости кода можно будет исключить. Главное — понятная декомпозиция и покрытие тестами. Почему? Сейчас расскажу, как я к такому выводу пришёл.

Для начала: вайб-кодинг, о котором я говорю — это такой вайб-кодинг, который научились нормально применять в продакшне. «Нормально» — это не просто «нажал кнопку, получил код», а полноценный TDD-процесс:
1. Объясняем AI, что нужно сделать — в продуктовом смысле.
2. Вместе с ним описываем сущности, генерим объявления: без логики, только структура.
3. Пишем тест-кейсы, валидируем их, просим написать тесты, принимаем.
4. Запускаем агента, который пишет код, проходящий эти тесты.

Отдельно уточню: в идеале тесты — это не только юнит-тесты, но и e2e, интеграционные и даже нагрузочные. Не влезая в код, нам всё же нужно убедиться, что мы не забиваем гвозди микроскопом.

Теперь представьте, что мы уже живём в этом вайб-кодинг-будущем. Код покрыт тестами. Требования описаны. Надо добавить фичу? Мы не лезем в код — мы добавляем тесты, описываем поведение и просим AI перегенерировать весь код так, чтобы все требования были выполнены, то есть все тесты — пройдены.

— Никаких рефакторингов.
— Никаких разборов старого кода.
— Никаких «ой, а как тут всё устроено?».

Больше не нужен читаемый код!

Упрощает ли это разработку от и до? — Не факт.
Ускоряет ли написание кода? — Да, определённо.
Требует ли чётких требований? — Безусловно.
Нужно ли понимать QA и архитектуру? — Да, и достаточно глубоко.

И, блин, мне нравится этот мир. Всю свою менеджерскую карьеру я челленджил архитектуры и подходы к тестированию. Возможно, по фану, возможно, потому что я контрол-фрик. А теперь это можно делать прямо в чате с LLM. И все мои знания по ООП, проектированию, тестированию теперь действительно нужны. А вот код, который я много лет не писал для настоящего продакшна, — писать не нужно. Максимум — читать с помощью LLM. Но если этот код реализует мои идеи, то почему бы и не прочесть?