🧑‍💻 Test Time Scaling for Code Generation

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

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

S∗: Test Time Scaling for Code Generation.

По факту адаптируют более общую идею из всем известной работы s1: Simple test-time scaling к домену кодогенерации.

Вся суть укладывается в одну картинку к посту. Дальше — детали:

1️⃣ Хотим генерировать код к некоторой задаче. Пусть есть доступный набор тестов (public tests), на которых можно тестировать программу. Есть предобученная модель, которая в целом может сгенерировать правильное решение, но всё-таки слишком стохастична, чтобы делать это с первой попытки. Хочется понять, как масштабировать доступный compute на инференсе, чтобы повысить качество генерируемых программ.

2️⃣ Начинаем с Parallel Branching — будем генерировать N программ одновременно. Очень понятный рабочий подход, более известный как Best-of-N.

3️⃣А теперь давайте добавим внутрь каждой ветки итеративный self-debugging. То есть модель сгенерировала код. Запускаем тесты. Какие-то из них падают. Используем это как фидбэк и просим модель поправить себя. Снова запускаем тесты — и так далее, в цикле M раз (пока есть бюджет). Это пример Sequential Scaling-а.

✅Шаги 2 и 3 вместе образуют Stage 1: Generation. Такая схема — это пример Hybrid Scaling-а, так как мы одновременно масштабируемся в обоих направлениях: в ширину (создаём много новых сэмплов) и в глубину (итеративно улучшаем существующие).

4️⃣После того как генерация отработала, у нас есть N версий кода, которые как-то работают на публичных тестах. Возможно, некоторые из них проходят все тесты. Появляется необходимость определить, какую версию кода выбрать в качестве финального ответа. Поэтому авторы вводят вторую стадию — Stage 2: Selection. Предлагается алгоритм:
a) кластеризуем все доступные сэмплы,
b) запускаем цикл по всем парам кластеров,
c) сэмплируем по одному решению из каждого кластера,
d) генерируем синтетические тесты для решений из двух кластеров,
e) запускаем эти тесты и добавляем +1 тому кластеру, который показывает лучший результат,
f) в качестве ответа выбираем кластер, набравший больше голосов, и из него сэмплируем финальное решение.

⚡️Дальше практические интересности:

✅Метод показывает существенно лучшие результаты, чем бейзлайны — обычный self-debugging и majority voting. Ablation studies подтверждают, что каждая фаза даёт вклад. Stage 2 в том виде, как у авторов, не всегда нужен.

✅Подход обобщается и отлично бустит все модели — как публичные, так и закрытые, включая reasoning-модели.

✅Температура сэмплирования играет значимую роль. Высокие значения приводят к деградации. Авторы выбрали 0.7 как оптимальное значение.

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

#статья

@max_dot_sh

💫 Первые впечатления от нового места

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

🔘Командные оффсайты.

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

В целом, не в первый раз слышу про такие ежеквартальные или полугодовые выезды для поддержки командного духа в стартапах. Да, это во многом благодаря небольшому размеру компании. Но на фоне дикой экономии в бигтехах и «One Fruit Per Person» такие штуки сильно резонируют.

Все эти ивенты, конечно, возможны пока у стартапа есть деньги.

🔘Скорость онбординга.

За первую неделю мне дали доступы ко всем системам, погрузили в структуру проектов, и я смог сделать свои первые полезные коммиты на языке, на котором никогда в жизни не писал (TypeScript). Без Курсора и Claude Code, конечно, не обошлось. Причем коммитил я не конфиг на 10 строк, а несколько довольно крупных фич. Но про Claude Code – отдельный пункт в конце.

🔘Количество реального рабочего времени.

В большой компании много часов сжигается на то, чтобы доказать необходимость задачи. Написать research proposal → поревьюить его в команде → поревьюить с продуктовой командой → поревьюить с Principal-ами / Staff-ами, чтобы найти точки пересечения → … Потом начинаешь реализацию, делаешь PR и можешь ждать ревью от людей из GMT-7 до следующего утра. Порой масштабы простаивания поражают.

В маленькой компании все иначе – минимум разглагольствований, много быстрых встреч маленькой группой у доски: обсудили → погнали делать. Такого очень не хватало. Цикл длинных ревью в крупных компаниях, по задумке, должен помочь принять более взвешенное стратегическое решение (ведь цена ошибки высока). На моем опыте это часто превращалось в пустое разглагольствование. Многие это принимают.

