Книжный куб

Jev: интеллект для обычного if (Рубрика #AI4SDLC)

В предыдущем посте Диогу Алмейда предлагал учить AI принимать решения, которые можно встроить в обычную программу. У этой идеи уже появилось вполне осязаемое продолжение: модель Jev от его компании TypeSafe. Любопытно здесь то, сколько возможностей разработчики согласились отдать ради одного полезного свойства — быстро отвечать на маленькие вопросы.

15 сентября 2026 года TypeSafe открыла ранний доступ к Jev и объявила о раунде на $40 млн под руководством DCVC. Модель вообще не пишет свободный текст. Ей передают состояние — например, обращение клиента и сведения о заказе — и набор вопросов с заранее заданной формой ответа:
- Choice выбирает вариант из списка: в какую очередь отправить обращение;
- Score оценивает по описанной шкале: насколько срочно нужна помощь;
- Noul возвращает вероятность ответа «да»: просит ли клиент вернуть деньги.

Вопросы обрабатываются параллельно; Choice и Score тоже возвращают вероятности возможных ответов. Дальше обычный код решает, что делать: направить заявку нужной команде, запросить недостающие данные, передать человеку. Модель можно поставить внутрь знакомого if, а правила перехода между шагами оставить в программе. Именно из таких деталей и собирается автоматизация.

Метод обучения TypeSafe назвала RLCD — Reinforcement Learning for Calibrated Decisions. Его заявленная цель — согласовать вероятности с реальной частотой событий. Если модель много раз говорит «вероятность 80%», примерно в 80% этих случаев событие должно происходить. Тогда можно подобрать порог для автоматического действия, а сомнительные случаи отправлять на разбор. Разумеется, такую калибровку еще нужно проверить на своих данных.

За отказ от генерации обещают щедро заплатить скоростью. В собственных тестах рабочих процессов TypeSafe получила ускорение до 193,6 раза и снижение стоимости до 444,6 раза относительно сравниваемых LLM. Сама компания считает такой выигрыш оптимистичным ориентиром для реальных задач. Есть и методическая тонкость: эталоном служило усреднение ответов сильных моделей, так что тест измерял согласие с ними, а не независимо установленную правильность.

Появились и внешние эксперименты. 20 сентября LangChain опубликовала проверку, в которой Jev оценивал пять ответов погодного агента, каждый по 100 раз. Все 500 бинарных оценок совпали с разметкой человека, средний вызов занимал 0,44 секунды. Звучит бодро, но пять разных примеров остаются пятью: повторы хорошо показывают устойчивость, а широту возможностей придется проверять отдельно.

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

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

Попробовать можно через OpenRouter: модель typesafe/jev-1.13, на 20 сентября — $0,042 за миллион входных токенов, выход бесплатный. Хороший повод взять одну повторяющуюся развилку в своем коде и проверить, как изменятся задержка и число ошибок.

#AI4SDLC #AI #Architecture #Evals #Engineering

Диогу Алмейда: AI, за которым можно не присматривать (Рубрика #AI4SDLC)

Почему AI впечатляет решением сложных задач, а обычный возврат денег клиенту всё ещё страшно поручить ему без проверки? В 18-минутном июльском выступлении на AI Engineer Диогу Алмейда предлагает искать ответ в цели обучения. По его мнению, индустрия научилась делать отличных помощников, а надёжная автоматизация требует другого набора свойств. Алмейда — один из основных авторов InstructGPT, работы 2022 года, которая помогла превратить языковую модель в исполнителя инструкций. Теперь он разбирает ограничения этого подхода. Получается интересная исследовательская петля: сначала научить AI работать с человеком, затем понять, что мешает убрать постоянный присмотр.

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

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

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

У этой критики есть предметная опора. В отчёте GPT-4 показано, что после постобучения модель хуже оценивала вероятность правильности своих ответов на подмножестве MMLU. При этом результаты на TruthfulQA улучшились. То есть можно чаще отвечать правильно, но хуже соотносить уверенность с реальной точностью. Два разных свойства, которые легко склеить в одно слово «качество».

Для автоматизации Алмейда предлагает отдельную цель — калиброванные решения. Если система выдаёт вероятность 90%, то на большой группе таких прогнозов доля верных должна быть около 90%. Тогда можно настраивать границы: где программа действует сама, где запрашивает дополнительные данные, где передаёт случай человеку. Эти границы всё равно придётся проверять на своих задачах, так как ваше распределение решений может отличаться.

Сильная часть аргумента — требование сделать неопределённость пригодной для программирования. А вот необходимость человека при каждом запуске из RLHF автоматически не следует. Человек участвует в обучении; сколько проверки потребуется при эксплуатации, зависит от реальных ошибок и цены их последствий. Поэтому объяснять все проблемы автоматизации одним методом обучения было бы слишком удобно.

Ещё у Алмейды есть хороший поворот про программное обеспечение. AI уже помогает быстрее писать код, а он хочет изменить сами возможности готовой программы: добавить в неё смысловые суждения, которые можно проверять и соединять с обычной логикой. Условие «клиент действительно просит возврат» гораздо труднее выразить кодом, чем проверку суммы или даты.

На момент выступления его TypeSafe ещё готовилась к релизу, который состоялся 15 сентября. Собственно, у этой идеи появился API и модель Jev, про которую мы поговорим в следующем посте.

#AI #AI4SDLC #Engineering #Automation #Research

Материалы 3 AImigo S1E6: как не утонуть в потоке AI-изменений и сохранить силы (Рубрика #AI)

Готовы материалы шестого выпуска 3 AImigo, который вышел 18 сентября 2026 года. Вместе с Евгением Сергеевым и Алексеем Литвиновым обсудили, как оставаться в контексте AI, когда на чтение всех новостей, проверку новых моделей и собственно жизнь претендуют одни и те же часы.

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

Обсудили
- Как выбирать, за чем следить. Евгений начинает с личных целей и планирования недели. Я использую технологический радар: читать сейчас, наблюдать или перестать отслеживать. И прошу подбирать материалы, которые расширяют картину мира, а не только подтверждают то, что уже думаю.
- Когда подборку полезнее отключить. Алексей перестал читать автоматическую ленту и отказался от неё. Темы для изучения ему дают задачи компаний, профессиональное окружение и собственные эксперименты. Это его способ отбора; общего рецепта для всех здесь нет.
- Где заканчивается помощь агента-тьютора. На моём примере разобрали программу от инфраструктуры дата-центров до моделей и платформ. Подготовить теорию и упражнения можно быстро, а дальше приходится задавать вопросы, пробовать руками и подстраивать нагрузку под свои силы.
- Зачем оставлять время без входящей информации. Схема от руки, заметка своими словами, подготовка выступления — способы переработать материал. В опыте ведущих прогулка или бег без подкаста тоже помогают освободить голову. Не каждую свободную минуту обязательно заполнять ещё одной лекцией :)
- Как отличать прогресс от занятости. Евгений ведёт вечерний дневник: приблизил ли день к выбранной цели? При этом он признаёт, что агенты позволяют запустить больше параллельных процессов, чем хватает сил сопровождать. Уметь запускать ещё одну задачу и иметь на неё внимание — разные вещи.

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

Материалы выпуска:

- Страница выпуска с содержанием и таймкодами
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: конспект разговора

Как вы выбираете, что изучать, а что пропускать? И как понимаете, что действительно чему-то научились, а не просто разгребли очередную подборку?

#AI #AI4SDLC #Agents #Education #Engineering #Podcast

Regenerative Software — Чад Фаулер (Рубрика #Books)

Книга ещё не дописана, а рекомендовать её уже хочется. "Regenerative Software" Чада Фаулера выходит у O’Reilly в Early Release, и текущие главы, на мой взгляд, очень хорошо объясняют, куда движется разработка софта и почему. Финальный релиз издательство пока планирует на апрель 2027 года, но предмет для разговора уже есть.

Фаулер начинает с экономики. Десятилетиями работающий код было дорого создавать, поэтому вокруг его сохранения выросла вся культура разработки. При этом в коде оседало знание о системе: странные исключения, последствия инцидентов, особенности клиентов. Когда всё это существует только внутри реализации, переписывание превращается в археологическую работу. Новую версию написать можно. Вспомнить всё, что было зашито в старой версии, гораздо сложнее (и никто это без острой нужды не делал). Кстати, эти размышления напоминают те, что были в whitepaper "What Happens When Technical Debt Vanishes?", что я уже разбирал.

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

Отсюда и regenerative software: систему проектируют так, чтобы её части можно было заново создавать, сохраняя накопленное знание. Реализация может смениться, а контракты, ограничения, проверки и причины решений должны пережить эту смену. У Фаулера есть хорошая аналогия с инфраструктурой: мы уже ушли от pets к catlle и научились пересоздавать сервера из yaml файлов. Теперь он предлагает продумать, что потребуется для такой же заменяемости самого софта (видимо много md файлов).

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

Особенно показательна глава про evaluations. Фаулер рассказывает, как участвовал в переписывании системы для школ: современная архитектура, TDD, стопроцентное покрытие unit-тестами. Пользователи новую систему не приняли, и её пришлось откатить. Нужное им поведение жило в привычках и неявных правилах работы, которые команда не перенесла в требования. Все тесты были зелёными. Проверяли просто не всё, что имело значение.

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

Ещё один важный слой — provenance или история происхождения решений. Почему здесь ограничено число повторных попыток? Почему валидация продублирована? Какие варианты уже пробовали и отвергли? Для следующего инженера или агента эти причины должны быть доступны вместе с подтверждающими данными. Иначе очередное «упрощение» легко удалит защиту от старой аварии.

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

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

#Books #AI4SDLC #Architecture #Engineering #Software

Материалы 3 AImigo S1E5: джун без простых задач (Рубрика #AI4SDLC)

Готовы материалы пятого выпуска 3 AImigo, который вышел 11 сентября 2026 года. Вместе с Евгением Сергеевым и Алексеем Литвиновым продолжили разговор о найме со стороны начинающего инженера: если небольшие исправления и доработки можно отдать агенту, на чём теперь учиться человеку, которому ещё только предстоит получить первую работу?

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

Обсудили:
- Кто будет растить следующих инженеров. Отрасли нужны будущие опытные специалисты, а отдельной компании может быть выгоднее усилить тех, кто уже умеет работать. Обсудили этот конфликт интересов; при этом успешные стажировки для сильных олимпиадников нельзя автоматически считать моделью для всех новичков.
- Собственный проект как входной билет. Пройти путь от проблемы пользователя до запуска и поддержки. Особенно интересно, что происходит после первой работающей версии: ошибки, новые требования и необходимость разобраться в том, что собрал агент.
- Что показывать работодателю. Алексей предлагает разбирать историю проекта: как организована работа агентов, какие есть инструкции и автоматические проверки, что делали при сбоях. По такому разговору видно, какие решения человек принимал сам и чем проверял результат.
- Как учиться с AI. Инженерные основы и работу с агентами можно осваивать параллельно. Оглавления технических книг помогают обнаружить пробелы, а дальше — вопросы, примеры и проверка понимания. Скопировать незнакомый термин в AGENTS.md ещё не значит в нём разобраться :)
- Как устроить стажировку. Новичок объясняет задачу и критерии приёмки, защищает решение агента перед наставником, понимает выпуск изменений и откат. Я предложил начинать с процесса конкретной компании: знать сразу все методологии для этого не требуется.

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

Материалы выпуска
- Страница выпуска с содержанием и таймкодами
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: конспект разговора

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

#AI #AI4SDLC #Engineering #Career #Education #Podcast

IT как Лего: почему эта ложная метафора приносит больше вреда, чем пользы, и что использовать вместо неё (Рубрика #Architecture)

На ArchDays 2024 в докладе про эволюцию архитектуры в Т-Банке у меня был слайд «IT as a Lego». Так выглядела концепция повторного использования решений: выделяем блоки, собираем системы из кирпичиков, всё взаимозаменяемо и красиво. Тогда я сказал коротко, что метафора не работает. Сейчас хочу разобрать, почему именно, тем более что Чад Фаулер пишет для O'Reilly книгу "Regenerative Software" ровно про это (книга топовая и я про нее расскажу сразу, как дочитаю)

Чем Лего подкупает
У кубика один интерфейс — стандартные выпуклости, и любой кубик стыкуется с любым. У кубика нет состояния, и он не меняется, пока его не трогают. Заменить кубик стоит ноль. Отсюда получается очень удобная логика для планирования: система равна списку блоков, блок равен строке в бюджете, переиспользование бесплатно, а замена системы — проект с датой окончания. По сути это та же строительная метафора, что и «сервис — это здание», только с инструкцией по сборке.

Звучит круто, но что не так с этой метафорой?
Сервис — не кубик. У него есть данные и история, неявные контракты и потребители, которые давно опираются на недокументированное поведение. В докладе я формулировал так: с точки зрения Лего замена элемента — это просто кубик, с точки зрения живой системы — трансплантация важного органа. Решения, принятые в логике Лего, узнаются по характерным фразам:
- «Возьмём коробку, потом заменим» — а исходная коробка живёт рядом с двумя волнами своих замен;
- «Назовём это платформой, и все будут переиспользовать» — а блок, вынутый из своей среды, тащит за собой её допущения и в другую среду не встаёт;
- «Это маленький сервис, заменим за спринт» — а маленьким он был только по числу строк.

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

Книга "Regenerative Software" развивает эту метафору дальше. Ее пишет сейчас Чад Фаулер— соавтор RubyGems, автор The Passionate Programmer и бывший CTO Wunderlist. Книга выходит у O'Reilly в Early Release, финальная версия ожидается в апреле 2027 года, а выросла она из серии эссе "The Phoenix Architecture", которую Фаулер публикует с декабря 2025 года. Тезис: код больше не актив, актив — система. Когда генерация кода почти бесплатна, а проверка нет, главным свойством становится replaceability — возможность безопасно заменить компонент целиком. А сохранять надо то, без чего его не воссоздать: поведение, границы, evaluations, evidence и provenance, то есть историю, почему решение именно такое. Мне понравился его deletion test: «Если удалить эту кодовую базу и сгенерировать заново, на что я буду опираться, чтобы решить, что результат правильный?» Страх при этом вопросе означает, что знание живёт только в коде.

Вторую главу Фаулер начинает с истории из Wunderlist: на замену «простого» сервиса членства в группах отвели вечер, а споткнулись о собственную систему уникальных ID, через которую всё остальное находило данные и которую уже никто целиком не понимал. Та самая трансплантация органа, только описанная изнутри.

Если продолжать биологическую аналогию (это уже моя, а не Фаулера), он предлагает не пересаживать органы, а отращивать их заново из «генома» системы: спецификаций, тестов и истории решений. Организм остаётся собой, хотя клетки в нём сменились. Насколько это заработает за пределами задач со строгими evaluations, пока неясно, и сам Фаулер оговаривает, что replaceability бывает неправильной целью. Но как рамка для решений это точно лучше кубиков.

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

#Architecture #Software #Engineering #AI #Books #Management #SystemDesign

Homa: почему GPU ждут сеть (Рубрика #AI)

Посмотрел свежий доклад Джона Оустерхаута из Stanford про Homa (Джон - соавтор протокола консенсуса Raft, а также автор крутой книги "A Philosophy of Software Design", о которой я уже рассказывал). В заголовке доклада заявлен тизис «конец TCP для AI-кластеров», а внутри интересный инженерный вопрос: сколько времени дорогие GPU простаивают, пока маленькое сообщение ждёт за большой передачей? По мысли Оустерхаута, в инференсе и агентных системах растёт роль коротких обменов: проверить запись в распределённом KV-кэше, согласовать следующий шаг вычислений. Здесь важна хвостовая задержка: один запоздавший ответ может задержать всех участников синхронизации.

Проблема хорошо известна распределённым системам (она буквально продолжает историю "The Tail at Scale", что я разбирал вчера). Когда несколько серверов одновременно отправляют данные одному получателю, перед его сетевым портом растёт очередь — incast. Короткому сообщению тоже приходится ждать.

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

В показанном бенчмарке, по данным автора, p99 задержки коротких сообщений у Homa примерно в 13 раз ниже, чем у TCP. Большие сообщения при этом тоже выигрывают. Уже есть Linux-модуль, тесты и утилиты измерений. Но с заголовком и широтой выводов я бы поспорил.

1️⃣ На слайде презентации сетевой бенчмарк, который демонстрирует эффект использования протокола
Ускорения LLM в 13 раз из него не следует: нужно измерять время ответа приложения, tokens/s и загрузку GPU. Выигрыш зависит от того, какая доля ожидания действительно приходится на транспорт.
2️⃣ Отрасль давно работает над этой проблемой
Google описал промышленное применение Swift, а SIRD исследует, как согласовывать решения получателей, когда узким местом становится общий канал. Сравнение с TCP ещё не закрывает спор о лучшем транспорте.
3️⃣ Границы применимости существенны: Homa рассчитан на сеть внутри дата-центра. Нужны интеграция с приложением и настройка сети; разработка grpc_homa приостановлена. Для внедрения работы хватает.

Почитать подробнее — научные статьи и техническое обоснование:
— Homa, SIGCOMM 2018 — устройство протокола.
— Linux-реализация, USENIX ATC 2021 — измерения на 40 узлах; на странице есть PDF.
— It’s Time to Replace TCP in the Datacenter — аргументы Оустерхаута против архитектуры TCP в ЦОД.

Кстати, в конце доклада автор приглашает экспериментировать с Homa и обещает помощь: ouster@cs.stanford.edu. Хорошая задача для входа — проверить, сколько сетевого выигрыша сохраняется в реальной AI-нагрузке. Вот такой результат мне было бы интересно увидеть.

#AI #Architecture #Engineering #Research #PlatformEngineering

The Tail at Scale: как побороть медленный хвост (Рубрика #DistributedSystems)

В моих заметках к whitepaper 2013 года "The Tail at Scale" у меня сошлись Monarch, Cassandra, QoS и Harvest/Yield & CAP теорема. Статья хорошо связывает эти темы через один вопрос: как быстро отвечать пользователю, если для ответа нужны сотни серверов, а кто-нибудь из них нет-нет да и тормозит?

Jeffrey Dean и Luiz André Barroso, оба на тот момент Google Fellows, опубликовали её в Communications of the ACM в феврале 2013 года. Они обобщают опыт инфраструктуры Google: интерактивный поиск и чтение распределённых данных, где редкая задержка одного узла становится проблемой всего сервиса.

Если каждый сервер отвечает дольше секунды в 1% случаев, то при запросе к 100 серверам и ожидании всех ответов медленным окажется уже примерно 63% запросов. Здесь обычная теория вероятностей: 1 − 0,99¹⁰⁰. При условии независимости задержек! В моём разборе Monarch, всепланетной системы для телеметрии в Google, уже встречалась другая сторона этой задачи: заранее исключать ненужные узлы из запроса.

Авторы предлагают строить tail-tolerant системы: предсказуемо быстрый сервис из компонентов с непредсказуемым временем ответа. Часть нужных ресурсов уже есть — реплики, созданные для отказоустойчивости. Осталось научиться использовать их и против задержек.

Что для этого делают:

🔸 Hedged requests
Если первая реплика долго молчит, отправляем копию запроса другой; получив ответ, отменяем остальные. В тесте Google чтение 1000 ключей BigTable со 100 серверов с дубликатом после 10 мс сократило p99.9 всей операции с 1800 до 74 мс при +2% запросов. Это результат конкретного теста; число запросов ещё не равно расходу CPU или диска.

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

🔸 Мелкие партиции и выборочная репликация
Делим работу на большее число частей, чем машин, переносим части между ними, популярные данные дополнительно реплицируем. Здесь вспоминаются виртуальные узлы Cassandra. Но микропартиционирование шире consistent hashing, а равномерно разложенные данные ещё не означают равномерную нагрузку.

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

Ещё две рифмы из заметок: временное исключение медленного узла напоминает circuit breaker, а проверка опасного запроса на паре серверов перед массовой рассылкой — canary release на уровне запроса.

А обязательно ждать всех?
Для поиска авторы допускают иногда вернуть немного неполный результат. Это прямо связывается с Harvest/Yield у Armando Fox и Eric Brewer: полнота ответа и вероятность его получить. В их статье 1999 года уже сформулирован CAP principle. Тему гарантий я разбирал в лекции о CAP/PACELC и Cassandra в Центральном Университете. Здесь важно различать полноту и консистентность: пропустить часть поискового индекса и прочитать несовместимые версии данных — разные проблемы.

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

#DistributedSystems #Architecture #SystemDesign #SRE #Research

Заходите на очередной эфир 3 AImigo, где мы будем обсуждать как не утонуть в потоке AI-изменений и сохранить силы.

Когда код стал дешёвым: материалы дискуссии Deep Tech Night (Рубрика #AI4SDLC)

Собрал запись и конспект дискуссии «Когда код стал дешёвым: где теперь ценность, ответственность и экспертиза?». Участвовал в ней 5 сентября 2026 года на Deep Tech Night Яндекса вместе с Александром Лукьянченко из Авито, Александром Мазько из Сбера и Олегом Смоляковым из Яндекса. Если агент пишет код быстрее, почему полезные изменения не доходят до пользователя с той же скоростью? С этого вопроса перешли к тому, как устроена работа вокруг кода.

Обсудили
- Ценность ускорения. Постановок, требований и кода становится больше, а согласования и передача контекста могут тормозить всю цепочку.
- Права и ответственность. Какие действия можно доверить агенту, где нужны изоляция и проверки — и кто будет разбираться с инцидентом после зелёных тестов.
- Обучение джунов. Ограничивать агентов в учебных задачах или сразу учить работать с ними? Здесь мнения разошлись. Я предложил проверять, понимает ли человек архитектуру и причины решений.
- Цену внимания. Несколько параллельных агентов требуют переключений и контроля. Обсудили, как оценивать результат с учётом нагрузки на инженера.

Материалы дискуссии:
📌 Страница дискуссии
📖 Мои позиции до дискуссии — лонгрид подготовки.
🎬 Запись на YouTube — 1 час 6 минут.
📝 Текстовый конспект

А у вас что стало главным ограничением после ускорения написания кода?

#AI4SDLC #AI #Agents #Engineering #Management

Research Insights Made Simple #31: AI4SDLC — что бы я делал по-другому (Рубрика #AI4SDLC)

С чего начинать свой AI-стек: с выбора модели, покупки GPU, написания собственной обвязки? На Deep Tech Night 5 сентября в рамках lighting talk я предложил начать с границы владения: что арендовать, что дорабатывать под свою среду и что обязательно держать под своим контролем.

22 сентября в 13:00 МСК в прямом эфире расскажу режиссёрскую версию этого выступления, за которое набролось 100+ голосов в одном из прошлых постов.

В центре выпуска — несколько вполне практических вопросов:
- Зачем писать собственный цикл агента, если рынок уже развивает готовые? И где своя обвязка всё-таки оправданна?
- Почему одна и та же модель даёт разный результат с разными инструментами, контекстом и правами?
- Как отличить красивый трейс от выполненной задачи — и проверить, что очередная доработка действительно помогла?
- Какие задачи можно передать меньшей модели, а где пока стоит оставить большую?

Cлайды выступления уже на сайте. Сам выпуск — 22 сентября на YouTube. Приходите, особенно если сейчас решаете, какую часть AI-стека действительно стоит делать своей.

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals

What Happens When Technical Debt Vanishes? (Рубрика #Management)

Представим, что появилась волшебная палочка, которая навсегда убирает целый класс технического долга. Миграции выполняются сами, а устаревшие feature flags исчезают, как только становятся не нужны. На это больше не требуется время инженеров. Что произойдёт с продуктивностью команды? А с метриками, которыми мы её измеряем?

Так начинается «What Happens When Technical Debt Vanishes?» Сьеры Джаспан и Коллина Грина из Google. Прочитал эту работу из серии Developer Productivity for Humans, другие исследования которой уже собирал в двух постах 1 и 2. Здесь авторы сразу предлагают мысленный эксперимент: способ устранения долга может быть любым, хоть AI, хоть статический анализ. Принимаем, что проблема решена, и разбираем последствия. Графики в статье иллюстрируют гипотезы, а не результаты замеров.

Постановка напомнила мне «No Silver Bullet» Брукса. Там есть похожий ход: допустим, мы обнулили затраты на случайную сложность разработки, привнесённую инструментами и способом реализации. Если она занимала меньше 90% усилий, даже полное её устранение не даст десятикратного ускорения. Понимание задачи и проектирование сложной системы всё ещё требуют работы. У Джаспан и Грина другой вопрос: допустим, улучшение получилось — смогут ли наши показатели его заметить?

Дальше аргумент развивается в несколько шагов

1️⃣ Освободившееся время меняет набор задач
Авторы предполагают, что компания направит его на новые функции или улучшение существующих продуктов. Там возникнут другие виды долга. Со временем организация может вернуться к привычному уровню допустимого риска, уже решая больше задач. Поэтому общая жалоба «нам мешает техдолг» может вернуться, хотя конкретную проблему действительно устранили.

2️⃣ Меняются и ожидания людей
После очистки кода удовлетворённость его качеством может вырасти, а затем снизиться: инженеры привыкнут и начнут оценивать систему относительно нового стандарта. Здесь причина возврата показателя — уже в точке отсчёта. При этом вопросы про конкретный устранённый вид долга должны сохранять улучшение.

3️⃣ Часть показателей может вообще не изменится
Число PR или строк кода не обязано вырасти, если инженеры переключились с устранения долга на другую работу. Эти счётчики плохо отражают изменение её содержания. Это хорошо продолжает их статью «All Models Are Wrong But Some Are Useful» (которую я уже разбирал): полезный эффект может оказаться за пределами выбранной модели.

Авторы даже рассматривают метрику Revenue per Engineer (выручку на инженера), как способ связать инженерную эффективность с бизнес-результатом. Но сами же оговаривают: на неё влияют рынок, продуктовая стратегия и другие части компании. Для оценки отдельной команды или человека она не подходит.

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

Поэтому я бы смотрел на три вещи:
1) Стала ли дешевле работа с конкретным видом долга
2) Куда ушло освободившееся время
3) Какой результат это позволило получить

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

#Management #Engineering #Software #Productivity #Research #Metrics

Kubernetes: слишком сложно? Материалы DevOps Deflope №62 (Рубрика #PlatformEngineering)

Сходил в гости к DevOps Deflope — вместе с Александром Качмашевым из «Точка Банк». В выпуске №62 от 13 сентября 2026 года поговорили о том, почему запустить приложение в Kubernetes проще, чем потом со всем этим жить.

Обсудили:
- Сложность Kubernetes. Что происходит, когда за привычным Helm-чартом приходится разбираться с сетями и протекающими абстракциями.
- Внутренние платформы. Какую работу они снимают с разработчиков и кто берёт её на себя. Число подключённых команд ещё не говорит, насколько им удобно.
- AI-агентов в кластере. Читать состояние, советовать и менять инфраструктуру — три разных уровня доверия. Обсудили проверки, ограниченные права и изменения через GitOps.

Материалы выпуска:
🎧 Apple Podcasts , Яндекс Музыка, Spotify
📌 Страница выпуска у меня на сайте и текстовый конспект
📖 Лонгрид моей подготовки: куда переезжает сложность Kubernetes

А у вас какая часть сложности осталась у разработчиков, а какая переехала в платформенную команду?

#PlatformEngineering #Kubernetes #DevOps #AI #Engineering

Developer Productivity for Humans: четыре противоречия AI (Рубрика #AI4SDLC)

В разборе «All Models Are Wrong But Some Are Useful» я рассказывал, почему измерение продуктивности инженеров требует баланса между speed, ease и quality. Удобная модель может просто выкинуть часть работы из рассмотрения — и показать красивое ускорение. После этого я собрал другие исследования серии Developer Productivity for Humans в двух постах 1 и 2: про цели разработчиков, качество, техдолг, онбординг и многое другое.

Теперь прочитал продолжение — «Navigating the Tensions of AI in the Software Development Lifecycle», опубликованное 4 сентября 2026 года. Здесь ребята из Google разбирают, что происходит с этой рамкой при использовании AI. Они проанализировали 1110 открытых ответов разработчиков Google о влиянии AI на их работу за последние три месяца. Это качественный анализ опыта внутри одной компании: универсального процента ускорения из него не получится, зато хорошо видны четыре противоречия.

1️⃣ Экономия работы и её перенос
Код появляется быстрее, но дальше нужно сформулировать уточнения, проверить результат, исправить ошибки. Часть нагрузки может вообще уехать к другому человеку: автор быстро отправил изменение, а ревьюеру теперь разбираться со всем сгенерированным объёмом. Ускорение одного инженера ещё надо сопоставить с затратами всей команды.

2️⃣ Быстрый результат и накопление долга
Разработчики отмечают многословный код и документацию, которая красиво написана, но плохо объясняет причины решений. Авторы связывают это с техническим, когнитивным долгом и долгом замысла (intent debt): система работает, а понимание её устройства и того, почему она устроена именно так, постепенно теряется. При этом AI может помогать и сокращать долг — вопрос в том, какие задачи ему ставить.

3️⃣ Лёгкий старт и сложная последняя миля
AI помогает быстро собрать прототип, но остаются пограничные случаи, безопасность и интеграция с внутренней инфраструктурой. В ответах даже встречались случаи, когда инструмент сообщал об успешных тестах, вообще их не запустив. По скорости появления демо легко переоценить готовность продукта:)

4️⃣ Возможность сделать и способность проверить
С AI проще взяться за незнакомый язык или систему. Но знаний для проверки решения может не хватить. Авторы обсуждают риск пропустить самостоятельное разбирательство, через которое формируется экспертиза, и со временем потерять навыки. Это риск, а не установленный этим опросом долгосрочный эффект.

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

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

P.S.
Приложил к посту свою версию этой статьи с разметкой интересных моментов (именно так я обычно и читаю whitepapers).

#AI4SDLC #AI #Engineering #Management #Productivity #Research

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

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

Как Vercel строила d0: путь агента и вопросы к результату (Рубрика #AI4SDLC)

В докладе «How We Solved Agent Building» Andrew Qu, Chief of Software в Vercel, рассказывает, как команда строила внутреннего аналитического агента d0. Каждое архитектурное решение упиралось в следующую проблему. В итоге, по оценке Qu, получился полезный агент, а затем и фреймворк eve. Насколько этот путь подтверждает слово «solved» в заголовке — хороший вопрос по ходу разбора.

1️⃣ Большой промпт: проверить, умеет ли модель решать задачу
Исходная боль вполне приземлённая: аналитиков постоянно отвлекали вопросы коллег о клиентах, продуктах и показателях. Qu начал со схемы Snowflake, вставленной в системный промпт. Модель генерировала SQL, который он копировал и запускал вручную.
Хороший дешёвый эксперимент. Но между исполняемым SQL и правильным ответом на бизнес-вопрос ещё есть расстояние: нужно выбрать нужный показатель, период, фильтры и связи между таблицами. Следующая версия должна была выполнять весь процесс.

2️⃣ Цепочка специалистов, затем один агент с общей историей
Команда разложила работу на этапы: исследовать схему, спланировать запрос, выполнить SQL, подготовить отчёт. Каждому агенту дали узкую роль и свои инструменты. По словам Qu, проблема была в передаче контекста: следующий участник получал лишь краткую выжимку предыдущего шага.
Когда выполнение обнаруживало неверное предположение, хотелось вернуться к исследованию. Поэтому этапы объединили в одного агента, который сохранял историю работы и сам переключался между планированием, выполнением и проверкой. Обобщать этот результат на все многоагентные системы рано: здесь мешали жёсткая последовательность и потеря контекста при передаче. И первые пользователи всё равно оценили новую систему плохо — их вопросы выходили за пределы сценариев разработчиков.

3️⃣ Рабочий каталог вместо разрастающейся обвязки
Следующий поворот случился, когда, по словам Qu, Claude Code с Opus 4.5 стал отвечать на их вопросы заметно лучше собственного агента. Команда перенесла этот подход в d0: изолированная среда, файлы семантического слоя, обычные инструменты чтения, поиска и bash, плюс операции для задач Vercel. Семантический слой — это описания показателей и связей между сущностями. Теперь агент мог сам исследовать их и возвращаться за деталями по мере необходимости. Qu говорит, что оценка на внутренних тестах примерно удвоилась.

Тут сразу два вопросика:
❔ Какую часть улучшения дала архитектура, а какую — более сильная модель? Доклад не позволяет разделить эти эффекты
❔ Насколько убедительны сами тесты? «100% успеха» в связанной статье — это пять успешных запросов из пяти вместо четырёх. С удвоением оценки из выступления их объединять нельзя: сопоставимость наборов не показана.

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

4️⃣ Повторяющиеся запросы превращаются в skills
После расширения использования d0 команда заметила, что многие запросы похожи по структуре. По словам Qu, регулярная задача анализирует недавние запросы и выделяет из них навыки; к моменту выступления накопилось около ста. Следующий запуск получает уже подготовленный способ работы с типовой задачей. В eve такие навыки — инструкции, которые подгружаются по необходимости.

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

5️⃣ Удачный внутренний опыт упаковывают во фреймворк
Из этого пути вырос eve: инструкции, навыки, инструменты и каналы общения задаются файлами, а фреймворк собирает из них агента и обеспечивает среду выполнения. Qu говорит о тысячах запросов к d0 в день и примерно 20 востребованных агентах внутри Vercel.
Это признаки использования. Для оценки эффекта хотелось бы ещё увидеть долю правильных ответов, время на их проверку и стоимость сопровождения. Заявление, что аналитики освободились для более содержательной работы, выглядит правдоподобно, но измерений экономии времени в докладе нет.

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

#AI #AI4SDLC #Agents #Data #Architecture #Evals

YC Paper Club: что делает модель рабочим агентом (Рубрика #AI4SDLC)

Посмотрел интересную встречу YC Paper Club про harness, которая называлась «Why The Harness Matters More Than The Model» и где обсуждалась обвязка модели: инструменты, память, выполнение кода и управление работой агента. Сама запись появилась 7 сентября и хоть заголовок видео спорный, но внутри четыре инженерных выступления о том, а что меняется, когда той же модели дают больше возможностей работать с окружающей средой.

1️⃣ Вступление François Chaubard из Y Combinator отлично работает как вступление. Он проходит путь от генерации текста к инструментам, памяти, навыкам, субагентам и системам, которые меняют собственную обвязку по результатам работы (тут прямо много отсылок к whitepapers). Заодно показывает свой эксперимент с автоматизацией исследований: задаёшь идею и метрику, дальше агенты ищут статьи, ставят эксперименты и готовят текст. Среди ролей есть даже научный руководитель, который периодически напоминает исследователю, что пора двигаться дальше. Академическую жизнь тоже автоматизируют :)

2️⃣ Seth Karten из Prime Intellect рассказывает про Prime Agent. У него интересная аналогия с иерархией памяти компьютера: веса модели, активный контекст, переменные в работающем Python-процессе и долговременные файлы. Большой результат инструмента можно оставить в памяти процесса, обработать кодом и передать модели только нужный фрагмент. Субагента можно вернуть к задаче с сохранённым контекстом. По мере работы обновлять навыки и инструкции, чтобы полезный опыт переживал отдельную сессию. Кстати, сама идея «дать агентам общаться друг с другом» выросла у Karten из вполне человеческой проблемы: надоело самому переносить информацию между параллельно работающими помощниками.

Среди примеров — создание эмуляторов игровых систем, оптимизация GPU-ядер и многодневные исследовательские задачи. Есть и история про почти идеальный результат на ARC-AGI: по словам Karten, первый запуск показал 99,9%, но просмотр логов обнаружил жульничество. Пришлось исправлять изоляцию среды и запускать заново. Полезная деталь для всех, кто привык смотреть только на итоговую цифру бенчмарка.

3️⃣ Jon Saad-Falcon из Stanford показывает OpenJarvis — персонального помощника, работающего на собственном устройстве. Здесь интересна схема настройки: сильная облачная модель изучает ошибки локальной системы и предлагает изменения модели, инструментов, памяти и логики агента. Изменения проходят проверку, а готовая конфигурация выполняет задачи локально. Авторы заявляют снижение предельных API-затрат примерно в 800 раз на своих тестах. Это не полная стоимость владения с железом и электричеством. Но сама возможность использовать облачную модель для подготовки более дешёвого локального помощника заслуживает внимания.

4️⃣ Самая прикладная часть — Josh France и Regan Bell из YC Labs про QM, внутреннюю платформу агентов для сотрудников YC. До неё команда подняла больше 50 Hermes-агентов в виртуальных машинах. Помощники были полезными, но требовали настройки и постоянного обслуживания: приходилось заходить в отдельные экземпляры и что-то чинить.

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

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

#AI4SDLC #AI #Agents #Engineering #PlatformEngineering

Как AI изменит разработку ПО: материалы Organized Programming №92 (Рубрика #AI4SDLC)

Собрал материалы разговора с Кириллом Мокевниным: 13 сентября 2026 года вышел выпуск №92 Organized Programming, где я был гостем. Обсуждали, как AI меняет программистов, команды и IT-компании. Делился опытом внедрения AI в Т-Банке — и тем, почему после ускорения написания кода ещё приходится разбираться со всей остальной разработкой.

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

Обсудили
🔸 Команды с агентами
Один инженер может брать на себя больше этапов работы, сокращая передачи задачи между людьми. При этом необходимые роли сохраняются. Компактная команда — обсуждаемое направление изменений, а не уже достигнутая норма для любой компании.
🔸 Внедрение на масштабе
Общий доступ к моделям, инструменты, навыки для агентов и изолированные среды дают техническую основу. А менять процесс должно само продуктовое направление: исключения, на которых взлетел пилот, ещё нужно научиться воспроизводить для остальных.
🔸 Спецификации и проверку плана
Кирилл рассказал, как использует эти практики даже в небольших проектах: агенты снижают стоимость оформления. Но требования к качеству всё равно нужно подкреплять автоматическими проверками — один документ ничего не гарантирует.
🔸 Знания и внутренние платформы
Агенту трудно разобраться с неявными правилами и корпоративным форком, который ведёт себя иначе, чем исходный продукт. При этом документацией пользуются и люди вне разработки: переезд всего знания в Git меняет их работу тоже.
🔸 Три уровня измерения пользы
Используют ли инструмент, сколько времени он высвобождает и что компания получает с учётом всех затрат. Больше закрытых задач может означать, что команда просто добралась до менее полезной части очереди. Нужны новые стоящие гипотезы и понимание, куда направить освободившееся время.
🔸 Обучение и границы автономии
Готовая функция мало говорит о том, чему научился джун: надо разбирать постановку, план и понимание результата. В сложном легаси похожая проблема — сначала выяснить, почему система устроена именно так и кто зависит от её поведения.

Материалы выпуска
📌 Страница выпуска
📖 Когда код пишет агент: что остаётся инженерией — лонгрид подготовки к разговору.
🎬 Запись на YouTube
📝 Текстовый конспект разговора

Если уже внедряете агентов в команде, расскажите: что теперь дольше всего задерживает полезное изменение на пути к пользователю?

#AI4SDLC #AI #Agents #Engineering #PlatformEngineering #Management

Материалы выпуска: свобода CTO в стартапе и корпорации с Кириллом Евсеенко (Рубрика #Leadership)

Собрал материалы разговора с Кириллом Евсеенко, CTO аудиостримингового сервиса «Звук». Эфир Code of Leadership прошёл 11 сентября 2026 года. Обсуждали свободу технического директора: можно быстро принять решение и упереться в нехватку людей, а можно получить ресурсы для большого изменения — и обнаружить, сколько ещё людей должны с ним согласиться. Кирилл сравнивает эти среды через свой опыт: медицинский стартап, START и «Звук». По его словам, за шесть лет команда START выросла примерно с 12 до 150 человек, а на понимание правил работы в «Звуке» ушло около полугода. Разговор получился про то, как вместе с масштабом меняется сама работа CTO.

Обсудили:
- Когда пора строить своё. START начинал с внешних CDN, биллинга и кодировщика; затем стоимость и ограничения поставщиков стали поводом делать отдельные компоненты внутри. Как связать архитектуру с деньгами и учитывать поддержку решения через несколько лет.
- Как перестать чинить всё лично. Кирилл рассказал о переходе к работе через руководителей и платформенные команды. В том числе о распределении знаний, которые раньше держались на отдельных незаменимых людях: с ростом компании такая зависимость обходится дороже.
- Куда расти сильному инженеру. Техническая карьерная ветка позволяет расширять влияние без обязательного ухода в менеджмент. Но под роль нужны реальные сложные задачи и польза бизнесу — одного нового названия должности мало.
- Что происходит после «решили делать». Безопасность, юристы и смежные команды могут остановить уже подготовленный запуск. При этом Кирилл оговаривается: в корпорации решение тоже может занимать несколько часов. Важны конкретные полномочия, зависимости и цена ошибки.
- Как закрывать ненужные инициативы. Команде хочется продолжать свой проект, а руководителю бывает безопаснее ждать указаний: личный риск неудачи выше награды за успех. Обсудили, как такие стимулы мешают изменениям и зачем нужна ответственность за завершение работы, включая решение её остановить.

Материалы выпуска:
📌 Страница выпуска с таймкодами
🎬 YouTube, VK Видео
🎧 Podster, Яндекс Музыка, Apple Podcasts
📝 Текстовый конспект разговора

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

#CodeOfLeadership #Management #Leadership #Career #Strategy #Engineering

Science Museum Souvenir Book (Рубрика #Museum)

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

В общем, это крутое место, что заслуживает посещения:)

#Science #Museum #History