Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Модель тройного долга от соавтора фреймворка SPACE
Сегодня я принес вам пост, который в очередной раз подчеркивает, что нельзя просто «внедрить ИИ, и всё будет хорошо» https://t.me/badTechProject/2108
Оказывается нужно:
- Работать над качеством. Тестирование и прочие контуры контроля, чтобы ломающая прод дичь (которую вы, может, даже и не прочтете в очередном пулреквесте на 10к строк кода) не дошла до деплоя.
- Нормально описывать спеки/adr’ы своих технических решений. Теперь не прокатит «Моя работа код писать, а не доки. Кому надо — код почитают, там всё понятно».
- Добросовестно формулировать не только что делать (привет менеджерам, которые приносят в задачу решение вместо проблемы), а и зачем это делать, что уже пробовали ранее, как и что исследовали (исследовали ведь? исследовали?!).
В общем, выглядит так, что нужно подготовить такой рабочий контекст и культуру в команде, о которых уже раньше много лет говорилось, но это было в некотором роде бест-практисом, рекомендацией, но не обязательным вариантом. Поэтому раньше люди срезали многие эти уголки, а со временем станет нельзя.
Сегодня я принес вам пост, который в очередной раз подчеркивает, что нельзя просто «внедрить ИИ, и всё будет хорошо» https://t.me/badTechProject/2108
Оказывается нужно:
- Работать над качеством. Тестирование и прочие контуры контроля, чтобы ломающая прод дичь (которую вы, может, даже и не прочтете в очередном пулреквесте на 10к строк кода) не дошла до деплоя.
- Нормально описывать спеки/adr’ы своих технических решений. Теперь не прокатит «Моя работа код писать, а не доки. Кому надо — код почитают, там всё понятно».
- Добросовестно формулировать не только что делать (привет менеджерам, которые приносят в задачу решение вместо проблемы), а и зачем это делать, что уже пробовали ранее, как и что исследовали (исследовали ведь? исследовали?!).
В общем, выглядит так, что нужно подготовить такой рабочий контекст и культуру в команде, о которых уже раньше много лет говорилось, но это было в некотором роде бест-практисом, рекомендацией, но не обязательным вариантом. Поэтому раньше люди срезали многие эти уголки, а со временем станет нельзя.
Telegram
Плохой менеджер Артём Арюткин
Модель тройного долга от соавтора фреймворка SPACE
Маргарет-Энн Стори, соавтор фреймворка SPACE для повышения продуктивности разработчиков, недавно представила свою модель тройного долга (Triple Debt Model), в которой скрытые человеческие издержки ускоренной…
Маргарет-Энн Стори, соавтор фреймворка SPACE для повышения продуктивности разработчиков, недавно представила свою модель тройного долга (Triple Debt Model), в которой скрытые человеческие издержки ускоренной…
Forwarded from Тимлид Очевидность | Евгений Антонов
Теория требований и ресурсов в работе
Недавно прочитал у оргпсихолога Аси Исаковой пост про теорию требований и ресурсов в работе. И это прям жиза. Потом как-нибудь расскажу про её лекции, как сам закончу их смотреть.
Что за теория такая?
Она рассматривает две сущности.
Требования: задачи, дедлайны, информационная и эмоциональная нагрузка, повышенная неопределенность. В общем, разряжатели.
Ресурсы: деньги, атмосфера в коллективе, признание, поддержка, обучение, возможности для развития, удобные инструменты. Заряжатели.
И вы не поверите, теория нам говорит, что надо следить за… БАЛАНСОМ первых и вторых. Вы скажете, ну, очередная очевидность же. Но давайте рассмотрим ситуации дисбаланса, вспомним наш рабочий опыт и как часто вы или ваши руководители бдели насчет этого баланса.
Много требований, мало ресурсов
Золотая классика. Куча работы, мало ресурсов, люди задолбанные, злые, саботирующие, не принимающие новшества (привет ИИ-буму и его отрицанию). Можно сказать, мол, времена такие, крутиться надо. В общем, да, но в частностях же, если всмотреться, то окажется, что где-то руководитель — трудоголик без семьи и хобби, у которого нога такая же, но не болит, где-то модель найма так специально построена: набираем недорого, выжимаем, берем следующих и т. д. Ну то есть баланс отрегулировать можно, но это не делают или нарочно, или по непониманию.
Мало требований, мало ресурсов
Я в такой ситуации бывал. Всё актуальное по красоте сделал, а сверх этого никому особо и не нужно ничего, да еще и платят мало. Тут люди либо работают откровенно мало и плохо, либо спустя полдня работы идут другими делами заниматься: одолевают непомерно выросшую библиотеку Стима, или забубенивают свой консалтинг да подкасты с каналами (ни на что не намекаю).
Мало требований, много ресурсов
Это немного отличается от предыдущего пункта. Тут тоже будет стагнация, но из-за того, что платят хорошо, атмосфера комфортная, забот мало, но любая какая-то новинка и суета потенциально может спугнуть этот комфорт. А в предыдущем случае платят мало, поэтому люди ищут какую-то компенсирующую по ресурсам деятельность.
Всегда шучу, что это идеальный вариант, чтобы выйти на пенсию, но никак не могу понять, где такое место. Если знаете, поделитесь по-братски в комментариях 🙂
Много требований, много ресурсов
Если «много ресурсов» не просто «ну мы, эцсамое, заплатили по рынку», а к этому еще прибавить моральный аспект из серии психологической безопасности, признания успехов, высоких стандартов качества работы (про это отдельный пост будет), то можно заиметь много высокомотивированных людей, которые фигачат как не в себя не потому, что кто-то требует, какие-то дедлайны жмут, или FOMO с тревожностью толкает вперед, а потому что людям правда приятно, интересно и они небезразличны ко всему происходящему. С такими мне тоже посчастливилось работать, и это было прекрасно.
Итог
Призываю каждого руководителя подумать о том, какую он создает ситуацию в команде и какая вокруг этой команды. Хороших вариантов, как вы видите, только четверть 🙂
Но баланс можно двигать иной раз даже в ситуациях, где кажется, что выхода нет. Я как-то работал в объективно недоплаченной команде и принимал сколько мог попыток это выровнять. Где-то помогло, а где-то было уже невозможно. Так вот, на уровне межличностных отношений, психологического и организационного комфорта мы создали настолько комфортные условия, что потом очень долго вместе работали в дружбе и согласии, а когда пришло время расходиться, то даже у некоторых ветром глазки надуло, если вы понимаете, о чем я 🙂
Недавно прочитал у оргпсихолога Аси Исаковой пост про теорию требований и ресурсов в работе. И это прям жиза. Потом как-нибудь расскажу про её лекции, как сам закончу их смотреть.
Что за теория такая?
Она рассматривает две сущности.
Требования: задачи, дедлайны, информационная и эмоциональная нагрузка, повышенная неопределенность. В общем, разряжатели.
Ресурсы: деньги, атмосфера в коллективе, признание, поддержка, обучение, возможности для развития, удобные инструменты. Заряжатели.
И вы не поверите, теория нам говорит, что надо следить за… БАЛАНСОМ первых и вторых. Вы скажете, ну, очередная очевидность же. Но давайте рассмотрим ситуации дисбаланса, вспомним наш рабочий опыт и как часто вы или ваши руководители бдели насчет этого баланса.
Много требований, мало ресурсов
Золотая классика. Куча работы, мало ресурсов, люди задолбанные, злые, саботирующие, не принимающие новшества (привет ИИ-буму и его отрицанию). Можно сказать, мол, времена такие, крутиться надо. В общем, да, но в частностях же, если всмотреться, то окажется, что где-то руководитель — трудоголик без семьи и хобби, у которого нога такая же, но не болит, где-то модель найма так специально построена: набираем недорого, выжимаем, берем следующих и т. д. Ну то есть баланс отрегулировать можно, но это не делают или нарочно, или по непониманию.
Мало требований, мало ресурсов
Я в такой ситуации бывал. Всё актуальное по красоте сделал, а сверх этого никому особо и не нужно ничего, да еще и платят мало. Тут люди либо работают откровенно мало и плохо, либо спустя полдня работы идут другими делами заниматься: одолевают непомерно выросшую библиотеку Стима, или забубенивают свой консалтинг да подкасты с каналами (ни на что не намекаю).
Мало требований, много ресурсов
Это немного отличается от предыдущего пункта. Тут тоже будет стагнация, но из-за того, что платят хорошо, атмосфера комфортная, забот мало, но любая какая-то новинка и суета потенциально может спугнуть этот комфорт. А в предыдущем случае платят мало, поэтому люди ищут какую-то компенсирующую по ресурсам деятельность.
Всегда шучу, что это идеальный вариант, чтобы выйти на пенсию, но никак не могу понять, где такое место. Если знаете, поделитесь по-братски в комментариях 🙂
Много требований, много ресурсов
Если «много ресурсов» не просто «ну мы, эцсамое, заплатили по рынку», а к этому еще прибавить моральный аспект из серии психологической безопасности, признания успехов, высоких стандартов качества работы (про это отдельный пост будет), то можно заиметь много высокомотивированных людей, которые фигачат как не в себя не потому, что кто-то требует, какие-то дедлайны жмут, или FOMO с тревожностью толкает вперед, а потому что людям правда приятно, интересно и они небезразличны ко всему происходящему. С такими мне тоже посчастливилось работать, и это было прекрасно.
Итог
Призываю каждого руководителя подумать о том, какую он создает ситуацию в команде и какая вокруг этой команды. Хороших вариантов, как вы видите, только четверть 🙂
Но баланс можно двигать иной раз даже в ситуациях, где кажется, что выхода нет. Я как-то работал в объективно недоплаченной команде и принимал сколько мог попыток это выровнять. Где-то помогло, а где-то было уже невозможно. Так вот, на уровне межличностных отношений, психологического и организационного комфорта мы создали настолько комфортные условия, что потом очень долго вместе работали в дружбе и согласии, а когда пришло время расходиться, то даже у некоторых ветром глазки надуло, если вы понимаете, о чем я 🙂
Forwarded from айти канал
Muon — сильная альтернатива AdamW для табличных DL моделей
Небольшой техрепорт от нашей tabular DL команды со сравнением оптимизаторов для современных табличных MLP, включая TabM:
https://arxiv.org/abs/2604.15297
В итоге рекомендуем попробовать для ваших tabular DL моделей, если еще не:
• Muon
• AdamW + EMA
Детали про Muon:
• Для успеха могут быть важны learning rate и weight decay. Скажем, у нас у Muon отдельный lr с более высокими характерными значениями, чем у AdamW.
• С Muon обучение будет дольше.
Небольшой техрепорт от нашей tabular DL команды со сравнением оптимизаторов для современных табличных MLP, включая TabM:
https://arxiv.org/abs/2604.15297
В итоге рекомендуем попробовать для ваших tabular DL моделей, если еще не:
• Muon
• AdamW + EMA
Детали про Muon:
• Для успеха могут быть важны learning rate и weight decay. Скажем, у нас у Muon отдельный lr с более высокими характерными значениями, чем у AdamW.
• С Muon обучение будет дольше.
arXiv.org
Benchmarking Optimizers for MLPs in Tabular Deep Learning
MLP is a heavily used backbone in modern deep learning (DL) architectures for supervised learning on tabular data, and AdamW is the go-to optimizer used to train tabular DL models. Unlike...
Forwarded from айти канал
🌐 sendme — инструмент для peer-to-peer обмена файлами 🌐
Иногда хочется поделиться файлами с другими людьми напрямую с ноутбука или удаленной машины, не загружая их ни в какое облако, мессенджер или репозиторий. Для этого есть разные инструменты, но хочу рассказать именно про sendme, который построен на интересном фреймворке iroh.
TL;DR (sendme)
Если у вас есть Pixi (рекомендую), то больше ничего и не нужно, просто делаете так:
И сообщаете получателям TICKET, который напечатала эта команда. Получатели файлов делают так:
После чего вы ждете завершения скачивания и останавливаете процесс. Готово! Файлы переданы напрямую получателям и не остались ни на каких third-party серверах.
Можно установить и использовать sendme без Pixi как написано тут.
Детали (iroh)
На самом деле sendme — это просто минимальный пример использования фреймворка iroh, который позволяет коммуницировать компьютерам безопасно и напрямую просто по сгенерированным ID вместо IP адресов, и почти без third-party серверов. "Почти", потому что промежуточный сервер все же нужен для установки первого контакта между машинами. Если контакт по каким-то причинам не установился, то промежуточный сервер служит прокси для передачи данных в зашифрованном виде, то есть сервер не видит и не сохраняет оригинальные данные.
У компании, которая разрабатывает iroh, есть публичные промежуточные серверы, благодаря которым и работают команды из TL;DR. Если для скорости и стабильности нужен собственный сервер, то можно либо заплатить за него, либо поднять свой такой сервер. А если вам интересно как это все вообще работает, чем отличается от WebRTC и прочее, то рекомендую поговорить с LLM или почитать раздел "How it works" и страницу "FAQ" в официальной документации.
Почему sendme
Вообще инструментов типа sendme много, но я в них не эксперт, поэтому не порекомендую что-то конкретное. Лично мне sendme приглянулся по таким причинам:
• Открытый код (для такого инструмента мне это кажется важным)
• Интересная технология под капотом
• Есть организация, которая за этим всем стоит
Ограничения
• sendme — это демо-приложение, код которого умещается в одном файле, и которое по дефолту полагается на сервера без гарантий на uptime и с rate limit'ами. Этого хватит для разовых пересылок, но не для сложных (production) сценариев. Для последних можно купить или поднять свой сервер.
• Технически количество получателей может быть любым, но вся нагрузка ляжет на вашу машину, плюс есть rate limit'ы публичных серверов. Так что транслировать файлы на весь интернет лучше не надо.
Иногда хочется поделиться файлами с другими людьми напрямую с ноутбука или удаленной машины, не загружая их ни в какое облако, мессенджер или репозиторий. Для этого есть разные инструменты, но хочу рассказать именно про sendme, который построен на интересном фреймворке iroh.
TL;DR (sendme)
Если у вас есть Pixi (рекомендую), то больше ничего и не нужно, просто делаете так:
pixi exec sendme send <FILE OR DIRECTORY>
И сообщаете получателям TICKET, который напечатала эта команда. Получатели файлов делают так:
pixi exec sendme receive <TICKET>
После чего вы ждете завершения скачивания и останавливаете процесс. Готово! Файлы переданы напрямую получателям и не остались ни на каких third-party серверах.
Можно установить и использовать sendme без Pixi как написано тут.
Детали (iroh)
На самом деле sendme — это просто минимальный пример использования фреймворка iroh, который позволяет коммуницировать компьютерам безопасно и напрямую просто по сгенерированным ID вместо IP адресов, и почти без third-party серверов. "Почти", потому что промежуточный сервер все же нужен для установки первого контакта между машинами. Если контакт по каким-то причинам не установился, то промежуточный сервер служит прокси для передачи данных в зашифрованном виде, то есть сервер не видит и не сохраняет оригинальные данные.
У компании, которая разрабатывает iroh, есть публичные промежуточные серверы, благодаря которым и работают команды из TL;DR. Если для скорости и стабильности нужен собственный сервер, то можно либо заплатить за него, либо поднять свой такой сервер. А если вам интересно как это все вообще работает, чем отличается от WebRTC и прочее, то рекомендую поговорить с LLM или почитать раздел "How it works" и страницу "FAQ" в официальной документации.
Почему sendme
Вообще инструментов типа sendme много, но я в них не эксперт, поэтому не порекомендую что-то конкретное. Лично мне sendme приглянулся по таким причинам:
• Открытый код (для такого инструмента мне это кажется важным)
• Интересная технология под капотом
• Есть организация, которая за этим всем стоит
Ограничения
• sendme — это демо-приложение, код которого умещается в одном файле, и которое по дефолту полагается на сервера без гарантий на uptime и с rate limit'ами. Этого хватит для разовых пересылок, но не для сложных (production) сценариев. Для последних можно купить или поднять свой сервер.
• Технически количество получателей может быть любым, но вся нагрузка ляжет на вашу машину, плюс есть rate limit'ы публичных серверов. Так что транслировать файлы на весь интернет лучше не надо.
GitHub
GitHub - n0-computer/sendme: A tool to send files and directories, based on iroh
A tool to send files and directories, based on iroh - n0-computer/sendme
Forwarded from айти канал
Herdr — современная замена tmux
TL;DR
Если вы используете tmux или zellij, не важно с агентами или без, обязательно попробуйте Herdr. Назад вы вряд ли вернетесь. Как минимум потому, что в Herdr работает мышка. Попробовать можно тут: https://github.com/herdrdev/herdr
Чем хорош Herdr?
💪 От самой базы ... (ее уже достаточно, чтобы заменить tmux):
- Персистентные сессии. Это как в tmux: можно запустить фоновую активность и закрыть терминал.
- Организация сессий в боковой панели. Это уже гораздо лучше, чем в tmux: в одном Herdr окне можно иметь много сессий и вкладок со всех проектов, которые у вас есть на одной машине, и легко в них ориентироваться, ничего не настраивая.
- Работает мышка. Как же это удобно. Все что должно скроллиться и нажиматься скроллится и нажимается.
- Сессии со всех машин в одном окне. Вы говорите herdr и получаете одно окно терминала со всеми сессиями и вкладками со всех (удаленных) машин, которые подключите.
🦾 ... и до агентских фичей:
- Нативные уведомления. Если во вкладке запущен агент, то из терминала приходят нативные OS уведомления, когда агенту нужен ваш ответ.
- Автоматическая детекция агентов. Если во вкладке запущен агент, то она отдельно выделяется в боковой панели.
- Agent-friendly CLI. Агенты могут сами управлять сессиями, вкладками и панелями через CLI.
Таймлайн личных наблюдений:
- Я узнал про Herdr, когда у него было около 400 звезд на гитхабе. Уникальность и полезность инструмента были очевидны, и сразу захотелось рассказать.
- Когда дошли руки до моего первого поста про Herdr, было уже около 4000 звезд.
- Сейчас у репозитория почти 40000 звезд. Проект был принят в YC Combinator и получил $6M инвестиций.
https://github.com/herdrdev/herdr
TL;DR
Если вы используете tmux или zellij, не важно с агентами или без, обязательно попробуйте Herdr. Назад вы вряд ли вернетесь. Как минимум потому, что в Herdr работает мышка. Попробовать можно тут: https://github.com/herdrdev/herdr
Чем хорош Herdr?
💪 От самой базы ... (ее уже достаточно, чтобы заменить tmux):
- Персистентные сессии. Это как в tmux: можно запустить фоновую активность и закрыть терминал.
- Организация сессий в боковой панели. Это уже гораздо лучше, чем в tmux: в одном Herdr окне можно иметь много сессий и вкладок со всех проектов, которые у вас есть на одной машине, и легко в них ориентироваться, ничего не настраивая.
- Работает мышка. Как же это удобно. Все что должно скроллиться и нажиматься скроллится и нажимается.
- Сессии со всех машин в одном окне. Вы говорите herdr и получаете одно окно терминала со всеми сессиями и вкладками со всех (удаленных) машин, которые подключите.
🦾 ... и до агентских фичей:
- Нативные уведомления. Если во вкладке запущен агент, то из терминала приходят нативные OS уведомления, когда агенту нужен ваш ответ.
- Автоматическая детекция агентов. Если во вкладке запущен агент, то она отдельно выделяется в боковой панели.
- Agent-friendly CLI. Агенты могут сами управлять сессиями, вкладками и панелями через CLI.
Таймлайн личных наблюдений:
- Я узнал про Herdr, когда у него было около 400 звезд на гитхабе. Уникальность и полезность инструмента были очевидны, и сразу захотелось рассказать.
- Когда дошли руки до моего первого поста про Herdr, было уже около 4000 звезд.
- Сейчас у репозитория почти 40000 звезд. Проект был принят в YC Combinator и получил $6M инвестиций.
https://github.com/herdrdev/herdr
GitHub
GitHub - herdrdev/herdr: the runtime your coding agents live on
the runtime your coding agents live on. Contribute to herdrdev/herdr development by creating an account on GitHub.
Forwarded from Борис опять
Постоянная рубрика: "блекпилл недели (и как с ним быть)"
После предыдущего болезненного опыта, где я обнаружил, что агенты ужасно пишут код и за ними потом надо неделями разгребать слоп, я задумался как быть. Это новая реальность разработки софта и мне как СТО нужно придумать как жить.
Изучая, что придумали более умные люди, я понял: ничего. Никто не знает как жить в новом мире, когда один разработчик производит столько кода, сколько в прошлом мог производить целый отдел. За пределами твиттера проблема известная (т.е. большие компании вроде Cloudflare и GitLab уже написали блог-посты), но решения никто не нашел.
На основе своего и чужого опыта придумал гайдлайны по AI разработке для нашей команды.
Основные предположения:
1. Код важен. Код это то, что действительно исполняется, а значит единственный источник истины. Все спеки это в лучшем случае искаженные описания кода, а чаще всего просто слоп-эссе на тему.
2. AI агенты это мультипликаторы скорости генерации кода. При наивном применении они перекладывают работу с автора кода на меинтейнера.
3. Главный ограничивающий ресурс это понимание кодовой базы разработчиками.
4. Деградация кода неизбежна и поддержание его качества это необходимая работа.
5. Агенты для кода ненадежны и непостоянны. Результат зависит от множества постоянно меняющихся факторов: модели меняются, сетап у всех разный, и так далее. Если что-то работает сейчас, нельзя гарантировать, что оно будет так же работать завтра.
6. Агенты для кода быстро производят техдолг и не могут самостоятельно его уменьшать.
Отсюда следующие принципы того, как может работать адекватная система:
1. Необходимо перенести работу по поддержанию качества назад с мейнтейнера на автора.
2. Люди отвечают за дизайн и архитектуру.
3. Люди отвечают за систему верификации: pre-commit, CI чеки, документация и принципы. Только люди редактируют AGENTS.md и постоянные доки.
4. Все правила, которые можно, нужно превращать в механические чеки, потому что промптинг не гарантирует, что агенты будут их соблюдать.
5. Борьба со слопом закладывается в бюджет.
6. Минимизируем человеческие затраты на ревью, максимально автоматизируем проверки и контроль качества.
Первый пункт самый главный: можно вайбкодить как угодно, если в результате у тебя рабочий код который ты понимаешь.
И конкретные практики:
1. Каждый PR не более +2к строк кода. Эмпирически найдено, что больше отревьюить невозможно.
2. Автор каждого PR сам пишет его описание по шаблону и указывает какие сущности за что отвечают.
3. Очень жесткие pre-commit и CI чеки.
4. Кастомный код-ревью бот в CI, который отсматривает каждый дифф и весь PR в целом с целью доказать, что он сломан. Промптится логом прошлых инцидентов, который пополняется только людьми.
5. Люди дизайнят скелет своих изменений в AI-assisted режиме, агенты заполняют пропуски.
6. Доки пишутся людьми, агентам запрещено их редактировать.
7. Разгребание слопа закладывается в планирование.
Всю карьеру (в эру кожаного кодинга) я считал pre-commit чеки очень бесячими и не особо полезными. Теперь же у нас самые жесткие чеки и линтеры в моей жизни. Там как базовые вещи вроде ruff и black, так и кастомные правила import linter, и многое другое. Я постоянно завожу что-то новое. Например, недавно добавил проверки на вложенность и цикломатическую сложность функций из SlopCodeBench. На днях появилась проверка всех диффов с помощью Jev.
Это более-менее сработало. Pre-commit с механически забитыми правилами позволяет видеть не совсем слоп на этапе ревью. Очень жесткий CI обеспечивает то, что слоп обнаруживается до мержа, а не после. Но появились новые проблемы.
Самая главная: актор с критиком могут очень долго итерироваться над PR без видимого прогресса. Агент делает изменения, ревьюер находит блокирующие проблемы, агент делает заплатку, ревьюер находит следующую дыру и так далее. Я видел как это происходило буквально днями, до тех пор, пока я не погружусь и не разберусь: в чем же корень проблемы? Ни одна модель (вклюбчая Fable и Astra) пока ни разу не смогла сама выбраться из этой спирали.
Вытекающая проблема: медленно. Теперь беклог PR разгребается гораздо медленнее, чем пополняется. У агентов как будто появляется новый инструмент: защита (своего кода) заебыванием. Когда ревьюер в десятый раз находит ошибку в каком-то PR возникает очень сильное желание вмержить его, чтобы просто больше не видеть. Парадоксальным образом я чувствую будто никогда в жизни столько не читал код, как в 2026.
Что иронично: ускорение от вайбкода как будто целиком компенсируется или замедлением на этапе ревью, или, если вы на вайбах, разгребанием проблем в проде спустя пару недель.
После предыдущего болезненного опыта, где я обнаружил, что агенты ужасно пишут код и за ними потом надо неделями разгребать слоп, я задумался как быть. Это новая реальность разработки софта и мне как СТО нужно придумать как жить.
Изучая, что придумали более умные люди, я понял: ничего. Никто не знает как жить в новом мире, когда один разработчик производит столько кода, сколько в прошлом мог производить целый отдел. За пределами твиттера проблема известная (т.е. большие компании вроде Cloudflare и GitLab уже написали блог-посты), но решения никто не нашел.
На основе своего и чужого опыта придумал гайдлайны по AI разработке для нашей команды.
Основные предположения:
1. Код важен. Код это то, что действительно исполняется, а значит единственный источник истины. Все спеки это в лучшем случае искаженные описания кода, а чаще всего просто слоп-эссе на тему.
2. AI агенты это мультипликаторы скорости генерации кода. При наивном применении они перекладывают работу с автора кода на меинтейнера.
3. Главный ограничивающий ресурс это понимание кодовой базы разработчиками.
4. Деградация кода неизбежна и поддержание его качества это необходимая работа.
5. Агенты для кода ненадежны и непостоянны. Результат зависит от множества постоянно меняющихся факторов: модели меняются, сетап у всех разный, и так далее. Если что-то работает сейчас, нельзя гарантировать, что оно будет так же работать завтра.
6. Агенты для кода быстро производят техдолг и не могут самостоятельно его уменьшать.
Отсюда следующие принципы того, как может работать адекватная система:
1. Необходимо перенести работу по поддержанию качества назад с мейнтейнера на автора.
2. Люди отвечают за дизайн и архитектуру.
3. Люди отвечают за систему верификации: pre-commit, CI чеки, документация и принципы. Только люди редактируют AGENTS.md и постоянные доки.
4. Все правила, которые можно, нужно превращать в механические чеки, потому что промптинг не гарантирует, что агенты будут их соблюдать.
5. Борьба со слопом закладывается в бюджет.
6. Минимизируем человеческие затраты на ревью, максимально автоматизируем проверки и контроль качества.
Первый пункт самый главный: можно вайбкодить как угодно, если в результате у тебя рабочий код который ты понимаешь.
И конкретные практики:
1. Каждый PR не более +2к строк кода. Эмпирически найдено, что больше отревьюить невозможно.
2. Автор каждого PR сам пишет его описание по шаблону и указывает какие сущности за что отвечают.
3. Очень жесткие pre-commit и CI чеки.
4. Кастомный код-ревью бот в CI, который отсматривает каждый дифф и весь PR в целом с целью доказать, что он сломан. Промптится логом прошлых инцидентов, который пополняется только людьми.
5. Люди дизайнят скелет своих изменений в AI-assisted режиме, агенты заполняют пропуски.
6. Доки пишутся людьми, агентам запрещено их редактировать.
7. Разгребание слопа закладывается в планирование.
Всю карьеру (в эру кожаного кодинга) я считал pre-commit чеки очень бесячими и не особо полезными. Теперь же у нас самые жесткие чеки и линтеры в моей жизни. Там как базовые вещи вроде ruff и black, так и кастомные правила import linter, и многое другое. Я постоянно завожу что-то новое. Например, недавно добавил проверки на вложенность и цикломатическую сложность функций из SlopCodeBench. На днях появилась проверка всех диффов с помощью Jev.
Это более-менее сработало. Pre-commit с механически забитыми правилами позволяет видеть не совсем слоп на этапе ревью. Очень жесткий CI обеспечивает то, что слоп обнаруживается до мержа, а не после. Но появились новые проблемы.
Самая главная: актор с критиком могут очень долго итерироваться над PR без видимого прогресса. Агент делает изменения, ревьюер находит блокирующие проблемы, агент делает заплатку, ревьюер находит следующую дыру и так далее. Я видел как это происходило буквально днями, до тех пор, пока я не погружусь и не разберусь: в чем же корень проблемы? Ни одна модель (вклюбчая Fable и Astra) пока ни разу не смогла сама выбраться из этой спирали.
Вытекающая проблема: медленно. Теперь беклог PR разгребается гораздо медленнее, чем пополняется. У агентов как будто появляется новый инструмент: защита (своего кода) заебыванием. Когда ревьюер в десятый раз находит ошибку в каком-то PR возникает очень сильное желание вмержить его, чтобы просто больше не видеть. Парадоксальным образом я чувствую будто никогда в жизни столько не читал код, как в 2026.
Что иронично: ускорение от вайбкода как будто целиком компенсируется или замедлением на этапе ревью, или, если вы на вайбах, разгребанием проблем в проде спустя пару недель.
Forwarded from NLP Wanderer
Halo: почти год моей работы в White Circle теперь в опенсорсе
Почти год я веду в White Circle разработку Halo - фреймворка для тренировки LLM, на котором мы учим все свои модели. Внутри он работал давно как замена Мегатрона, но до публичного релиза пришлось догнать transformers, TRL и vLLM, добавить модели и упростить адопшен - образы, CLI, документация. Подробный блогпост - на сайте White Circle (https://whitecircle.com/research/halo).
Если вы файнтюните открытые модели, то наверняка упирались в: модель уже не лезет в TRL и обычный FSDP, но связываться с Megatron и конвертацией чекпоинтов еще рано или просто не хочется. С MoE все еще хуже, без Expert Parallelism их по большому счету не потренировать. Halo добавляет EP, Context, Tensor и Expert-Tensor Parallelism прямо поверх обычных классов HuggingFace: на вход HF модель, на выходе HF модель. Новое MoE семейство подключается оберткой меньше 140 строк (у Megatron-Bridge на то же самое уходит 600-1900), сейчас их 15.
Немного цифр, все на B300, воспроизводимы из репо:
- 2.3-2.8x throughput относительно стокового TRL на gpt-oss-20b при тех же кернелах, loss совпадает в пределах ~1%.
- Gemma 4 26B-A4B на 2 GPU: 7.2k tok/s против 3.2-5.0k у NeMo AutoModel, Axolotl, Megatron Bridge, MS-SWIFT и Unsloth.
- Оптимизатор целиком в bf16 со стохастическим округлением: 120 GB состояния вместо 240 для 20B.
Все это првоерялось на реальных кластерах B300/B200/H200/H100 а топология заложена вплоть до NVL72: невалидные раскладки отбрасываются еще на этапе конфига. Запускается через
Отдельная моя гордость - Async RL. vLLM или SGLang живут в отдельном контейнере, роллауты идут асинхронно через Ray, веса уезжают по NCCL (по EFA 53-80 GB/s, gpt-oss-120b обновляется за 3-4 секунды), а генерации во время синка не обрываются. Внутри routing replay, importance sampling с масками, обучение на токенах, которые насэмплил движок, и 11 встроенных сред - от code contests и SWE до тулов через MCP. По механикам это сопоставимо с verl и Miles, только на HF-моделях и без Megatron.
Для студентов и тех, кто только начинает, Halo, мне кажется, хорошая точка входа. Все запускается из одного docker-образа:
Выложили и модель - GLM-4.7-Flash-Coder, 30B MoE под агентские скаффолды: SFT на 7.8k успешных траекторий GLM-5.1, на SWE-rebench-V2 pass@1 вырос с 33.2% до 41.7%, а модель сама научилась вызывать тулы параллельно. Она уже слегка устарела, но как гайд по агентскому SFT актуальна.
Код мы пишем с агентными скаффолдами и сильными моделями вроде Claude Fable и Opus, репозиторий под это спроектирован. Контрибьт приветствуется, но через фильтр: сначала issue и approve мейнтейнера, потом PR. Главное правило - понимать свой код: с AI писать можно, но это нужно раскрыть, а тесты должны падать, когда ломается поведение.
Дальше больше: Pipeline Parallelism (все уже в коде, но докатим после полных тестов) и серия блогов про тренировку, например про async RL для code contests. Лицензия Apache 2.0.
P.S. Если помните такую вещь как SMPO из времен Vikhr, то он теперь тоже живет там, но уже с EP и CP и улучшениями.
Почти год я веду в White Circle разработку Halo - фреймворка для тренировки LLM, на котором мы учим все свои модели. Внутри он работал давно как замена Мегатрона, но до публичного релиза пришлось догнать transformers, TRL и vLLM, добавить модели и упростить адопшен - образы, CLI, документация. Подробный блогпост - на сайте White Circle (https://whitecircle.com/research/halo).
Если вы файнтюните открытые модели, то наверняка упирались в: модель уже не лезет в TRL и обычный FSDP, но связываться с Megatron и конвертацией чекпоинтов еще рано или просто не хочется. С MoE все еще хуже, без Expert Parallelism их по большому счету не потренировать. Halo добавляет EP, Context, Tensor и Expert-Tensor Parallelism прямо поверх обычных классов HuggingFace: на вход HF модель, на выходе HF модель. Новое MoE семейство подключается оберткой меньше 140 строк (у Megatron-Bridge на то же самое уходит 600-1900), сейчас их 15.
Немного цифр, все на B300, воспроизводимы из репо:
- 2.3-2.8x throughput относительно стокового TRL на gpt-oss-20b при тех же кернелах, loss совпадает в пределах ~1%.
- Gemma 4 26B-A4B на 2 GPU: 7.2k tok/s против 3.2-5.0k у NeMo AutoModel, Axolotl, Megatron Bridge, MS-SWIFT и Unsloth.
- Оптимизатор целиком в bf16 со стохастическим округлением: 120 GB состояния вместо 240 для 20B.
Все это првоерялось на реальных кластерах B300/B200/H200/H100 а топология заложена вплоть до NVL72: невалидные раскладки отбрасываются еще на этапе конфига. Запускается через
torchrun, accelerate или halo CLI, в репо есть рецепты под SLURM, SkyPilot, RunPod и Nomad. Большая часть года ушла на то, чтобы все это не разваливалось на всех комбинациях моделей и параллелизмов - тестов в репозитории больше, чем кода. При этом работать будет также и на современных консьюмерских GPU.Отдельная моя гордость - Async RL. vLLM или SGLang живут в отдельном контейнере, роллауты идут асинхронно через Ray, веса уезжают по NCCL (по EFA 53-80 GB/s, gpt-oss-120b обновляется за 3-4 секунды), а генерации во время синка не обрываются. Внутри routing replay, importance sampling с масками, обучение на токенах, которые насэмплил движок, и 11 встроенных сред - от code contests и SWE до тулов через MCP. По механикам это сопоставимо с verl и Miles, только на HF-моделях и без Megatron.
Для студентов и тех, кто только начинает, Halo, мне кажется, хорошая точка входа. Все запускается из одного docker-образа:
halo launch sft config.yaml, а QLoRA Qwen3-4B занимает 7.9 GB и должна работать на 3090/4090. Документации больше 170 страниц, отдельно советую прочитать лекцию GPU Training Theory: база того как работают такие фреймворки, почему эксперты в MoE упираются в память, а не в compute, и почему в EP-шаге 88% времени - это all-to-all. Там же честно написано, что не помогает и что тихо ломает, например TF32 по умолчанию в NGC-образе, портящий RoPE после 2048 токенов.Выложили и модель - GLM-4.7-Flash-Coder, 30B MoE под агентские скаффолды: SFT на 7.8k успешных траекторий GLM-5.1, на SWE-rebench-V2 pass@1 вырос с 33.2% до 41.7%, а модель сама научилась вызывать тулы параллельно. Она уже слегка устарела, но как гайд по агентскому SFT актуальна.
Код мы пишем с агентными скаффолдами и сильными моделями вроде Claude Fable и Opus, репозиторий под это спроектирован. Контрибьт приветствуется, но через фильтр: сначала issue и approve мейнтейнера, потом PR. Главное правило - понимать свой код: с AI писать можно, но это нужно раскрыть, а тесты должны падать, когда ломается поведение.
Дальше больше: Pipeline Parallelism (все уже в коде, но докатим после полных тестов) и серия блогов про тренировку, например про async RL для code contests. Лицензия Apache 2.0.
P.S. Если помните такую вещь как SMPO из времен Vikhr, то он теперь тоже живет там, но уже с EP и CP и улучшениями.
Forwarded from Остриков пилит агентов
YouTube
3 AImigo S1E4: AI нанимает AI. Как пересобрать IT-собеседования?
AI соискателя встречается с AI нанимающего — мегазорд против супер-рейнджера. Запрет AI не делает интервью AI-free, резюме всё хуже подтверждает способность работать, а старые онлайн-этапы дают всё более шумный сигнал. Вопрос у компании прежний: сможет ли…
https://www.youtube.com/watch?v=ZpL3QsO5A9U
Спокойное, неторопливое и глубокое видео для тех, кто пересобирает у себя в компаниях найм, который раньше работал, но поломался с приходом AI.
Там нет TLDR или списка того, как вам переписать свои секции, ребята просто делятся мыслями, освещают проблемы с разных сторон и думают над решениями.
Понравилась идея про то, что цель интервью как и раньше - собрать максимальное количество флагов для принятия решения, а AI позволяет тебе собрать их больше и быстрее.
Что писать код на бумажке теперь вряд ли стоит, но увидеть как мыслит человек обязательно нужно, чтобы понять кто паре ведущий: кандидат или клод и не нанять meat proxy.
Понравилась идея вместо 3-4 разных этапов сделать одно 2х-часовое интервью где вы на звонке и проходите несколько фаз вместе с AI - проблема, исследование, архитектура, кодинг, деплой, анализ.
Интересную тему затронули про схлопывание ролей, например инженера с менеджером, насколько сильным будет их пересечение и различие, приведет ли это с появлению одной универсальный роли - member of staff, по нашему мастер на все руки.
Такое годно смотреть, если вы уже сделали несколько попыток перестроить найм, новые идеи хорошо лягут на ваши прошлые.
Спокойное, неторопливое и глубокое видео для тех, кто пересобирает у себя в компаниях найм, который раньше работал, но поломался с приходом AI.
Там нет TLDR или списка того, как вам переписать свои секции, ребята просто делятся мыслями, освещают проблемы с разных сторон и думают над решениями.
Понравилась идея про то, что цель интервью как и раньше - собрать максимальное количество флагов для принятия решения, а AI позволяет тебе собрать их больше и быстрее.
Что писать код на бумажке теперь вряд ли стоит, но увидеть как мыслит человек обязательно нужно, чтобы понять кто паре ведущий: кандидат или клод и не нанять meat proxy.
Понравилась идея вместо 3-4 разных этапов сделать одно 2х-часовое интервью где вы на звонке и проходите несколько фаз вместе с AI - проблема, исследование, архитектура, кодинг, деплой, анализ.
Интересную тему затронули про схлопывание ролей, например инженера с менеджером, насколько сильным будет их пересечение и различие, приведет ли это с появлению одной универсальный роли - member of staff, по нашему мастер на все руки.
Такое годно смотреть, если вы уже сделали несколько попыток перестроить найм, новые идеи хорошо лягут на ваши прошлые.