Forwarded from Pavel Zloi
Вайб-код StarterKit - как эффективно писать код на `auto` агенте
Всем привет! Сегодня расскажу про некоторые мои промты, которые я использую для вайбкодинга, они сильно упрощают процесс разработки и повышают точность агентов, благодаря чему можно использовать даже слабые и self-hosted модели.
Инициализация
Обычно если мне нужно быстро разобраться в каком-то новом проекте написанном на python, или же беру в работу новую фичу, я прошу Cursor:
Это позволяет прогреть контекс перед началом работы.
Генерация правил
Если проект новый или старый и у него нет правил Cursor Rules то я прошу курсор сгенерировать правила работы с проектом (к сожалению авторы в 2.0 решили убрать эту фичу, но можно описать, как генерировать правила самостоятельно и всё будет окей).
Тут очень важно у вас в корне проекта были текстовые спецификации проекта подготовленные заранее, либо как вариант актуальная документация.
Желательно чтобы в спеках или доке была информация об архитектуре, о том какую бизнес-задачу решает система, от каких компонентов система зависит и каким образом предполагается пользователям с ней взаимодействовать. Нефункциональные требования тоже будут плюсом, это чуть уменьшит полёт фантазии модели.
Пример промта смотри на GitHub, а в моих более ранних сообщениях (раз, два, три) на тему вайбкода будут подробности.
Исправление бага
В случае если нужно решить какой-то баг на прогретом контексте пишем текстом, что нужно исправить и далее такую вот простенькую инструкцию:
Финальная прогонка
Перед тем как коммитать файлы в репозиторий я прошу курсор выполнить следующее:
Предполагаю, что у меня уже настроен pre-commit, который тригерит хуки ruff, flake8, docformatter, mdformat и так далее.
Итог
Надеюсь эти промты пригодятся и вам, репозиторий с промтами на GitHub.
UPD. Добавил в реп примеры моих cursor rules, которые мигрируют из проекта в проект.
Всем привет! Сегодня расскажу про некоторые мои промты, которые я использую для вайбкодинга, они сильно упрощают процесс разработки и повышают точность агентов, благодаря чему можно использовать даже слабые и self-hosted модели.
Инициализация
Обычно если мне нужно быстро разобраться в каком-то новом проекте написанном на python, или же беру в работу новую фичу, я прошу Cursor:
Изучи код, документацию и тесты, `venv` в .venv, запускать тесты через `pytest`, выполни тесты, попытайся разобраться что и как работает, напиши краткий отчёт.
Это позволяет прогреть контекс перед началом работы.
Генерация правил
Если проект новый или старый и у него нет правил Cursor Rules то я прошу курсор сгенерировать правила работы с проектом (к сожалению авторы в 2.0 решили убрать эту фичу, но можно описать, как генерировать правила самостоятельно и всё будет окей).
Тут очень важно у вас в корне проекта были текстовые спецификации проекта подготовленные заранее, либо как вариант актуальная документация.
Желательно чтобы в спеках или доке была информация об архитектуре, о том какую бизнес-задачу решает система, от каких компонентов система зависит и каким образом предполагается пользователям с ней взаимодействовать. Нефункциональные требования тоже будут плюсом, это чуть уменьшит полёт фантазии модели.
Пример промта смотри на GitHub, а в моих более ранних сообщениях (раз, два, три) на тему вайбкода будут подробности.
Исправление бага
В случае если нужно решить какой-то баг на прогретом контексте пишем текстом, что нужно исправить и далее такую вот простенькую инструкцию:
<описание бага>
Сначала напиши тест воспроизводящий данный баг, выполни его и убедись, что ошибка действительно есть, потом пиши код исправляющий ошибку и выполни тест, вноси исправления до тех пор, пока новый тест не заработает, выполни прогонку всех тестов и если они все зелёные пиши краткий отчёт о проделанной работе.
Финальная прогонка
Перед тем как коммитать файлы в репозиторий я прошу курсор выполнить следующее:
Используя `pre-commit run -a` выполни проверку всех файлов, в случае возникновения ошибок внеси корректировки в соответствии с рекомендациями линтеров.
Предполагаю, что у меня уже настроен pre-commit, который тригерит хуки ruff, flake8, docformatter, mdformat и так далее.
Итог
Надеюсь эти промты пригодятся и вам, репозиторий с промтами на GitHub.
UPD. Добавил в реп примеры моих cursor rules, которые мигрируют из проекта в проект.
Forwarded from Pavel Zloi
GitHub
GitHub - vamplabAI/sgr-agent-core: Hybrid Schema-Guided Reasoning (SGR) has agentic system design created by neuraldeep community
Hybrid Schema-Guided Reasoning (SGR) has agentic system design created by neuraldeep community - vamplabAI/sgr-agent-core
Ну что ж, Новый год уже на носу, поэтому я с подарочками.
Вы, возможно, помните замечательный проект sgr-agent-core, в котором я участвую. Так вот, мы с командой очень старались и запилили большое обновление 0.5.0!
Главная цель этого релиза была в том чтобы максимально упростить для пользователей развёртывание и вход в проект. Теперь можно поставить всё одной командой:
После установки появляется возможность запустить локальный API-сервер командой:
Да, конечно, понадобится подготовить конфигурационный файл и настроить модели через конфиг, но мы как раз запилили документацию, так что всё стало сильно проще и понятнее.
Лично мне в этом релизе очень хотелось добиться ситуации, когда проект можно использовать примерно как docker compose, то есть максимально просто и удобно, без лишних сложностей, а именно запилил нужные тулзы, описал то, как работают агенты в конфиге, подкинул промпты и вуаля, у вас в распоряжении API-шка, совместимая с любым OpenAI-клиентом, только с SGR под капотом.
Надеюсь, вы оцените мой скромный вклад в то, что оно ощущается теперь именно так.
По ходу разработки нам стало пилить проект заметно проще, благодаря Валерию @neuraldeep удалось заручиться поддержкой ребят из red_mad_robots! Так что теперь у нас нет ограничений по инференсу и вычислительным ресурсам, и дело пошло с очень мощным бустом.
Отдельное спасибо всем, кто участвовал в подготовке релиза, а именно:
- Артёму @virrius (и да - подписывайтесь на его канал @virrius_tech) за кропотливый труд и внимание к моему, скажем так, вайбкоду ;)
- Михаилу @mixaill76 - за помощь с упаковкой в python-пакет и оптимизацию пайплайнов тестирования и деплоя
- Новичкам проекта SnakeOilSalesman и igorvolk1961 за помощь в приведении кодовой базы в порядок
Вот такой вот отличный релиз получился, прямо вам под новогоднюю ёлку🎄
Всех с наступающими праздниками и длинными выходными!
Вы, возможно, помните замечательный проект sgr-agent-core, в котором я участвую. Так вот, мы с командой очень старались и запилили большое обновление 0.5.0!
Главная цель этого релиза была в том чтобы максимально упростить для пользователей развёртывание и вход в проект. Теперь можно поставить всё одной командой:
pip install sgr-agent-core
После установки появляется возможность запустить локальный API-сервер командой:
sgr
Да, конечно, понадобится подготовить конфигурационный файл и настроить модели через конфиг, но мы как раз запилили документацию, так что всё стало сильно проще и понятнее.
Лично мне в этом релизе очень хотелось добиться ситуации, когда проект можно использовать примерно как docker compose, то есть максимально просто и удобно, без лишних сложностей, а именно запилил нужные тулзы, описал то, как работают агенты в конфиге, подкинул промпты и вуаля, у вас в распоряжении API-шка, совместимая с любым OpenAI-клиентом, только с SGR под капотом.
Надеюсь, вы оцените мой скромный вклад в то, что оно ощущается теперь именно так.
По ходу разработки нам стало пилить проект заметно проще, благодаря Валерию @neuraldeep удалось заручиться поддержкой ребят из red_mad_robots! Так что теперь у нас нет ограничений по инференсу и вычислительным ресурсам, и дело пошло с очень мощным бустом.
Отдельное спасибо всем, кто участвовал в подготовке релиза, а именно:
- Артёму @virrius (и да - подписывайтесь на его канал @virrius_tech) за кропотливый труд и внимание к моему, скажем так, вайбкоду ;)
- Михаилу @mixaill76 - за помощь с упаковкой в python-пакет и оптимизацию пайплайнов тестирования и деплоя
- Новичкам проекта SnakeOilSalesman и igorvolk1961 за помощь в приведении кодовой базы в порядок
Вот такой вот отличный релиз получился, прямо вам под новогоднюю ёлку
Всех с наступающими праздниками и длинными выходными!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from эйай ньюз
This media is not supported in your browser
VIEW IN TELEGRAM
LTX-2 - open weight 4K/50fps видео с аудио от Lightricks
Lightricks, компания, стоящая за одним из первых "контент-заводов" LTX-Studio ещё до того, как эти заводы заполонили Твиттер, сделала интересный пивот. Чуваки выпустили в опенсорс видеомодель LTX-2, первая версия которой, лежала в основе их реактора.
Модель занимает не самое высокое 23-е место на LM видео арене, но главное здесь не это. LTX-2 — первая полностью открытая модель, которая умеет генерить нативное 4K видео при 50 FPS с синхронизированным аудио (диалоги, музыка, SFX) длиной до 20 секунд.
В основе LTX-2 лежит единый асимметричный двухпоточный трансформер для совместной генерации аудио и видео через кросс-атенш.
Модель на 19B (14 для видео и 5 для аудио) спроектирована для запуска на потребительских GPU. В опенсорс выложены не только веса, но и пайплайны для инференса и код для тренировки. Кроме того из коробки LTX-2 квантована в NVFP8 (на 30% меньше, до 2х раз быстрее) и оптимизирована под экосистему NVIDIA, а ComfyUI поддерживает её с первого дня.
Не совсем понятно, как этот релиз сочетается с их основной бизнес-моделью. И если раньше их амбициозное желание создать свою модель было понятно, то зачем выкладывать её в опенсорс — совсем неясно. Ведь умельцы из ComfyUI уже повторили тот же LTX Studio у себя в Comfy и n8n на других моделях.
UPD: На сайте пишут про нативные 4K, но на деле же, как верно подметили в комментариях, там стоит стоит апскейл.
Техрепорт
GitHub
Hugging Face
Попробовать
@ai_newz
Lightricks, компания, стоящая за одним из первых "контент-заводов" LTX-Studio ещё до того, как эти заводы заполонили Твиттер, сделала интересный пивот. Чуваки выпустили в опенсорс видеомодель LTX-2, первая версия которой, лежала в основе их реактора.
Модель занимает не самое высокое 23-е место на LM видео арене, но главное здесь не это. LTX-2 — первая полностью открытая модель, которая умеет генерить нативное 4K видео при 50 FPS с синхронизированным аудио (диалоги, музыка, SFX) длиной до 20 секунд.
В основе LTX-2 лежит единый асимметричный двухпоточный трансформер для совместной генерации аудио и видео через кросс-атенш.
Модель на 19B (14 для видео и 5 для аудио) спроектирована для запуска на потребительских GPU. В опенсорс выложены не только веса, но и пайплайны для инференса и код для тренировки. Кроме того из коробки LTX-2 квантована в NVFP8 (на 30% меньше, до 2х раз быстрее) и оптимизирована под экосистему NVIDIA, а ComfyUI поддерживает её с первого дня.
Не совсем понятно, как этот релиз сочетается с их основной бизнес-моделью. И если раньше их амбициозное желание создать свою модель было понятно, то зачем выкладывать её в опенсорс — совсем неясно. Ведь умельцы из ComfyUI уже повторили тот же LTX Studio у себя в Comfy и n8n на других моделях.
UPD: На сайте пишут про нативные 4K, но на деле же, как верно подметили в комментариях, там стоит стоит апскейл.
Техрепорт
GitHub
Hugging Face
Попробовать
@ai_newz
Forwarded from Канал Доброго Вани | Data Science и Продуктики
Как обычно, будем обсуждать всё в контексте маркетплейса. Пусть, для определенности, у нас есть
User_1, который купил товары Item_1, Item_2, ..., Item_N. Мы хотим по этой цепочке спрогнозировать Item_N+1, который пользователь с наибольшей вероятностью приобретет следующим.• Количество Item ограничено. Да, на маркетплейсе могут появляться новые товары, но мы будем считать, что асортимент внутри дня меняется незначительно. Допустим, что всего у нас M айтемов.
• Пользователи могут быть "Холодными" — то есть с короткой историей. Например, пользователь зарегистрировался только вчера и еще не успел купить ни одного товара. Пусть, на момент построения модели у нас U уникальных пользователей.
Очевидно, что у пользователей может быть как короткая, так и длинная история взаимодействий. Однако при обучении нейросети на Next Item Prediction все вектора пользователей (последовательность их действий) должны быть одинаковой длины (назовем ее D).
• У пользователей со слишком длинной историей оставим только последние D действий
• У пользователей с длиной истории меньшей, чем D, оставим все действия и дополним их "Паддингами" (то есть нулями). Для
D=5 у нас может получиться история юзера "0, 0, Item_X, Item_Y, Item_Z".Таким образом, для каждого из U пользователей мы хотим выбрать один из M товаров, который те захотят приобрести. При этом для каждого пользователя мы имеем его вектор длины D — для всех пользователей получится матрица размера
U x D (см фото).Изображение взято из статьи на Хабре
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AI и грабли
Делать прогнозы – дело неблагодарное. Но полезное. Заставляет оглянуться назад и отделить хайп от долгосрочных трендов. Пока катался по горам на байке, наформулировал три прогноза, которые меняют мои планы в 2026ом
1️⃣ Claude Code как агентное ядро для любой нишевой херни.
Что произошло ближе к концу 2025 года – агентность моделей прокачалась достаточно, чтобы уйти от фиксированных воркфлоу к гибким агентным системам. Теперь системы принимают решения о следующем шаге на основе инфы с предыдущего. И это наконец-то работает не только в презентациях
Вот только делать свою агентную систему – запарно. А хорошую агентную систему – еще запарнее. И особенно бомбит от осознания, что повторяешь все шишки, которые уже набили разработчики топового general-purpose агента – Claude Code
Вы скажете, что это специализированный агент для кодинга, но это не так. Любой кастомный агент так же обрастает вызовом тулов, сэндбоксом для запуска скриптов и динамическими промптами aka skills
Все больше команд вместо костыляния своих агентнов, будут брать Claude Agent SDK, докидывать ему нужные скиллы, MCP, рулсы и оборачивать в понятный простому пользователю UI вместо терминала. В конце поста – ссылка на крутой кейс от Рефата
2️⃣ Skills станут более популярными, чем MCP
Для меня и MCP выглядел странно как стандарт. Типа, просто зафиксировали формат вызова внешнего API в виде function calling. А где рокет саенс?
Но это дало простой унифицированный способ подключать внешние инструменты к LLMкам. А во многих компаниях "мы делаем свой MCP" вообще стало самым простым способом для топов отчитаться о наличии "AI стратегии" 📈
Skills – еще более простая штука. По сути – просто папочка с промптами + набор скриптов. У большинства опытных пользователей это и так было – помогает не засирать контекст сотней тулов какого-нибудь github mcp, а просто описать как пользоваться такой волшебной командой как git. А в большинстве случаев даже детали не нужны – ведь агент может просто вызвать
А тот факт, что они подгружаются динамически (в зависимости от текущей задачи) – убирает главное ограничение MCP
3️⃣ Стандартный работающий подход к архитектуре постоянной памяти агентов
Это прям новый тейк, родившийся во время разбора лидерборда ERC-3 (соревнование по построению агентских систем)
Я если честно думал, что мы еще далеко от самообучающихся систем. Да, что-то понемногу начинает работать, и даже Claude Code может сам корректировать свой CLAUDE.md, но это детский сад, если честно.
А тут кейс, где цифры говорят сами за себя. В ERC-3 с отрывом аж в 10 процентных пунктов (71.8% vs 62.1%) побеждает решение, где агент сам обучается и "запоминает" результаты предыдущих неудачных попыток.
Да, там это скорее хак – агент делает выводы по прогону сразу на всей паре сотен задач, а не на каждой индивидуально, но это не важно. Важно – что система вообще сходится к оптимуму, сама переписывая свой промпт. В 2024ом у меня такое не работало – ее болтало из стороны в сторону.
Значит, сейчас боттлнек агентских систем смещается – в область того, а что запомнить из предыдущих попыток, какие выводы сделать и как поменять поведение, чтобы не совершать одних и тех же прыжков по граблям при каждом запуске.
4️⃣ (бонус)
Нормальные Tools уже есть – модели уже берут инфу из внешнего мира (и помещают в него обратно). Если будет нормальная внешняя память, то собственные знания модели обо всем на свете – не нужны.
Даже маленькая модель, которая почти ничего не знает, но умеет обращаться с тулами, выявлять паттерны и запоминать точечную информацию – будет эффективнее, чем жирная модель без всего этого. Жду появления быстрых и дешевых LLMок на 1-2b параметров, в которых большая часть весов – не знания, а навыки. Такие execution engine
Ставим ставки?
Если есть другие любопытные прогнозы – делитесь в комментах, интересно, что думаете
Почитать:
- Пост Рефата про Claude Code в качестве agentic core
- Лидерборд соревнования ERC3 с описанием архитектур
1️⃣ Claude Code как агентное ядро для любой нишевой херни.
Что произошло ближе к концу 2025 года – агентность моделей прокачалась достаточно, чтобы уйти от фиксированных воркфлоу к гибким агентным системам. Теперь системы принимают решения о следующем шаге на основе инфы с предыдущего. И это наконец-то работает не только в презентациях
Вот только делать свою агентную систему – запарно. А хорошую агентную систему – еще запарнее. И особенно бомбит от осознания, что повторяешь все шишки, которые уже набили разработчики топового general-purpose агента – Claude Code
Вы скажете, что это специализированный агент для кодинга, но это не так. Любой кастомный агент так же обрастает вызовом тулов, сэндбоксом для запуска скриптов и динамическими промптами aka skills
Все больше команд вместо костыляния своих агентнов, будут брать Claude Agent SDK, докидывать ему нужные скиллы, MCP, рулсы и оборачивать в понятный простому пользователю UI вместо терминала. В конце поста – ссылка на крутой кейс от Рефата
2️⃣ Skills станут более популярными, чем MCP
Для меня и MCP выглядел странно как стандарт. Типа, просто зафиксировали формат вызова внешнего API в виде function calling. А где рокет саенс?
Но это дало простой унифицированный способ подключать внешние инструменты к LLMкам. А во многих компаниях "мы делаем свой MCP" вообще стало самым простым способом для топов отчитаться о наличии "AI стратегии" 📈
Skills – еще более простая штука. По сути – просто папочка с промптами + набор скриптов. У большинства опытных пользователей это и так было – помогает не засирать контекст сотней тулов какого-нибудь github mcp, а просто описать как пользоваться такой волшебной командой как git. А в большинстве случаев даже детали не нужны – ведь агент может просто вызвать
<command> --helpА тот факт, что они подгружаются динамически (в зависимости от текущей задачи) – убирает главное ограничение MCP
3️⃣ Стандартный работающий подход к архитектуре постоянной памяти агентов
Это прям новый тейк, родившийся во время разбора лидерборда ERC-3 (соревнование по построению агентских систем)
Я если честно думал, что мы еще далеко от самообучающихся систем. Да, что-то понемногу начинает работать, и даже Claude Code может сам корректировать свой CLAUDE.md, но это детский сад, если честно.
А тут кейс, где цифры говорят сами за себя. В ERC-3 с отрывом аж в 10 процентных пунктов (71.8% vs 62.1%) побеждает решение, где агент сам обучается и "запоминает" результаты предыдущих неудачных попыток.
Да, там это скорее хак – агент делает выводы по прогону сразу на всей паре сотен задач, а не на каждой индивидуально, но это не важно. Важно – что система вообще сходится к оптимуму, сама переписывая свой промпт. В 2024ом у меня такое не работало – ее болтало из стороны в сторону.
Значит, сейчас боттлнек агентских систем смещается – в область того, а что запомнить из предыдущих попыток, какие выводы сделать и как поменять поведение, чтобы не совершать одних и тех же прыжков по граблям при каждом запуске.
4️⃣ (бонус)
Нормальные Tools уже есть – модели уже берут инфу из внешнего мира (и помещают в него обратно). Если будет нормальная внешняя память, то собственные знания модели обо всем на свете – не нужны.
Даже маленькая модель, которая почти ничего не знает, но умеет обращаться с тулами, выявлять паттерны и запоминать точечную информацию – будет эффективнее, чем жирная модель без всего этого. Жду появления быстрых и дешевых LLMок на 1-2b параметров, в которых большая часть весов – не знания, а навыки. Такие execution engine
Ставим ставки?
Если есть другие любопытные прогнозы – делитесь в комментах, интересно, что думаете
Почитать:
- Пост Рефата про Claude Code в качестве agentic core
- Лидерборд соревнования ERC3 с описанием архитектур
Forwarded from Ebout Data Science | Дима Савелко
Гайд по выходу из жопы: Стратегия жизни на 10 лет Возьмём двух челиксов: оба не глупые, оба пашут, у обоих по 24 часа в сутках. Но проходит 3 года: Первый уже живет у океана, у него системный бизнес и капитал, он пришел к цели быстро и словно по прямой. Второй всё так же в какашках: тушит пожары, вечно занят, устал, а по деньгам - тот же уровень, что и был
В чем может быть магия? В богатых родителях? Нет, вся разница - в дисциплине и механике постановки цели. Я был таким вторым, мне надоело быть челом, который плывёт по течению, хочется ставить долгосрочные цели и бить прям точно в них, понимая весь свой путь. Сегодня речь пойдёт про постановку личных целей на жизнь. Вам может показаться, что оно нахой вам и не надо, вы всё знаете. В таком случае я могу вам пожелать только удачи в жизни, а для остальных - текст ниже
Как не надо ставить цели? Второй (который буксует) мыслит из «сегодня» в «завтра»: «надо заработать кеш, что бы поделать? Запущу эту темку, потом эту». Это движение в тумане и движение в никуда.
И тут главный вопрос: Если ты идешь к новой жизни, используя свои старые паттерны мышления - как ты собираешься туда дойти? Твои старые паттерны привели тебя ровно туда, где ты сейчас сидишь. Они не могут привести тебя в новое место. Нельзя старыми ключами открыть новые двери.
Чтобы сделать прорыв, нужны совершенно новые паттерны. А где их взять? Только из будущего, надо ставить цель не «от забора до обеда», а из точки С (твоего идеала) - декомпозируя путь назад к сегодняшнему дню. Вот как это работает по шагам (сохраняй, это твоя инструкция на этот год)
ШАГ 1. Точка А (Где я сейчас?)
Самый больной, но самый важный этап, лично мне было тяжело его делать. Навигатор не построит маршрут в Дубай, если он думает, что ты в Париже, а ты в Суздали. В Точке А без иллюзий признаем, в каком мы состоянии прямо сейчас (по деньгам, энергии и отношениям).
Что тут важно: сначала мы пишем про духовность, здоровье, внешность, отношения и тд, а только в самом конце про деньги/доход. Так как деньги/доход - это всего лишь инструмент к достижению вещей выше
ШАГ 2. Точка С (Видение на 10+ лет)
Зачем она нужна? Точка С - твой маяк, в котором ты должен прям почувствовать, что это твоё. У меня была картинка, что я в своём доме, где моя семья, хуячу какой-то пиздатый бизнес с видом на горы/лес/море. Меня окружают дети/жена/семья, моя тусовка - предприниматели, а друзья всегда на подхвате, чтобы сходить в баньку или поиграть в плойку. Хочу, чтобы вы тоже представили каждую мелочь из своей точки С на 10 лет вперёд
ШАГ 3. Точка Б (Твердая цель на 2-3 года)
Это уже не мечты, а промежуточный проект к достижению Точки С. Мы берем энергию из точки С и приземляем её в цифры.
Критерии Точки Б:
Шаблон к табличке, чтобы вы заполнили, там кста будет автор данной методологии.
ШАГ 4. Обратная Декомпозиция
Вот здесь ломаются старые паттерны, и мои сломались тоже.
Мы не думаем: "Что мне поделать завтра?". Мы встаем в Точку Б (2028 год), где у нас уже всё есть, и смотрим НАЗАД.
Пример, как это выглядит:
Видите разницу? Каждое действие сегодня - это неизбежный шаг, продиктованный будущим, а не хаотичная попытка "что-то сделать"
Поэтому я вам искренне желаю сделать свою личную стратегию на 10 лет вперёд и увидеть чёткий план на 2026 год. Я составлял её 2 дня, было больно, руки опускались, но результат себя не составил долго ждать
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тимлид Очевидность | Евгений Антонов
Бигтех бигтеху рознь
Три года назад, когда я менял работу, мне хотелось понять, насколько мне будет подходить работа в бигтехе, поэтому я целенаправленно ходил на собеседования именно в такие организации.
Теперь-то я понимаю, что на самом деле, хоть и общие принципы работы в крупных компаниях едины: все эти пайплайны собеседований, планирования, перф-ревью, любовь к циферкам-метричкам-дашикам, внутренние коммуникации и прочие штуки, — НО бигтехи в частностях ОЧЕНЬ разные.
Я пишу этот пост по двум причинам:
1. Вдруг кто-то, как и я 3 года назад, думал, что есть какой-то абстрактный бигтех и оно всё везде похоже.
2. Я слушал одну книгу (потом отдельным постом её обязательно принесу, ибо она замечательная) и там описывалась идея «транзакционного налога» в крупных компаниях, которого нет в мелких. И вот у меня как раз был противоположный опыт, поэтому я решил с вами этим поделиться.
Сегодня я попробую просто порефлексировать о некоторых своих местах работы и посмотреть, где было дольше и тягомотнее.
Сисадмин в небольшой региональной компании (5-10 человек)
Мало людей, много объектов обслуживания, 1 тимлид. Так он там не назывался, но по факту делал всё, что делает тимлид, и даже больше. До сих пор является для меня одним из лучших примеров руководителей. Поймал себя сейчас на мысли, что ведь тогда он был моложе, чем я сейчас. Удивительный человек, конечно.
Всё делалось и решалось максимально быстро, согласований минимум.
Разработчик и тимлид в веб-студии (около 50 человек)
Тоже всё решалось быстро. Или через проектного менеджера, или напрямую с клиентом. До сих пор использую как шутку историю, когда меня добавил ПМ в чатик с клиентом. Посидел в этом чате недельку-две и со словами «ну вроде у вас и так всё нормально получается» вышел оттуда :)
Разработчик и тимлид в среднего размера продуктовой компании (700-1000 человек)
После десяти лет опыта очень динамичной работы я попадаю в компанию, где всё оооочень долго. Многоступенчатые согласования длятся месяцами. Это не прикол.
Однажды я был в цепочке писем с 10+ людьми в копии, где я как тимлид был самым младшим по иерархии. Там и руководители отделов и департаментов, и даже один топ был. Решали, какие написать буквы в названии продукта на разных платформах. Решали очень долго, хотя многократно были предупреждены, что покуда это не решится, не будет работать одна важная интеграция, которая оооочень много мильенов денег приносила.
Тимлид и технический менеджер проектов в крупной компании (10-20к+ людей)
Не уверен, сколько сейчас разработчиков в Яндексе, но мне кажется, где-то между 10 и 20 тысяч. Казалось бы, вот тут-то и должна быть еще бОльшая тягомотина. И внезапно всё оказалось довольно быстро. Много простора для инициативы, создания, изменения, а согласовывать каждый чих не нужно. Какие-то особо важные и крупные чихи нужно, конечно, но в целом довольно много можно запилить на уровне команды или даже одного человека.
(Чужой опыт) менеджер проектов в крупной компании (20к+ людей)
Общался месяц-два назад со своим товарищем, который в еще одном бигтехе работает. Обсуждали примерно одинаковые вещи, и вот у него опыт совершенно другой. Говорит, некоторые даже небольшие вещи надо месяцами согласовывать с ЛПР, комитетами, подкомитетами, уполномоченными ответственными, службой безопасности и прочее прочее.
(Чужой опыт) менеджер проектов в крупной компании (10к людей)
Другой мой товарищ в середине между «быстро» и «медленно». Темп бодрый, согласования, комитеты, обоснования и прочее подобное ярко выражено, но процессы так отлажены, что оно по конвейеру бежит довольно быстро.
Итог
Поработав в одном бигтехе, вы точно будете иметь представление об общих процессах. Но в темпе и деталях они очень сильно различаются. А внутри бигтеха отдельные подразделения тоже сильно отличаются, но уже в рамках культуры этой компании.
Три года назад, когда я менял работу, мне хотелось понять, насколько мне будет подходить работа в бигтехе, поэтому я целенаправленно ходил на собеседования именно в такие организации.
Теперь-то я понимаю, что на самом деле, хоть и общие принципы работы в крупных компаниях едины: все эти пайплайны собеседований, планирования, перф-ревью, любовь к циферкам-метричкам-дашикам, внутренние коммуникации и прочие штуки, — НО бигтехи в частностях ОЧЕНЬ разные.
Я пишу этот пост по двум причинам:
1. Вдруг кто-то, как и я 3 года назад, думал, что есть какой-то абстрактный бигтех и оно всё везде похоже.
2. Я слушал одну книгу (потом отдельным постом её обязательно принесу, ибо она замечательная) и там описывалась идея «транзакционного налога» в крупных компаниях, которого нет в мелких. И вот у меня как раз был противоположный опыт, поэтому я решил с вами этим поделиться.
Сегодня я попробую просто порефлексировать о некоторых своих местах работы и посмотреть, где было дольше и тягомотнее.
Сисадмин в небольшой региональной компании (5-10 человек)
Мало людей, много объектов обслуживания, 1 тимлид. Так он там не назывался, но по факту делал всё, что делает тимлид, и даже больше. До сих пор является для меня одним из лучших примеров руководителей. Поймал себя сейчас на мысли, что ведь тогда он был моложе, чем я сейчас. Удивительный человек, конечно.
Всё делалось и решалось максимально быстро, согласований минимум.
Разработчик и тимлид в веб-студии (около 50 человек)
Тоже всё решалось быстро. Или через проектного менеджера, или напрямую с клиентом. До сих пор использую как шутку историю, когда меня добавил ПМ в чатик с клиентом. Посидел в этом чате недельку-две и со словами «ну вроде у вас и так всё нормально получается» вышел оттуда :)
Разработчик и тимлид в среднего размера продуктовой компании (700-1000 человек)
После десяти лет опыта очень динамичной работы я попадаю в компанию, где всё оооочень долго. Многоступенчатые согласования длятся месяцами. Это не прикол.
Однажды я был в цепочке писем с 10+ людьми в копии, где я как тимлид был самым младшим по иерархии. Там и руководители отделов и департаментов, и даже один топ был. Решали, какие написать буквы в названии продукта на разных платформах. Решали очень долго, хотя многократно были предупреждены, что покуда это не решится, не будет работать одна важная интеграция, которая оооочень много мильенов денег приносила.
Тимлид и технический менеджер проектов в крупной компании (10-20к+ людей)
Не уверен, сколько сейчас разработчиков в Яндексе, но мне кажется, где-то между 10 и 20 тысяч. Казалось бы, вот тут-то и должна быть еще бОльшая тягомотина. И внезапно всё оказалось довольно быстро. Много простора для инициативы, создания, изменения, а согласовывать каждый чих не нужно. Какие-то особо важные и крупные чихи нужно, конечно, но в целом довольно много можно запилить на уровне команды или даже одного человека.
(Чужой опыт) менеджер проектов в крупной компании (20к+ людей)
Общался месяц-два назад со своим товарищем, который в еще одном бигтехе работает. Обсуждали примерно одинаковые вещи, и вот у него опыт совершенно другой. Говорит, некоторые даже небольшие вещи надо месяцами согласовывать с ЛПР, комитетами, подкомитетами, уполномоченными ответственными, службой безопасности и прочее прочее.
(Чужой опыт) менеджер проектов в крупной компании (10к людей)
Другой мой товарищ в середине между «быстро» и «медленно». Темп бодрый, согласования, комитеты, обоснования и прочее подобное ярко выражено, но процессы так отлажены, что оно по конвейеру бежит довольно быстро.
Итог
Поработав в одном бигтехе, вы точно будете иметь представление об общих процессах. Но в темпе и деталях они очень сильно различаются. А внутри бигтеха отдельные подразделения тоже сильно отличаются, но уже в рамках культуры этой компании.
Forwarded from Small Data Science for Russian Adventurers
#визуализация
Ещё одна электронная книга (небольшая) с визуализацией концепций ML. Сделано аккуратно: приводятся формулы, код и доводится до красивой картинки (или видео). Правда, всего 4 главы: оптимизация, кластеризация, линейные модели и нейросети. Материал "начального уровня" (но удобно, что он тут собран).
https://ml-visualized.com/
Ещё одна электронная книга (небольшая) с визуализацией концепций ML. Сделано аккуратно: приводятся формулы, код и доводится до красивой картинки (или видео). Правда, всего 4 главы: оптимизация, кластеризация, линейные модели и нейросети. Материал "начального уровня" (но удобно, что он тут собран).
https://ml-visualized.com/