Как подсадить разработку на ИИ

“А давайте все с помощью ИИ разрабатывать” — эту фразу в разных вариациях я слышу во многих командах разработчиков. И вижу огромное количество попыток заставить программистов использовать ИИ. Как правило в результате получается одно из двух:

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

2. Программисты имитируют использование или крайне неэффективно используют ИИ, массово жгут токены, и все ради того, чтобы руководство видело красивую картинку, что ИИ якобы используется. Но результаты по-прежнему “так себе” или (что еще хуже) происходит очень кратковременный “всплеск” производительности, но продукт (кодовая база) превращается в помойку, которая со временем становится абсолютно неуправляемой. И в итоге команда приходит к выводу, что ИИ пока рано внедрять, надо еще подождать.

Между тем правильное и грамотное использование ИИ в разработке реально ускоряет выпуск продукта, улучшает его качество и снижает его стоимость. Да, все три параметра (качество, скорость и стоимость) одновременно. И секрет очень прост, ИИ надо использовать грамотно, как любой дорогостоящий и сложный инструмент. В руках дикарей БАК бесполезен, в руках физиков он срывает покровы с тайны мироздания.

Я не буду в этой статье рассказывать про ИИ модели, тулзы и фреймворки и как правильно их использовать. Эта статья в первую очередь для менеджеров, руководителей проектов, CIO, CTO и т.д. Менеджеров, которые нутром чуют, что настало время ИИ, но не знают как подступиться к задаче: “перевести команду разработки на рельсы ИИ”. Я поделюсь своим личным опытом, как это получилось у меня, возможно это будет полезно кому-то еще. Буду благодарен за обратную связь в комментариях.

Пропущу кучу ошибок и пустых усилий, которые не дали в конечном итоге никакого результата и опишу лишь только те действия, которые увенчались успехом и заставили команду перейти в формат: “ни строчки кода руками, все только через ИИ”.

Базово нужно разделить задачу внедрения ИИ в команду на две фазы:

Фаза №1 — снять барьеры и сделать ИИ доступным для команды:

1. Убрать ментальный барьер

2. Убрать технический барьер

Фаза №2 — эволюционно, но с революционной скоростью перейти на ИИ

3. Разделите команду на авангард, центр и арьергард

4. Переводите на ИИ не только разработку, но и аналитиков, тестировщиков и т.д.

5. Используйте ИИ сами, сделайте на нем пару реальных задач

6. Введите метрики использования ИИ командой

Фаза №1 — убираем барьеры мешающие использовать ИИ

Основная задача сделать так, чтобы люди поверили, что ИИ реально работает и его использование не что-то из области “там за горизонтом”.

1. Ментальный барьер

Первый и самый главный барьер, который вам придется убрать — это ментальный барьер. Сейчас (в июне 2026-го года) программисты, в большинстве своем, относятся к ИИ как к прикольной штуке, которая может быть использована для написания MVP, для самообразования, для чего угодно еще, но только не для написания продакшен кода, который должен быть архитектурно правильным, высокопроизводительным, удобочитаемым и далее по списку. И особенно непонятно, как можно в легаси систему вкрячить ИИ, если там его отродясь не бывало.

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

• ИИ может делать только узкий круг задач

• ИИ в конечном итоге сильно дороже, чем сделать все руками

• ИИ превратит наш проект и код в хаос

• ИИ можно использовать только если ты делаешь проект в одиночку

• ИИ нужно использовать только в новом проекте, в легаси он бесполезен

• и т.д. 

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

Расскажу, как одномоментно получилось поменять менталитет в моей команде. Я нашел хорошего знакомого, который успешно пишет код с помощью ИИ и попросил его сделать online демонстрацию его работы. Прям мастер-класс выполнения реальной задачи с помощью ИИ на реальном проекте. Эксперт пришел, показал как он реально работает с ИИ, показал, что больше не пишет ни строчки кода руками. Показал IDE, тулзовины, показал как общается с моделями, как заставляет их проверять результаты друг друга, выбирает лучшие решения, ответил на вопросы. И ментальный слом произошел. Люди увидели, что умный, серьезный человек на большом продакшен проекте давно и успешно использует ИИ и больше не пишет код руками. Программисты уверовали, что можно заставить ИИ работать и больше никогда не писать код руками.

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

2. Технический барьер

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

Берите топовые модели, чтобы точно знать, что ошибка в белковой нейронной сети, а не в силиконовой. Грубо говоря, если ваш программист говорит, что Claude или ChatGPT “гумно”, то вы знаете ответ )).

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

Вывод: дайте людям топовые ИИ модели, чтобы специалисты могли легко и просто начать работать с ИИ.

Фаза №2 — быстро быстро эволюционируем до ИИ экспертов

1. Деление команды

Как и в любом другом деле, ваша команда разделится на три группы:

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

• Арьергард — это те, кто не хочет использовать ИИ, ищет почему это плохо, и всячески саботирует его внедрение. Они не просто балласт, они тянут вас назад, они сопротивляются неизбежным изменениям, стоят на пути прогресса. Про таких индивидов можно (и нужно) сказать команде следующее: “он не любил синематограф ИИ”.

