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

Где профит от данных, Лебовски? Материалы первого выпуска (Рубрика #Data)

Собрал материалы первого выпуска «Где профит от данных, Лебовски?». Эфир прошёл 7 сентября 2026 года: вместе с Андреем Цыбиным и Николаем Головым обсуждали, как превратить данные в деньги. Начали с вполне житейского запроса: данных накопили много, теперь хочется на них заработать. Только размер хранилища ещё ничего не говорит о том, кто готов за его содержимое платить. Кстати, у проекта есть собственный отдельный сайт prodata.tech, а следующий эпизод выйдет где-то через неделю.

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

Обсудили:
- Три пути к деньгам. Продать данные наружу, улучшить решения внутри компании или построить на них продукт. Рамку обозначили целиком, а большую часть первого выпуска посвятили внешней продаже.
- Покупателя и его задачу. Кому нужен именно этот набор и что человек сможет с ним сделать? Андрей обращает внимание на охват, репрезентативность и стабильность сбора: рост показателя может означать, что мы стали больше наблюдать, а не что вырос сам рынок.
- Копию, права и обезличивание. Николай разбирает вопросы целей сбора и дальнейшего использования; отдельно говорили о повторной идентификации по событиям и маршрутам. Юридические примеры в разговоре — вопросы к проверке конкретной сделки, а не готовое разрешение продавать данные после удаления имён.
- Агрегированную аналитику. На примерах Strava и аналитики для поставщиков X5 спорили о цене детализации. Мы с Николаем обсуждали, как её потеря может снизить ценность; Андрей возражал, что качественный ответ на нужный покупателю вопрос сам может стать продуктом.
- Расходы после выгрузки. Подготовка, поддержка, защита, возможность копирования и собственное конкурентное преимущество, которым делишься с покупателем. Счёт за первую поставку ещё не отвечает на вопрос, выгодно ли всё это компании.

Материалы выпуска:
📌 Страница выпуска с таймкодами
📖 Лонгрид: три пути от массива к деньгам — отдельный разбор темы с кейсами и схемами, который я делал при подготовке к выпуску
🎬 Запись на YouTube
📝 Текстовый конспект разговора

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

#Data #Product #Analytics #Architecture #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

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