⌨ Опен Соурсный ответ Claude Code

Компания All Hands AI релизунла CLI инструмент для кодинга - OpenHands CLI.

Твит с релизом.

Поставить можно через pip install openhands-ai.

Функционал аналогичен Claude Code – агент может редактировать код, запускать команды, делать навигацию по файловой системе, ходить в веб, делать API вызовы, взаимодействовать с MCP серверами, работать в автономном режиме.

При желании можно развернуть свою LLM и подключить ее, а не провайдера.

Лицензия MIT. Все есть на гитхабе. Можно расширить под свои нужды как хочется.

Еще добавили микро гайд про Prompting Best Practises для кодинг агентов. Читать тут

TL;DR Нужно быть как можно конкретным и локальным в запросах к агенту, чтобы он ничего не додумывал. Хотите пофиксить баг – локализуйте файл и строчку кода, где возникает проблема или дайте указатель на функцию и опишите ожидаемое поведение:

Fix the TypeError in frontend/src/components/UserProfile.tsx occurring on line 42. The error suggests we’re trying to access a property of undefined.

В анонсе пишут, что Has top accuracy (similar to Claude Code). Буду тестировать в ближайшее время.

@max_dot_sh

💼 Career Update - ушел из Фаанга в ранний стартап

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

В стартапах я никогда прежде не работал. В целом в компаниях без четкого продуктового виденья (или как принятно говорить market fit-а) тоже. Поэтому было интересно "умеренно" рискнуть.

В итоге присоединился в качестве первого рисерчера к series A стартапу Tessl. Задумка компании в слогане на лэндинге:

You make the spec, AI codes & maintains

На данный момент компания хочет прийти к будущему, в котором больше не нужно писать код (как неожиданно). Вместо этого есть спецификация (spec), такой исчерпывающий дизайн док, в котором описаны все требования (архитектура, язык, стек, фреймворки, API) к продукту или сервису. И на основе этого документа AI Engine напишет весь код самостоятельно. Ну а дальше, когда появится необходимость в новой фиче, взаимодействие будет через тот же документ – AI сделает весь maintenance. spec писать самому с нуля не надо – LLM-ы будут помогать.

Концепция спецификации сейчас регулярно проскакивает у многих компаний как один из векторов развития AI кодогенерации. На недавнем саммите Open AI выступали c точно такой же мотивацией: The new code: Specs, write once, run everywhere и несколько раз подчеркивали A written specification aligns humans.

Интерес к генерации кода с помощью LLM сильно нагрелся в последние год-полтора. В целом все стартапы и крупные игроки так или иначе делают "spec driven development" в том или ином виде. А большие сделки по типу поглощения Windsurf-а, или огромному раунду инвестиций в Cursor только разгоняют ажиотаж (и одновременно повышают тревожность🥲) дальше.

Так что да, решил покрутить рулетку и поиграть в стартапы – посмотрим что выйдет.

Принимая решения руководствовался такими факторами:

0) хочу для себя понять, где комфортнее: в ранних компаниях или больших
1) сильный фаундер (вырастил два Юникрона),
2) очень хорошие инвесторы и вера в проект ($25М seed и $100M round A)
3) сильная инженерная и продуктовая команда (чуть ли не треть людей ex-Гуглеры, от Principal инженеров до директоров)
4) рисерч команда (пока что я один, но скоро выйдут ребята из других фаангов, включая Мету и Дипмайнд)
5) новый домен, новая роль

В отдельном посте подробнее расскажу, как выбирал новое место.🫡

__

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

Еще можете послушать подкаст. Да, у компании есть свой подкаст с разными AI фаундерами / интересными людьми! Слушать/смотреть тут. Я с удовольствием посмотрел выпуск с ко-фаундером 11Labs.

@max_dot_sh

🔍AI Development Ecosystem Landscape

Собрали вместе с командой классификацию популярных AI инструментов для разработчиков. Вносим немного структуры в навигацию по рынку доступных решений.

Посмотреть можно тут

Выделили следующие базовые категории: Product (тулзы для no-code прототипирования типа Lovable), Code (все что полезно для продуктивности тех, кто пишет код), Terminal (для CLI решений), Devops, Quality Assurance и AI Engineering (про модели, MCP сервера и сэндбоксы для запуска агентов).

В каждой категории есть подкатегории.

Классификация будет обновляться.

Любой желающий может стать контрибьютором и добавить свой инструмент или порекомендовать правку к описанию. Инструкция тут.

#образование

@max_dot_sh

Senior SWE ML в Ⓜ️, Infra Team, London

Cовсем свежая история успеха (оффера) в команду ML инфраструктуры Ⓜ️ – Позиция для людей с опытом в машинном обучении и большим бэкграундом в разработке.

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

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

➡️Расскажите про свой бэкграунд - ML Engineer в TikTok, Antispam & Integrity
➡️Как подались на вакансию - Referred by a friend

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

➡️Когда начали процесс - 03/25
➡️Когда закончили процесс - 05/25

➡️ Позиция, на которую собеседовались - SWE ML, SWE Infra
➡️Грейд на который собеседовались (если известно) -E5 (Senior роль, аналог L5 Гугл, L6 Амазон)
➡️Локация вакансии - London

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

Подавался на SWE ML

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

- Литкод 1
Два медиума +- из списка 100 задач с литкода в мету https://interviewsolver.com/interview-questions/meta

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

- Финал день 1
Два медиума литкода на одном интервью и бихейв вопросы на 2м интервью. Спросили как решал конфликты с командой, про проекты с большим импактом над которыми работал, что и как я там делал, как вел проекты и общался с командой.

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

- Фидбэк с финала
Позвонил эйчар и сказал что все интервью прошел хорошо, кроме МЛ систем дизайна, на ML SWE меня брать не хотели, но он предложил пройти обычный систем дизайн и пойти на SWE Infra

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

- Фидбэк с систем дизайна
Позвонил эйчар, сказал что обычный систем дизайн я прошел хорошо и сказал что дают оффер на E5 SWE Infra, нужно дальше сматчится с командой

- Team matching
Через неделю или меньше нашлась команда, я пару раз созвонился с менеджером и задавал вопросы, был хороший матч, текущая моя роль была очень похожа

⏺ Что понравилось:
- Эйчар не торопил, можно было взять время подготовиться


⏺Что не понравилось:
- Торопили на тим матчинге, только одна команда была доступна, эйчар сказал что нельзя выбирать из нескольких параллельно


➡️Итоги собеседования: У меня был другой оффер, я сказал об этом, и попросил больше, мета отказалась поднимать оффер и я пошел в другую компанию. Плюс не очень хотел заниматься тем же самым что и в предыдущем месте (Integrity)

💸Информация про Total Compensation: 100-110 gbp base, 300-350 usd RSU over 4 years, 0 sign on

🎤От автора канала: Недавно обсуждали что классический System Design для ML ролей вроде как убрали, но на SWE ML позиции он все-таки есть, думаю из-за специфики позиции. Сессия ML Design в этом отзыве очень напоминает историю отсюда. В остальном все как и всегда у Меты: очень-очень много литкода, большой фокус на скоростном решении алгоритмических задач и как-то совсем мало внимания опыту кандидата в рамках тех. интервью

#интервью

@max_dot_sh

🧑‍💻 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 часов в неделю, то пространство есть )))

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

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