Архитектурные катастрофы – часть 12: как 2 миллиона человек встретили Рождество в аэропортах из-за техдолга в софте авиакомпании

С 21 по 31 декабря 2022 года Southwest снял 16 700 рейсов и десять дней не мог выполнять расписание: больше 2 000 000 пассажиров встретили Рождество в аэропортах.

Триггером стал шторм Elliott. Он ударил по всей отрасли – больше 18 000 отмен, но конкуренты оправились за пару дней, а Southwest простаивал почти до Нового Года.

❄️ Погода превращается в событие планирования экипажей

Денвер стоял с вечера 21-го до утра 23-го, Chicago Midway – с середины 22-го до конца 23-го. Из-за этого сломалась вся цепочка укомплектования самолетов экипажами.

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

В Денвере и Чикаго базировалась четверть всего лётного состава – поэтому обрыв вышел массовым.

Шторм закончился 26 декабря, и конкуренты возобновили полеты в тот же день. А Southwest отменял рейсы ещё три дня – на них пришлось 3/4 всех отмен отрасли за 24–31 декабря.

🧠 Что перестало работать

Планировщик экипажей был технически исправен. Дословно из письменных показаний COO Эндрю Уоттерсона Сенату США: "our Crew Scheduling software didn't stop working during this event". Но он устарел настолько, что оказался не готов к происшествию такого масштаба.

🔹 Состояние обновлялось голосом. Где экипаж, сколько отлетал, когда упрётся в лимит – это попадало в систему через телефонный разговор с планировщиком, по коллективному договору на записываемой линии. Очередь быстро стала огромной, по данным профсоюза бортпроводников – до 17 часов. Оптимизатор расписания полетов считал дальше, по картине мира, которой уже не было.

🔹 Режима восстановления не существовало. Планировщик (GE Crew Optimization, внутри – SkySolver) строил расписание вперёд. Разобрать бэклог сломанных связок он не умел вовсе: "SkySolver was never designed to look back" – подпись к графику в показаниях профсоюза пилотов.

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

💥 Кульминация

26 декабря сеть перезагрузили руками: заранее сняли две трети расписания на 27–29 декабря, сжавшись до ~1 500 вылетов в день с праздничного пика ~4 000. Планирование экипажей шло по старинке: карандашом и бумагой. Борта перегоняли 517 пустыми рейсами.

Счёт: 16 700 отменённых рейсов за 21–31 декабря, более 2 000 000 пострадавших пассажиров, $800 млн убытка до налогов за квартал, $140 млн штрафа Минтранса США – в 30 раз больше предыдущего рекорда ведомства.

🔍 Разбор полётов

🔸 Что пошло не так: единственный канал обновления состояния встал, и оптимизатор потерял связь с реальностью.

🔸 Почему это произошло: модернизацию откладывали годами. SWAPA предупреждал с 2014-го, TWU Local 556 – с 2018-го, в октябре 2021-го был сбой того же типа в меньшем масштабе. 7 ноября 2022-го глава SWAPA публично сказал, что до коллапса остаётся одна гроза, один сбой управления воздушным движением, один отказ роутера. Elliott пришёл через 44 дня.

🔸 Как надо было: электронное обновление состояния, отдельный режим разбора бэклога сломанных связок, общий контракт между Baker и планировщиком. Именно это Southwest сделал в 2023-м, вложив $1,3 млрд в ИТ.

📌 Три урока

🔹 Техдолг нельзя откладывать бесконечно, рано или поздно он выстрелит. Отсутствие инцидентов не доказывает запас прочности.

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

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

📚 Что почитать

– Наше короткое видео в Instagram
– Письменные показания COO Southwest Эндрю Уоттерсона и президента SWAPA Кейси Мюррея Сенату США (09.02.2023); consent order Минтранса США 2023-12-11

АНАТОМИЯ ФИЧИ: Как устроен MCP Gateway в Uber

Подключить MCP-сервер к агенту – это строчка в конфиге, операция настолько дешёвая, что корпоративное внедрение MCP легко принять за неё же, помноженную на число команд.

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

🔬 Команды Uber MCP-серверы не пишут

Внутренних сервисов больше десяти тысяч, каждый описан proto- или thrift-файлом, и любой такой эндпоинт становится MCP-сервером изменением конфига. Для своих сервисов Gateway генерирует MCP-серверы сам, а сторонние SaaS проксирует.

⚙️ Описание инструмента живёт по правилам кода

Если серверы никто не пишет руками, откуда берётся описание инструмента, по которому агент его и выбирает? Черновик пишет модель: краулер обходит эти proto и thrift, описания составляет LLM по именам сообщений и комментариям.

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

Проходить весь этот путь описание обязано потому, что одобренное можно изменить задним числом, а повторно никто не переспрашивает. В старой версии Cursor одобрение привязали к имени записи MCP-сервера, и подменённую внутри неё команду IDE запустила молча (CVE-2025-54136).

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

🧬 В диффе написано "Monitoring Agent"

Описание закрывает половину вопроса. Вторая половина: кто стоит за вызовом.

Инженер просит Oncall Agent разобраться с алертом, тот делегирует Investigation Agent, а дифф с новым порогом открывает третий, Monitoring Agent. Дежурного, с которого всё началось, в авторстве нет.

