ИИ в разработке — год спустя

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

Ниже — то, к чему я пришёл на практике. Это не universal truth, а мои рабочие правила.

Что работает

Держать себя архитектором, а ИИ — исполнителем. Решение о том, какие у системы границы, какие сущности и как течёт состояние, остаётся за мной. ИИ отлично разворачивает уже принятое решение в код, но доверять ему сам выбор решения — значит получить правдоподобную архитектуру, которую невозможно сопровождать. Я формулирую намерение, он предлагает реализацию, я решаю.

Узкие циклы обратной связи. Чем меньше шаг, тем лучше результат. Большой расплывчатый запрос даёт большой расплывчатый ответ, в котором легко спрятать ошибку. Маленький запрос с понятным критерием «готово» — проверяемый. Я скорее проведу ИИ через десять маленьких шагов, чем поручу один большой.

Незнакомый стек и черновики. Войти в новую библиотеку, набросать первый каркас, получить три варианта подхода, объяснить чужой код — здесь ИИ экономит часы. Скорость входа в новое для меня выросла кратно.

Типы и тесты как ограждения. Здесь функциональная привычка окупается напрямую. ИИ любит писать правдоподобный код — он выглядит правильным, компилируется в голове, но разваливается на краевом случае. Строгие типы, явные состояния и тесты ловят это раньше меня. У строгости могут быть разные уровни строгости — и тут я для себя различаю три уровня.

Три уровня надёжности

Я выстраиваю для себя три уровня надёжности в построении современных систем.

TypeScript — первый рубеж. Уже лучше, чем чистый JavaScript: ловит большой класс ошибок ещё до запуска. Но может пропустить и часть — состояния, которые были плохо описаны или под которые попросту не построили тип. К тому же TypeScript нужно настраивать, и корректная работа сама по себе не гарантирована. Он снижает вероятность ошибки, но не отменяет её.

Effect-ts — тот же TypeScript, но внутри философии. А именно — effect-типов: состояния описаны явно, ошибки явно выделены в типе (а не прячутся в исключениях), а pipe-driven development упрощает сборку сложных систем. Вокруг — довольно развитая экосистема полезных библиотек, и подходит это в том числе для бэкенда. Это уже не «типы как подсказки», а типы как способ проектировать.

Elm — гарантия корректности на уровне компилятора. Высший для меня уровень: если компилируется — значит работает. Нет null и undefined, есть чёткие типы и границы, есть архитектура TEA — по ней собирается компонент любой сложности. Большая экосистема как альтернатива npm, строгое версионирование, на редкость чёткие и понятные сообщения об ошибках — настолько, что разработку можно вести прямо на уровне compiler-driven development. Цена — нишевость: в коммерческой разработке Elm пока используется редко. Но, возможно, в эру LLM что-то изменится: когда код пишет машина, язык, который физически не даёт ей собрать неверную программу, стоит куда дороже.

Чего я не делаю

Не отдаю понимание. Если я не могу объяснить строку, я её не мёржу. Соблазн принять работающий код, который ты не понимаешь, — самая дорогая ловушка: долг копится не в коде, а в голове, и проявляется в тот момент, когда что-то ломается, а разобраться уже некому.

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

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

Что под этим лежит

Год работы с ИИ не отменил инженерию — он сместил её центр тяжести. Механическая часть — набор кода — подешевела почти до нуля. Подорожало всё остальное: умение поставить задачу, выбрать границу, заметить, что правдоподобный ответ неверен, и взять на себя ответственность за результат. Это ровно те навыки, которые ИИ пока не умеет, и именно они теперь отличают сильного инженера от слабого.

Поэтому я не боюсь, что ИИ заменит разработчиков. Я думаю, он заменит тех, кто относился к разработке как к набору кода. А тех, кто относился к ней как к проектированию, — сделает заметно сильнее.