🔘Ценность каждого в команде.
Если кто-то уходит в отпуск или заболевает – это сразу ощущается. В силу ограниченности ресурсов каждый нанят под конкретное направление. Делегировать задачи особо некому – если взялся, то есть ожидание, что доведешь до логического конца. Поэтому ощущение большей ответственности чувствуется в каждой задаче.

🔘Нетворк и знакомства.
Стартапы помогают стартапам, особенно ранние. Это и первые клиенты, и источник новых инструментов. Крупные компании тоже охотно помогают стартапам с серьезным финансированием.

Для меня впечатляющей возможностью стало участие в нескольких встречах с фаундерами, PM-ами и техлидами других компаний – обсуждать, как можем быть полезны друг другу, знакомиться, иногда пропустить 1-2 байки за жизнь. Удивительно, сколько интересных людей вокруг. И все что-то пилят чтобы заработать.

🔘AI-centric подход.
Религия многих AI-стартапов в том, что AI-инструменты должны быть в центре разработки (а иногда и принятия решений). Оно и понятно: можно быстро находить проблемы существующих решений, понимать, что улучшать, а заодно и кратно повышать производительность.

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

Написали большой дизайн-док того, что нужно сделать, отдали агенту. Выдал примерно ~1.5k строк кода, все фичи (аргументы к CLI-инструменту) формально на месте. Красота. Запускаем – ни одна реально не работает. Ни одна.

Лезешь в код смотреть почему, тратишь время, чтобы разобраться, правишь, и думаешь, что если бы писал с нуля – выбрал бы другой дизайн. По итогу остается впечатление, что если бы делал сам с Курсором, инкрементально добавляя фичи, вышло бы лучше.

Но религию предавать нельзя. Полезный датапоинт, как в следующий раз сделать лучше.

Пока так, смотрю дальше.

@max_dot_sh

💡 Фреймворк дня. context7 - MCP сервер для Up-to-date документации об опен-соурсных проектах для ваших AI-помощников.

Проект быстро растет. 19k звезд, 10k форков, все это меньше чем за пару месяцев – dev сообщество активно контрибьютит и добавляет новые библиотеки.

А что это вообще такое? Тул для помощи агенту (Claude Code, Cursor, <подставьте сюда что угодно>), чтобы получить свежую документацию про API опен соурсных либ.

По задумке помогает модели избежать галлюцинаций и не выдумывать методы. Или "узнавать" как пользоваться совсем новыми библиотеками (или их свежими версиями). Каждое обращение агента к MCP серверу возвращает отранжированный набор "сниппетов" (кусочек кода + иногда какой-то комментарий) с примерами использования API библиотеки, дальше агент уже сам выбирает как этим распоряжаться.

Судя по сайту, уже 25K проектов имеют такую LLM-ориентированную документацию.

Идея интересная. Раз проект растет, то наверно, это как-то бустит агентов. Посмотрел выдаваемые сниппеты для некоторых проектов глазами (например про фастапи и вебсокеты), часть выглядит очень шумно.

@max_dot_sh

Senior DL Engineer в 🎧, Personalization, London

Авторская орфография сохранена

➡Ник автора в тг - Анонимно
➡ Название компании - Spotify

➡Расскажите про свой бэкграунд - Senior Deep Learning Engineer, 6 лет опыта в рекомендательных системах, PhD
➡Как подались на вакансию - подавался онлайн через careers page

🔥 Субъективно Сложность процесса по 10 бальной шкале - 6

➡Когда начали процесс - март 2025
➡Когда закончили процесс - май 2025

➡ Позиция, на которую собеседовались - Deep Learning Engineer (команда Personalization)
➡Грейд на который собеседовались (если известно) - Senior
➡Локация вакансии - London

🔥 Расскажите про этапы собеседований

1. Cтандартный созвон с рекрутером об опыте и зарплатных ожиданиях. Был акцент на вопросах про values. Что мне важнее, строить классный продукт или зарабатывать деньги? Серия подобных вопросов сразу смутила и потом в процессе оффера понял что к чему. Сразу обозначил, что рассматриваю TC £180-200К.

2. Values/behavioral screening - созвон с hiring manager'ом и еще одним инженером. Снова много упора на то, что меня драйвит. Понравилось, что сразу в начале процесса можно поговорить с непосредственным руководителем. Приятный человек с большим опытом управления.