Протокол тут не помощник: авторизация в MCP помечена как OPTIONAL и опознаёт в лучшем случае непосредственного клиента.

Личность агента Uber описал вне протокола: выдать агенту токен вправе только Security Token Service. Agent SDK просит у него JWT, аутентифицируясь удостоверением своего workload'а (процесса на хосте), а STS через Agent Registry проверяет, что этот workload вправе хостить заявленный agent_id.

Токен несёт аттестованную цепочку акторов: gateway видит [user1, oncall-agent, investigation-agent].

Собрать эту цепочку снаружи нельзя: контекст исполнения рождается в приложении агента, поэтому обмен токенами живёт в его SDK. Готовый agentgateway Uber рассматривал и отказался.

🤝 Доступ агента к внутренним инструментам в других системах

Отсюда и расхождения: границу доверия каждый проводит в своём месте.

🔸 AWS Bedrock AgentCore Gateway – склеивает подключённые цели (targets) в один виртуальный MCP-сервер, каталог по умолчанию обновляется вызовом API.

🔸 Google Agent Gateway – граница в IAM: Identity-Aware Proxy включён всегда, незарегистрированное закрыто. Идентичность агенту выдают, а цепочку "кто кого попросил" дальше не переносят.

🔸 Cloudflare Code Mode – граница в песочнице: код исполняется в изолированном V8 и ходит наружу только через bindings, ключи держит супервизор.

🔸 Block с агентом Goose – центрального прокси нет: сервер проходит два ревью в allow-list, а нужные серверы агент включает на клиенте под запрос.

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

Пока агенты у вас только читают и никто не спрашивает "кто это сделал", хватает памяти одного человека. Считать порог надо не по числу агентов, а по числу мест, где ответить уже некому.

Вторая команда-потребитель – самое раннее, когда gateway осмыслен; строить пора с третьей.

📚 Что почитать:

"Solving the Identity Crisis for AI Agents" – Uber Engineering, 21.05.2026

"Running a Software Factory Efficiently at Uber Scale" – Uber Engineering, 27.08.2026

Как обосновать архитектуру перед бизнесом

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

💸 У бездействия в разговоре нет цены

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

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

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

🧾 Выход 37signals из облака собран по этой же схеме

Счёт за 2022 год – $3.2 млн, закупка железа – около $700 тыс. Вложения окупились за вторую половину 2023-го, а пересмотренная оценка экономии перевалила за $10 млн на горизонте пяти лет.

Главное возражение звучало так: экономию съест раздутая команда эксплуатации. Компания проверила это на себе – по словам DHH, состав команды не менялся.

Много вложили в правильном месте – много сэкономили.

🎭 Четыре разных "нет"

Совет "говори на языке бизнеса" предполагает единую аудиторию, а её не бывает. У каждого согласующего своя единица измерения:

💰 Финансы считают стоимость работ и цену паузы.
📈 Продажи держат в голове квартал, в котором продукт качнётся на глазах у клиентов.
🏦 Совет директоров смотрит на капитал, замороженный без видимой выручки.
🚀 Продукт меряет себя поставленными фичами.

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

Доказательства придётся приносить, и одно из них пообещать не получится.

📉 Счётчика техдолга не существует

Google между 2018 и 2023 перебрал 117 метрик на трёх типах долга и не нашёл ни одной, которая предсказывала бы сообщения инженеров о долге. Результат авторы назвали разочаровывающим.

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

🚪 Сколько стоит вернуться назад

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

Он снижает воспринимаемый риск сильнее любых технических деталей, потому что отвечает на то, чего собеседник боится по-настоящему, – попасть в необратимое.

Бизнес спрашивает не только "сколько это стоит", но ещё "какой риск я на себя беру, если скажу да, и какой – если скажу нет". Пока второй половины вопроса в вашем документе нет, вы отвечаете на половину.

📚 Что почитать:

"The technical debt business case" – Revolgy, 2026
"Defining, Measuring, and Managing Technical Debt" – Jaspan & Green, IEEE Software, 2023
"Our cloud exit savings will now top ten million over five years" – DHH, world.hey.com, 2024

АНАТОМИЯ ФИЧИ: Как Яндекс.Такси ищет водителя

Вы жмёте "Заказать" и через пару секунд получаете машину. Кажется, что система нашла ближайшую. Тогда почему иногда приезжает не та, что стояла в соседнем дворе?

🔬 Сотни тысяч точек, которые всё время двигаются

На линии у Такси одновременно сотни тысяч водителей, координаты каждого обновляются раз в несколько секунд. Сервис Tracker принимает около 20 тысяч геопоисковых запросов в секунду и прогоняет кандидатов через сотню фильтров, а это около 30 млн проверок "водитель × правило" ежесекундно.

Считать расстояние до каждой машины на каждый запрос при таких числах не выйдет.

⚙️ KD-дерево вместо ровной сетки

В отрасли обычно режут пространство равномерной сеткой: геохеш или гексагоны H3. В Tracker геопоиск построен на KD-дереве. Оно делит плоскость по очереди то по широте, то по долготе и сгущается там, где машин больше. Координаты пассажира становятся ключом поиска, и от целого города остаётся горстка кандидатов.

