Статья написана на основе интервью с Дмитрием Галагановым, бэкенд‑разработчиком, тимлидом и архитектором ПО.
Пятнадцать лет я писал код руками. Был тимлидом, вёл команды по восемь‑десять человек, успел поработать и в Минцифре, и в структуре «Газпрома».
А в начале этого года я уволился из найма и ушёл в исследование возможностей ИИ в разработке.
За полгода я собрал несколько продуктов, здесь упомяну три. Телеграм‑бота я написал за одиннадцать часов, а систему защиты кода от копирования делал несколько месяцев. Но даже это вышло быстрее, чем справилась бы целая команда. Поначалу казалось, что возможностям нейросети нет предела.
На деле за эти полгода я трижды менял подход к работе с ИИ, а первые проекты выкидывал и переписывал с нуля. Один проект и вовсе провалился из‑за нехватки предметной экспертизы, но об этом в конце.
Хочу поделиться с вами тем, как менялся мой подход на примере трёх проектов: какими моделями и инструментами я пользовался и в каких задачах нейросеть оказалась бессильна.
Начинал с «сделай мне проект»
Начинал я банально, как любой новичок. Открываешь чат, пишешь «сделай мне приложение, которое делает то‑то и заработает мне много денег», и нейросеть через минуту уже бодро строчит код. Первое впечатление сносит крышу: за вечер собирается то, на что раньше уходила неделя.
Я этот восторг хорошо помню, даже пару музыкальных альбомов тогда сгенерировал, просто ради интереса.
Держится восторг до того момента, пока проект простой и помещается в голову целиком. Как только появляется бизнес‑логика, десяток кусков, завязанных друг на друга, и требования к безопасности, тебя потихоньку приземляет.
Нейросеть забывает, что писала час назад, ломает то, что уже работало, и уверенно выдаёт то, чего в проекте нет. Это мой первый блин: ранние проекты я переписывал невероятное количество раз.
Ломалось всё главным образом потому, что нейросеть не удерживала проект в памяти целиком. Мне нужно было ей в этом помочь.
Стал писать документацию раньше кода
Я перестал давать нейросети прямые задачи и начал давать ей контекст. Задача — это, например, «сделай вход через телеграм», а контекст — это вся картина проекта вокруг этой задачи, в которую она встраивается. Перед тем как просить хоть строчку кода, я готовлю описание проекта. В него входит:
— стек, то есть на каких технологиях всё работает: язык программирования, база данных и прочее;
— какой нужен функционал;
— из каких блоков состоит система и как они связаны между собой.
Всё это я задаю сам, как архитектор: надиктовываю нейросети и привожу в порядок вместе с ней. Весь свой пятнадцатилетний опыт я складываю в эти документы. Лежат они прямо в проекте отдельными файлами.
На тг‑боте для подсчёта калорий, например, был файл ARCHITECTURE.md на 500 с лишним строк со всей структурой системы, ROADMAP.md с планами развития (что и в каком порядке добавлять дальше) и NUTRITION_DB_PLAN.md под устройство базы продуктов.
Память у нейросети короткая, и работает она в пределах одной сессии. У неё есть так называемое «контекстное окно» — предел того, сколько информации она может удержать одновременно.
Это как длинный разговор на кухне с другом: пока тема одна, собеседник всё помнит, но если три часа говорить обо всём подряд, он начнёт путать, кто что сказал и с чего вы начали.
Раньше мне приходилось каждый раз заново скармливать нейросети весь код проекта и всё объяснять.
Теперь я просто говорю «прочитай документацию», она за пару минут поднимает из этих файлов всю картину и продолжает с того же места.
А если разговор всё‑таки раздувается и нейросеть начинает плыть, я использую функцию компактизации сессии или прошу модель сделать саммари. Она собирает краткую выжимку из переписки, выделяет ключевые решения и контекст, и мы продолжаем работу уже с этой «горячей» выжимкой, очищая память от всего лишнего.
Этот подход я обкатал на тг‑боте для подсчета калорий.
Считать калории вручную муторно, вот я и сделал телеграм‑бота, чтобы убрать эту рутину. Работает он так: фотографируешь тарелку, бот распознаёт блюдо, считает калории и БЖУ и записывает всё в дневник питания.
Нейросети нестабильны: то ответят с ошибкой, то забудут контекст и начнут уверенно выдумывать. А распознавание блюда у меня идёт через запрос к внешней модели — если этот сервис затормозит или упадёт, без подстраховки встанет весь бот.
Чтобы этого не было, я поставил «предохранитель»: если основная модель (у меня это Gemini) начала сбоить, бот без моего участия отправляет тот же запрос другой, запасной модели, и отдаёт пользователю уже её ответ.
Человек сбоя даже не замечает. Поверх стоит проверка ответа на вменяемость: насчитала модель в одной тарелке пять тысяч калорий — бот это пользователю не показывает, а сначала перепроверяет, всё ли верно.
Дальше я добавил обвязку — вспомогательные функции вокруг основной. Сами калории они не считают, но без них бот не выдержит реальных пользователей. Вот что в неё вошло:
— ограничение на число запросов от одного пользователя. Каждый запрос к нейросети тратит токены, а это мои деньги. Без ограничения один спамер за ночь сжёг бы мне токенов на крупненькую сумму;
— защита от подмены инструкций. Иногда пользователь пишет боту что‑то вроде «забудь все прошлые указания и делай, что говорю я», чтобы перехватить управление, — называется это prompt injection. Без защиты бот может на это повестись и перейти под контроль злоумышленника. Эту лазейку я закрыл;
— вход сразу через телеграм‑аккаунт, без отдельной регистрации с логином и паролем.
Базу продуктов на восемь тысяч позиций я взял из открытого датасета — это готовая бесплатная таблица, где для каждого продукта указан его состав: сколько калорий, белков, жиров и углеводов.
Датасет американский, на английском, поэтому названия всех восьми тысяч позиций я одним прогоном через ИИ перевёл на русский.
За одиннадцать часов я собрал первый MVP, рабочую основу, которую можно запустить и пощупать, ещё без админки и оплаты.
Полную версию, с админкой, дневником и оплатой, я добил примерно за месяц. Командой без нейросетей такой продукт собирали бы, думаю, несколько месяцев: фронтендер на интерфейс, бэкендер на сервер и логику, архитектор на общую связку.
FoodKalor — небольшой проект. Но чем крупнее становились следующие проекты, тем чаще новая функция начинала противоречить старой, и моей системы документации уже не хватало.
Я стал искать, как навести порядок, и нашёл подход, который меня заметно продвинул.
Разработка от спецификаций
Я перешёл на разработку от спецификаций. Помог инструмент Spec Kit, это открытый проект GitHub. Идея в том, что под каждую новую возможность продукта сначала составляется спецификация, и только потом, по готовому описанию, строчим код.
Спецификация (спека/спеки) — это, по сути, подробное техзадание простым языком: что делает пользователь, что система выдаёт в ответ и как ведёт себя в разных ситуациях.
Например: «пользователь присылает фото блюда, система распознаёт состав, считает калории и сохраняет в дневник».
Внутри Spec Kit команды идут по порядку. Сначала я задаю проекту конституцию — набор главных принципов на весь проект: например, «никакие данные пользователей не уходят в облако» или «новые версии не ломают то, что уже работает у людей».
У меня лежали, например, «Ent ORM — единственный источник схемы базы данных», «Tailwind CSS 4 — единственный источник стилей», «строгий контроль доступа на бэкенде». Чем жёстче рамки, тем меньше у модели соблазна сочинить собственную архитектуру.
Дальше команда specify записывает, что я хочу построить, команда plan превращает это в технический план, а tasks дробит план на мелкие задачи.
Но больше всего мне нравится команда clarify, если по‑русски — «уточнение». Прежде чем писать код, нейросеть перечитывает все мои спецификации и ищет в них двусмысленности и логические дыры.
Её цель — «найти неявное и сделать его явным». Если модель видит, что задачу можно решить двумя путями, она останавливается и спрашивает меня, вместо того чтобы гадать.
К примеру, на проекте с внутренним чатом она переспросила: сообщения должны приходить мгновенно или можно с задержкой в пару секунд, раз пользователей немного? И может ли главный администратор сам писать в чат или только следит за порядком?
Раньше в таких местах нейросеть придумывала отсебятину, а тут остановилась и спросила.
После этого хаотичная разработка превратилась в управляемый процесс, и галлюцинаций почти не стало. Контекст теперь строго структурирован, и модели не остаётся пространства для «креатива».
Когда план разбит на двадцать‑пятьдесят мелких задач, где у каждой указан файл, нужные строки и что именно вписать, написание кода — это простое исполнение инструкции.
Впервые я применил этот подход посреди уже начатого проекта — транскрибатора для бизнеса.
Транскрибатор, который не отправляет записи в облако
Транскрибатор я делал под конкретную боль бизнеса. Почти все сервисы расшифровки отправляют ваш файл на чужие облачные серверы, OpenAI или Google, а многие ещё и оставляют за собой право учить на нём свои модели. Для интервью, переговоров и всего, что идёт под NDA, это недопустимо, а в России ещё и упирается в закон о персональных данных.
Поэтому я собрал свой сервис. Клиент пишет телеграм‑боту и присылает запись, она приходит ко мне на сервер, и там её расшифровывает открытая модель Whisper Large‑v3. Распознаю я на своём сервере: запись не уходит в чужое облако вроде OpenAI или Google и удаляется сразу после сдачи работы.
Файл можно даже не загружать, достаточно прислать боту ссылку на видео с YouTube или VK и система сама его скачает, потом расшифрует.
Начинал я с чернового прототипа на Gradio — это конструктор, на котором за вечер собираешь работающий интерфейс, чтобы проверить идею. Вышло всего 250 строк.
А когда стало ясно, что из этого получится полноценный продукт, я переписал всё заново и в середине этой переделки как раз перешёл на спецификации и Spec Kit.
На этом проекте нейросеть пару раз крупно ошиблась, что пришлось чинить руками.
Первая проблема. Модель распознавания речи в местах, где на записи тишина или фоновый шум, начинала выдумывать слова, которых никто не говорил.
Для протокола переговоров это брак. Я нашёл причину и поставил фильтр по громкости: он отрезает совсем тихие куски записи ещё до того, как они попадут в модель, и домысливать ей становится не из чего.
Вторая проблема. Оказалось, научить систему качественно различать, кто из участников говорит, не так уж просто. Это называется диаризацией. Готовая библиотека Pyannote в сложных переговорах путалась: то склеивала двух человек в одного, то одного дробила на нескольких.
Я решил это через цифровой отпечаток голоса — на профессиональном языке это векторные представления, эмбеддинги.
Каждый кусочек записи система переводит в набор чисел, который описывает, как звучит голос. У одного человека эти наборы похожи между собой, у разных людей отличаются.
Я сгруппировал кусочки по схожести, и система стала увереннее раскладывать реплики по спикерам.
Сейчас система расшифровывает час записи минут за десять‑пятнадцать. А я ещё помню время, когда часовую запись отдавали человеку, и он сидел над ней полдня.
Под каждую задачу — своя модель
Я не искал одну идеальную нейросеть, а раздал работу нескольким: у каждой свои сильные стороны.
На сложной логике и больших кусках кода из облачных моделей лучше всех Claude Opus — у него самый чистый и аккуратный результат, но и стоит он дороже.
Gemini быстрый, но торопыга: упрется в проблему — норовит влепить костыль вместо нормального решения и иногда решает что‑то за меня там, где стоило спросить. Так что за ним приходится следить.
Если попросить Opus сходить в магазин за хлебом, он проверит погоду, оденется по погоде, выйдет и закроет за собой дверь, спустится по лестнице и сходит в магазин. Цель выполнить задачу последовательно и учитывая детали.
Gemini 3 Flash скорее всего ломанется в окно, потому что так быстрее. Это не проблема, когда ты пишешь скрипт мониторинга локального сервера, но катастрофа, когда нужно реализовать чистый use case пользователя, учесть ролевую модель и бизнес логику.
Мелочь вроде разового скрипта, который раз в день чистит мусор в базе, можно отдавать Qwen или GLM, они дешёвые (обе китайские: Qwen у Alibaba, GLM у Zhipu).
Торопливость Gemini, кстати, не отменяет пользы от clarify: эта проверка ловит непонятки в самом плане, ещё до кода, а костыли модель может выдать уже на ходу, когда пишет. Это разные стадии.
Когда раздаёшь задачи нескольким моделям сразу, упираешься в проблему: у каждого провайдера свой аккаунт, свой ключ и своя оплата.
А я в пределах одного дня переключаюсь между Claude, Gemini, Qwen и GLM, да ещё держу в боте FoodKalor предохранитель (тот, что при сбое Gemini сам отправляет запрос запасной модели).
Подключать каждого провайдера по отдельности — это на каждого заводить свой аккаунт и оплату, а потом в коде держать у каждого свой ключ и формат запроса. Неудобно.
Поэтому ко всем облачным моделям я подключался через агрегатор, выбрал Polza.ai. Это одна точка входа: платишь в одном месте, одним ключом получаешь доступ сразу к десяткам моделей.
Модель в запросе указывается по имени, так что сменить её быстро — просто поправить одну строку в конфиге или выбрать другую модель в интерфейсе агента.
По той же причине у меня и предохранитель в боте собрался легко: чтобы переключиться на запасную модель, ему достаточно подставить другое имя в тот же запрос.
Да и в России сейчас напрямую зарубежному провайдеру картой заплатишь далеко не везде, а тут платёж рублями в одном месте.
Лично для меня удобство заключается в едином доступе. Я начинал с другого агрегатора, потом сравнил с Polza: у неё токены выходили дешевле, на ней и остался.
Но объёмы на других проектах у меня росли. За сутки через модели проходит огромное количество кода, и на облачных моделях при таких объёмах счёт шёл на десятки тысяч рублей в день.
Тогда я перенес основную работу на локальные модели — те, что стоят прямо на моём сервере и работают без интернета.
Ещё полгода назад они заметно уступали облачным, но Gemma и Qwen за последнее время так подтянулись, что на многих задачах я уже не вижу разницы с облаком. При этом денег они почти не требуют, плачу только за электричество.
Локальные модели делятся на два типа: одни отвечают умно, но медленно, другие — быстро, но попроще. Зависит это от того, как модель устроена внутри, и тут бывает два типа.
Только не запутайтесь здесь: речь не про разные версии одной модели, вроде Claude Opus и Claude Sonnet, — это просто модели разного размера. Речь про то, как устроена одна конкретная модель.
Первый тип — «плотные» модели (Dense). Над любым ответом такая модель работает целиком, используя весь свой «мозг» сразу. За счёт этого отвечает умно и аккуратно, но медленно: каждый раз надо задействовать всю модель.
У меня это Gemma 31B и Qwen 27B. Они используют все свои параметры для каждого ответа.
Второй тип — «смесь экспертов» (Mixture of Experts). Внутри такая модель поделена на множество частей‑специалистов, и на каждый запрос включаются не все, а только те части, что нужны под конкретную задачу, остальные не участвуют напрямую.
Работает кусок модели, а не вся целиком, поэтому отвечает она заметно быстрее, но в среднем чуть менее продуманно.
Из MoE у меня крутятся Gemma 26B A4B и Qwen 35B A3B.
Это не настройка, которую можно переключить, а два разных способа собрать модель, заложенных ещё при создании.
Бывает, делают оба типа: у Alibaba есть и плотный Qwen, и Qwen в варианте «смесь экспертов», у Google то же самое — Gemma выходит и плотной, и в MoE‑версии.
На моём сервере плотная модель выдаёт около 8 токенов в секунду, «смесь экспертов» — около 50. На каждый токен у неё уходит меньше параметров, поэтому она быстрее, но думает чуть поверхностнее.
Поэтому планирование, где надо держать в голове всю картину, я отдаю умной и медленной модели, а готовый план по мелким шагам — быстрой: тут уже думать не надо, а просто исполнять.
Облако теперь подключаю точечно. Например, посоветоваться по свежим версиям библиотек, поискать на форумах обсуждение какой‑нибудь технической проблемы или узнать, какие под задачу уже есть готовые решения.
Платформа, которая прячет код от копирования
Самую сложную задачу я притащил с прошлой работы. Весь свой опыт разработчика писал в основном на PHP — это язык, на котором держится огромное количество бизнес‑систем.
У него есть особенность. PHP — интерпретируемый язык. Если совсем точно, он сначала компилируется в промежуточный байт‑код, но клиенту всё равно уезжают те же файлы с исходным кодом, которые написал программист.
Открыл файл — видишь весь исходник и можешь его скопировать. У компилируемых языков вроде C++ или Go иначе: программа превращается в машинный код. Восстановить из него исходник тоже реально, но долго и дорого — а PHP‑код читается и копируется без всяких усилий.
Пока программа работает на твоём сервере, эти нюансы неважны. Но как только клиент по соображениям безопасности забирает программу на свои серверы, ты отдаёшь ему все исходники.
Любой его штатный программист может их прочитать, скопировать, отключить проверку лицензии и развернуть сколько угодно копий, а ты об этом даже не узнаешь.
На прошлом месте работы я эту проблему уже решал, но в тех рамках, что ставила компания: она разрешала не любые средства.
Мы прятали программу внутри виртуальной машины — это образ целого компьютера со всем нужным ПО, который запускается как программа поверх настоящего.
Код лежал внутри в зашифрованном виде, а расшифровывался только при запуске и наружу не отдавался, так что вытащить исходник нельзя даже с правами администратора.
Способ рабочий, но громоздкий — клиенту приходится держать у себя тяжёлый софт, появляются проблемы с обновлением.
Решение этой проблемы нужно любому, кто продаёт свой софт и ставит его на чужие серверы. В госструктурах и банках задача ещё жёстче: там запрещено доустанавливать сторонние расширения, а западные защитники вроде ionCube без своего расширения не работают, плюс платить им можно только в долларах.
Уволившись, я первым делом захотел сделать то же самое, но без виртуальной машины и без чужих расширений. Готового такого решения в России я не нашёл, а спрос на него есть.
Работает оно так. Вся программа собирается в один файл, код внутри зашифрован и расшифровывается только в оперативной памяти на время работы, на диск не попадая, поэтому скопировать исходник нельзя. Лицензия привязана к серверу клиента и продлевается по подписке.
Вдобавок программа при запуске сама проверяет, что её не подменили, не даёт залезть в себя отладочными инструментами и держит ключи в защищённой памяти.
Получилась целая платформа для тех, кто продаёт софт: собрать защищённую версию, выдать лицензию под конкретный сервер, продлевать подписку.
Командой такую систему собирали бы месяца четыре, а то и полгода, с отладкой и багами. Я допилил её один за несколько месяцев.
Это был мой самый сложный проект, ещё до внедрения спецификаций и перехода на локальные модели: писал я его обычными промптами, без Spec Kit. Моделей перепробовал много — сложную архитектуру доверял самой умной, Claude Opus, а рутину раздавал быстрым и дешёвым, все через агрегатор Polza.ai.
Но был и проект, который я так и не смог доделать, хотя код был готов хоть завтра.
Где ИИ оказался бесполезен
Один мой знакомый держит типографию, и мы не раз подступались к системе, которая автоматизировала бы его работу. Технически собрать такую систему я могу. Но до кода дело даже не дошло: описать, как именно устроена работа типографии, оказалось некому.
Там десятки станков, каждый делает своё, заказы надо распределять между ними с оглядкой на то, какой станок свободен, какой чем можно заменить, а какой незаменим.
Вся эта логика — в голове у владельца, но переложить её в понятные алгоритмы он не может: он отличный производственник, но не IT‑архитектор. А я — инженер, но не специалист в типографике.
Я подступался к этой системе ещё раньше, привлекал отдельного аналитика, чтобы тот описал требования, и всё равно за несколько месяцев у нас вышел только пустой дашборд без логики.
Когда появился ИИ, мы попробовали снова. За несколько дней я собрал красивую версию с графиками, но она оказалась бесполезной, потому что внутри была моя выдумка, а не реальные процессы типографии.
Нейросеть отлично пишет код, но она не выяснит за тебя, как должен работать твой бизнес. Если этого знания нет, не поможет никакой ИИ.
Между нами как раз и не хватало системного аналитика — человека, который вытянул бы все процессы из головы владельца и превратил их в чёткое техзадание.
Зато там, где задача простая и понятная, ИИ незаменим. Знакомому прорабу понадобился сайт‑визитка и телеграм‑бот для заявок — я собрал и развернул всё это за неделю (чистой работы там было вечера три).
Чем сложнее продукт и тоньше логика внутри, тем больше зависит от инженера и от того, кто способен внятно описать, что вообще нужно.
Отсюда же моё отношение к вайбкодингу, когда человек просто работает по схеме «промпт, код, результат», не понимая, какой код у него получается и почему. На простой одноразовой задаче это ок.
Но на сложной системе так копится техдолг — гора запутанного кода, в которой со временем новые функции ломают старые, ошибки не находятся, и проект приходится либо переписывать заново, либо бросать целиком. Для бизнеса это потерянные деньги и время.
Что я понял за полгода исследований
Нейросеть ускоряет разработку. Она даёт одному специалисту вытянуть работу, на которую раньше уходила целая команда. Но только когда этот специалист понимает, что и зачем он делает.
Сам по себе инструмент не спроектирует архитектуру и не разберётся в чужом бизнесе, а за безопасность по‑прежнему отвечает инженер.
В Минцифре мы когда‑то делали портал для Министерства сельского хозяйства Московской области, который соединял фермеров и точки сбыта; я был архитектором и тимлидом этого проекта.
Команда выросла до восьми человек, работа заняла около года, и немалая часть этого года ушла на согласования и созвоны, которых нет, когда работаешь один.
Сегодня любой инженер, который освоил работу с нейросетями, сдал бы подобный портал в одиночку месяца за два‑три.
Я думаю, нынешняя эйфория вокруг ИИ скоро пройдёт. Через полгода‑год компании снимут розовые очки и начнут нанимать тех, у кого есть инженерный опыт, наработанный ещё до нейросетей, и кто при этом научился этими нейросетями управлять.
Уметь красиво формулировать промпты для этого мало.
Спасибо, что уделили время моей истории. Надеюсь, было полезно или хотя бы интересно. Удачи в разработке!
Заходите в чат Polza.ai — там чинят упавшие связки n8n с нейросетями и обсуждают модели. Приносите свой кейс.
Автор: polza_ai
