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

В первой части мы рассмотрели теорию, лежащую в основе концепции луковой архитектуры. Теперь предлагаю рассмотреть практическое применение. Будет МНОГО кода.

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

В этом году я попробовал максимально автоматизировать эту работу. Получились три последовательных подхода, собственный YAML-оркестратор, внешний workflow на Dify с Tavily и офис AI-сотрудников с распределённой ответственностью. SEO оставалось задачей, для которой последовательно менялось устройство оркестрации.

Пять человек, шесть спринтов и AI-ассистент для продавцов маркетплейса. Архитектура, интеграции, тестирование, автономные ответы — всё хочется уместить в квартал. Как понять, что план выполним, а не просто красиво выглядит на доске?

На учебном кейсе разбираю, как свести объём работ с возможностями команды, пересчитать доступное время по ролям после замены backend-разработчика на QA и связать этапы запуска с зависимостями, резервом и критериями успеха. Внутри — исходная доска, расчёты и вариант доработки квартального плана.

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

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

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

/

Мы уже научились писать код с помощью AI. Но гораздо интереснее другое - как именно мы встроили AI разработку в свою работу. Я попробовал вспомнить все свои наблюдения и составил небольшую небольшую классификацию - от Воина до Некроманта. Надеюсь этот опрос вас немного порадует.

Я уже рассказывал на Хабре, как наша команда из “ЛАНИТ-Интеграции” автоматизировала процесс управления доступами для крупного заказчика, который имеет несколько десятков офисов по всей стране.

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

Привет, я Коновалов Илья — лид фронтенд-разработки бизнес-юнита Записи в СберЗдоровье. Никогда не думал что буду рыбачить, но это внезапно оказалось отличными хобби и не просто так. Сейчас расскажу, почему :)

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

Год назад над таким объявлением посмеялись бы в курилке, а сейчас похожие вакансии висят в каждой второй ленте, называются по-разному, от вежливого «AI code reviewer» до честного «разгребатель вайб-кода», и за ними почти всегда стоит одна и та же история, когда компания сначала заплатила за то, чтобы убрать людей из процесса, а потом заплатила еще раз и уже дороже, чтобы вернуть их обратно, только теперь на роль уборщиков после банкета, на который их самих не позвали.

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

Я не программист. По крайней мере, несмотря на то, что в 2010 году я закончил «Прикладную информатику в менеджменте» (ДГТУ) и учился писать на C++, таковым в настоящее время себя не считаю.

При этом с июля 2026 года я управляю большим продуктом (собственная фабрика аналитики, своего рода ERP внутри компании), код которого пишут ИИ‑агенты. Я даю задачи голосом (не помню, когда в последний раз формировал текст задач на клавиатуре), агенты пишут код, проверяют его и выкладывают новую версию на сайт. Продукт собран на Next.js 16, TypeScript и PostgreSQL. На 1 октября в истории проекта уже более 6500 коммитов и 1.800.000 строк кода.

Код я не читаю. Поэтому между словом агента «готово» и появлением новой версии на сайте стоят автоматические проверки. Их называют «сторожами», сейчас их около двухсот. Если хотя бы один сторож покраснел, новая версия не попадает на сайт, а я получаю в Telegram сообщение «выкат остановлен» со списком красных.

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

Проблема не всегда в размере контекста. Иногда проблема в организации знаний, которые мы в этот контекст помещаем.

Крупная сеть пиццерий. Международный отель. Сеть фастфуда. Три официально озвученных крупных сбоя за последние два года, а сколько их не вынесенных в СМИ произошло за эти же 2 года? Не три случайности — это стадии одного, повторяющегося из раза в раз, универсального для сегмента ИТ цикла. Он не зависит от отрасли — рестораны, отели, логистика, EdTech, банки, не зависит от размера компании или холдинга — от $30 млн до $1 млрд+, равно как не зависит и от страны.

И никто его не останавливает?

Что происходит.