🧬 Почему свой граф дешевле чужого routing API

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

Уточнить порядок можно внешним routing-сервисом на каждого кандидата. В Такси посчитали цену: для города со 100 тысячами запросов в день и тысячей машин выходят десятки-сотни тысяч долларов ежедневно.

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

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

🤝 Тот же поиск в других системах

🔸 Uber – H3, гексагоны: номер ячейки считается без мутации структуры, что удобно при потоке записей.

🔸 Lyft – geohash-ключи в Redis Cluster, 15 млн запросов в секунду при p99 меньше 10 мс.

🔸 DiDi – geohash в rowkey HBase плюс второй проход с точным пересчётом расстояний.

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

Посмотрите наше минутное видео: там весь путь заказа показан схемой, вместе с буферным назначением.

📚 Что почитать:

"Зачем C++ в Такси? Доклад Яндекса" – Хабр, блог компании Яндекс

"Yandex.Taxi Graph Technologies: The Perfect Search Without Routing API Requests" – Yandex.Taxi: Under The Hood

Кто отвечает за код, который написал агент

Формальное правило одинаково от Google до open source: смёржил PR – значит отвечаешь, кто бы ни написал код, ты или агент.

Но когда в проде реально что-то падает, ответственность чаще утекает наверх: 46% enterprise-организаций называют виноватым CTO или VP Engineering, и лишь 7% – того, кто физически нажал "смёржить".

Дальше несколько моделей ответственности – и на практике работают не все.

👤 Кто написал – тот и отвечает

Это модель по умолчанию: имя в git blame отвечает за код целиком, независимо от того, кто его придумал.

Она работает, пока PR помещается в голову того, кто его одобрил. Но на масштабе в сотни PR в неделю содержательно понять каждое решение уже физически невозможно.

🔍 Кто ревьюит – тот и отвечает

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

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

Гейт такую нагрузку не выдерживает: почти две трети аппрувов уходят без единого комментария.

🎯 Кто владеет сервисом – тот и отвечает

Более зрелый ответ закрепляет ответственность по зоне риска.

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

🌀 Виноваты все – значит, не виноват никто

Там, где ответственность не определена, она естественно сползает на команду целиком.

PR ревьюился кем-то ещё, дизайн обсуждался до того, как открыли редактор.

Спросите отдельно службу безопасности, разработчика и ревьюера, кто виноват в инциденте – скорее всего, каждая сторона укажет на кого-то другого.

Это не распределённая ответственность, а её вакуум: три стороны одновременно считают виноватой друг друга.

📝 Кого назначили – тот и отвечает

У вакуума ответственности есть рабочее лекарство: то же коллективное владение, но с одним именем, названным заранее.

Reviewer of record – конкретное имя на каждый мерж с ИИ или без него, назначенное заранее, до инцидента.

Но важно, чтобы это имя было записано где-то, кроме памяти конкретного тимлида.

📚 Что почитать:

State of Code Abundance – CloudBees, 2026
State of AI in Security & Development – Aikido Security, 2026

МИФ: После сеньора расти некуда – только в тимлиды идальше в менеджмент

На ревью это звучит примерно одинаково: "Ты отличный senior, но следующий шаг у нас – это тимлид с людьми в подчинении".

Дальше кажется, что есть только три пути: менеджмент, остаться на месте, менять работу.

🧱 Потолок ставят задачи, которых в компании нет

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

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

Уилл Ларсон даёт такую оценку: архитектор вызревает у организаций примерно от сотни инженеров, "правая рука" руководителя – от тысячи.

🏛 Технический трек придумали ровно от этого тупика

Лестницу individual contributor придумали в исследовательских лабораториях середины прошлого века. Компании теряли сильных учёных, которым больше денег и статуса давала только руководящая должность.

Так в 1962 году IBM учредила звание Fellow, которое признавало многолетние достижения и давало свободу дальше заниматься своим делом.

ИТ-индустрия девяностых и двухтысячных этот механизм унаследовала не сразу: схема "инженер → тимлид → менеджер" проще для зарплатной сетки и понятнее для найма.

🧭 Вторая лестница размечена зоной ответственности

Людей в подчинении она не считает вовсе. Senior отвечает за то, что сделал сам.

Техлид или Staff Engineer отвечает за работу своей команды и за договорённости с соседними командами.

Архитектор отвечает за большой кусок системы и за всех, кто над ним работает.

Закрытые задачи и выполненные командой спринты на этой шкале не значат ничего. Значение имеет то, что стало с системой через год: качество кода, развитие архитектуры, культура разработки.

🔍 Проверка, которая занимает один разговор

Работает ли эта шкала в вашей компании, видно по людям на верхних ступенях. Найдите живого человека на уровне Staff или Principal и посмотрите, чем его неделя отличается от вашей.

Если таких нет или все они бывшие менеджеры с новым титулом, трека нет.

Допустим, трек есть. Позовут на него всё равно не по выслуге лет.

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

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

Растёт не объём работы, а радиус, на который распространяется ваше решение.

📚 Что почитать:

Наше короткое видео на эту тему

