Codex: почему дешёвые переделки не отменяют архитектуру (Рубрика #AI4SDLC)
Агенты удешевляют переделку систем, но хорошие границы и архитектура от этого становятся только важнее. Раньше команда росла постепенно, вместе с ней появлялись договорённости и документация. Теперь, по образному сравнению Тибо Соттьо, за выходные к проекту можно подключить сотню агентов. И все они начнут что-то менять. Хорошо бы к этому моменту понимать, что мы строим и как эти изменения должны уживаться друг с другом.
Это интересная линия в интервью Building Codex with Tibo Sottiaux, которое вышло 9 сентября на The Pragmatic Engineer. Тибо — один из создателей Codex, сейчас руководит Core Products & Platform в OpenAI. Разговаривает с ним Gergely Orosz, чей доклад «замедлиться, чтобы ускориться» я уже разбирал.
У Тибо хорошо прослеживается интерес к инструментам, которые помогают другим работать быстрее. В DeepMind он занимался инфраструктурой для исследователей. По его рассказу, из интерфейса для экспериментов с языковыми моделями вырос внутренний чат, которым коллеги активно делились ещё до выхода ChatGPT. Но превратить его в публичный продукт не удалось: Тибо связывает это с устройством Google и сложностью выпуска новых продуктов (но он сам признаёт, что ранние модели были довольно бестолковыми и это историю стоит читать с этой оговоркой).
В OpenAI он пришёл в 2024 году ради более тесной связи исследований и продукта. Снова начал с инфраструктуры, а затем вместе с коллегами стал обучать модели работать с внутренним Python-кодом и собирать агентов для ускорения исследований. Эти эксперименты объединились с направлением Autonomous Software Engineer и стали одной из основ Codex. Причём Тибо признаёт, что ранняя облачная версия не нашла product-market fit: слишком много трения для пользователя. Внутри полезно — ещё не значит, что снаружи удобно.
Дальше в разговоре есть несколько деталей о том, как это меняет саму разработку:
🔸 Архитектура нужна и самому агенту
Ядро Codex отделили от интерфейсов и написали на Rust ради надёжности, безопасности и эффективности. Хотя тогда модели лучше писали на Python и TypeScript. Команда заранее думала о том, как агент будет работать в разных продуктах и масштабироваться.
🔸 Часть обвязки должна уметь отмирать
Harness — окружение с инструментами и инструкциями — компенсирует слабости модели. Сначала ей приходится напоминать запускать тесты, потом это поведение появляется в самой модели. Тибо описывает совместную работу инженеров и исследователей: где исправлять проблему и сколько ждать следующую модель. Ты можешь написать большой обходной механизм, который через месяц уже не понадобится.
🔸 Code review смещается к намерению и контрактам
По словам Тибо, в OpenAI автоматизируют проверки корректности и безопасности; найденные проблемы безопасности блокируют PR. Человеческое обсуждение он предлагает сосредоточить на том, что компонент должен делать, какие данные может использовать и какие инварианты обязан сохранять. Об этом полезно договориться до генерации реализации.
🔸 Агенту нужна история решений
Внутри OpenAI Codex подключён к коду, Slack и документам. При объединении Codex с ChatGPT он даже вёл хронику обсуждений и выбранных решений. Получается интересное применение агента: помогать команде восстанавливать, почему система стала именно такой.
Это продолжает тему AI для software architecture: границы, ограничения и история компромиссов должны быть доступны для работы. А рядом остаётся вопрос из разбора Geoffrey Litt про понимание: что из этого способна объяснить сама команда?
По оценке Тибо, обслуживание и смена архитектуры сильно дешевеют. Но в его рассуждении есть условие: хорошие абстракции позволяют менять внутренности компонента, не задевая всё вокруг.
#AI4SDLC #AI #Agents #Architecture #Engineering
Агенты удешевляют переделку систем, но хорошие границы и архитектура от этого становятся только важнее. Раньше команда росла постепенно, вместе с ней появлялись договорённости и документация. Теперь, по образному сравнению Тибо Соттьо, за выходные к проекту можно подключить сотню агентов. И все они начнут что-то менять. Хорошо бы к этому моменту понимать, что мы строим и как эти изменения должны уживаться друг с другом.
Это интересная линия в интервью Building Codex with Tibo Sottiaux, которое вышло 9 сентября на The Pragmatic Engineer. Тибо — один из создателей Codex, сейчас руководит Core Products & Platform в OpenAI. Разговаривает с ним Gergely Orosz, чей доклад «замедлиться, чтобы ускориться» я уже разбирал.
У Тибо хорошо прослеживается интерес к инструментам, которые помогают другим работать быстрее. В DeepMind он занимался инфраструктурой для исследователей. По его рассказу, из интерфейса для экспериментов с языковыми моделями вырос внутренний чат, которым коллеги активно делились ещё до выхода ChatGPT. Но превратить его в публичный продукт не удалось: Тибо связывает это с устройством Google и сложностью выпуска новых продуктов (но он сам признаёт, что ранние модели были довольно бестолковыми и это историю стоит читать с этой оговоркой).
В OpenAI он пришёл в 2024 году ради более тесной связи исследований и продукта. Снова начал с инфраструктуры, а затем вместе с коллегами стал обучать модели работать с внутренним Python-кодом и собирать агентов для ускорения исследований. Эти эксперименты объединились с направлением Autonomous Software Engineer и стали одной из основ Codex. Причём Тибо признаёт, что ранняя облачная версия не нашла product-market fit: слишком много трения для пользователя. Внутри полезно — ещё не значит, что снаружи удобно.
Дальше в разговоре есть несколько деталей о том, как это меняет саму разработку:
Ядро Codex отделили от интерфейсов и написали на Rust ради надёжности, безопасности и эффективности. Хотя тогда модели лучше писали на Python и TypeScript. Команда заранее думала о том, как агент будет работать в разных продуктах и масштабироваться.
Harness — окружение с инструментами и инструкциями — компенсирует слабости модели. Сначала ей приходится напоминать запускать тесты, потом это поведение появляется в самой модели. Тибо описывает совместную работу инженеров и исследователей: где исправлять проблему и сколько ждать следующую модель. Ты можешь написать большой обходной механизм, который через месяц уже не понадобится.
По словам Тибо, в OpenAI автоматизируют проверки корректности и безопасности; найденные проблемы безопасности блокируют PR. Человеческое обсуждение он предлагает сосредоточить на том, что компонент должен делать, какие данные может использовать и какие инварианты обязан сохранять. Об этом полезно договориться до генерации реализации.
Внутри OpenAI Codex подключён к коду, Slack и документам. При объединении Codex с ChatGPT он даже вёл хронику обсуждений и выбранных решений. Получается интересное применение агента: помогать команде восстанавливать, почему система стала именно такой.
Это продолжает тему AI для software architecture: границы, ограничения и история компромиссов должны быть доступны для работы. А рядом остаётся вопрос из разбора Geoffrey Litt про понимание: что из этого способна объяснить сама команда?
По оценке Тибо, обслуживание и смена архитектуры сильно дешевеют. Но в его рассуждении есть условие: хорошие абстракции позволяют менять внутренности компонента, не задевая всё вокруг.
#AI4SDLC #AI #Agents #Architecture #Engineering
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Building Codex with Tibo Sottiaux
Tibo Sottiaux is one of the engineers who created Codex, and today, he heads up the Core Products & Platform org at OpenAI which also includes Codex. He’s also one of the most public faces of Codex due to his frequent – and generous – usage reset announcements…
🔥6👍4🤪2
Habitat: эволюция слоя хранения OpenAI (Рубрика #AI4SDLC)
Во втором квартале 2026 года два инженера с помощью Codex и GPT‑5.5 переписали Habitat с Python на Rust. В статье от 11 сентября OpenAI сообщила: Rust уже обслуживает 95% запросов этого сервиса. Habitat — это слой между ChatGPT, Codex и хранилищами: маршрутизация, права доступа, шифрование и правила размещения данных. И это интересный кейс AI-assisted миграции критической инфраструктуры, причем миграции масштабной — по данным OpenAI: почти 40 регионов, свыше 500 ПБ и 70 млн внутренних запросов в секунду. Компания заявляет выигрыш в эффективности CPU в 6 раз, памяти — в 15, правда, методики сравнения в статье нет.
Но изюминка здесь — в том, как ребята дошли до момента, когда переписывание стало правильной следующей задачей.
1️⃣ В 2023 году Habitat начинался как Python-библиотека над Cosmos DB. Она прятала детали хранения от продуктовых команд. Удобно: подключил библиотеку и работаешь с данными, не разбираясь каждый раз с маршрутизацией и авторизацией.
2️⃣ К середине 2025-го эта простота стала дорого обходиться. Новую логику приходилось раскатывать через десятки сервисов. Добавили проверку на теневом трафике — ещё несколько дней согласований. Исправили ошибку — новый круг. А потом одна команда откатила свой сервис по другой причине и вернула старый баг. Получили именно тот сбой, от которого пытались защититься.
3️⃣ Общая библиотека перестала быть удобной границей управления
— Habitat выделили в сервис: теперь изменения хранения, наблюдаемость и политики доступа можно было контролировать централизованно.
— И тут команда сознательно оставила Python. Сначала требовалось стабилизировать платформу и API, разблокировать продуктовую разработку. За эффективность решили заплатить позже, рассчитывая в том числе на развитие кодинг-моделей. Техдолг здесь был осознанным выбором порядка работ.
— При этом API намеренно сделали менее мощным. Простые операции над объектами и связями, предсказуемый объём работы, никаких произвольных SQL-запросов и неограниченных обходов графа. Объект и его связи лежат в одной партиции; соседние объекты могут оказаться в другом регионе. Красивый граф в модели данных ещё не обещает дешёвого обхода.
— Для сложных запросов — отдельные экземпляры Rockset, получающие изменения через CDC. Их масштабируют сами команды. Да, клиентам добавили хлопот. Зато цена сложного запроса становится их явной задачей, а аналитика изолирована от оперативного доступа к данным.
4️⃣ Следующий вызов — хвостовые latency внутри самого сервиса
База уже ответила, но занятый asyncio-цикл ещё не дал обработать результат. Команда стала измерять задержку планирования задач. Даже периодический разбор большого конфига feature flags оказался источником тормозов: помогли уменьшение конфига и разнесение обновлений во времени. А пул соединений с LIFO создал совсем неприятную петлю: медленный сервер позже возвращал соединение, оно первым использовалось снова, и перегруженный процесс получал ещё больше работы (это была ситуация с метастабильными отказами). Переход на FIFO разорвал эту обратную связь.
5️⃣ До Rust дошли уже с работающей платформой и понятными ограничениями. Python-версия на пике обслуживала более 20 млн запросов в секунду. Дальше пришло время снижать ресурсную цену этой архитектуры. Поэтому «два инженера переписали сервис» — финал длинной истории. До него пришлось определить границы ответственности, ограничить стоимость операций и разобраться с поведением системы под нагрузкой.
В общем, AI помог переписать реализацию, но сам кейс гораздо интереснее.
#AI4SDLC #Architecture #PlatformEngineering #Engineering #Rust #AI
Во втором квартале 2026 года два инженера с помощью Codex и GPT‑5.5 переписали Habitat с Python на Rust. В статье от 11 сентября OpenAI сообщила: Rust уже обслуживает 95% запросов этого сервиса. Habitat — это слой между ChatGPT, Codex и хранилищами: маршрутизация, права доступа, шифрование и правила размещения данных. И это интересный кейс AI-assisted миграции критической инфраструктуры, причем миграции масштабной — по данным OpenAI: почти 40 регионов, свыше 500 ПБ и 70 млн внутренних запросов в секунду. Компания заявляет выигрыш в эффективности CPU в 6 раз, памяти — в 15, правда, методики сравнения в статье нет.
Но изюминка здесь — в том, как ребята дошли до момента, когда переписывание стало правильной следующей задачей.
1️⃣ В 2023 году Habitat начинался как Python-библиотека над Cosmos DB. Она прятала детали хранения от продуктовых команд. Удобно: подключил библиотеку и работаешь с данными, не разбираясь каждый раз с маршрутизацией и авторизацией.
2️⃣ К середине 2025-го эта простота стала дорого обходиться. Новую логику приходилось раскатывать через десятки сервисов. Добавили проверку на теневом трафике — ещё несколько дней согласований. Исправили ошибку — новый круг. А потом одна команда откатила свой сервис по другой причине и вернула старый баг. Получили именно тот сбой, от которого пытались защититься.
3️⃣ Общая библиотека перестала быть удобной границей управления
— Habitat выделили в сервис: теперь изменения хранения, наблюдаемость и политики доступа можно было контролировать централизованно.
— И тут команда сознательно оставила Python. Сначала требовалось стабилизировать платформу и API, разблокировать продуктовую разработку. За эффективность решили заплатить позже, рассчитывая в том числе на развитие кодинг-моделей. Техдолг здесь был осознанным выбором порядка работ.
— При этом API намеренно сделали менее мощным. Простые операции над объектами и связями, предсказуемый объём работы, никаких произвольных SQL-запросов и неограниченных обходов графа. Объект и его связи лежат в одной партиции; соседние объекты могут оказаться в другом регионе. Красивый граф в модели данных ещё не обещает дешёвого обхода.
— Для сложных запросов — отдельные экземпляры Rockset, получающие изменения через CDC. Их масштабируют сами команды. Да, клиентам добавили хлопот. Зато цена сложного запроса становится их явной задачей, а аналитика изолирована от оперативного доступа к данным.
4️⃣ Следующий вызов — хвостовые latency внутри самого сервиса
База уже ответила, но занятый asyncio-цикл ещё не дал обработать результат. Команда стала измерять задержку планирования задач. Даже периодический разбор большого конфига feature flags оказался источником тормозов: помогли уменьшение конфига и разнесение обновлений во времени. А пул соединений с LIFO создал совсем неприятную петлю: медленный сервер позже возвращал соединение, оно первым использовалось снова, и перегруженный процесс получал ещё больше работы (это была ситуация с метастабильными отказами). Переход на FIFO разорвал эту обратную связь.
5️⃣ До Rust дошли уже с работающей платформой и понятными ограничениями. Python-версия на пике обслуживала более 20 млн запросов в секунду. Дальше пришло время снижать ресурсную цену этой архитектуры. Поэтому «два инженера переписали сервис» — финал длинной истории. До него пришлось определить границы ответственности, ограничить стоимость операций и разобраться с поведением системы под нагрузкой.
В общем, AI помог переписать реализацию, но сам кейс гораздо интереснее.
#AI4SDLC #Architecture #PlatformEngineering #Engineering #Rust #AI
OpenAI
Rapidly scaling online storage to serve over 1 billion ChatGPT users
Learn how OpenAI evolved Habitat from a Python library into a globally distributed storage platform serving 1 billion ChatGPT users and 22M requests per second.
🔥5❤3👍3🫡1
Где профит от данных, Лебовски? Материалы первого выпуска (Рубрика #Data)
Собрал материалы первого выпуска «Где профит от данных, Лебовски?». Эфир прошёл 7 сентября 2026 года: вместе с Андреем Цыбиным и Николаем Головым обсуждали, как превратить данные в деньги. Начали с вполне житейского запроса: данных накопили много, теперь хочется на них заработать. Только размер хранилища ещё ничего не говорит о том, кто готов за его содержимое платить. Кстати, у проекта есть собственный отдельный сайт prodata.tech, а следующий эпизод выйдет где-то через неделю.
Получился разговор с трёх сторон: продуктовая аналитика и эксперименты, архитектура платформ данных и инженерное лидерство. И со спором о том, сколько ценности остаётся в данных, когда убираешь подробности.
Обсудили:
- Три пути к деньгам. Продать данные наружу, улучшить решения внутри компании или построить на них продукт. Рамку обозначили целиком, а большую часть первого выпуска посвятили внешней продаже.
- Покупателя и его задачу. Кому нужен именно этот набор и что человек сможет с ним сделать? Андрей обращает внимание на охват, репрезентативность и стабильность сбора: рост показателя может означать, что мы стали больше наблюдать, а не что вырос сам рынок.
- Копию, права и обезличивание. Николай разбирает вопросы целей сбора и дальнейшего использования; отдельно говорили о повторной идентификации по событиям и маршрутам. Юридические примеры в разговоре — вопросы к проверке конкретной сделки, а не готовое разрешение продавать данные после удаления имён.
- Агрегированную аналитику. На примерах Strava и аналитики для поставщиков X5 спорили о цене детализации. Мы с Николаем обсуждали, как её потеря может снизить ценность; Андрей возражал, что качественный ответ на нужный покупателю вопрос сам может стать продуктом.
- Расходы после выгрузки. Подготовка, поддержка, защита, возможность копирования и собственное конкурентное преимущество, которым делишься с покупателем. Счёт за первую поставку ещё не отвечает на вопрос, выгодно ли всё это компании.
Материалы выпуска:
📌 Страница выпуска с таймкодами
📖 Лонгрид: три пути от массива к деньгам — отдельный разбор темы с кейсами и схемами, который я делал при подготовке к выпуску
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если пробовали монетизировать данные, расскажите, где оказалось сложнее: найти покупателя, подготовить полезный продукт или посчитать, что осталось после всех расходов?
#Data #Product #Analytics #Architecture #Management
Собрал материалы первого выпуска «Где профит от данных, Лебовски?». Эфир прошёл 7 сентября 2026 года: вместе с Андреем Цыбиным и Николаем Головым обсуждали, как превратить данные в деньги. Начали с вполне житейского запроса: данных накопили много, теперь хочется на них заработать. Только размер хранилища ещё ничего не говорит о том, кто готов за его содержимое платить. Кстати, у проекта есть собственный отдельный сайт prodata.tech, а следующий эпизод выйдет где-то через неделю.
Получился разговор с трёх сторон: продуктовая аналитика и эксперименты, архитектура платформ данных и инженерное лидерство. И со спором о том, сколько ценности остаётся в данных, когда убираешь подробности.
Обсудили:
- Три пути к деньгам. Продать данные наружу, улучшить решения внутри компании или построить на них продукт. Рамку обозначили целиком, а большую часть первого выпуска посвятили внешней продаже.
- Покупателя и его задачу. Кому нужен именно этот набор и что человек сможет с ним сделать? Андрей обращает внимание на охват, репрезентативность и стабильность сбора: рост показателя может означать, что мы стали больше наблюдать, а не что вырос сам рынок.
- Копию, права и обезличивание. Николай разбирает вопросы целей сбора и дальнейшего использования; отдельно говорили о повторной идентификации по событиям и маршрутам. Юридические примеры в разговоре — вопросы к проверке конкретной сделки, а не готовое разрешение продавать данные после удаления имён.
- Агрегированную аналитику. На примерах Strava и аналитики для поставщиков X5 спорили о цене детализации. Мы с Николаем обсуждали, как её потеря может снизить ценность; Андрей возражал, что качественный ответ на нужный покупателю вопрос сам может стать продуктом.
- Расходы после выгрузки. Подготовка, поддержка, защита, возможность копирования и собственное конкурентное преимущество, которым делишься с покупателем. Счёт за первую поставку ещё не отвечает на вопрос, выгодно ли всё это компании.
Материалы выпуска:
📌 Страница выпуска с таймкодами
📖 Лонгрид: три пути от массива к деньгам — отдельный разбор темы с кейсами и схемами, который я делал при подготовке к выпуску
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если пробовали монетизировать данные, расскажите, где оказалось сложнее: найти покупателя, подготовить полезный продукт или посчитать, что осталось после всех расходов?
#Data #Product #Analytics #Architecture #Management
polomodov.tech
Превращаем данные в деньги: что это… — Где профит от данных, Лебовски?
Андрей Цыбин, Николай Голов и Александр Поломодов задают рамку нового подкаста: продать данные, улучшить внутренние решения или встроить данные в продукт. Первый…
❤5🔥4👍2
Science Museum Souvenir Book (Рубрика #Museum)
Музей науки в Лондоне мне очень понравился - по нему было интересно гулять как одному, так и с детьми. В нем много экспонатов, организованных в серии по доменам, а внутри по времени. Примерно та же схема прослеживается и в сувенирной книге, что выхватывает изобретения, которые продвинули человечество, а также присутствуют в коллекции музея.
В общем, это крутое место, что заслуживает посещения:)
#Science #Museum #History
Музей науки в Лондоне мне очень понравился - по нему было интересно гулять как одному, так и с детьми. В нем много экспонатов, организованных в серии по доменам, а внутри по времени. Примерно та же схема прослеживается и в сувенирной книге, что выхватывает изобретения, которые продвинули человечество, а также присутствуют в коллекции музея.
В общем, это крутое место, что заслуживает посещения:)
#Science #Museum #History
❤5🔥4👍2🌚1
Материалы выпуска: свобода 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
Собрал материалы разговора с Кириллом Евсеенко, CTO аудиостримингового сервиса «Звук». Эфир Code of Leadership прошёл 11 сентября 2026 года. Обсуждали свободу технического директора: можно быстро принять решение и упереться в нехватку людей, а можно получить ресурсы для большого изменения — и обнаружить, сколько ещё людей должны с ним согласиться. Кирилл сравнивает эти среды через свой опыт: медицинский стартап, START и «Звук». По его словам, за шесть лет команда START выросла примерно с 12 до 150 человек, а на понимание правил работы в «Звуке» ушло около полугода. Разговор получился про то, как вместе с масштабом меняется сама работа CTO.
Обсудили:
- Когда пора строить своё. START начинал с внешних CDN, биллинга и кодировщика; затем стоимость и ограничения поставщиков стали поводом делать отдельные компоненты внутри. Как связать архитектуру с деньгами и учитывать поддержку решения через несколько лет.
- Как перестать чинить всё лично. Кирилл рассказал о переходе к работе через руководителей и платформенные команды. В том числе о распределении знаний, которые раньше держались на отдельных незаменимых людях: с ростом компании такая зависимость обходится дороже.
- Куда расти сильному инженеру. Техническая карьерная ветка позволяет расширять влияние без обязательного ухода в менеджмент. Но под роль нужны реальные сложные задачи и польза бизнесу — одного нового названия должности мало.
- Что происходит после «решили делать». Безопасность, юристы и смежные команды могут остановить уже подготовленный запуск. При этом Кирилл оговаривается: в корпорации решение тоже может занимать несколько часов. Важны конкретные полномочия, зависимости и цена ошибки.
- Как закрывать ненужные инициативы. Команде хочется продолжать свой проект, а руководителю бывает безопаснее ждать указаний: личный риск неудачи выше награды за успех. Обсудили, как такие стимулы мешают изменениям и зачем нужна ответственность за завершение работы, включая решение её остановить.
Материалы выпуска:
📌 Страница выпуска с таймкодами
🎬 YouTube, VK Видео
🎧 Podster, Яндекс Музыка, Apple Podcasts
📝 Текстовый конспект разговора
Если переходили между стартапом и большой компанией, расскажите: какую привычку пришлось менять первой — и какое решение оказалось труднее всего довести до результата?
#CodeOfLeadership #Management #Leadership #Career #Strategy #Engineering
polomodov.tech
Свобода CTO в стартапе и корпорации — Code of Leadership
Кирилл Евсеенко о свободе CTO: рост START, переход в «Звук», полномочия, экономика решений, инженерная карьера и ответственность за изменения.
❤3👍2🔥2
Как AI изменит разработку ПО: материалы Organized Programming №92 (Рубрика #AI4SDLC)
Собрал материалы разговора с Кириллом Мокевниным: 13 сентября 2026 года вышел выпуск №92 Organized Programming, где я был гостем. Обсуждали, как AI меняет программистов, команды и IT-компании. Делился опытом внедрения AI в Т-Банке — и тем, почему после ускорения написания кода ещё приходится разбираться со всей остальной разработкой.
Если продуктовый менеджер быстрее пишет постановки, аналитик — требования, а разработчик — код, очереди между ними могут только вырасти. Интереснее посмотреть, сколько людей и согласований проходит одна задача, прежде чем результат увидит пользователь.
Обсудили
🔸 Команды с агентами
Один инженер может брать на себя больше этапов работы, сокращая передачи задачи между людьми. При этом необходимые роли сохраняются. Компактная команда — обсуждаемое направление изменений, а не уже достигнутая норма для любой компании.
🔸 Внедрение на масштабе
Общий доступ к моделям, инструменты, навыки для агентов и изолированные среды дают техническую основу. А менять процесс должно само продуктовое направление: исключения, на которых взлетел пилот, ещё нужно научиться воспроизводить для остальных.
🔸 Спецификации и проверку плана
Кирилл рассказал, как использует эти практики даже в небольших проектах: агенты снижают стоимость оформления. Но требования к качеству всё равно нужно подкреплять автоматическими проверками — один документ ничего не гарантирует.
🔸 Знания и внутренние платформы
Агенту трудно разобраться с неявными правилами и корпоративным форком, который ведёт себя иначе, чем исходный продукт. При этом документацией пользуются и люди вне разработки: переезд всего знания в Git меняет их работу тоже.
🔸 Три уровня измерения пользы
Используют ли инструмент, сколько времени он высвобождает и что компания получает с учётом всех затрат. Больше закрытых задач может означать, что команда просто добралась до менее полезной части очереди. Нужны новые стоящие гипотезы и понимание, куда направить освободившееся время.
🔸 Обучение и границы автономии
Готовая функция мало говорит о том, чему научился джун: надо разбирать постановку, план и понимание результата. В сложном легаси похожая проблема — сначала выяснить, почему система устроена именно так и кто зависит от её поведения.
Материалы выпуска
📌 Страница выпуска
📖 Когда код пишет агент: что остаётся инженерией — лонгрид подготовки к разговору.
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если уже внедряете агентов в команде, расскажите: что теперь дольше всего задерживает полезное изменение на пути к пользователю?
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering #Management
Собрал материалы разговора с Кириллом Мокевниным: 13 сентября 2026 года вышел выпуск №92 Organized Programming, где я был гостем. Обсуждали, как AI меняет программистов, команды и IT-компании. Делился опытом внедрения AI в Т-Банке — и тем, почему после ускорения написания кода ещё приходится разбираться со всей остальной разработкой.
Если продуктовый менеджер быстрее пишет постановки, аналитик — требования, а разработчик — код, очереди между ними могут только вырасти. Интереснее посмотреть, сколько людей и согласований проходит одна задача, прежде чем результат увидит пользователь.
Обсудили
Один инженер может брать на себя больше этапов работы, сокращая передачи задачи между людьми. При этом необходимые роли сохраняются. Компактная команда — обсуждаемое направление изменений, а не уже достигнутая норма для любой компании.
Общий доступ к моделям, инструменты, навыки для агентов и изолированные среды дают техническую основу. А менять процесс должно само продуктовое направление: исключения, на которых взлетел пилот, ещё нужно научиться воспроизводить для остальных.
Кирилл рассказал, как использует эти практики даже в небольших проектах: агенты снижают стоимость оформления. Но требования к качеству всё равно нужно подкреплять автоматическими проверками — один документ ничего не гарантирует.
Агенту трудно разобраться с неявными правилами и корпоративным форком, который ведёт себя иначе, чем исходный продукт. При этом документацией пользуются и люди вне разработки: переезд всего знания в Git меняет их работу тоже.
Используют ли инструмент, сколько времени он высвобождает и что компания получает с учётом всех затрат. Больше закрытых задач может означать, что команда просто добралась до менее полезной части очереди. Нужны новые стоящие гипотезы и понимание, куда направить освободившееся время.
Готовая функция мало говорит о том, чему научился джун: надо разбирать постановку, план и понимание результата. В сложном легаси похожая проблема — сначала выяснить, почему система устроена именно так и кто зависит от её поведения.
Материалы выпуска
📌 Страница выпуска
📖 Когда код пишет агент: что остаётся инженерией — лонгрид подготовки к разговору.
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если уже внедряете агентов в команде, расскажите: что теперь дольше всего задерживает полезное изменение на пути к пользователю?
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering #Management
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как AI изменит разработку ПО: будущее программистов, команд и IT-компаний /Александр Поломодов #92
🔹 Присоединяйся к курсу «Системный дизайн» https://ru.hexlet.io/programs/system-design?utm_source=youtube
Через несколько лет в IT может не остаться привычного разделения на фронтендеров, бэкендеров, аналитиков и тестировщиков. Не потому, что эти задачи…
Через несколько лет в IT может не остаться привычного разделения на фронтендеров, бэкендеров, аналитиков и тестировщиков. Не потому, что эти задачи…
❤4👍2🔥2