Управление разработкой *

Эта игра получила две номинации IGF, выиграла призы Excellence in Design и Excellence in Audio, вышла на PS3 и PC и собрала хорошие отзывы критиков, а студия, которая её сделала, после успешного релиза фактически развалилась, а один из двух сооснователей выгорел и ушёл в найм. Ни провала, ни скандала, ни закрытого издателя, просто четыре года разработки человеческих жизней были потрачены. Что за игра, если не узнаете, напишу в конце.

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

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

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

Что произошло

Задача: изменить стоимость тарифа подписки.

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

Сценарий звучит экзотично ровно до момента, когда понимаешь, сколько у сервиса таких пользователей. Любой, кто когда-то оформлял подписку и потом отписался, попадает в эту категорию.

За два месяца моя система AI-агентов принесла компании около 350 тысяч рублей дополнительного дохода, и он только растет. Она самостоятельно выполняет задачи в реальных коммерческих проектах, работает с существующими репозиториями и позволяет закрывать часть задач практически без участия разработчиков. С точки зрения бизнеса эксперимент оказался успешным, а с инженерной точки зрения у меня накопилось достаточно претензий к собственной архитектуре, чтобы начать разработку новой системы.

Обычно истории об AI-агентах строятся вокруг их возможностей: какую модель использовали, сколько агентов запустили и какие задачи удалось автоматизировать. Но в коммерческой разработке рано или поздно возникает более приземленный вопрос: какую пользу все это приносит компании? Мне удалось получить на него вполне конкретный ответ, а заодно выяснить, что работающий продукт и надежный продукт далеко не всегда одно и то же.

Агента сегодня можно собрать за вечер: длинный промпт, пара инструментов — и он что-то делает. Сложности начинаются потом: поведение нельзя проверить, любая правка промпта что-то ломает, а на вопрос «почему он так сделал?» ответа нет.

В этой статье разберём, как спроектировать агента как инженерный объект: со спецификацией, тестами, ограничениями и метриками. Подход собран из Spec-Driven Development (SDD), моделей зрелости и автономности агентов и практики команд, которые уже внедряли агентов в разработку.

Для кого: разработчики и тимлиды, которые уже работают с Claude Code, Cursor или другим агентом и хотят сделать своего — для конкретной задачи команды.

Сквозной пример: агент-ревьюер, который проверяет pull request на соответствие спецификации фичи (spec.md) и оставляет отчёт. Он полезен сам по себе, и на нём хорошо видны все слои: чтение данных, действия с последствиями, эскалация к человеку. Примеры файлов даны в формате Claude Code, но подход переносится на любой инструмент.

Что получится в конце: шесть файлов-артефактов (конституция, спека агента, скилы, эталонные примеры, правила доступа, метрики).

В прошлой статье я писал про GitBor, git-клиент, через который я проверяю, что на самом деле наворотил ИИ-агент. Эта статья про самого агента. Делал я их параллельно. Один инструмент пишет код, второй показывает, что получилось.

Корпоративная модель у нас хорошая, но контекст около 100 тысяч токенов, а популярные агенты тратят его не задумываясь. Рассказываю, как переделал агента под закрытый контур: экономия контекста, несколько задач во вкладках, голосовой ввод без интернета — и почему расширение для VS Code прошло туда, куда программу с ИИ не пустили.

Картина знакома почти каждому, кто работал в команде ИТ‑департамента внутри компании. Задачи прилетают в мессенджер конкретному аналитику/программисту, приоритет определяется громкостью заказчика, доработки проверяются прямо в рабочей базе. Бизнес недоволен скоростью и качеством, ИТ — бесконечными пожарами и невозможностью что‑либо планировать и распределять ресурсы.

При этом все понимают,что необходимы изменения и организация рабочих процессов.

Почему же ничего не меняется? Неожиданный ответ мне подсказала теория игр (спасибо университету за это!) и она же подсказывает, как из этой ловушки выбраться.

На самом деле история началась не с Rust. Наша система управления корпоративными устройствами обслуживает более 200 тысяч Android-устройств. Для нового контура связи понадобился прокси, а команда оценила его разработку и функциональные тесты примерно в 12 недель. Я собирался использовать ИИ как план Б – подготовить прототип и передать разработчику, но постепенно он стал основным инструментом работы – примерно за 30 часов активных итераций мы получили версию, готовую к нагрузочным испытаниям.

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

Как мы выбрали решение, адаптировали статусы под внутренний процесс и поняли, что главное - не картинка, а управление рекомендациями

Привет, Хабр! Меня зовут Алексей Бубликов, я Solution Architect в Банке Уралсиб.