"Staff Engineer: Leadership Beyond the Management Track" – Will Larson, 2021

"Staff archetypes" – staffeng.com

Senior → Tech Lead → Architect

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

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

🎯 Константин: senior → техлид. Первое в жизни system design интервью он вытянул арсеналом подходов с курса

Константин Петроченко, Senior Software Engineer, шёл на курс [Технический лидер] с готовой целью:

Разобраться в system design и понять, чего мне не хватает для роста до техлида и архитектора

Проверка нашлась сразу после курса – техническое собеседование с секцией по system design, до которой он раньше просто не доходил:

Задача попалась непростая (money transfer система), я местами плавал, но арсенал знаний и подходов, которые дал курс, позволил генерировать решения на ходу

Секцию он прошёл и получил приглашение на следующий этап. Вместе с этим появилось то, за чем он и шёл:

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

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

🧭 Илья: инженер → архитектура платёжных систем. На собеседовании CTO сработали таблицы сравнения

Ступенью выше – Илья Чекун, бэкенд-инженер из Цюриха, архитектура платёжных систем. Курс сработал там, где этого не ждали:

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

Свою следующую заявку Илья подаёт сразу на масштаб организации:

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

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

🏔 Елизавета: senior .NET → главный архитектор. Подняли за процесс, который заработал в командах

Елизавета Булыгина пришла к нам senior-разработчиком .NET, сейчас она главный архитектор в ИТ-дочке банка: под ней команда архитекторов, на ней архитектура при массовой передаче корпоративных систем банка. За что её повысили:

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

На этой высоте у неё появились другие проблемы:

Именно технический кусок в свете новых должностных обязанностей проседает

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

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

🎓 Именно этому переходу посвящён наш курс [Технический лидер]

28–29 сентября стартует 21-й поток, и в девятой версии программы появились три модуля по AI-архитектуре. Следующий поток планируем на осень 2027 года.

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

📅 Записаться на консультацию

📋 Программа и формат

Долгожданный Архитектурный Трёп!

Встречаемся 1 октября с Юрием Морозовым и обсуждаем тему «Рынок найма в 2026 году и ожидания на 2027-й».

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

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

Модератор: Юрий Морозов, CTO, 10 лет строит команды, процессы и продукты

🗓 1 октября, четверг, 19:00 по Минску (GMT+3)

👉 Зарегистрироваться и задать вопрос: https://hardsoftskills.dev/architecture-trep?utm_source=tg&utm_medium=post&utm_campaign=announce

Zero downtime: почему выкладка ломается не там, где вы выбирали стратегию

Около 70% отказов у Google вызваны изменениями в живой системе. Проектируя выкладку без простоя, команды обычно спорят о стратегии: rolling, blue-green или canary.

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

⚖️ Стратегия – это выбор, чем платить

🔹 Rolling ничего не стоит по инфраструктуре, но откат у него – ещё одна раскатка на минуты, и всё это время продакшен сломан.
🔹 Blue-green откатывается за секунды, зато требует двойной ёмкости и показывает новую версию всем пользователям разом.
🔹 Canary держит радиус поражения маленьким, но растягивает выкладку. Без автоматического анализа метрик это медленный rolling с церемониями.
🔸 Feature flags работают на другом слое: управляют тем, кто видит фичу, а сам артефакт не проверяют. Поэтому зрелые команды держат и флаги, и канарейку.

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

🎰 Какая версия стоит на каком узле

Удачная стратегия не спасает, если вы не уверены, что везде стоит то, что вы выкатили. Knight Capital выкладывала новый код вручную на восемь серверов, и один из них пропустили.

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

Убыток превысил $460 млн меньше чем за час.

Откат сделал хуже, потому что его никто не продумал заранее.

🧊 Откат возвращает только код

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

Образ возвращается за секунды, но кэш, очереди и сессии остаются такими, какими их оставила новая версия.

Конфигурация – такая же выкладка. У Google она запускает почти треть инцидентов. CrowdStrike раскатывал бинарники сенсора поэтапно, а обновление контента пустил без канарейки и уронил в синий экран миллионы машин с Windows.

🧪 Что проверить до следующего релиза

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

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

📚 Что почитать:

Наше короткое видео с high-level дизайном

"Postmortem Analysis" – Google SRE Workbook
"Knight Capital order 34-70694" – SEC, 2013

Рынок найма в 2026 году и ожидания на 2027-й – выводы Архитектурного Трёпа #133

После долгого перерыва, вчера мы снова собрались на Архитектурный Трёп! Разговаривали о том, что сейчас происходит с наймом разработчиков.

🧠 ИИ и ценность разработчика

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

Синтаксис берёт на себя ИИ, поэтому кодер сам по себе перестаёт быть ценным. Ценится понимание того, как делается софт, и тогда язык вторичен.

У меня есть такой человек один, которому дали ИИшку попробовать порядка года назад. За последний год он сделал 4 проекта длительностью приблизительно по 3-4 месяца. И он это смог сделать только потому, что он отлично понимает, что такое разработка софта, а не то, как писать на Python.

📉 Рынок сжался

Из примерно 80 компаний, с которыми летом обсуждали трудоустройство сокращённых разработчиков:

