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

Продолжение «Манифеста созидателя», «Лицензии на агентство» и «На трёх слонах». #profgames

Вы не встречались с ситуацией, когда ваш клиент говорит «я засунул ваш отчёт в гопоту...» или «у меня бухгалтер навайбил...»? Нет? Значит, вы не общаетесь с клиентами.

Облачные PaaS-сервисы позволяют использовать платформенные компоненты для построения инфраструктуры и избежать при этом лишних затрат, предоставляя сервисы в том объеме и той конфигурации, что необходимы клиенту. Одна из категорий клиентов PaaS-сервисов — разработчики ПО, и в этой статье предлагаю поговорить о том, чем использование платформенных сервисов ценно именно для разработчиков, обсудить принципы разработки Cloud-native приложений (методику 12 факторов), а также я расскажу о том, что мы в Cloud X делаем для повышения эффективности процессов создания ПО. 

Год мы обкладывали мобильный проект правилами для ИИ-агентов: CLAUDE.md, AGENTS.md, правила Cursor, доменные документы хрупких зон, hooks. Каждый файл решал реальную проблему. Все они грузились всегда.

Потом я померил. Чтобы поправить отступ у кнопки, агент стартовал с 39 000 токенов фиксированного слоя — до того, как я задавал вопрос. Один CLAUDE.md весил 70 килобайт и давал 69% always-on пакета. Контекст заканчивался посреди обычных задач, крупные уходили в суммаризацию.

Четыре фазы: CLAUDE.md превратился в индекс на 114 строк вместо учебника на 409; главный кодекс на 417 строк разрезан по globs, чтобы правила про оффлайн не грузились при правке профиля; ревизия alwaysApply и прополка вендорных skills; привычки чата и защита от отката.

Стало: −64% на лёгкой задаче, −60% always-on, CLAUDE.md −77%. Задача в самой сложной зоне проекта теперь легче по контексту, чем раньше была любая правка одной строки.

Внутри: все замеры с методом, который можно повторить в своём репозитории за минуту, что мы сознательно не резали и почему, и три вопроса к каждому файлу в always-on.

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

Всем привет! Меня зовут Олеся, я руковожу отделом процессов и технологических стандартов ИТ на Московской Бирже.

Сегодня хочу поделиться опытом, который мы накопили при построении единой производственной системы SDLC (Software Development Life Cycle), включающей три компании Группы MOEX.

Это была не просто бюрократическая задача по написанию инструкций, а сложный инженерный и организационный вызов для нас!

Материал будет полезен CIO, руководителям ИТ-подразделений и архитекторам, которые сталкиваются с проблемой разрозненности в подходах к разработке внутри одной экосистемы.

Что полезного вас ждет в этой статье?

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

В «Первой Форме» ИИ-агент помогает в контуре разработки: работает с кодом, инструментами и ревью. Состав моделей в этом контуре мы регулярно пересматриваем. За последние недели мы обновили Muse Spark с версии 1.2 до 1.3, добавили Gemini 3.8 Flash и подготовили для него быстрый откат на предыдущую модель. Расскажем, как устроен этот процесс.

Miro продали в 13 раз дешевле оценки 2021 года, и я пошёл считать, что вышло из нашей попытки уйти от подписок. За год мы заменили Tilda, Confluence, Jira и Slack своим кодом, целей было две: экономия и гибкость. Экономии не получилось: по полной ставке сеньора и с учётом владения первый год ушёл в минус около 2 млн. Гибкость, кажется, получилась, и выяснилось, что трекер до рабочего состояния доводит не разработчик, а скрам-мастер. В статье цифры по четырём заменам, инцидент с уязвимостью в авторизации, который заставил поставить ревью второй нейронкой, и критерий из трёх вопросов, что переписывать не стоит.

31 августа прод моего приложения пролежал около часа.

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

Дальше он начал чинить. Ошибка, правка, следующая ошибка, еще правка. Каждая починка тянула за собой новую поломку. Я посмотрел на это и написал: «верни просто старую версию» То есть откатись к последнему состоянию, про которое точно известно, что оно работало.

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

Переезд с include на GitLab CI Components: у модуля появляется объявленный spec: inputs с типами и дефолтами, а опечатка в имени input роняет пайплайн до старта…

