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

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

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

В мае Сбер выпустил whitepaper “AI-Disrupt PDLC” - документ о том, как перестраивать жизненный цикл разработки вокруг намерения человека. В сентябре Олег Бунин разобрал его на Хабре, отделив инженерную рамку от продуктовой витрины.

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

Главное, что я нашел, относится к самому документу: одна и та же цифра употреблена в нем с двумя разными базами сравнения, и расхождение между прочтениями четырехкратное. Об этом ниже, сначала про данные.

Нейросети с нами надолго. Даже если вдруг исчезнут OpenAI, Anthopic, Z.ai и прочие, мой личный Qwen 3.8 27B никуда не денется. Вопрос - a что с этим делать? Как разрабатывать софт в новую эпоху?

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

Есть такой университетский предмет, который все давненько подзабыли (а люди с ИТ-курсов его и в глаза не видели): "методология разработки программного обеспечения". Разработка хорошего ПО - это всегда вопрос методологии. Это и общие принципы архитектуры, и дисциплина работы, и возможность передать работу соседу, разделить между несколькими людьми, признать нечто готовым или не готовым. Без методологии разработка стремительно теряет управляемость.

Как сейчас.

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

Мой сайт ведут ИИ‑агенты. Они пишут код, правят тексты, проводят ревью, собирают и выкатывают. 207 коммитов.

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

Две цифры для затравки:

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

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

Через 48 часов мы уже тестировали первую итерацию клона системы.

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

Одиннадцать недель я вёл дневник каждой рабочей сессии с Claude Code: часы агента, свои часы, судьба каждого кандидата в дефекты. Вышло 277 агентских часов против 213 моих и 94 подтверждённые находки — 77 нашёл агент, 16 я. Внутри: почём обошёлся час агента, где он не окупился, что пропустил и почему первый подсчёт находок оказался завышен почти вдвое.

Привет! Меня зовут Игорь, я отвечаю за развитие Naumen Project Ruler. Много общаюсь с заказчиками, изучаю их задачи и практики проектного управления и вместе с командой определяю, куда продукт будет двигаться дальше.

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

В любой компании нужно решать, над чем и как работать. Одна из широко распространённых методологий для принятия таких решений в IT — lean startup, то есть небольшие итерации с тестированием гипотез. Проблема в том, что методология не работает «в лоб», если вы не стартап.

Привет! Это Арсений Проценко, я лидирую AI‑команду в продажах в Точка Банк. В статье поделюсь опытом, который пришёл нашей команде за последние годы. Обсудим, что не так с lean в больших компаниях и как можно изменить метод под ваши реалии.

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

По данным портала levelup.com, в 2026 году на Steam в среднем публикуется от 70 до 100 игр в день.

Если говорить о мобильных играх, то, по данным apptopia.com, в 2026 году в App Store в среднем публиковалось свыше 500 игр в день, а в Google Play Store - свыше 200 игр в день. Цифры приблизительные и консервативные - взяты мной в сторону уменьшения.

Если для Steam‑релизов признаки вайбкодинга не звучат явно, то, по мнению The New York Times, для мобильных приложений в App Store рост обусловлен во многом именно вайбкодингом. Полагаю, это применимо и к Google Play Store.

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

Представьте: в игре хорошо работает фича, которая приносит деньги. Команда хочет развить её дальше и ставит себе цель. Инженер, приценившись, говорит: «Нам нужно три недели». А бизнес вставляет: «Но у нас есть только две!».

Кто из них прав?

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

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

Ниже — перевод статьи «Friends Don’t Let Friends Use Ollama», опубликованной на Sleeping Robots в апреле 2026 года. Поскольку за прошедшие месяцы Ollama успела заметно измениться, я добавил к переводу несколько комментариев и примечание в конце статьи, где обновил ключевые технические детали по состоянию на сентябрь 2026 года.

Ollama стала популярной потому, что первой предложила простой интерфейс поверх llama.cpp. А затем годами старалась лишний раз не напоминать, на чём на самом деле работает, вводила пользователей в заблуждение и в конце концов развернулась в сторону облака — всё это на венчурные деньги, привлечённые вокруг чужого движка.

Вот эта история целиком — и почему сегодня альтернативы выглядят лучше.

Ollama — самый популярный способ запускать большие языковые модели локально. И, пожалуй, не должна им быть.