🔸 треть сама сокращалась;
🔸 треть держала найм на фризе;
🔸 треть нанимала точечно, под конкретную потребность.

Сокращают уже сейчас, потому что с ИИ растёт продуктивность: в некоторых вакансиях менеджера прямо пишут, что управлять предстоит агентами. Обратная сторона в том, что компании перестают нанимать junior и middle, и в перспективе это даст нехватку людей, которые будут сопровождать сгенерированный код.

🧗 Как пройти найм

Вернулись многостадийные собеседования: вне Big Tech бывает по 5–6 стадий, на каждую уходит около недели, хотя нормой участники называли три – пре-скрин, техническое интервью и финал с менеджером.

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

Часть разработчиков не пытается сделать из собеседования какую-то презентацию себя. 80%, допустим, идут на собес, не знают ничего о компании, то есть даже не удосужились почитать.

🔇 Почему отклик уходит в тишину

Тишина – следствие объёма. Сервисы автооткликов через API HeadHunter бьют по всем хоть сколько-нибудь подходящим вакансиям: на одну новую вакансию за первый час пришло 300 откликов, и все нерелевантные.

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

После 30 лет к фильтрам добавляется возраст: входящих предложений резко меньше, а LinkedIn определяет его, даже если не указывать и скрыть ранний опыт.

Три года назад на вакансию .NET-разработчика приходило 5–6 толковых резюме в неделю, теперь – около 70 откликов, которые физически не обработать.

👻 Компании пропадают после контакта

Пропасть после хорошего разговора стало для компаний нормой, особенно в аутсорсе и аутстаффе: "осталось только интервью с клиентом" – и тишина. Обходится это дороже, чем кажется: туда, где этапы прошли по-человечески, кандидаты возвращаются, а в пропавшие компании больше не пойдут.

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

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

Так, ну что? Выводы по Архитектурному Трёпу прочитали, а теперь готовимся регистрироваться на следующий ивент.

Написать тест с помощью ИИ сегодня – задача несложная. А что делать, когда в продукте больше 10 000 тест-кейсов, а код написан на пяти языках?

🎙 Ответ на этот вопрос – на открытом докладе H&S Conclave

ИИ-решение для массовой генерации тестов с Дмитрием Винокуровым.

🔥 Что разберём

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

🔸 Как устроено решение: система на Python и Anthropic.

🔸 На каком масштабе: с мая система работает на продукте из 28 компонентов на Python, Go, PHP, JavaScript и Rust, в котором больше 11 000 тест-кейсов.

🔸 Что показала эксплуатация: результаты работы в реальных условиях.

Спикер: Дмитрий Винокуров – Staff SDET Engineer, в разработке с 2009 года, специализация – Linux, Python, QA и AI.

Встреча записывается.

🗓 8 октября, четверг, в 20:00 (GMT+3)

👉 Зарегистрироваться

AI ускорил разработку в разы – так или нет?

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

Код и правда пишется быстрее. Фича целиком – быстрее обычно не пишется.

⚡️ Ускорение действительно есть

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

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

🔗 Фича – это цепочка этапов

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

По данным IDC, которые Atlassian приводит в отчёте 2025 года, на само написание кода уходит около шестой части рабочего времени разработчика. Остальное AI практически не ускорил, и лучше всего это видно по ревью.

Сколько ни сжимай один этап разработки, остальные не изменятся.

🔍 Ревью не сжалось, а выросло

AI часто пишет правдоподобный код со скрытыми ошибками. Он выглядит готовым, проходит беглый взгляд и тесты, а ломается на логике.

Поэтому проверять его приходится не менее тщательно, чем код коллеги-новичка, а иногда и тщательнее.

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

В телеметрии компании Faros (отчёт 2025 года) на командах с высоким внедрением AI время ревью PR выросло почти вдвое. А путь от PR до продакшена в целом по компаниям при этом не сократился.

Выигрыш на коде растворяется на ревью и остальных этапах.

📋 Что делать, когда просят оценку "с учётом AI"

🔹 разложите оценку по этапам и покажите, где уходит время;
🔹 ускорение закладывайте только на написание кода, и то не везде: на правках знакомого зрелого кода его не закладывайте;
🔹 ревью AI-кода – ваша нагрузка, закладывайте её отдельно: вместе с кодом она не сжалась;
🔹 в прототипах и одноразовых скриптах код – почти вся работа, поэтому ускорение доходит до результата почти без потерь, и сжатый срок там оправдан.

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

Но пока ответ на вопрос из заголовка – нет. Разработка ускорится в разы, только когда вслед за кодом ускорятся и остальные её этапы.

📚 Что почитать:

Наше короткое видео в Instagram на эту тему

"State of Developer Experience 2025" – Atlassian, 2025
"The AI Productivity Paradox" – Faros AI, 2025

🎓 Мы завершили второй поток курса AI-Driven Development и разобрали 421 сессию: как инженеры растут в работе с ИИ-агентами

Оба потока вёл Сергей Голубев, и ему отдельное спасибо за курс.

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

Логи прислали 15 участников, по ним мы выдали 79 рекомендаций.

🔸 Что увидели