Я вам расскажу как в банке превратили хаос технологических решений в управляемый процесс. Раньше перед стартом проекта приходилось собирать контекст по крупицам: десятки ссылок, мнения архитекторов, старые Wiki и презентации, а в ответ на вопрос «что рекомендуем?» - фраза «лучше уточнить у команды». Вместо красивого списка технологий банк получил живой процесс управления техрекомендациями: инициатива → экспертная оценка → решение → публикация → обратная связь → пересмотр.

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

Большинство руководителей подсознательно воспринимают барьеры (silo, изолированное подразделение, зернохранилище, бункер, силосная башня) как что-то ПЛОХОЕ, а взаимодействие — как нечто ХОРОШЕЕ. А эта публикация выступает в защиту барьеров и ставит под сомнение ценность межкомандного сотрудничества.

Перед вами не гайд из разряда «10 шагов к идеальному кастдеву». Я не планирую в сотый раз объяснять, что такое Customer Development или клиентское интервью. Лучше расскажу, как это выглядит на практике, где я ошибалась, паниковала, а потом вдруг перестала воспринимать процесс как экзамен и начала получать от него реальную пользу. Выводы в статье сделаны на основе моего трехлетнего опыта в «Онланте».

Для тех, кто только знакомится с темой, коротко: кастдев – это не опросник «Понравилось ли вам». Это разговоры с реальными или потенциальными пользователями, чтобы понять их контекст, скрытые боли и готовность менять стандартизированные вещи. Без этого этапа продукт часто превращается в красивое решение для проблемы, которую никто не формулировал. Поначалу, кстати, интервью и у меня вызывали ломку и отрицание. Но обо всем по порядку.

У меня немного подгорела жопа, простите. Это случилось давно, поэтому постараюсь быть объективным.

Мы тут ворвались с ноги в банк и написали АБС. Это, если что, ядро банка. Я рассказывал, что мы были отвлечены от облака корпоративными проектами, так вот это один из них. Про то, что там под капотом, расскажу позже отдельно — сейчас система на стейджинге и будет там ещё где-то полгода минимум, но базовый функционал уже работает.

Но сегодня не про это.

Если вы делаете проект такого масштаба в корпорации — тем более в банке, — то внезапно может выясниться, что вам там не очень-то и рады.

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

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

Я знал, что так будет, но не ждал, что там всё настолько нагло.

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

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

В 2022 году Jira официально прекратила работу в России. Несмотря на это, многие компании продолжают использовать зарубежный сервис для управления ИТ-проектами в «сером» контуре: технически сервис доступен через удаленные серверы или ранее активированные лицензии. Есть ли смысл искать замену и в сторону каких ИСУП смотреть? Делимся опытом одного из наших заказчиков.

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

***

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

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

Наблюдая за этим, я задаюсь вопросом: где в такой конфигурации будет место разработчика через пару лет?

Мы разработали Stenograf - приложение, которое записывает локальное аудио, преобразует в транскрипт, создает короткое содержание встречи и структурирует память. Речь распознаётся не покидая устройство, можно задать вопрос по сохранённым заметкам и этот функционал тоже не покидает ваше устройство.

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

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

Джун закрывает задачи быстрее, PR проходят ревью, метрики радуют руководителя. Но на первом серьёзном инциденте выясняется, что разработчик с трудом понимает устройство сервиса, над которым работал несколько месяцев. Разбираемся, как AI‑агенты меняют привычный процесс обучения новичков, какие ошибки допускают руководители при онбординге и что поможет вырастить самостоятельных инженеров.

15 октября 2026 года в Москве в кластере «Ломоносов» и в онлайн-формате состоялся масштабный форум о проектировании, цифровизации и инновациях в строительстве «СИЛА ПЛАТФОРМЫ». Мероприятие собрало 1450 очных участников и несколько тысяч зрителей онлайн-трансляции.

Форум представил участникам актуальную картину цифровизации строительной отрасли: с какими инструментами работают передовые проектные компании, как российские решения применяются на реальных объектах и для каких прикладных задач инженеры уже сегодня используют искусственный интеллект. В деловой программе прозвучали десятки практических кейсов от команд Сбера, ДОМ.РФ, ПИК, Sminex, MARKS GROUP, ФСК, Росатома, Setl Group, «Татнефти», «ЕвроХима» и других компаний.

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

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

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

Андрей Карпатый, который придумал слово «вайбкодинг» в феврале 2025 года, имел в виду простое: сваять сайт-визитку или утилиту для себя, не читая код, доверяя результату. Но слово приросло ко всему: от поделок до продакшн-систем, где инженер отвечает за каждую строку. Разница между этими двумя способами работы огромна, а название для второго подхода как будто отсутствует.

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

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

В августе суд в Москве отказал автору картинок из нейросетей в защите прав: ввод и уточнение команд - это не творчество. Программа по ГК охраняется по тем же правилам, что и картинка. Разбираю, чей код, который написал ваш ИИ-агент, что тут поменяет закон об ИИ с 1 марта 2027 года и где это ударит по разработчикам и компаниям уже сейчас.