Своим положением она обязана прежде всего тому, что оказалась первой: первым инструментом, который сделал llama.cpp доступным людям, не желавшим компилировать C++ или самостоятельно писать конфигурацию сервера. На тот момент это действительно был полезный вклад.

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

Это не попытка найти «правду где‑то посередине». Я пользовался Ollama. Потом перестал. Ниже — почему, на мой взгляд, вам стоит сделать то же самое.

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

За семь дней вышло $230 (около $960/мес). При подписке $60 в месяц и нулевой доплате.

Всем привет! На связи Елизавета, я agile-коуч продуктовых стримов корпоративного бизнеса — транзакционных сервисов, продуктов для малого бизнеса, страхования. Внедряю Discovery и проверку гипотез, а ещё веду курс по CJM для топ-менеджмента и продуктовых лидеров. Отсюда и тема статьи: расскажу о том, как выстроить карту клиентского пути для ИТ-продуктов.

Свои процессы ИТ-команда знает хорошо: сколько занимает разработка, где стоит согласование, какой сервис отвечает за шаг, сколько проходит от постановки задачи до релиза. Мы считаем сроки и смотрим на продукт через метрики. Внутренние процессы не отвечают на один вопрос: что в этот момент происходит с клиентом?

На бумаге открытие счёта занимает 20 минут: регламент выполнен, сроки соблюдены. При этом клиент трижды приезжает в офис, потому что с первого раза ему не сказали, какие документы нужны. Потом несколько дней ждёт ответа, звонит в контактный центр и заново объясняет свою ситуацию. Банк считает такой процесс корректным. Клиент за это время потратил неделю и четыре обращения.

Команды берутся за CJM, чтобы посмотреть на продукт снаружи. Внутри процесс выглядит так:

заявка → проверка → согласование → решение → уведомление клиента.

Клиент не делит банк на приложение, сайт, контактный центр и офис. Если в приложении он прочитал одно, от оператора услышал второе, а в офисе третье, он не станет разбираться, какая система дала сбой. Он скажет, что у банка проблемы. У клиента последовательность другая:

узнал о продукте → попытался разобраться → не понял условия → написал в чат → получил один ответ → пришёл в офис → узнал о дополнительных документах → ушёл → вернулся через несколько дней → снова связался с банком.

Первые несколько дней с AI агентом легко создают ощущение, что разработку наконец-то «сломали». Даёшь задачу, через несколько минут получаешь diff на несколько файлов, тесты и уверенный отчёт о том, что всё готово. Если мерить производительность от момента, когда ты сформулировал prompt, до появления кода, результат действительно впечатляет.

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

Поэтому в течение месяца я смотрел не на количество сгенерированного кода, а на полный цикл изменения: задача → понимание контекста → реализация → review → тесты → интеграция → release. И именно здесь эффект оказался гораздо интереснее простого «AI ускоряет разработчика».

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

Использование локальных агентов для сбора, саммаризации и валидации требований в закрытом контуре. Инструменты: агент-опросник, извлечение переписки, расшифровка встреч, RAG-поиск по Confluence, агент-контролёр.

Одна из наших крупных функциональностей ехала до пользователей 519 дней.

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

Следующий большой кейс занял 666 дней.

То есть после осознанной попытки ускорить разработку мы получили ещё худший результат.

В статье разбираю, почему декомпозиция сначала не помогла, зачем мы постепенно переносили её с этапа разработки на аналитику и продуктовую проработку, как в эту историю вписались MVP и WIP-limit и что в итоге позволило сократить Lead Time похожих больших функциональностей до 90–120 дней.

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

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

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

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

Модераторы INFOSTART TECH EVENT 2026 обсудили, где ИИ уже помогает тестировщикам, зачем растущим командам матрицы компетенций и почему качество продукта давно перестало быть зоной ответственности только QA.

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

Для работы аналитика точнее подходит термин вайб-спекинг — диалог с ИИ, в котором исходная идея постепенно превращается в спецификацию: с границами доработки, объектами конфигурации, исключениями, рисками и критериями приёмки.

Главное условие здесь — контекст. Универсальная языковая модель может хорошо оформить документ, но не обязана знать устройство конкретной версии конфигурации 1С. Поэтому полезность ответа зависит не только от промпта, но и от того, есть ли у агента сведения о метаданных и типовых механизмах системы.

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