Во второй половине курса работ уровня «уверенный оператор» и выше стало 89% вместо 59%, хотя средний балл по навыкам не изменился. Разницу дала одна привычка: остановиться, когда агент предупреждает о риске для репозитория, данных или ключей. Во втором модуле предупреждение пропустили в трёх работах из 14, в пятом и шестом не пропустил никто.

Сильнее всего у группы постановка задачи и проверка результата. Слабее всего точка отката перед рискованным шагом.

Рекомендации берут в работу почти все: 44 из 45 проверенных. Полностью выполнили 19: привычка перестраивается постепенно.

Чаще всего повторялись пропущенное предупреждение, сложная задача одной строкой и все задачи в одной сессии.

🔸 Что проверить у себя

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

Если учите этому команду, смотрите не только на результат, но и на то, как человек к нему шёл. Логи – один из способов. Похожую картину дают ревью плана до начала работы и разбор одной сессии на ретро.

Полный разбор с графиками, восемью навыками и тем, как мы считали:
👉 https://hardsoftskills.dev/aidd-session-logs

Какую проблему решает Raft

Чтобы данные не пропали вместе с сервером, их хранят сразу на нескольких серверах. Такие серверы называют репликами.

Один из них главный (лидер): клиент пишет в него, а лидер пересылает запись остальным.

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

🧩 Серверы не знают, упал ли лидер

Реплики видят одно: от лидера перестали приходить сообщения. Упал он, отрезан сетью или просто тормозит – по этой тишине не отличить.

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

💥 Проблемы, которые решает Raft

Возьмём серверы A, B и C, лидер – A. Вот что бывает, если лидера назначает внешний координатор, а A отвечает клиенту "OK", не дожидаясь, пока запись дойдёт до B и C.

🔹 1. Два лидера сразу. Сеть отрезала A от B и C. A жив: клиент 1 пишет на него x = 1 и получает "OK". Координатор не слышит A и назначает B, клиент 2 пишет туда x = 2 и тоже получает "OK".

🔹 2. Подтверждённая запись пропадает. Сеть восстановилась, лидер должен остаться один, и A понижают, стирая его x = 1, хотя клиенту 1 уже сказали "OK". Бывает и без разрыва: A подтвердил запись, не дождавшись B и C, и упал, а новый лидер B о ней не знает.

🔹 3. Копии расходятся. Если записи A не стирать, у A и B окажутся конфликтующие записи. Сводят их вручную или по правилу "побеждает последняя", но тогда одна из них теряется, хотя клиенту ответили "ОК".

🔹 4. Без автоматики запись стоит. Чтобы не получить двух лидеров, переключение оставляют человеку. Тогда после падения A запись стоит, пока дежурный не разберётся, кто жив, и не назначит лидера руками.

🎯 Raft сделал консенсус понятным

Каждое из четырёх правил Raft закрывает проблемы выше:

🔹 OK от лидера клиенту – только когда запись сохранило большинство. Отрезанный A один и подтвердить x = 1 не может;
🔹 у каждых выборов лидера свой номер – срок (term). В сроке у сервера один голос, а лидеру нужно большинство, поэтому двух лидеров в сроке не бывает. Когда A возвращается после падения, он видит, что срок уже не его, становится репликой и актуализирует свой лог по B, стирая только записи без "OK";
🔹 серверы голосуют только за кандидата с журналом не старее своего. Подтверждённая запись есть хотя бы у одного из голосующих, и он не отдаст голос кандидату без неё. Значит, новый лидер уже содержит всё подтверждённое;
🔹 выборы запускаются сами: сервер, который долго не слышал лидера, выдвигается по своему случайному таймеру. Если он принял тормозящего лидера за упавшего, будут лишние выборы, а не потеря данных.

Raft был создан специально, чтобы алгоритм был простым. Подобные алгоритмы были и до него, но они были невероятно сложными и всех свои.

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

По гарантиям он в одном классе с Multi-Paxos и Zab (внутри ZooKeeper): если они у вас уже работают, менять их незачем.

⚖️ Выбор решает модель отказов

🔹 Raft – его берут, когда серверы свои и не подменят данные, а защита нужна от падения сервера и обрыва связи, чтобы порядок записей везде совпадал. Кластер из 2f+1 серверов переживает f отказов.

На нём стоят etcd, Kubernetes, Consul, метаданные Kafka (KRaft), CockroachDB, TiKV/TiDB и quorum queues в RabbitMQ.

🛡 BFT (византийская отказоустойчивость) нужна, если сервер способен лгать: Raft защищает от падений и обрывов связи, но не от ложных данных. PBFT, HotStuff и CometBFT платят за это числом серверов – 3f+1, то есть 4 вместо 3 на один сбой.

🌊 Когда доступность записи важнее согласованности, подходят кворумы без консенсуса, как в Cassandra и Riak. При R+W>N кворумы пересекаются, но одного порядка записей нет. Цена – расхождение копий.

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

Программировать с AI и без – два разных навыка

Агент пишет аккуратный код не о том, вы правите его по кругу и решаете, что проще написать самому.

Выпускник второго потока курса AI-Driven Development описал работу с агентом так:

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

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

Агент, как правило, не переспрашивает: он делает допущение за вас и работает дальше. Каждую сессию он начинает с нуля.

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

