Пару недель назад я писал пост о том, что это вообще такое.
Если коротко, то за названием крылось сразу несколько вещей:
1) бенчмарк, по задумке и идее, такой же как SWE Bench: агенту дают задачу и среду для работы, а потом прогоняют решения через юнит-тесты
2) среда для запуска агентов и тестирования - фреймворк брал на себя самую сложную и неприятную часть вокруг инфраструктуры и логов
3) агент, адаптированный под работу в терминале
Проект обрел большую популярность у разработчиков кодинг агентов и собрал обширное комьюнити, которое хотело еще больше фичей.
Авторы подумали-подумали и выкатили апгрейд, где теперь все три сущности разделены и имеют свое имя.
Во-первых, terminal-bench – это теперь только название бенчмарка. Он и именуется terminal-bench 2.0
Усложнили задачи, уделили больше внимания валидации качества.
Лидерборд тут https://www.tbench.ai/leaderboard и лидирует пока Warp с accuracy 50%
Самое большое же нововведение – это выпуск фреймворка Harbor. Теперь Harbor представляет из себя пункт 2) описанный выше. То есть это все то же самое, что уже было в оригинальной версии + три больших фичи.
- теперь можно гонять агентов не только в локальных контейнерах, но и в облаке, через интеграции с Daytona или Modal. Так можно кратно добиться масштабирования ваших eval-ов
- добавили возможность делать RL! И это самое горячее нововведение. Но правда пока что очень сыро и с трудом работает. По задумке можно тюнить своего агента на траекториях (или как их называют rollouts). для этого нужно собирать реворды и токены. Реализовать эту часть на вас, а делать обучение агента и запускать агентов для сбора этих самых траекторий на плечах фреймворка. Детали тут
- добавили утилиту для экспорта логов действий агента в формате ShareGPT для дальнейшего SFT тюнинга. Детали тут
Причина почему Harbor вынесен в новый проект (а не существующий) только в попытке развивать бренд и уйти от путаницы в названиях.
Так, terminal bench будет ассоциироваться у всех только с бенчмарком, а Harbor с средой для прогонов агента.
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡10👍9🔥6🆒1
Media is too big
VIEW IN TELEGRAM
Gemini 3 Pro доступна в Gemini CLI.
С сегодняшним релизом Gemini 3, тут же релизнули и интеграцию в гугловсокго кодинг агента.
Модель доступна подписчикам Google AI Ultra или тем, кто пользуется через платный API: Gemini API/ Vertex API . Все остальные, включая бесплатных юзеров, могут пока встать в waitlist
В посте с анонсом обращают внимание на такие фичи:
– улучшенные способности в генерации красивых UI-интерфейсов. Старая модель безумно страдала в этом аспекте.
- генерация 3D сцен.Прикрепленное видео из поста с анонсом, довольно впечатляюще
– генерация сложных терминальных команд
– генерация аккуратной документации (Гугл на днях тут еще запустил и Code Wiki, сервис для автоматической документации проектов)
– улучшенный ризонинг, требующий работы одновременно с несколькими файлами (старая модель тоже страдала с этим), помощь в дебаге и способность мониторить логи запущенных сервисов, чтобы диагностировать проблемы
Стал ли агент действительно интереснее и полезнее и насколько крутая модель скоро увидим. По тем скудным кодинг бенчмаркам что представлены (terminal bench, SWE Bench, livecodebench) модель не на голову выше других гигантов.
С сегодняшним релизом Gemini 3, тут же релизнули и интеграцию в гугловсокго кодинг агента.
Модель доступна подписчикам Google AI Ultra или тем, кто пользуется через платный API: Gemini API/ Vertex API . Все остальные, включая бесплатных юзеров, могут пока встать в waitlist
В посте с анонсом обращают внимание на такие фичи:
– улучшенные способности в генерации красивых UI-интерфейсов. Старая модель безумно страдала в этом аспекте.
- генерация 3D сцен.Прикрепленное видео из поста с анонсом, довольно впечатляюще
– генерация сложных терминальных команд
– генерация аккуратной документации (Гугл на днях тут еще запустил и Code Wiki, сервис для автоматической документации проектов)
– улучшенный ризонинг, требующий работы одновременно с несколькими файлами (старая модель тоже страдала с этим), помощь в дебаге и способность мониторить логи запущенных сервисов, чтобы диагностировать проблемы
Стал ли агент действительно интереснее и полезнее и насколько крутая модель скоро увидим. По тем скудным кодинг бенчмаркам что представлены (terminal bench, SWE Bench, livecodebench) модель не на голову выше других гигантов.
🔥12⚡6👍4👎1👏1👌1🆒1
Мб пригодится начинающим стартаперам:
http://yandex.ru/aistartup
Критерии участия:
В ногу с трендами ждут проекты про AI
http://yandex.ru/aistartup
Критерии участия:
Вы совершеннолетний студент, аспирант, исследователь или предприниматель
Команда от двух человек, и участники готовы уделять проекту 10–15 часов в неделю
Хотите валидировать свои гипотезы и открыты к обратной связи
У вас технологический проект с подтверждёнными гипотезами или прототипом, TRL 3+
В ногу с трендами ждут проекты про AI
Yandex AI Startup Lab — пространство, где идеи превращаются в реальные продукты
Приходите с технологическими идеями, дорабатывайте их с поддержкой Яндекса и попробуйте получить 3 000 000 рублей на дальнейшее развитие
❤13🔥6👍4⚡1
Applied Scientist L5 в🛒 Amazon. Отзыв на Интервью.
Пополняем копилку свежей историей. Буду рад видеть новые от читателей, гугл форма тут.
Другие по тегу #интервью
➡ Ник автора в тг - N/A
➡ Название компании, можете указать ссылку или коротко описать что за место - Amazon
➡ Расскажите про свой бэкграунд - в этом году закончила ICL, PhD степень, машинный перевод, ищу работу. До этого только летние стажировки и подработки между учебой. IBM, Intel, McKinsey.
➡ Как подались на вакансию - сама через вакансию в Linkedin
➡ Субъективно Сложность процесса по 10 бальной шкале - 7
➡ Когда начали процесс - сентябрь 25
➡ Когда закончили процесс - октябрь 25
➡ Позиция, на которую собеседовались - Applied Scientist, AGI команда
➡ Грейд (если известно) - L5
➡ Локация вакансии - Лондон / Кэмбридж
🔥 Расскажите про этапы собеседований
Virtual Screening
Раунд 1. Сначала дали leetcode style задачу на поиск элементов в матрице. Дословно как здесь: https://leetcode.com/problems/search-a-2d-matrix/denoscription/. Линейное решение пришло быстро, а с бинарным поиском всё получилось не идеально в плане реализации. Интервьюер, кажется, был больше заинтересован в том, что я правильно проговариваю логику, чем в самом коде и краевых случаях. Ушло минут 35-40. Далее обсуждали LP-вопрос про мой опыт работы в исследовательской команде. У меня был сильный кейс, потому что я немного поработала и в индустрии, и в академии, и использовала этот опыт как пример на интервью. Похоже, это впечатлило.
Раунд 2. На этом раунде всё было наоборот: сначала минут 25-30 обсуждали LP-принципы, затем были разнообразные вопросы по классическим понятиям машинного обучения: gradient descent и его виды, свёртки, случайные величины, закон больших чисел. Не везде у меня были хорошие ответы, интервьюер просто шёл дальше, выглядело больше как викторина. Видимо, набрала достаточно галочек, чтобы позвали на он-сайт.
Virtual On-site
Раунд 1. Behavioral Interview с нанимающим менеджером.
Раунд 2. Bar Raiser Interview. Раунд похож на скриниг. В этот раз фокус на оценку качества моделей, A/B тесты. Как бы я проектировала вывод в продакшн новой болталки, какие оффлайн и онлайн метрики использовала. Было очень круто поговорить с Principal Scientist-ом.
Раунд 3. Лит код. Первая задача на дизайн структуры, написать функции для обхода графа. Потом применить их для конкретной задачи. Дали модификацию вот такой задачи: https://leetcode.com/problems/number-of-islands/denoscription/.
Раунд 4. ML Дизайн. Самая сложная для меня секция, потому что такого опыта у меня никогда не было. Интервьюеры дали задачу приближенную к их работе: дизайн Text-To-Speech системы для озвучивания аудио книг. А именно построить решение для multi voice narration. Покрыли такие пункты: какие данные собирать, как делать разметку, как оценивать систему, которая генерирует сразу несколько голосов, какие есть модели. Я никогда не работала над TTS, поэтому было сложно в целом рассуждать про архитектурные подходы, а уж тем более как в одной модели смешать многоголосый синтез. Интервьюеры были очень поддерживающими, и помогали вести диалог в тех частях, где я буксовала. В итоге раунд, который мне казался самым страшным превратился в комфортную беседу. Блеснуть, конечно не вышло, из-за специфики задачи, но в одной части разговора речь зашла про языки за пределами английского и удалось применить опыт с машинным переводом, что кажется очень зашло.
➡ Итоги собеседования, например оффер или отказ, или что-то другое: В течение недели после собеседования поставили звонок с рекрутером. Сказали, что до уровня L5 не дотягиваю и дали конструктивный фидбэк, что улучшить. При этом не хотят делать reject, и готовы нанять на грейд L4 (это скорее джун), либо взять на стажировку на 4-6 месяцев по итогам которой могут дать полноценный оффер на L5. Проблема только в том, что вакансий сейчас нет 🤷♀️, но могут появиться в Q1 2026. Посмотрим, возможно к тому моменту будет уже не актуально.
➡ Информация про Total Compensation: N/A
@max_dot_sh
Пополняем копилку свежей историей. Буду рад видеть новые от читателей, гугл форма тут.
Другие по тегу #интервью
Virtual Screening
Раунд 1. Сначала дали leetcode style задачу на поиск элементов в матрице. Дословно как здесь: https://leetcode.com/problems/search-a-2d-matrix/denoscription/. Линейное решение пришло быстро, а с бинарным поиском всё получилось не идеально в плане реализации. Интервьюер, кажется, был больше заинтересован в том, что я правильно проговариваю логику, чем в самом коде и краевых случаях. Ушло минут 35-40. Далее обсуждали LP-вопрос про мой опыт работы в исследовательской команде. У меня был сильный кейс, потому что я немного поработала и в индустрии, и в академии, и использовала этот опыт как пример на интервью. Похоже, это впечатлило.
Раунд 2. На этом раунде всё было наоборот: сначала минут 25-30 обсуждали LP-принципы, затем были разнообразные вопросы по классическим понятиям машинного обучения: gradient descent и его виды, свёртки, случайные величины, закон больших чисел. Не везде у меня были хорошие ответы, интервьюер просто шёл дальше, выглядело больше как викторина. Видимо, набрала достаточно галочек, чтобы позвали на он-сайт.
Virtual On-site
Раунд 1. Behavioral Interview с нанимающим менеджером.
Раунд 2. Bar Raiser Interview. Раунд похож на скриниг. В этот раз фокус на оценку качества моделей, A/B тесты. Как бы я проектировала вывод в продакшн новой болталки, какие оффлайн и онлайн метрики использовала. Было очень круто поговорить с Principal Scientist-ом.
Раунд 3. Лит код. Первая задача на дизайн структуры, написать функции для обхода графа. Потом применить их для конкретной задачи. Дали модификацию вот такой задачи: https://leetcode.com/problems/number-of-islands/denoscription/.
Раунд 4. ML Дизайн. Самая сложная для меня секция, потому что такого опыта у меня никогда не было. Интервьюеры дали задачу приближенную к их работе: дизайн Text-To-Speech системы для озвучивания аудио книг. А именно построить решение для multi voice narration. Покрыли такие пункты: какие данные собирать, как делать разметку, как оценивать систему, которая генерирует сразу несколько голосов, какие есть модели. Я никогда не работала над TTS, поэтому было сложно в целом рассуждать про архитектурные подходы, а уж тем более как в одной модели смешать многоголосый синтез. Интервьюеры были очень поддерживающими, и помогали вести диалог в тех частях, где я буксовала. В итоге раунд, который мне казался самым страшным превратился в комфортную беседу. Блеснуть, конечно не вышло, из-за специфики задачи, но в одной части разговора речь зашла про языки за пределами английского и удалось применить опыт с машинным переводом, что кажется очень зашло.
@max_dot_sh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤38🔥13🙏8👏3⚡1🆒1
Выпустили первый инженерный лонг рид, активно участвовал в создании и всех экспериментах.
Почитать полный текст можно тут.
✍️ Пообсуждать, покритиковать или предложить идей в комментариях или в лс – буду очень рад)
На самом деле релизнули его еще несколько недель назад, но только сейчас доехали красивые картинки.
Основная мысль такая. С рассветом агентов и улучшением LLM-ов для кодинга, проблема галлюцинаций или того, что LLM-ка чего то не знает становится менее центральной. Все потому что у агента есть много инструментов найти недостающее знание: 1) посмотреть в исходный код (если работаете с какой-то библиотекой, то агент может просто найти, где она установлена и прочитать код оттуда) 2) поискать в браузере 3) интерактивно повзаимодействовать с библиотекой и в fix-loop парадигме научиться пользоваться библиотекой.
Реальной практической проблемой становится вопрос того, насколько агент эффективно пользуется этой самой библиотекой. Пользуется ли агент ей так, как задумывали авторы? Или вместо использования готового API начинает городить сложные конструкции. Которые формально могут решать задачу. Функционально все будет ок. Функциональная корректность кода – это безумно важно и актуально, никто не отменяет eval-ы про юнит-тесты. Но в реальных приложениях, в продуктовом коде, который пишут разрабы в огромных развитых экосистемах, помимо функциональной корректности нужна еще какая-то валидация на его качество.
Игрушечный пример (модели уровня Opus 4.5 или Sonnet 4.5 справляются, а маленькие могут облажаться). Допустим, вы просите агента реализовать self-attention механимз в PyTorch. Он идёт и вручную пишет функцию со всеми умножениями q, k, v матриц, в духе собеседований. А вот «умный» агент знает, что начиная с версии 2.x в торче существует
Такой пример подсвечивает проблемы с идиоматичным использованием фреймворков. Вот в блоге и оценивали масштаб такого эффекта.
* Собрали 270 разных опенсоурсных реп разных лет, от очень старых до новых.
* Нагенерировали на основе исходного кода репозиториев разных coding exercises – задач, в которых агенту нужно было реализовать некоторую логику используя конкретную библиотеку
* Дали разным агентам (cursor, claude code) решать эти задачи
* Оценивали решения с помощью рубрик отдельным агентом-валидатором. Штрафовали за ситуации, когда решение не использовало какой-то метод или паттерн, который ожидался
Посмотрели на результаты в разных разрезах.
Один результат, что лучше модель – лучше качество. Картинка 1 про перформанс разных моделей Антропика.
Другой интересный разрез – это перформанс в зависимости от даты релиза библиотеки. Агенты довольно плохо перформят на старых репах и на супер новых, Картинка 2. По популярности репозитория точно такой же тренд – чем больше форков, тем выше скор. Оно и понятно: такие репы являются основой для трейн данных любой LLM-ки.
Отдельно в блоге еще затронули пункт про то, а как это можно улучшить. Мы предлагаем способ в виде Спек – таких сжатых документов, оптимизированных под то, что они пойдут в контекстное окно модели, чтобы на ходу обучить ее работе с репой. Спеки содержат примеры как работать с API репы, какие best practices и основные детали. Короче по задумке как context7, но построено на других принципах.
Все coding challenges и рубрики для оценки выложили, в блоке есть ссылка.
Почитать полный текст можно тут.
На самом деле релизнули его еще несколько недель назад, но только сейчас доехали красивые картинки.
Основная мысль такая. С рассветом агентов и улучшением LLM-ов для кодинга, проблема галлюцинаций или того, что LLM-ка чего то не знает становится менее центральной. Все потому что у агента есть много инструментов найти недостающее знание: 1) посмотреть в исходный код (если работаете с какой-то библиотекой, то агент может просто найти, где она установлена и прочитать код оттуда) 2) поискать в браузере 3) интерактивно повзаимодействовать с библиотекой и в fix-loop парадигме научиться пользоваться библиотекой.
Реальной практической проблемой становится вопрос того, насколько агент эффективно пользуется этой самой библиотекой. Пользуется ли агент ей так, как задумывали авторы? Или вместо использования готового API начинает городить сложные конструкции. Которые формально могут решать задачу. Функционально все будет ок. Функциональная корректность кода – это безумно важно и актуально, никто не отменяет eval-ы про юнит-тесты. Но в реальных приложениях, в продуктовом коде, который пишут разрабы в огромных развитых экосистемах, помимо функциональной корректности нужна еще какая-то валидация на его качество.
Игрушечный пример (модели уровня Opus 4.5 или Sonnet 4.5 справляются, а маленькие могут облажаться). Допустим, вы просите агента реализовать self-attention механимз в PyTorch. Он идёт и вручную пишет функцию со всеми умножениями q, k, v матриц, в духе собеседований. А вот «умный» агент знает, что начиная с версии 2.x в торче существует
F.scaled_dot_product_attention, который делает всё в одну строку.Такой пример подсвечивает проблемы с идиоматичным использованием фреймворков. Вот в блоге и оценивали масштаб такого эффекта.
* Собрали 270 разных опенсоурсных реп разных лет, от очень старых до новых.
* Нагенерировали на основе исходного кода репозиториев разных coding exercises – задач, в которых агенту нужно было реализовать некоторую логику используя конкретную библиотеку
* Дали разным агентам (cursor, claude code) решать эти задачи
* Оценивали решения с помощью рубрик отдельным агентом-валидатором. Штрафовали за ситуации, когда решение не использовало какой-то метод или паттерн, который ожидался
Посмотрели на результаты в разных разрезах.
Один результат, что лучше модель – лучше качество. Картинка 1 про перформанс разных моделей Антропика.
Другой интересный разрез – это перформанс в зависимости от даты релиза библиотеки. Агенты довольно плохо перформят на старых репах и на супер новых, Картинка 2. По популярности репозитория точно такой же тренд – чем больше форков, тем выше скор. Оно и понятно: такие репы являются основой для трейн данных любой LLM-ки.
Отдельно в блоге еще затронули пункт про то, а как это можно улучшить. Мы предлагаем способ в виде Спек – таких сжатых документов, оптимизированных под то, что они пойдут в контекстное окно модели, чтобы на ходу обучить ее работе с репой. Спеки содержат примеры как работать с API репы, какие best practices и основные детали. Короче по задумке как context7, но построено на других принципах.
Все coding challenges и рубрики для оценки выложили, в блоке есть ссылка.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5❤17🔥13👍6🤓2
Solutions Architect в ByteDance, Дубай. Отзыв на Интервью.
Новая история про собеседования, самое то для пятницы.
Буду рад видеть свежие от читателей, гугл форма тут.
Все отзывы по тегу #интервью
спойлер: тотал комп в оффере отличный, дочитайте до конца
➡ Ник автора в тг - N/A
➡ Название компании, можете указать ссылку или коротко описать что за место - ByteDance
➡ Расскажите про свой бэкграунд - 7YOE, Engineering & Solution Architecture (стартапы), никаких FAANG'ов в резюме. Своя компания Engineering & Technical Consulting & Solution Architecture (6 years), AI Content generation & workflows (1 year) + продажа различного софта онлайн.
➡ Как подались на вакансию - Рекрутер на LinkedIn сам написал (его потом уволили, хех)
➡ Субъективно Сложность процесса по 10 бальной шкале - 7
➡ Когда начали процесс - Август 2025
➡ Когда закончили процесс - Ноябрь 2025
➡ Позиция, на которую собеседовались - Solutions Architect, Enterprise AI, MaaS (models as a service)
➡ Грейд (если известно) - N/A, 2-2 или 3-1 скорее всего (от автора канала: в комментариях описали разбивку грейдов)
➡ Локация вакансии - Дубай
🔥 Расскажите про этапы собеседований
0 - HR Screening,
1 - Solution Architecture Technical Chat (AI Content generation),
2 - Solution Architecture Technical Interview (Experience assessment and use cases),
3 - Panel interview with Sales and General Manger (Experience assessment and use cases),
4 - Technical Presentation for Sales team and Hiring manager,
5 - Offer and follow-up conversations on expectations (my initiative).
⏺ Что понравилось:
Понравилось, что не было тупых вопросов (типа как Amazon leadership задротство, бррр). Все интервьюверы задавали хорошие глубокие вопросы про GTM. Ожидания проговаривались.
ByteDance - масштабная контора - у них свой большой cloud и свои топ модели (видео, аудио и т.п.) - много клиентов, нужно строить AI солюшны, Models as a service продвигать. В 2026 собираются порвать многих акул рынка.
⏺ Что не понравилось:
Был Лондон, а стал Дубай, но решил процесс довести до конца. После раундов часто долго не было фидбека. Оффер высылали неделю.
➡ Итоги собеседования, например оффер или отказ, или что-то другое: Получил оффер. В итоге отказался. Увы, тайминг не подходящий. Нужно быть в ЮК
➡ Информация про Total Compensation: OTE: 260k GBP / year, 180k - base (tax free cash, т.к. Дубай), 5-6 зарплат - бонус (каждый квартал), 10k GBP - стоки (да, смешно). В Дубайских тугриках OTE: ~1.2-1.3M AED (20k GBP в месяц кэшом на руки). Офис 4/1.
@max_dot_sh
Новая история про собеседования, самое то для пятницы.
Буду рад видеть свежие от читателей, гугл форма тут.
Все отзывы по тегу #интервью
спойлер: тотал комп в оффере отличный, дочитайте до конца
0 - HR Screening,
1 - Solution Architecture Technical Chat (AI Content generation),
2 - Solution Architecture Technical Interview (Experience assessment and use cases),
3 - Panel interview with Sales and General Manger (Experience assessment and use cases),
4 - Technical Presentation for Sales team and Hiring manager,
5 - Offer and follow-up conversations on expectations (my initiative).
Понравилось, что не было тупых вопросов (типа как Amazon leadership задротство, бррр). Все интервьюверы задавали хорошие глубокие вопросы про GTM. Ожидания проговаривались.
ByteDance - масштабная контора - у них свой большой cloud и свои топ модели (видео, аудио и т.п.) - много клиентов, нужно строить AI солюшны, Models as a service продвигать. В 2026 собираются порвать многих акул рынка.
Был Лондон, а стал Дубай, но решил процесс довести до конца. После раундов часто долго не было фидбека. Оффер высылали неделю.
@max_dot_sh
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥22🤯11❤4👍3
Послушал очень плотное по контенту и интересное для размышлений выступление с недавнего AI Engineer митапа от Dexter Horthy (фаундер YC стартапа, много выступает с докладами про Context Engineering для кодинг агентов)
Смотреть тут
⚫️ Одна мысль про так называемую "dumb zone". Контекстное окно агента (Claude Code, Codex, ...) стоит держать заполненным только до определенного размера. В докладе автор эмперически говорит о 40%. Как только контекстное окно переваливает через этот рубеж, агент быстро начинает тупеть.
Учитывая MCP инструменты, кастомные правила, всякие манифесты типа CLAUDE.md и входы/выходы размышлений агентов, окно заполняется очень быстро.
Один способ побороть это, делегировать выполнение кусков задачи другим агентам (так называемые sub agents). Они будут выполнять задачу от главного агента, в своей копии контекстного окна, никак не засоряя основное, по итогу работы вернув в главное контекстное окно сжатое эффективное представление.
Другой подход – это agent skills, который активно продвигают Антропики.
⚫️ Автор продвигает подход RPI (Research Planing Implementation) суть которого в том, что агент должен решать задачу (особенно если она сложная и подразумевает работу в уже существующей кодовой базе) в несколько этапов. Каждый этап может выполняться отдельным агентом или серией агентов. Исходя из названия подхода, в целом понятно, что должен делать каждый агент: делать поиск по кодовой базе в поисках актуального контекста, суммаризировать все это в план действий, а затем уже переходить к написанию кода через план.
Предлагается еще ввести Huaman Review на каждой из стадий. Потому что процесс принятия решений пока еще нельзя полностью аутсорсить агентам. Ревью так или иначе нужно. Автор подкрепляет свою ветку красивыми диаграммами вида: Одна плохая строчка в CLAUDE.md -> десятки тысяч плохого кода; Плохой рисерч агента –> потенциально сотни строк плохого кода; Плохой план исполнения -> потенциально десятки строк плохого кода.
⚫️ Ну и напоследок, из-за того, что сломать агента на масштабе больших рефакторингов и кодовых изменений крайне просто, у инженеров разной сеньорности со временем формируется полярное отношение к AI агентам. Пока VP of Eng ломают голову, как его внедрять на уровне организаций и плавно переходят к ненависти AI технологий (неоднократно слышал такой фидбэк лично от разных матерых разрабов), более джуновые инженеры, оперирующие на уровне фичей, обожают все новые технологии, потому что это бустит продуктивность.
Смотреть тут
Учитывая MCP инструменты, кастомные правила, всякие манифесты типа CLAUDE.md и входы/выходы размышлений агентов, окно заполняется очень быстро.
Один способ побороть это, делегировать выполнение кусков задачи другим агентам (так называемые sub agents). Они будут выполнять задачу от главного агента, в своей копии контекстного окна, никак не засоряя основное, по итогу работы вернув в главное контекстное окно сжатое эффективное представление.
Другой подход – это agent skills, который активно продвигают Антропики.
Предлагается еще ввести Huaman Review на каждой из стадий. Потому что процесс принятия решений пока еще нельзя полностью аутсорсить агентам. Ревью так или иначе нужно. Автор подкрепляет свою ветку красивыми диаграммами вида: Одна плохая строчка в CLAUDE.md -> десятки тысяч плохого кода; Плохой рисерч агента –> потенциально сотни строк плохого кода; Плохой план исполнения -> потенциально десятки строк плохого кода.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍12❤7
В посте выше я ссылался на доклад с AIE митапа. Так вот, у них есть болшой YT канал с очень годным контентом от передовых лаб и AI стартапов.
Канал тут.
Выступления все в среднем по 20 минут и крайне прикладные. Тут вы никогда не увидите формул, глубоких деталей методов или какие-то строгие специфичные eval-ы. Но можно зацепить много идей, посмотреть что делают в индустрии, набраться ключевых слов и ссылок и потом пойти копать дальше.
Большой дисклеймер: Да, крутого контента много, но еще больше бесполезного маркетингового мусора, которое слово в слово дублирует какой-нибудь релиз. Благо, видео короткие, можно быстро отсеять.
Мне, например, очень понравились доклады про разный RL, многие совсем свежие:
1. OpenAI про Agent RL, во второй части доклада рассказывают про пилоты с реальными кастомерами
2. Про эффективный RL, где боттленеки обучения, где простаивают GPU
3. про обучение своих агентов с помощью RL, вот тут вообще кайфовый case study от сбора данных до reward-hacking-ов
Happy Learning!
—
кстати, митапы проходят не только в SF, но и в других локациях. В этом году состоялся первый в Париже и несколько прошло в Лондоне. Здесь все скромнее по масштабу, но все равно очень интересно. Запланировал выступить в следующем году на таком.
#образование
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Agent Reinforcement Fine Tuning – Will Hang & Cathy Zhou, OpenAI
Deep dive into OpenAI's approach to reinforcement fine-tuning for code models.
https://x.com/willhang_
https://x.com/cathyzhou
AIE is coming to London and SF! see dates and sign up to be notified of sponsorships, CFPs, and ticketsa: https://ai.engineer
https://x.com/willhang_
https://x.com/cathyzhou
AIE is coming to London and SF! see dates and sign up to be notified of sponsorships, CFPs, and ticketsa: https://ai.engineer
4🔥12👍7❤5⚡2😍1
Сегодня в историях про собесы уникальное пополнение. Рассказа про OpenAI.
Буду рад видеть свежие от читателей, гугл форма тут.
Все отзывы по тегу #интервью
Дизайнить и деливерить LLM-based солюшны в EMEA, общаться со стейкхолдерами на стороне кастомера, с сейлзами, продукт-тимой и рисёрчерами.
До 3 дней в неделю могли быть из офиса клиента (по словам рекрутера), скорее 1-2 дня по словам Hiring Manager (и что компенсация тревела щедрая)
1) Созвон с рекрутером
2) Screening с менеджером (30 мин) - опыт, технологии, ожидания от позиции
3) Техническое задание на кодинг (домашнее на 5 business days) - выслали сразу после менеджера, а у меня отпуск на 2 недели был на следующий день, предложила заменить задачу по возвращении - сказали норм, когда вернусь.
Сделать рабочий солюшн, диаграмму, документацию, next steps.
Тут я начала на 2 недели позже, дня 3 бизнесовых потратила, кодила 1.5 вечера, потом они неделю проверяли.
4) 4 интервью пачкой (в 1 день должны были, но одно перенеслось):
- Partnering with Sales (30 мин) - рассказать про разные конфликтные ситуации, когда продали что-то, а тебе делать, другие behavioural аспекты
- Deep Dive with Manager (30 мин) - опыт, cultural fit, про миссию, про мои цели
- Case (Being a Solutions Architect) (45 мин) - прошли по задаче от нечёткого определения задачи (LLM-based солюшн) через мои вопросы и их уточнения до имплементации, evaluation, это было парное интервью - второй интервьюер учился-шедоуил.
- Coffee Chat with peer (тут мне обещали, что я буду задавать вопросы, но чувак - очень классный! - кажется, что-то перепутал и распрашивал меня всякое техническое, на мои осталось 5 минут).
Отказ и фидбек дали через ещё неделю.
Все, с кем разговаривала - приятные, профессиональные интервьюеры, быстрые ответы на вопросы от них и координатора, минимальный стресс, фидбек-сессия с HR
Несоответсвие Coffee Chat объявленному наполнению, я думала я перепутала (и на стрессе где-то тупила явно), но потом извинились, сказали, интервьюер увлёкся вот и.
Довольно много времени заняло (у меня очень мало опыта в интервью, впрочем - третье в жизни, может, это норма)
Кредиты на тех. задание начислить не смогли ("что-то сломалось"), просили купить самой и зареимбёрсить - напомнила об этом после отказа, тут же выслали ссылку, ещё через 5 дней заревьюили и выслали.
Отказ. Без детального фидбека, но с созвоном с HR. Посчитали, что ответы по case study для общения с бизнес-кастомерами должны быть почётче, а технический опыт отличный.
Думаю, что я не выказывала сильного энтузиазма работать с кучей заказчиков, да и напрямую спрашивала про транзишны внутри компании и возможность исходно работать над более сложными задачами, чтобы туда двигаться.
Обещали стукнуться, если будут такие позиции и просили меня им тоже писать, если увижу что-то (подписаться на алёрты нет опции).
@max_dot_sh
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍13❤5⚡2👻1