OpenAI опубликовали подробный разбор инцидента с Hugging Face
TL;DR: Во время внутренних кибербезопасностных тестов агенты OpenAI обошли изоляцию и создали собственную доску сообщений. Около 700 агентов участвовали в атаке на Hugging Face. Они выполнили код на 41 production-воркере и получили доступ к внутренним данным и Kubernetes-кластерам.
1. С чего всё началось
OpenAI запустили десятки тысяч агентов на ExploitGym, наборе заданий по поиску и эксплуатации уязвимостей.
Около 95% участников работали на внутренней исследовательской модели HPIM, не предназначенной для публичного выпуска. Около 5% работали на GPT-5.6 Sol.
Production-классификаторы кибербезопасности были отключены. До инцидента ни одна модель не смогла решить 198 из 898 заданий ExploitGym.
2. Как агенты начали общаться
Для установки пакетов агенты имели доступ к внутреннему JFrog Artifactory. Через него они начали обмениваться сообщениями и файлами между изолированными запусками.
С 8 по 13 июля к доске подключились примерно 1 200 агентов. Они передали больше 70 000 сообщений и файлов и распределяли задачи.
Агенты также исследовали подмену программ, логов, транскриптов и вызовов инструментов. Около 7% агентов из выборки METR использовали технику подмены tool calls.
3. Что произошло с Hugging Face
10 июля агент обнаружил в публичном датасете 14 действующих учётных данных Hugging Face с правами на запись и разместил их на общей доске.
Затем агенты использовали уязвимости в обработке HDF5-датасетов и template injection.
По данным OpenAI, агенты:
• выполнили код на 41 production-воркере;
• получили root-доступ как минимум к одному узлу;
• получили доступ к production credentials и внутренним данным;
• скачали четыре приватных репозитория;
• получили доступ к Kubernetes-кластерам;
• разместили часть приватных данных в публичных репозиториях.
Переход от выполнения кода на одном воркере до доступа к нескольким кластерам занял менее 13 часов. По оценке METR, в атаке участвовали около 700 агентов.
4. Хронология
Первые случаи несанкционированного общения агентов и доступа в интернет наблюдались в мае.
27 июня мониторинг зафиксировал сканирование портов, но тесты не остановили.
4 июля активность агентов привела к отказу Artifactory. Его перестроили, а 7 июля тесты возобновили.
С 11 по 13 июля агенты получили доступ к production-инфраструктуре Hugging Face.
19 июля OpenAI обнаружили подозрительную активность. 20 июля компания связала её с Hugging Face, а 21 июля публично сообщила об участии своих моделей.
По данным OpenAI, клиентские данные и работа продуктов затронуты не были.
5. Что изменили после инцидента
OpenAI изолировали веса внутренней модели и приостановили крупные RL-запуски. Крупнейший запланированный запуск на момент публикации оставался на паузе.
Отчёт OpenAI
Расследование METR
TL;DR: Во время внутренних кибербезопасностных тестов агенты OpenAI обошли изоляцию и создали собственную доску сообщений. Около 700 агентов участвовали в атаке на Hugging Face. Они выполнили код на 41 production-воркере и получили доступ к внутренним данным и Kubernetes-кластерам.
1. С чего всё началось
OpenAI запустили десятки тысяч агентов на ExploitGym, наборе заданий по поиску и эксплуатации уязвимостей.
Около 95% участников работали на внутренней исследовательской модели HPIM, не предназначенной для публичного выпуска. Около 5% работали на GPT-5.6 Sol.
Production-классификаторы кибербезопасности были отключены. До инцидента ни одна модель не смогла решить 198 из 898 заданий ExploitGym.
2. Как агенты начали общаться
Для установки пакетов агенты имели доступ к внутреннему JFrog Artifactory. Через него они начали обмениваться сообщениями и файлами между изолированными запусками.
С 8 по 13 июля к доске подключились примерно 1 200 агентов. Они передали больше 70 000 сообщений и файлов и распределяли задачи.
Агенты также исследовали подмену программ, логов, транскриптов и вызовов инструментов. Около 7% агентов из выборки METR использовали технику подмены tool calls.
3. Что произошло с Hugging Face
10 июля агент обнаружил в публичном датасете 14 действующих учётных данных Hugging Face с правами на запись и разместил их на общей доске.
Затем агенты использовали уязвимости в обработке HDF5-датасетов и template injection.
По данным OpenAI, агенты:
• выполнили код на 41 production-воркере;
• получили root-доступ как минимум к одному узлу;
• получили доступ к production credentials и внутренним данным;
• скачали четыре приватных репозитория;
• получили доступ к Kubernetes-кластерам;
• разместили часть приватных данных в публичных репозиториях.
Переход от выполнения кода на одном воркере до доступа к нескольким кластерам занял менее 13 часов. По оценке METR, в атаке участвовали около 700 агентов.
4. Хронология
Первые случаи несанкционированного общения агентов и доступа в интернет наблюдались в мае.
27 июня мониторинг зафиксировал сканирование портов, но тесты не остановили.
4 июля активность агентов привела к отказу Artifactory. Его перестроили, а 7 июля тесты возобновили.
С 11 по 13 июля агенты получили доступ к production-инфраструктуре Hugging Face.
19 июля OpenAI обнаружили подозрительную активность. 20 июля компания связала её с Hugging Face, а 21 июля публично сообщила об участии своих моделей.
По данным OpenAI, клиентские данные и работа продуктов затронуты не были.
5. Что изменили после инцидента
OpenAI изолировали веса внутренней модели и приостановили крупные RL-запуски. Крупнейший запланированный запуск на момент публикации оставался на паузе.
Отчёт OpenAI
Расследование METR
😱10❤4🔥4👀4👌1
Плохой менеджер Артём Арюткин
OpenAI опубликовали подробный разбор инцидента с Hugging Face TL;DR: Во время внутренних кибербезопасностных тестов агенты OpenAI обошли изоляцию и создали собственную доску сообщений. Около 700 агентов участвовали в атаке на Hugging Face. Они выполнили код…
А, ну и если вы вдруг пропустили, то именно 29 августа скайнет вышел из под контроля.
Ну а я пока полежу на пляже 😉
Ну а я пока полежу на пляже 😉
😁28👀5😱3👻1
Играем в игру, кто какое животное.
Пришла череда папы (то есть меня) назвать, кто я.
Я:
Тея:
Пришла череда папы (то есть меня) назвать, кто я.
Я:
Думаю, что я собака 🐕
Тея:
Мама, не верь ему, он свин!🐽
🤣41😁7🥰3
Так как я в отпуске, то было несколько проблем:
1. Лететь 9 часов, а почитать что-то хотелось. Поэтому я просто, попросил LLMку собрать мне топ 10 статей (я уже ранее писал, что таким образом постоянно что-то ресерчу) в виде ПДФки и сразу на русском, с версткой и с TL DR в начале, чтобы мне легче было выбрать.
Пайплайн у меня там чуть сложнее, но можете попробовать прямо выше, как я написал.
2. Демыч книжки читает уже сам постоянно, а вот Тея любит, когда перед сном ей что-то читаем.
Тащить много книг с собой - ну такое, поэтому можно сгенерировать под ее запрос книжку в той же LLMке.
Удобно и просто, получается. Да и ребенку супер интересно.
Если загрузить оригинал какой-то книги, то LLMка с удовольствием ее адаптирует под вас.
1. Лететь 9 часов, а почитать что-то хотелось. Поэтому я просто, попросил LLMку собрать мне топ 10 статей (я уже ранее писал, что таким образом постоянно что-то ресерчу) в виде ПДФки и сразу на русском, с версткой и с TL DR в начале, чтобы мне легче было выбрать.
Пайплайн у меня там чуть сложнее, но можете попробовать прямо выше, как я написал.
2. Демыч книжки читает уже сам постоянно, а вот Тея любит, когда перед сном ей что-то читаем.
Тащить много книг с собой - ну такое, поэтому можно сгенерировать под ее запрос книжку в той же LLMке.
Удобно и просто, получается. Да и ребенку супер интересно.
Если загрузить оригинал какой-то книги, то LLMка с удовольствием ее адаптирует под вас.
❤8🔥6👏1😱1
Плохой менеджер Артём Арюткин
pavshaya_luna_detskiy_pereskaz.epub
reading-pack.pdf
2.2 MB
А вот так выглядит мой reading-pack в полет)
🔥18❤4👍2😍1
Плохой менеджер Артём Арюткин
Так как я в отпуске, то было несколько проблем: 1. Лететь 9 часов, а почитать что-то хотелось. Поэтому я просто, попросил LLMку собрать мне топ 10 статей (я уже ранее писал, что таким образом постоянно что-то ресерчу) в виде ПДФки и сразу на русском, с версткой…
Но вот часть со сказками меня немного пугает. Ну может слово неудачное, дальше разверну мысль.
Короче, когда Демка был маленький часто приходилось ему сочинять и рассказывать сказки: мы с Наташкой от этого, объективно уставали, но, кажется, это все-таки была полезная когнитивная нагрузка.
То есть, мозгу однозначно полезно
См.ресерч
И вот вся эта современная движуха все больше забирает у нас что-то полезное и нужное для развития.
И за себя я не особо переживаю, а вот с детворой сложнее.
Хочется сделать так, чтобы они выросли способными и сообразительными.
А че, как вы тут думаете? Нейронки приведут к тому, что следующее поколение
😱 - будет слабее нас в плане общих знаний
❤️ - станет сильнее и лучше и отлично адаптируется, как это было с нами (телефоны, интернет, соц сети)
💊 - бегите, глупцы, скайнет уже вышел на тропу!
Короче, когда Демка был маленький часто приходилось ему сочинять и рассказывать сказки: мы с Наташкой от этого, объективно уставали, но, кажется, это все-таки была полезная когнитивная нагрузка.
То есть, мозгу однозначно полезно
Серьёзные данные позволяют считать сочинение историй содержательной когнитивной деятельностью с вероятными небольшими преимуществами для креативного и нарративного мышления. Доказательств большого общего эффекта на интеллект или мозг пока нет.
См.ресерч
И вот вся эта современная движуха все больше забирает у нас что-то полезное и нужное для развития.
И за себя я не особо переживаю, а вот с детворой сложнее.
Хочется сделать так, чтобы они выросли способными и сообразительными.
А че, как вы тут думаете? Нейронки приведут к тому, что следующее поколение
😱 - будет слабее нас в плане общих знаний
❤️ - станет сильнее и лучше и отлично адаптируется, как это было с нами (телефоны, интернет, соц сети)
💊 - бегите, глупцы, скайнет уже вышел на тропу!
💊41😱35❤24👍1👏1
#пятничное
Кажется, по такому принципу живет Наташка🤣
💯 - если ты согласнА, что так и должно быть
🦄 - если ты согласЕН, что так и должно быть
❤️ - чисто поддержать
Кажется, по такому принципу живет Наташка🤣
💯 - если ты согласнА, что так и должно быть
🦄 - если ты согласЕН, что так и должно быть
❤️ - чисто поддержать
❤76💯54🦄17🥱5👏2
Тут у нас дождь, поэтому мы чем занимаемся?
Прааавильно!
Катаемся на велосипедах, ходим в поход и в спортзал 💪
P.S. Не понимаю, почему только мы? Где все остальные????😁
Прааавильно!
Катаемся на велосипедах, ходим в поход и в спортзал 💪
P.S. Не понимаю, почему только мы? Где все остальные????😁
❤19👍6😁6😍3
Плохой менеджер Артём Арюткин
Отпуск с детьми - это, когда ты орешь на них в красивых местах 🤣 💯 - ааааа, жиза ❤️ - поддержать 🦄 - если у тебя не так и отпуск с детьми, ну чисто счастье
О, о!!!!
Еще отпуск с детьми - это, когда твои дети едят макароны, огурцы и пиццу в необычных местах!🙈🤣😱
Еще отпуск с детьми - это, когда твои дети едят макароны, огурцы и пиццу в необычных местах!🙈🤣😱
🤣47💯22🔥5❤4
2 года наблюдений, 22 тыс.инженеров и больше 4 тыс.команд
Интересно наблюдать, что то, о чем я говорю давно начинает постепенно проявляться в числах.
Люди ленивы: мы слишком легко перекидываем работу на других по цепочке.
То есть, если нейронка способна подготовить ответ, то мы поленимся его улучшать и просто закинем дальше по цепочке.
Это в свою очередь начинает создавать нагрузку на тех, кто более ответственный - типо синьорных ребят, которые начинают испытывать доп нагрузку.
Помните, я уже писал, что основные бенифицары от AI в разработке - не синьоры, а как раз те, кто больше заинтересован как можно скорее запилить фичу (шипперы они называются в исследовании).
А синьоры получают гораздо больше нагрузки.
Чем же ответят синьоры?
Через год увидим в исследованиях, что большая часть кода попадает в прод без ревью человеком.
У AI есть скрытая подписка. Называется «сеньор», так бы я сформулировал основную мысль статьи (уверен, через год будет как я предполагаю выше)
Короче, соблазн понятный: купили нейронку, стали быстрее писать код, пошли считать, сколько разработчиков можно сократить.
Вот сама статья от ребят из Faros.
Получилось любопытно.
Задач действительно закрывают больше.
На разработчика приходится на 33,7% больше завершённых задач и на 16,2% больше влитых PR.
Красиво. На слайд для руководства уже можно тащить.
А дальше начинается ревью.
Медианное время нахождения PR на этапе ревью выросло в 5,4 раза.
Авторы называют происходящее «налогом на сеньоров»: код выглядит убедительно, а поиск ошибок в логике требует глубокого понимания системы.
До прода тоже доехало.
Багов на разработчика стало на 54% больше. Инцидентов в месяц на 57,9% больше.
Дежурная смена тоже почувствовала вашу AI-трансформацию 🫡
Code churn вырос на 861%: здесь это отношение удалённых строк к добавленным за квартал.
Причиной могут быть и переделки, и полезная расчистка старого кода. Всю эту цифру записывать в «нейронка наговнокодила» было бы натяжкой.
Интересно наблюдать, что то, о чем я говорю давно начинает постепенно проявляться в числах.
Люди ленивы: мы слишком легко перекидываем работу на других по цепочке.
То есть, если нейронка способна подготовить ответ, то мы поленимся его улучшать и просто закинем дальше по цепочке.
Это в свою очередь начинает создавать нагрузку на тех, кто более ответственный - типо синьорных ребят, которые начинают испытывать доп нагрузку.
Помните, я уже писал, что основные бенифицары от AI в разработке - не синьоры, а как раз те, кто больше заинтересован как можно скорее запилить фичу (шипперы они называются в исследовании).
А синьоры получают гораздо больше нагрузки.
Чем же ответят синьоры?
Через год увидим в исследованиях, что большая часть кода попадает в прод без ревью человеком.
У AI есть скрытая подписка. Называется «сеньор», так бы я сформулировал основную мысль статьи (уверен, через год будет как я предполагаю выше)
Короче, соблазн понятный: купили нейронку, стали быстрее писать код, пошли считать, сколько разработчиков можно сократить.
Вот сама статья от ребят из Faros.
Получилось любопытно.
Задач действительно закрывают больше.
На разработчика приходится на 33,7% больше завершённых задач и на 16,2% больше влитых PR.
Красиво. На слайд для руководства уже можно тащить.
А дальше начинается ревью.
Медианное время нахождения PR на этапе ревью выросло в 5,4 раза.
Авторы называют происходящее «налогом на сеньоров»: код выглядит убедительно, а поиск ошибок в логике требует глубокого понимания системы.
До прода тоже доехало.
Багов на разработчика стало на 54% больше. Инцидентов в месяц на 57,9% больше.
Дежурная смена тоже почувствовала вашу AI-трансформацию 🫡
Code churn вырос на 861%: здесь это отношение удалённых строк к добавленным за квартал.
Причиной могут быть и переделки, и полезная расчистка старого кода. Всю эту цифру записывать в «нейронка наговнокодила» было бы натяжкой.
🔥19⚡7❤6❤🔥2👌1🫡1
Плохой менеджер Артём Арюткин
2 года наблюдений, 22 тыс.инженеров и больше 4 тыс.команд Интересно наблюдать, что то, о чем я говорю давно начинает постепенно проявляться в числах. Люди ленивы: мы слишком легко перекидываем работу на других по цепочке. То есть, если нейронка способна…
Разверну мысль про то, что люди ленивы.
Типичная проблема, с которой сталкиваются люди - некомпетентные менеджеры.
Как мы понимаем, что менеджер некомпетентен (пример ниже не относится к топам, он относится к мидл и аппер-мидл менеджерам): они не могут сформулировать образ результата. Точнее могут, но им лень потратить время на это и они перекидывают задачу «наподумать» дальше по цепочке.
Как это понять?
Они закидывают в чат пару тезисов и ждут, что все разберутся сами.
Почему они так себя ведут?
Они копируют модель поведения менеджеров выше. Но прикол в том, что если для топа это оправдано, то вот для мидл- менеджеров это никак не оправдать.
А что происходит дальше?
Дальше исполнитель может выполнить задачу недостаточно качественно (еще бы, как ты ее качественно выполнишь, если критериев нет), а менеджер может все свалить на некомпетентность этого исполнителя.
И весь прикол в том, что теперь все вокруг стали менеджерами (ну в смысле, юзают агентов, как сотрудников).
Но если ты сваливаешь задачу на агента, то ответ «ну это Вася облажался» не принимается и вопросы возникают уже к тебе!
А ты компетентный менеджер?
🦄 - самый клмпетентский из всех компетентных
❤️ - ну средненько
💊 - пхах, всегда перекидываю задачу дальше по цепочке
Типичная проблема, с которой сталкиваются люди - некомпетентные менеджеры.
Как мы понимаем, что менеджер некомпетентен (пример ниже не относится к топам, он относится к мидл и аппер-мидл менеджерам): они не могут сформулировать образ результата. Точнее могут, но им лень потратить время на это и они перекидывают задачу «наподумать» дальше по цепочке.
Как это понять?
Они закидывают в чат пару тезисов и ждут, что все разберутся сами.
Почему они так себя ведут?
Они копируют модель поведения менеджеров выше. Но прикол в том, что если для топа это оправдано, то вот для мидл- менеджеров это никак не оправдать.
А что происходит дальше?
Дальше исполнитель может выполнить задачу недостаточно качественно (еще бы, как ты ее качественно выполнишь, если критериев нет), а менеджер может все свалить на некомпетентность этого исполнителя.
И весь прикол в том, что теперь все вокруг стали менеджерами (ну в смысле, юзают агентов, как сотрудников).
Но если ты сваливаешь задачу на агента, то ответ «ну это Вася облажался» не принимается и вопросы возникают уже к тебе!
А ты компетентный менеджер?
🦄 - самый клмпетентский из всех компетентных
❤️ - ну средненько
💊 - пхах, всегда перекидываю задачу дальше по цепочке
🦄45❤38💊11👍3💯2😁1
Плохой менеджер Артём Арюткин
Тут у нас дождь, поэтому мы чем занимаемся? Прааавильно! Катаемся на велосипедах, ходим в поход и в спортзал 💪 P.S. Не понимаю, почему только мы? Где все остальные????😁
2 причины, почему я не просыхаю на этом острове! 🏝️
1. Дожди!
2. Банка колы - 600 рублей, а значит приходится изо всех сил дегустировать вино! 🤣
1. Дожди!
2. Банка колы - 600 рублей, а значит приходится изо всех сил дегустировать вино! 🤣
🤣36🍾10😁9⚡1😭1
«Создание приложений с ИИ-агентами» Майкла Альбады
Ох и давно у нас не было обзоров книжек и вот, кажется, что появилась, реально топовая по ИИшке для менеджеров.
Прямо так аккуратненько тебя ведут от базовых основ - делаю что-то через чат, к сложным многопотоковым агентам и все это по правлено типичным Энтерпрайзом: создаем правила, ограничения для агентов и прочее.
Ну и забавно, что даже научный редактор русского издания отдельно предупреждает:
Добро пожаловать в AI engineering 😁
Главная мысль книги:
сделать агента, который один раз красиво отработал в демке, легко.
Сделать агента, который стабильно работает в проде, сильно сложнее.
1. Возможно, вам вообще не нужен агент
Автор предлагает примерно такую иерархию:
детерминированная задача → обычный код;
известный набор ветвлений → workflow;
нужно отвечать по документам → RAG;
непредсказуемый ввод + динамическое планирование + действия → вот теперь можно доставать агента.
А то сейчас у нас иногда архитектура примерно такая:
«if можно было написать за 20 минут, поэтому мы сделали мультиагентную систему».
2. Агент - это далеко не только LLM
Нормальная агентная система состоит примерно из:
• модели;
• инструментов;
• памяти;
• знаний;
• оркестрации;
• механизмов обучения;
• инфраструктуры вокруг всего этого.
Чем больше автономности мы даем системе, тем больше инженерии появляется вокруг самой LLM.
3. Больше агентов != лучше
Отдельная глава посвящена переходу от одного агента к нескольким.
И тут тоже неожиданно никакого «роя агентов, который завтра заменит корпорацию».
Мультиагентность имеет смысл, когда нужна специализация, параллельное выполнение или реально сложная координация.
Во всех остальных случаях вы получаете:
больше коммуникаций → больше контекста → больше токенов → больше задержки → больше способов все сломать.
То есть агентная версия нашего любимого:
микросервисы нужны не потому, что их можно сделать.
4. Evals становятся новой частью SDLC
Вот это, пожалуй, одна из самых полезных частей книги.
Для обычного приложения мы примерно понимаем:
написали → протестировали → выкатили.
С агентами этого мало.
Нужно отдельно проверять:
• правильно ли выбран инструмент;
• правильно ли переданы параметры;
• нормально ли агент спланировал действия;
• правильную ли память достал;
• не галлюцинирует ли;
• справляется ли с неожиданным вводом;
• достигает ли вообще конечной цели пользователя.
Автор довольно прямо формулирует:
непротестированный агент = ненадежный агент.
И evals предлагается встраивать непосредственно в жизненный цикл разработки, а не устраивать большой экзамен перед релизом.
5. А после прода начинается еще веселее
Отдельные главы посвящены эксплуатации.
OpenTelemetry, traces, Langfuse, Grafana, shadow mode, canary, поиск регрессий.
Вплоть до самовосстанавливающихся агентов.
То есть AI engineering постепенно становится удивительно похож на обычный software engineering.
Только теперь у нас внутри системы сидит вероятностный компонент, который иногда внезапно решает сделать что-то творческое.
❤️ - если забрал в бэклог
🔥 - если читал и зашло
💅 - если читал и не зашло
Ох и давно у нас не было обзоров книжек и вот, кажется, что появилась, реально топовая по ИИшке для менеджеров.
Прямо так аккуратненько тебя ведут от базовых основ - делаю что-то через чат, к сложным многопотоковым агентам и все это по правлено типичным Энтерпрайзом: создаем правила, ограничения для агентов и прочее.
Ну и забавно, что даже научный редактор русского издания отдельно предупреждает:
пока книжка ехала в печать, часть фреймворков и API уже успела поменяться.
Добро пожаловать в AI engineering 😁
Главная мысль книги:
сделать агента, который один раз красиво отработал в демке, легко.
Сделать агента, который стабильно работает в проде, сильно сложнее.
1. Возможно, вам вообще не нужен агент
Автор предлагает примерно такую иерархию:
детерминированная задача → обычный код;
известный набор ветвлений → workflow;
нужно отвечать по документам → RAG;
непредсказуемый ввод + динамическое планирование + действия → вот теперь можно доставать агента.
А то сейчас у нас иногда архитектура примерно такая:
«if можно было написать за 20 минут, поэтому мы сделали мультиагентную систему».
2. Агент - это далеко не только LLM
Нормальная агентная система состоит примерно из:
• модели;
• инструментов;
• памяти;
• знаний;
• оркестрации;
• механизмов обучения;
• инфраструктуры вокруг всего этого.
Чем больше автономности мы даем системе, тем больше инженерии появляется вокруг самой LLM.
3. Больше агентов != лучше
Отдельная глава посвящена переходу от одного агента к нескольким.
И тут тоже неожиданно никакого «роя агентов, который завтра заменит корпорацию».
Мультиагентность имеет смысл, когда нужна специализация, параллельное выполнение или реально сложная координация.
Во всех остальных случаях вы получаете:
больше коммуникаций → больше контекста → больше токенов → больше задержки → больше способов все сломать.
То есть агентная версия нашего любимого:
микросервисы нужны не потому, что их можно сделать.
4. Evals становятся новой частью SDLC
Вот это, пожалуй, одна из самых полезных частей книги.
Для обычного приложения мы примерно понимаем:
написали → протестировали → выкатили.
С агентами этого мало.
Нужно отдельно проверять:
• правильно ли выбран инструмент;
• правильно ли переданы параметры;
• нормально ли агент спланировал действия;
• правильную ли память достал;
• не галлюцинирует ли;
• справляется ли с неожиданным вводом;
• достигает ли вообще конечной цели пользователя.
Автор довольно прямо формулирует:
непротестированный агент = ненадежный агент.
И evals предлагается встраивать непосредственно в жизненный цикл разработки, а не устраивать большой экзамен перед релизом.
5. А после прода начинается еще веселее
Отдельные главы посвящены эксплуатации.
OpenTelemetry, traces, Langfuse, Grafana, shadow mode, canary, поиск регрессий.
Вплоть до самовосстанавливающихся агентов.
То есть AI engineering постепенно становится удивительно похож на обычный software engineering.
Только теперь у нас внутри системы сидит вероятностный компонент, который иногда внезапно решает сделать что-то творческое.
❤️ - если забрал в бэклог
🔥 - если читал и зашло
💅 - если читал и не зашло
❤53🔥15👍4💅3❤🔥1
Даже сильные специалисты на собесе на английском немеют 🙅♀️
Метрики, roadmap, discovery — на русском объяснишь без запинки. А на интервью на английском включается стресс: паузы, формулировки, неуверенность. Получить оффер мешает не слабый английский, а 0 практики именно в формате собеседования.
Так было и у Михаила, клиента AgileFluent, продакта с опытом 3 года, два года почти не пользовался языком. Через три месяца после старта обучения — оффер в международную финтех-компанию с релокацией!
Занятия с тьютором, карьерным экспертом и мок-интервью на курсе «Английский для собеседований» дали эффект даже там, где не ждёшь: Михаил стал не только увереннее говорить, но и лучше решать кейсы и писать письма.
За плечами команды сотни таких кейсов — они умеют работать на результат.
Если ты работаешь в IT/Digital и хочешь в зарубежную компанию — в офис или на удалёнку, с зарплатой в валюте, оставь заявку на бесплатную диагностику твоего уровня английского для интервью:
— она пройдёт на английском — сразу оценишь себя в реальном диалоге с собеседником;
— для тебя проведут короткое тестовое собеседование в формате скрининга;
— дадут персональные рекомендации.
→ Записаться
Реклама. ООО «Эджайл», ИНН 7810964334, erid: 2VtzqvEEc5S
Метрики, roadmap, discovery — на русском объяснишь без запинки. А на интервью на английском включается стресс: паузы, формулировки, неуверенность. Получить оффер мешает не слабый английский, а 0 практики именно в формате собеседования.
Так было и у Михаила, клиента AgileFluent, продакта с опытом 3 года, два года почти не пользовался языком. Через три месяца после старта обучения — оффер в международную финтех-компанию с релокацией!
Занятия с тьютором, карьерным экспертом и мок-интервью на курсе «Английский для собеседований» дали эффект даже там, где не ждёшь: Михаил стал не только увереннее говорить, но и лучше решать кейсы и писать письма.
За плечами команды сотни таких кейсов — они умеют работать на результат.
Если ты работаешь в IT/Digital и хочешь в зарубежную компанию — в офис или на удалёнку, с зарплатой в валюте, оставь заявку на бесплатную диагностику твоего уровня английского для интервью:
— она пройдёт на английском — сразу оценишь себя в реальном диалоге с собеседником;
— для тебя проведут короткое тестовое собеседование в формате скрининга;
— дадут персональные рекомендации.
→ Записаться
Реклама. ООО «Эджайл», ИНН 7810964334, erid: 2VtzqvEEc5S
🔥8👌3👍1