Что делать, когда процесс разработки с ИИ-агентами уже устоялся, но всё ещё приходиться сидеть рядом с ними и ждать, когда они закончат очередной этап работы, чтобы запустить следующий?

У меня это выглядит так. Появилась идея новой фичи для разработки. Я запускаю /opsx:explore скил OpenSpec и обсуждаю с ИИ как будем делать эту фичу, какие нюансы и детали надо предусмотреть. Когда открытых вопросов не остаётся, перехожу к /opsx:propose, чтобы подготовить спецификации перед разработкой. Потом ревью спек с помощью команды /review-artifacts и правка найденных нестыковок. Дальше запускаю /opsx:apply-sequential для реализации в автономном режиме и чистым контекстом агента для каждой подзадачи. Потом ревью через /audit-implementation и правки после него. Архивирование изменения через /opsx:archive. И наконец-то создание PR, финальное ревью и merge.

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

Я больше десяти лет делаю рекламные платформы. Команды за это время были разные — по размеру, по составу, по зрелости. Но почти всегда был один загон — всем почему‑то было очень важно работать по спринтам.

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

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

Скорость выросла у всех, а дисциплина почти ни у кого. Эта статья про то, почему обычное ревью и обычный SAST в эпоху vibe coding перестают быть достаточным контуром контроля, какой стандарт приёмки ИИ-кода мы считаем минимально рабочим и как устроена проверка, в которой модель, написавшая код, не является тем, кто его принимает. Мы разберём, что именно ломается в инженерном процессе, когда код пишет не человек, и какие слои контроля должны появиться до репозитория, в IDE, в pull request и в CI/CD.

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

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

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

Собрали несколько историй с митапа в один обзор. В детали здесь специально не уходим — наиболее интересные кейсы разберём отдельно.

С redb команда пишет только бизнес-логику: что экосистема заменяет, во что обходится, какие риски снимает и что важно знать до старта.

12 сентября вышла redb 4.0.0. Четыре продукта экосистемы (хранилище, интеграционный движок, рантайм и сервер идентификации) получили общий мажорный номер: 76 пакетов, внутренний аудит безопасности и сборку на .NET 10, который Microsoft поддерживает до ноября 2028 года. Для инженеров изменения разобраны в отдельной статье. Этот текст для тех, кто решает, на чём строить бэкенд: что экосистема заменяет, во что обходится, какие риски снимает и что важно знать до старта.

Коротко, из чего она состоит:

Разбор нашумевшей статьи Флориана Херренгта и спор с ней. Он предлагает нанимать тех, кто хочет разбираться в коде. Я покажу на своих данных, почему одного этого мало: желание понимать не помогает, если инструмент показывает неправду. Плюс рыночные цифры, из которых видно, что у нас всё сложнее, чем на Западе.

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

— В этом проекте нам надо хорошо распознавать документы.

— А что значит «хорошо»?

— Сейчас же везде ИИ. Я загружаю документ в чат, и он мне всё правильно отвечает. Нам надо так же для всех документов.

Такие диалоги я всё чаще слышу при обсуждении новых проектов.

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

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

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

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

Кажется, что при создании сложных инженерных систем разработка создает технологию, а продукт упаковывает ее для заказчика. У каждой команды своя зона ответственности. На самом деле всё не так просто.

Мы в «Фалькон Тех» уже 9 лет разрабатываем цифровые решения для умного города на основе видеоаналитики и машинного зрения. В статье рассказываем, почему продукт и разработка должны работать в связке, а не передавать друг другу задачи по цепочке.

Этот пост для разработчиков, которые еще скептически относятся к кодингу с ИИ агентами и не используют его. Мир стремительно меняется и пора «проснуться» и поменять методику работы.

Ниже я расскажу личный опыт, чтобы было нагляднее.

Когда вы в последний раз проверяли свои репозитории на забытые токены? Пока вы скроллите ленту, боты парсят GitHub и подхватывают утекшие ключи за 2–3 минуты. Мы собрали главные дыры — от .env и CI-логов до ИИ-конфигов. В конце чек-лист, чтобы проверить себя за пару минут.