• Основная масса — продемонстрировав на арьергарде кнут, а на авангарде пряник, вы однозначно склоните всю оставшуюся команду в сторону ИИ

Устраивайте для всей команды workshops работы с ИИ. Берите любого вашего авангардиста и просите его показать всей команде как он работает с ИИ. Просите авангардистов делиться опытом и поощряйте их за это. В общем суть понятна, я думаю.

Вывод: всячески поощряйте тех, кто хочет и может программировать с помощью ИИ

2. ИИ нужен не только разработчикам

Одна из главных ошибок, которые я совершил, это то, что пытался вначале только разработчиком заставить работать с ИИ. Но это категорически неправильно. Разработчики получают ТЗ (техническое задание) от аналитиков, а если ТЗ написано для человека, а не для ИИ, то разработчику становится на порядок сложнее использовать ИИ в разработке.

ТЗ которое пишет аналитик, должно соответствовать следующим критериям:

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

б) Обязательно добавьте шаги по валидации того, что должно получиться в итоге. Т.е. буквально если в ТЗ написано, что: “по этой кнопке скачивается файл”, следом должен идти  валидационный скрипт (пользовательский сценарий, use case — как угодно назовите). “Пользователь кликает на кнопку и видит такой-то файл у себя в папке Downloads”. Эти критерии приемки не только позволят ИИ грамотно сгенерить и проверить правильность работы системы, но и позволят тестировщикам и тем же разработчикам писать тесты с помощью ИИ. Особенно полезно если кто-то проповедует TDD (Test-Driven Development).

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

г) И самое главное, по этому ТЗ аналитик должен генерить работающий прототип. Причем прототип этот должен быть в контексте самой системы, т.е. буквально стать частью системы с реальными продакшен данными. Объясню, почему это так. Очень часто после того, как ТЗ согласовано, разработано, протестировано и выведено в продакшен, у заказчика/владельца возникает масса замечаний, хотелок, так как он/она видит как реально работает система. Теперь же, с помощью ИИ этот процесс “прототипирования” можно сделать не на Figma, не на HTML прототипах, а на реальной системе. Да, криво, косо, не оптимально, с багами и ошибками, но это реально работающая функциональность, с реальными данными, которую можно потрогать и исправить требования еще ДО того, как хотя бы одно требование ушло в разработку.

Ну и конечно никто не отменял классического: однозначность, полнота, непротиворечивость, проверяемость, реализуемость. Для ИИ это крайне важно.

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

Не могу раскрывать детали проекта, так как работаю под NDA, но на реально живом примере, когда нам пришла задача запрограммировать 20+ экранных форм и 800+ логических проверок, мы оценили эту работу примерно в 3 месяца для команды из 3-х программистов, по итогу задача была сделана и запущена за 2 месяца 2-мя программистами. Ускорение примерно в ДВА раза.  И это только начало, я вижу как реально растет производительность программистов вооруженных ИИ, что будет через год, если такая тенденция продолжится, мне сложно себе представить.

Вывод: пишите ТЗ в первую очередь для ИИ, люди в этом теперь вторичны. Если ИИ не смог сделать прототип по ТЗ это плохое ТЗ — переписывайте.

3. Hands on — must have

Обязательно поставьте себе Cursor или VSCode + codex или PyCharm + opencode или в чем вы там писали код, когда были простым программистом, а не большим начальником. Попробуйте и ощутите смену парадигмы программирования на собственном опыте.

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

Не попробовав самостоятельно программировать с помощью ИИ у вас не будет никакого морального права заставлять это делать ваших подчиненных. Так что с этого можно в принципе начать )).

Вывод: начните с себя

4. Метрики использования ИИ

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

Второй очевидный способ это конечно “соц. опросы”, такие как:

• какой % кода на прошлой неделе за тебя написал ИИ

• как часто ты используешь режим планирования

• какие модели ИИ и тулзовины используешь для каких задач

• и т.д.

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

Следующий способ отслеживать насколько ИИ используется в команде это разумеется смотреть как меняется (или создается) кодовая база. Сколько в вашем коде появляется md файлов типа: README.md, CONTRIBUTING.md, CONTRIBUTING.md и т.д. Насколько код становится академичным, аккуратным, структурированным, покрытым тестами и т.д. Ваша задаче сделать так, чтобы как можно больше вашего кода стало ИИ читаемым и понимаемым. Тогда разработка с помощью ИИ пойдет значительно быстрее.

В этом месте я бы хотел обратиться к аудитории, а особенно к тем, кто уже давно и успешно пишет код, с помощью ИИ. А какие метрики вы используете, для того, чтобы понять насколько хорошо и качественно ваш проект развивается с помощью ИИ? За чем следите?

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

PS. Осознанно и намеренно не пишу сюда про риски внедрения ИИ в разработку, наверное будет отдельная статья, когда набью шишки. А также не стал утруждать читателя тем, что “НЕ работает” иначе большая статья получается )).