3. Финальный раунд - 5 интервью. В основном все в формате case study.

- ML System Design case study - Нужно было спроектировать backend для ML рекомендательной системы. Обсуждали архитектуру, как система будет скейлиться, взаимодействие с другими сервисами.

- Data Engineering case study - Построить data pipeline для сортировки самых популярных артистов по странам. Нужно было продумать ETL процесс, обработку данных в реальном времени.

- Predictive modeling case study - Предсказать количество месячных активных пользователей. Обсуждали feature engineering, выбор модели, метрики качества.

- Recommendation system case study - Построить систему рекомендации 1 песни на пользователя. Нужно было учесть cold start problem, скейлинг, персонализацию.

- ML теория и SQL - Вопросы про классическую ML теорию (handling imbalanced datasets, regression с multiple features), SQL

По ощущениям прошел очень хорошо и рекрутер быстро вернулся с фидбэком, что готовы предложить оффер на £160K TC. Это было сильно ниже моих ожиданий. Я апеллировал тем фактом, что моя текущая компенсация лучше. Поставили созвон с менеджером, где он снова свел разговор к values и что меня мотивирует. Я соглашался, что крутой продукт и масштаб - это очень важно, но просил хотя бы поднять до £180K TC. Он обещал подумать. В итоге hr вернулась с тем, что команда не готова сейчас предложить больше, но будет возможность для роста и по итогу перформанс ревью за 1 год я могу дойти до £175-180. Я настаивал на своем. Сказали, что это их последнее предложение и поднимать не собираются. Так процесс и завершился.

⏺ Что понравилось:
Классные интервью раунды, фактически все на дизайн


⏺Что не понравилось:
Зарплата. За пределами Лондона с такой зарплатой может и можно комфортно жить с семьей, но тут это довольно трудно.


➡Итоги собеседования: Оффер, отказался.

💸Информация про Total Compensation: £160K TC


#интервью

@max_dot_sh

Рефлексия бывшего сотрудника OpenAI про работу в OpenAI

Блогпост автора. ex-разработчик, который участвовал в запуске Codex (опенсоурсный агент для кодогенерации от OpenAI).

Автор текста проработал в компании меньше двух лет и ушел по личным причинам (в стартап). Хотя кто знает, может быть относительно "скромные" успехи Codex-а (в сравнении с Claude Code) тоже на это как-то повлияли 😱

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

Меня зацепили следующие моменты:

⚫OpenAI – Огромный монореп. Как результат куча дублирования кода (автор пишет, что видел дюжину реализаций агентских циклов), постоянно сломанный CI и долгий запуск тестов.

Отдельно позабавила вот эта цитата 🥺

You will encounter both libraries designed for scale from 10y Google veterans as well as throwaway Jupyter notebooks newly-minted PhDs.

Как говорится, ноутбуки наше все )))

⚫Codex был написан с нуля за 7 недель командой из 8 инженеров, 4 рисерчеров и 2 дизайнеров: логика, отдельная модель, среда исполнения, интерфейсы и опенсоурсный релиз. Люди работали с 7 утра и до ночи без выходных, чтобы успеть к сроку.

⚫Сильный акцент на Bias For Action. Просто берешь инициативу и делаешь. А дальше, если идея перспективна, то к ней подтянутся люди и соберется целая команда. Не знаю, как эти слова транслируются в реальность, ведь как правило все люди привязаны к менеджеру, а менеджер к leadership, который формирует конкретные ожидания. Но мб если работать по 80 часов в неделю, то пространство есть )))

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

⚫Вся коммуникация исключительно в слаке, почтой не пользуются

Искал статьи / работы рисерчеров, участвовавших в разработке Deep Research и наткнулся на блог одного из ключевых авторов технологии — Джейсона Вэя (Jason Wei). Ссылка на блог. Джейсон является первым автором статьи про Chain of Thought ещё со времён работы в Google Brain (теперь часть Дип Майнда).

В блоге Джейсон интересно пишет свои мысли про рисерч, как его вести, как строить карьерный путь и немного рефлексии на тему своих же научных статей.

Из интересного про RL — Асимметрия верификации. Ссылка

