Как я пишу адекватный код с помощью ИИ

Продолжаю беседы с нашим тимлидом Дмитрием. Сегодня о том, как ИИ врывается в мир разработки и меняет процесс написания кода. Какие можно использовать подходы, чтобы этот код в итоге был адекватным?

Разработчики нейросетей активно распространяют идею, что они могут сгенерировать код, объяснить сложный алгоритм, предложить архитектурное решение и помочь с отладкой. Однако, само по себе наличие ИИ-инструмента не гарантирует ни качества кода, ни роста продуктивности. Более того, при неумелом использовании нейросети легко превратить проект в набор плохо связанного, трудно поддерживаемого и потенциально небезопасного кода. А есть ли умелый способ?

2025 год был насыщен новинками ИИ. На мой взгляд, самый значимый запуск среди кучи всего прикольного произошел в сентябре – вышла Claude Sonnet 4.5 версии. Эта модель сильно повлияла на индустрию разработки. И думаю, это только начало.

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

Подтолкнула к изысканиям меня одна история.

Поскольку я участвую в пресейлах с клиентами, собеседую кандидатов к нам в компанию, да и в целом много общаюсь внутри отрасли, через меня проходит довольно большой поток людей. Поэтому до меня долетает множество разных историй. Одна из них – про новый стартап. Его основатель делает сервис доставки наподобие Яндекса в Казахстане для уже существующей (своей) курьерской службы.

Когда мы говорили с ним в сентябре, планируя расширять штат разработчиков, он не собирался брать тех, кто не использует нейронки для написания кода. С учетом негатива в сторону вайбкодинга, я удивился и обратил внимание на его рассказ.

Через некоторое время мы встретились снова. Он уже активно собеседовал людей и жаловался, что никто в отрасли нормально нейросетями не умеет пользоваться. Рынок еще не переквалифицировался… Но он все еще настаивал на новом подходе к проектированию.

После этого рассказа я начал время экспериментировать с ИИ. Мучения мои продлились, наверное, недели четыре. После чего взялся изучать матчасть вглубь и вширь.

Движемся от проектирования

Я понял, что на качество результата работы нейросети очень влияет подход к проектированию. Писать таким образом код – как разговаривать с джуном, который знает синтаксис языка, но не понимает, как писать правильно, как должны работать микросервисы, как они между собой взаимодействуют в проекте, как все это должно запускаться и т.п. Так что я пошел подтягивать навыки проектирования: изучил подходы к написанию ТЗ, углубился в DDD, BDD, SDD, которые и начал применять, чтобы лучше формулировать задания.

Как в итоге выглядит процесс: я беру какой-то концепт, декомпозирую его в соответствии с моделью C4. А потом начинаю взаимодействовать с нейросеткой.

Помните, как мы создавали системы на блокчейне? Спека должна была стоять во главе угла, поскольку любые изменения в уже запущенную систему внести очень дорого. Смарт-контракты, которые живут в продакшене, уже не остановить. Поэтому спека и контракты должны разрабатываться в первую очередь. Сначала мы описываем их на бумаге, потом пишем спецификации и только по ним код и всю архитектуру. Это Spec-Driven Development (SDD).

Обычно в других сферах разработки все сильно проще. Поэтому требованием сначала писать спеки пренебрегают. Но с точки зрения взаимодействия с нейронкой это очень хороший подход. Если его не использовать – не объяснять нейросети, что нужно на выходе получится как в известной формулировке: “Без ясного ТЗ результат ХЗ”. Это та самая история про написанный нейросетью макаронный код, в котором человеку разобраться уже очень сложно.

Чтобы самому не закопаться в документации, задачу написать спеку тоже можно выдать нейросети, указав, какие при этом нужны API, методы и структуры данных. Ее же можно попросить описать юзеркейсы бизнесовым языком, используя Behaviour-Driven Development (BDD). С Domain-Driven Design (DDD) несколько сложнее. Нейронка в этот подход не умеет, но его можно реализовать руками, грубо говоря, на доске со стикерами или в Miro.

Спеками дело не ограничилось. Я пошел копать дальше и в своих изысканиях наткнулся на ролевые истории, когда ты просишь нейросеть встать на позицию, допустим, DevOps или QA-автоматизатора, и покритиковать только что написанные спецификации. Дошел до того, что в параллели запускал четыре-пять ролей, которые критиковали ТЗ, спорили между собой и пытались прийти к консенсусу. В процессе они подсвечивали целый пул проблемных сценариев ТЗ, указывая доступные варианты решения. Мне оставалось только выбрать тот, что я считал правильным, и дополнить ТЗ. Каждый предметный пункт при этом претерпевал до 10 итераций изменений. И только когда они были все внесены, запускалась разработка.