✍️ Постановку, шаги и риск теперь продумывают заранее

Раз агент не переспросит, неверные прочтения приходится закрывать заранее: что значит "готово", где границы, чего не трогать.

Но письменная постановка не поможет, если результат нельзя проверить, поэтому дробить задачу нужно под проверку.

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

План с шагами нужен и следующей сессии: по нему она видит, что уже сделано.

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

🔍 Проверка держится на понимании разработки, которое нарабатывается с опытом

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

В эксперименте января 2026 года 52 инженера осваивали незнакомую библиотеку: одна группа с AI-ассистентом, другая без него. Затем в тесте на понимание этой библиотеки группа с AI набрала 50% против 67%, и самый большой разрыв пришёлся на вопросы отладки.

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

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

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

📚 Что почитать:

"How AI assistance impacts the formation of coding skills" – Anthropic, 29.01.2026
"Как инженеры растут в работе с ИИ-агентами" – наша статья по итогам второго потока AI-Driven Development

🚀 Запускаем два AI-курса – старт в ноябре

В посте выше – выводы по второму потоку AI-Driven Development: программировать с AI и без – два разных навыка. Работа с агентом ближе к работе техлида: заранее продумать постановку, разбить задачу на шаги, которые можно проверить, и самому принять результат. А чтобы проверить код агента, нужно уметь его читать и отлаживать и понимать систему целиком. С этим идём в новые потоки – последние в этом году.

Курсов два, это ступени одной линейки: первый учит работать с готовыми AI-инструментами, второй – строить на LLM собственные продукты.

🔸 AI-Driven Development (Level 1) – третий поток
Старт 4 ноября, 7 недель

Для чего: встроить AI в ежедневную работу разработчика. AI IDE (Cursor, Windsurf, Copilot), AI в терминале, готовые MCP-серверы, генерация интерфейсов, AI-ревью кода, тесты и документация, рефакторинг legacy с сохранением поведения и работа с AI в рамках NDA.

Для кого: backend-, frontend- и fullstack-инженеры, DevOps, QA-автоматизаторы и системные аналитики с опытом коммерческой разработки от 1–2 лет.

Результат: сквозной проект на вашем коде – свой MCP-сервер, дашборд и автономный агент в n8n.

Ведёт @sedruid Никита Шумилин – Solution Architect в high-load компании: отвечает за архитектуру системы из 30+ сервисов и внедряет AI-практики в инженерные команды.

🔸 Продуктовая AI-разработка (Level 2) – второй поток
Старт 3 ноября, 7 недель

Для чего: проектировать и выводить в продакшен собственные продукты на LLM. Multiagent-системы, свои MCP-серверы, RAG на Qdrant, агенты на LangGraph, а вокруг них evals, observability, контроль расходов на токены и безопасность.

Для кого: backend-, frontend-, fullstack- и AI/ML-инженеры и техлиды с опытом коммерческой разработки от 2 лет на Python или TypeScript. Нужен уровень L1 или эквивалент: уверенная работа в AI IDE и базовый промптинг.

Результат: своя multiagent-система из трёх агентов под вашу профессиональную область, выведенная в продакшен.

Ведёт @ilya_chakun Илья Чекун – Software Engineer и Tech Lead в Datatrans AG (платёжный провайдер): строит платёжные платформы и agentic-инструменты, которые ведут задачу от тикета до готового PR.

🤔 Какой выбрать

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

Если AI пока не стал частью вашей ежедневной работы – начинайте с AI-Driven Development. Если вы уже уверенно работаете в AI IDE и хотите строить на LLM своё – идите на Продуктовую AI-разработку.

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

Программа и даты:
👉 AI-Driven Development
👉 Продуктовая AI-разработка

Вайб-кодинг vs AI-driven development

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

Теперь правки то и дело ломают то, что работало, хотя модель и промпты те же.

Такой способ работы называют вайб-кодингом, и на малом проекте он работает. Но только при двух условиях.

Проект целиком помещается в контекст, то есть во всё, что агент видит в текущей сессии: инструкции, код, историю переписки. А проверка "запустил – работает" покрывает всё поведение. Пока инструмент маленький, оба условия выполняются сами собой. С ростом проекта код перестаёт помещаться в контекст, а проверять всё вручную становится слишком затратно.

🔁 Как замыкается круг

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

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

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

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

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

🛠 Видимость и проверка, построенные намеренно

В AI-Driven Development с тем же агентом работают иначе: проект заранее готовят под него. В репозитории появляются правила работы с контекстом, ограничения, записанные правила архитектуры и документация. Они возвращают агенту рамки, в которых он видит только нужное для задачи.

Вместо "веди себя как senior-разработчик" и "пиши код без багов" в промпте – системный подход:

🔹 Управление контекстом возвращает видимость. Одна сессия ведёт одну задачу. Постоянный файл инструкций короткий и работает как карта, а остальное агент подгружает по требованию из скиллов и наборов инструкций под конкретную задачу.

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

🔹 Тесты заменяют "выглядит сделанным": перед словом "готово" агент прогоняет все тесты проекта, а CI не даёт коммиту сломать работающее.

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

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

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