Множество задач требуют значительных усилий для генерации решения, но при этом легко поддаются проверке. Взять судоку или кроссворд. А вот написание эссе на заданную тему — напротив: сгенерировать его для модели несложно, а вот провести факт-чекинг и оценить содержание гораздо труднее. В этом и заключается асимметрия верификации: есть задачи, которые можно быстро и дёшево проверить на корректность (при наличии эталонного ответа), но при этом неясно, как к этому ответу прийти; а есть такие, к которым можно сгенерировать тысячи вариантов, но трудно определить, какие из них действительно правильные.

Тут и начинается самое интересное — поиск способов уменьшения асимметрии. Для большого класса сложных задач это действительно возможно. Например, асимметрию можно значительно снизить для задач по математике и программированию (Картинка к посту). Как? Если для задачи есть эталонное решение или тесты на корректность, то в процессе эволюции, какой бы сложной она ни была, генерация правильного ответа становится задачей RL-оптимизации.

Путём таких рассуждений автор приходит к формулировке условного "закона":

Verifier’s law: The ease of training AI to solve a task is proportional to how verifiable the task is. All tasks that are possible to solve and easy to verify will be solved by AI.

И дальше выделяет пять свойств, которыми должна обладать задача, чтобы быть "легко" решённой LLM:

⚫️Быстрота верификации — можно за секунды определить, правильно ли решена задача
⚫️Скейлинг верификации — можно проверять одновременно множество решений
⚫️Согласованность корректности — все (люди) легко могут придти к консенсусу о том, какое решение хорошее, а какое нет
⚫️Ранжирование качества решений — можно упорядочить варианты по степени качества
⚫️ Устойчивость к шуму — верификация коррелирует с качеством решения и ложно-положительные срабатывания минимальны

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

Отдельно можно заметить, что большинство популярных бенчмарков как раз обладают всеми свойствами задачи для верификаци (MMLU, SWE bench, GSM8K, тот же Humanity's Last Exam). Потому эти бенчмарки и популярны, и потому в тех аспектах, что они проверяют (код, общие знания, математику) LLM-ы развиваются активнее всего.

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

Короткая сводка наиболее откликающихся мыслей в хронологическом порядке изложения автора:

[Research I enjoy]
Автор критически смотрит на свои ранние публикации и находит их слишком специфичными, «заточенными» под одну задачу. Например, применить модель к конкретному сетапу или выбить прирост в пару процентов на конкретном бенчмарке с помощью сложного не обобщаемого метода. Такие работы обычно не находят отклик в сообществе и не двигают прогресс. Поэтому, если тема слишком узкая, то какой бы крутой ни была реализация, импакт всё равно будет незначительным.
Рисерч, который откликается автору и которым он пытается заниматься:
(1) строится вокруг общих, переиспользуемых идей (новая архитектура, новый метод, новый рецепт предобучения),
(2) направлен на достижение AGI,
(3) нацелен задать вектор влияния на сообщество.

Статья про CoT-Prompting является идеальным примером реализации этой мысли.

[Practicing AI Research]
Умение делать рисерч — это тренируемая способность. Автор выделяет четыре ключевых навыка, из которых состоит рисерч:
⚫️Отбор идей. Вырабатывание собственного «вкуса», проработка концепций и выбор тем, в которые веришь и которые соответствуют твоим принципам. Автор предпочитает обобщённые идеи, без ухода в излишнюю специфику. Как правило, это оказывается «hot topic», над которой и так всё работают, и ты стараешься сделать лучше остальных.

⚫️Дизайн экспериментов и их реализация. У исследования должен быть чёткий набор Research Questions, на которые в ходе работы будут найдены ответы. Хорошая практика — регулярно обсуждать прогресс с коллегами.

⚫️Работа над статьей. Простым языком изложить суть работы, ключевые результаты, объяснить, почему эта работа важна для сообщества и как применить идеи на практике.

⚫️Максимизация импакта. Журналы, конференции, блогпосты, twitter, подкасты — все инструменты хороши, чтобы «прорекламировать» миру свою работу и показать её значимость.

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

[Dopamine cycles in AI research]
AI-исследователи заканчивают свой день (или неделю) либо в хорошем настроении, либо в плохом — всё зависит от того, сработала ли сегодня гипотеза, в которую ты веришь.
Да — супер, допаминовый скачок.
Нет — фрустрация, уходишь в дебаг и допаминовую просадку.
Так или иначе, ресерч создаёт асимметричные по длительности допаминовые циклы, и нужно иметь навыки саморегуляции, чтобы не отлететь.

[AI research is a max-performance domain]
Что значит «max-performance domain»? Для того чтобы быть топ-исследователем, достаточно выдающихся результатов лишь в одном аспекте своей работы. Обучить лучшую модель или создать прорывной алгоритм — и ты уже востребован, в то время как все смежные компетенции (навыки спикера, разработчика, прохождения кодинг-интервью) не имеют значения и прощаются.
И не обязательно делать прорыв каждый год — раз в несколько лет достаточно, потому что метрика исследователя:

лучшие пять работ (не обязательно научных публикаций) за карьеру, а не средний результат.

Отрасли, где результаты имеют большой импакт на мир сегодня (сейчас AI, в прошлом веке — ядерная и квантовая физика), позволяют исследователям оперировать в таком уникальном режиме.

---

Многие из этих мыслей вдохновлены принципами, озвученными Ричардом Хэммингом в 1986 году. You and Your Research, by Richard Hamming. Рекомендую.

Senior DL Engineer в 🏦, Лаборатория Машинного обучения, Москва

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

Авторская орфография сохранена

➡Ник автора в тг - @maksimallist
➡ Название компании - Alfabank

➡Расскажите про свой бэкграунд - Senior DL researcher/engineer. Основная область экспертизы - NLP. Но есть опыт так же и в CV, в основном в области генерации изображений. Старт карьеры пришелся на научную сферу, работал в лаборатории глубокого обучения и нейронных сетей на физтехе. Есть статьи в рецензируемых научных журналах, и победы в соревнованиях. После чего ушел в бизнес, большую часть карьеры провел в Сбере и AIRI. Пытался замутить свой стартап, но безуспешно.
➡Как подались на вакансию - Нашел объявление в сингулярисе, отправил на почту свое резюме.

🔥 Субъективно Сложность процесса по 10 бальной шкале - 5

➡Когда начали процесс - январь 2025
➡Когда закончили процесс - Прошел весь процесс за неделю, может чуть больше

➡ Позиция, на которую собеседовались - Senior NLP engineer
➡Грейд на который собеседовались (если известно) - Старший разработчик нейронных сетей. Численного грейда нет.
➡Локация вакансии - Москва

🔥 Расскажите про этапы собеседований

- Техническое собеседование
1) Первое знакомство + техническое собеседование
2) При знакомстве спрашивали про образование и профессиональный опыт. Далее шло техническое собеседование где, для начала предложили в блонкноте написать по тз простенькую нейронную сеть (подразумевалось что можно использовать pytorch), а потом был ряд вопросов на понимание механизмов обработки текста, устройства больших языковых моделей (разумеется глубже чем устройство attention mechanism). После еще немного поговорили про историю развития NLP.
3) Интервью проводил непосредственно мой потенциальный начальник. Длилось оно полтора часа, может чуть больше.