В целом получалось весьма неплохо. А можно было пойти дальше и вспомнить про более жесткие требования к коду – что есть разные модели структуры данных, чистый код или стандарты его написания (например, PEP8 в Python). Нейросеть можно заставить писать все в соответствии с ними, скормив ей текст правил. Причем, человек, который заявляет, что пишет свой код на основе этих стандартов, скорее всего, сделает это хуже. Нейросеть также можно заставить отрефакторить уже написанный код в соответствии с этими стандартами. Она сделает это минут за 15 – щелк и готово – в то время, как человеку придется долго переписывать весь проект, вложив в это огромный труд.

Первые работающие проекты

Буквально за месяц, набив руку на декомпозиции задач, я написал свой первый проект –прототип игрушки в 2D. На голом движке Pygame герой из зеленых, красных и коричневых квадратов бегал по карте, ставил и разбивал кубики.

Второй мой кейс – за новогодние праздники я написал простое управление складом для своих домашних, которые занимаются изготовлением мерча по играм. Бэкенд на Go, фронт на Next JS. Здесь нейросеть сделала все – написала спецификацию, полное ТЗ и тест-кейсы (обеспечила unit, end-to-end тесты и проверку фронтенда с полным прокликиванием всех сценариев). На сладкое я получил 100% покрытие тестами, чего не добивался в реальной жизни ни в одном проекте.

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

Ложка дегтя – квалификация архитектора

Осознав возможную скорость проектирования, я пробовал запустить все в параллель - четыре нейросети сразу писали код. И все получилось! В теории, если написано ТЗ, я мог бы так озадачить любое количество нейросетей. Потом писать следующее ТЗ и снова запускать модель. Так можно даже прикрывать отсутствие у себя каких-то знаний - по бэку, фронту или тестированию.

Например, QA я более-менее понимаю, бэкенд – тоже, SRE и DevOps навыки у меня отличные и с архитектурой тоже хорошо. Однако закрыть полный цикл разработки без нейросети я не мог, потому что у меня слабые скиллы по фронтенду. Нейросеть помогла компенсировать эту “хромоту” за счет тестов.

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

Плата за доступ

В своих экспериментах я использовал облачные модели. За 5 дней работы (примерно по 6 часов) при создании складского инструмента MiniMax M2.1 потребовала около 2 тысяч рублей. Подписка на Claude Sonnet 4.5 – а сейчас это лучшая нейросеть для написания кода – стоила бы дороже, особенно если брать отечественный платежный шлюз. В зависимости от способа оплаты, потребовалось бы от 4 до 10 тысяч рублей.

Не так давно Nvidia анонсировала свои коробочки для запуска моделей – DGX. Выглядит как неттоп, подключается по сети. По сути, это маленький компьютер, в котором очень много быстрой памяти. Его можно использовать, чтобы запускать нейронную сеть локально, грубо говоря, на своем рабочем месте. Вижу, что аналогичные коробочки выпускает Raspberry Pi, Orange Pi и другие. Но пока ничего из этого нет в продаже в РФ (то, что есть, продается по заоблачной цене).

Это очень напоминает момент, когда молодежь только переходила с кнопочных телефонов на смартфоны и начинала пользоваться социальными сетями. Тогда смартфон как устройство очень удачно попал в тренд и был востребован, именно благодаря соцсетям.

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

Кстати, заплатить придется не только деньгами, но и навыками. Это же все придется поддерживать!

Хорошо описал ситуацию мой коллега, Михаил Евдокимов: “Модель в ноутбуке у Data Scientist'а – это 0% бизнес-результата. Нужен MLOps, который позволит модели работать в реальном мире, под нагрузкой, 24/7, и не деградировать. Обучить модельку – это не так сложно. Вот у тебя модель готова, высокая точность. Но сделать так, чтобы она работала в инфре, чтобы она работала на новых данных и не теряла качество – вот это задача. Внедрить ее так, чтобы люди реально пользовались, чтобы данные корректно подтягивались с 1С-ки и других разных источников, нормально обрабатывались, чтобы ничего не ломалось. Сотрудник случайно вобьет что-то не так в 1С, данные с этой ошибкой подтянутся в модель – произойдет сбой, модель нормально не обучится или выдаст ерунду. А потом модель еще дообучать нужно (потому что мир меняется, жизнь меняется, тренды меняются). А еще модель может начать деградировать со временем. Всё это сделать и заставить работать стабильно – это и есть самая большая задача на самом деле”.

Что в итоге

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

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