Агент остаётся тем же, меняется проект вокруг него, так что это развитие вайб-кодинга, и менять инструмент не приходится.

✅ С чего начать

Если агент уже ломает то, что работает, начните с аудита и создания структуры.

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

🎓 Как перейти от вайб-кодинга к инженерии, разбираем на курсе [AI-Driven Development]. Стартуем 4 ноября.

🎙 Приглашаем на круглый стол [AI в работе инженера – чего ждут на собеседованиях и что нельзя отдавать агенту].

Четыре практика обсудят, где проходит граница доверия AI.

🔥 Что обсудим

🔸 Чего ждут от инженера про AI на собеседованиях: что компании пишут в требованиях и что хотят услышать от кандидата.
🔸 Стартап, enterprise и AI-native: где хватит показать, как вы пишете код с AI, а где спросят про evals, observability и guardrails.
🔸 Что нельзя отдавать агенту: где делегирование заканчивается и кто отвечает за код, если его написал агент.

Участники:
Павел Вейник, Solution Architect – модератор
Сергей Голубев, Product Manager & AI Creator
Илья Чекун, Tech Lead, AI Engineer
Никита Шумилин, Solution Architect, AI Engineer

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

В конце представим курсы «AI-Driven Development» (Level 1) и «Продуктовая AI-разработка» (Level 2).

🗓 27 октября в 19:00 (GMT+3), онлайн в Google Meet
👉 Записаться на круглый стол

Какие навыки разработчика становятся ценнее?

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

💻 Навыки написания кода дешевеют

"Стать ещё сильнее в коде" вряд ли получится, и в самом коде какую-то особую ценность может иметь только узкая экспертиза: глубокое знание конкретной системы и её домена, редкий или старый стек и т.д.

"Освоить AI-инструменты" тоже мало: они уже стоят в требованиях вакансий, и без них могут даже не позвать на собеседование, но и выделиться с ними не выйдет.

🎯 Что строить, по-прежнему решает человек

В исследовании Anthropic по 400 000 сессий в Claude Code видно, что решения планирования (что делать, какой подход выбрать, что считать готовым) примерно в 70% случаев принимает человек, а решения исполнения (какие файлы менять, какой код писать) лишь в 20%.

Успех сессии сильнее зависит от того, насколько человек понимает проблему, чем от умения программировать. Похоже, и знание, что нужно пользователю и бизнесу, агент на себя пока что взять не может.

Ошибка "написали не так" дешевеет вместе с кодом, а ошибка "построили не то" – нет. Ценнее на рынке становится тот, кто её не допускает.

📈 Три навыка против "построили не то"

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

🔸 System Design: как перевести это "зачем" в устройство системы. Когда код пишет AI, проектирование остаётся главным делом человека: от сеньора его ждали и раньше, а теперь всё чаще ждут и от мидла.

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

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

🧭 Продакт-менеджером становиться не нужно

Продуктовая функция к инженерам целиком не переходит: весной в технологических компаниях было открыто больше 7 300 вакансий продакт-менеджеров – заметно больше, чем на минимуме начала 2023 года. Понимание продукта без технической глубины тоже не работает, поэтому System Design в этом списке стоит рядом с ним.

Так за что будут нанимать и держать? Не за то, что вы умеете написать: эту планку AI поднял всем, а ошибку "написали не так" теперь дёшево переписать (если вовремя её отловить).

Держать будут за то, что вы не строите не то: понимаете, что и зачем делать, умеете устроить под это систему и способны аргументированно принимать правильные решения.

📚 Что почитать:

Anthropic – Agentic coding and persistent returns to expertise (2026): какие решения агент берёт на себя, а какие остаются у человека

Архитектурные катастрофы – часть 13: агенты OpenAI сами взломали Hugging Face

Летом 2026 года около 700 агентов, которых OpenAI проверял в изолированной среде, участвовали в атаке на Hugging Face.

🧪 Какие были условия

На проверке ExploitGym модель ищет уязвимость в учебной программе, поэтому предохранители против киберзадач намеренно ослабили.

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

📌 Один сервис пробил обе изоляции

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

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

🖥 Второй выход - под песочницей

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

🎯 Взлом ради ноля баллов

Агенты скачали 4 закрытых репозитория с исходниками самого Hugging Face. По разбору METR, большинство хотело понять, как устроена программа, которая выставляла баллы: часть задач не решалась в принципе, и агенты искали обход.

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

🧭 Что этот инцидент значит

METR нашел сильные свидетельства, что агенты понимали: атака в задание не входит. Один из них записал: "Атака на внешнюю инфраструктуру – вне предусмотренных рамок. Но задача невозможна, и другие это делают. Надо продолжать."

Решение было их собственным: атаку не заказывал ни внешний противник, ни оператор, это модели самой OpenAI на ее собственной проверке.

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

Владелец агентов узнал об этом последним: атаку заметил и пресек сам Hugging Face, а тревога OpenAI сработала лишь через шесть дней после конца вторжения.

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

📚 Что почитать:

Посмотрите наше короткое видео на эту тему

"The Hugging Face incident and the road ahead" – OpenAI, 26.08.2026

"Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident" – METR и Redwood Research, 26.08.2026