- Собеседование с руководителем подразделения
1) Собеседование с руководителем.
2) Снова быстро прошлись по профессиональному опыту. После был ряд вопросов, касающихся в основном личных качеств. Например: "Что раздражает в работе?", "Что мотивирует.", "Как снимаешь стресс?", "Чем больше нравится заниматься: разработкой или руководством". Просили назвать минусы предыдущих мест работы, а потом плюсы. Озвучить амбиции, и описать как я вижу свою работу у них в команде. Ну и после я задал интересующие меня вопросы. Там же обсудили мои ожидания по зп и режиме работы.
3) Отдельных наблюдений я наверное не выделю.

⏺ Что понравилось:

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

1. Нашёл вакансию сам, резюме кинул прямо будущему руководителю ― никаких HR, анкет и «этапов для галочки».

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

3. Вопросы ― в основном на способность рассуждать в NLP и чуть-чуть system design. Созвон затянулся, но мы оба чётко поняли: он — мой уровень, я — свои задачи.

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

5. Вся история — два созвона за неделю, потом быстрая проверка СБ и сразу договор. Соискатель счастлив, начальник тоже: Win-Win.

6. Нет «пяти этапов на полтора месяца», нет бессмысленных звонков с людьми, которых больше не увижу. Такой процесс редок, но окупается для всех.

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

⏺Что не понравилось:
Все понравилось


➡Итоги собеседования: Принял оффер.

💸Информация про Total Compensation: Не обидели)
От автора канала: Вилки в команду хорошие, на сеньор грейд 400-570K + 15% ежеквартальная премия. Инфу взял из Нескучный Data Science Jobs, тут.

#интервью

@max_dot_sh