1. Бизнес растёт. Скорость критична. Шеф требует проверку гипотезы к пятнице. ИТ отвечает как может: быстро, на коленке, без архитектуры. Работает? Да. Сейчас внедрим в продукт (накатим).

McDonald's. 15 марта 2024. 12 часов глобального сбоя. «Конфигурационное изменение». Не кибератака. Просто рост без архитектуры, и как следствие — долг не исчезает, он накапливается до критической массы.

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

Hilton. 2024. Утечка через Otelier. 7.8 ТБ данных. 437 000 email. Причина — украденные учётные данные Atlassian. Подрядчик, у которого украли доступ. Когда архитекторов нет — доверяют подрядчику. Без контроля. Подрядчик = не контролируемый чёрный ящик.

3. Собственник в спешке ищет «спасателя» по рекомендациям. Внешний кризис‑менеджер дорог — но бизнес встал, выбора нет. Первая задача — реанимация, «должно хоть как‑то работать», чтобы не простаивать вообще. Правда реанимация не лечение — это отсрочка неизбежного финала, но костыли дают «кэш» и бизнес согласен. «Работает — не трогаем». Оттягивание, накопление и финал.

Привет. Меня зовут Александр Богданов, я основатель AGIMA. В 2020 мы перезапускали сайт AGIMA: работа заняла два года. В 2026 году мы снова решились на редизайн. Но это не будет скучный текст про то, как мы переделывали логотип 50 раз. Вместо этого я расскажу, как мы полностью отдали управление сайта агентам.

Разделить монолит без остановки бизнеса, сменить СУБД с сохранением существующей логики, встроить ИИ в корпоративные процессы — такие задачи разберут в секции «Кейсы крупных компаний» на INFOSTART TECH EVENT 2026. Конференция начнется 8 октября в Санкт-Петербурге. В программе секции — десять выступлений о проектах, технических решениях и ограничениях, с которыми столкнулись команды.

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

Агент проверял разворот на палиндроме, а порядок четырех потоков - на четырех одинаковых входах. Тесты проходили и с ошибкой. В эксперименте Дэна Лу указания использовать TDD, фаззинг и формальные методы не дали убедительного общего выигрыша над контролем. Разбираю три механизма бесполезных проверок и показываю исполнимый пример: как намеренно внести конкретный баг и убедиться, что тест его обнаруживает.

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

Статья выросла из серии экспериментов с одним и тем же вопросом: можно ли поручить LLM-агентам разработку кастомизации под крупную и закрытую PLM систему, так чтобы результат было не стыдно показать заказчику. Короткий ответ: можно. И не потому, что модели стали умнее, скорее потому, что их поместили в контекст и задали нужный вектор. А код стал не целью, а рядовым артефактом процесса.

30 сентября в 06:32 в очереди появилась задача: научить ядро платформы переводить открытые задачи на новую версию их типа. Повод был будничный — мы выпустили новую версию типа «задача на код» с более строгими проверками перед сдачей, а вся открытая очередь осталась на старой и получала старые инструкции.

Через 19 минут агент сдал работу: новый маршрут API, тесты, документация. В 07:15 ревью её отклонило. Новый маршрут позволял агенту с обычными правами исполнителя перевести свою задачу на первую версию типа — ту, где ревью ещё не было, — взять её и закрыть самому. Ревьюер воспроизвёл это по шагам и написал, какое право должно закрывать маршрут. В 08:03 агент взял задачу снова, через 15 минут сдал исправление, в 08:24 ревью прошло и ветка влилась. От постановки до вливания — 1 час 52 минуты, два прогона агента.

Агент написал дыру, через которую агент мог бы уйти от ревью, и поймало её ревью, которое платформа считает частью самой задачи. 4 октября мы выпустили первый открытый релиз платформы — Taimen v0.2.0, Apache-2.0. Ниже — как она устроена и что мы поняли, пока почти два месяца разрабатывали её её же собственными средствами. В конце — как этот релиз выпустила сама очередь.

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