10065
Канал про IT менеджмент ex-Дир-р по тех. разв-ю в Сбере: данные, AI, рек.системы. Ex-head of PMO СБОЛ. Автор:Арюткин Артём Реклама: @Badtechproject_contact Рег № 4923327959
#пятничное
Кажется, по такому принципу живет Наташка🤣
💯 - если ты согласнА, что так и должно быть
🦄 - если ты согласЕН, что так и должно быть
❤️ - чисто поддержать
А вот так выглядит мой reading-pack в полет)
Читать полностью…
Играем в игру, кто какое животное.
Пришла череда папы (то есть меня) назвать, кто я.
Я:
Думаю, что я собака 🐕
Мама, не верь ему, он свин!🐽Читать полностью…
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
Отпуск с детьми - это, когда ты орешь на них в красивых местах 🤣
💯 - ааааа, жиза
❤️ - поддержать
🦄 - если у тебя не так и отпуск с детьми, ну чисто счастье
HR — это не человек, который поздравляет вас с днем рождения и организует корпоратив
Ну, точнее, не только это😁
Сегодня сильная HR-команда — полноценный партнер бизнеса.
А значит, она должна:
1. Понимать, как компания зарабатывает деньги.
2. Говорить с бизнесом на одном языке.
3. Приносить данные, а не только ощущения.
4. Задавать руководителям неудобные вопросы.
5. Влиять не только на «счастье сотрудников», но и на бизнес-результат.
Ииии тут есть важный момент.
Процессы, аналитику и рутину можно автоматизировать и масштабировать технологиями.
А вот развитие руководителей, доверие внутри команды и сложные разговоры автоматизировать пока не получается.
Как ни старайтесь, нейросетка не объяснит вашему руководителю, что переставлять людей на оргструктуре — еще не значит управлять изменениями😉
Об этом поговорили в новом выпуске подкаста с Юлией Брук — HR-директором бизнес-группы «Социальные платформы и медиаконтент» VK.
Отдельно зацепили две мысли.
Первая — большие изменения в компании невозможны без вовлечения руководителей.
HR может придумать прекрасный процесс, нарисовать модель компетенций и провести 38 обучений.
Но если сами руководители не создают среду, в которой люди могут развиваться, ничего особо не изменится.
Вторая — карьера не обязана быть забегом на скорость.
Иногда поступательное движение дает сильно больше, чем попытка получить новую должность каждые полтора года.
Потому что вместе с названием позиции успевают вырасти профессиональный и жизненный опыт.
У Юлии тут показательный путь: она работает во ВКонтакте уже 16 лет и прошла вместе с компанией путь от соцсети для общения с друзьями до огромной контентной и бизнес-платформы с командой более 2000 человек.
Компания выросла, продукты изменились, людей стало сильно больше, а задача осталась примерно прежней:
— развивать бизнес;
— не превратить процессы в бетон;
— сохранить драйв;
— не потерять культуру по дороге.
Короче, получился разговор не столько про HR, сколько про то, как компании расти и меняться, не превращаясь при этом в бездушную машину из процессов, регламентов и согласований.
26 сентября, что?
Правильно!
Я буду выступать на нашей топовой конференции Avito Tech Conf и расскажу, как же на самом деле меняется PDLC:
- не будет ощущений (ладно будут),
- а будут только реальные сравнения с фокусом на данные.
Ваще, мой основной замысел - поговорить именно про данные и про то, что видно на них.
Будут исследования, сравнения бенчмарков рынка и факты, где и какие ботел-неки встречаются.
Ну и традиционно Avito Tech Conf ну прямо кайфовая!
P.S. Вспомнил, что я еще и ведущим буду
То есть нормальный скроллинг у вас сделать не получается, да?!
Есть гипотеза, что никто не ожидает, что ваще будут читать люди, а не агенты)
Жизнь - это бесконечные попытки:
- выучить Английский
- накачаться 😁
У меня, кстати, год назад был обзор книги по инвестициям
Можно и продублировать. Книжка хороша!
💰«Разумный инвестор» — или как не сжечь свои деньги в костре жадности
Короче, у меня инвестиционный счет появился в 2017 году.
Но я тот еще инвестор…
Однако уже тогда давно я осознавал, что моя цель - сохранение капитала, а не х10.
Пошел искать книги и наткнулся на это сокровище!
Это не книга - анти-курсы по «как быстро разбогатеть».
Актуальна каждый раз, когда ты соблазняешься очередным «тут точно x10, брат».
🧓 Кто такой Бенджамин Грэм?
Отец value-инвестирования, человек, которому Уоррен Баффет до сих пор ставит свечки в инвестиционном храме.
Он не учит угадывать рынок. Он учит не терять деньги. И в этом вся магия.
📊 Основные идеи, чтобы потом не говорить «а я не знал»:
1. Рынок - это Мистер Шизик
Каждый день он приходит и предлагает тебе купить-продать акции. Сегодня - в истерике. Завтра - в эйфории.
Что ты должен делать? Во первых, ты никому ничего не должен!А, сори, не та, статья! 😁
Игнорировать его и пользоваться моментами, когда он особо не в себе.
2. Инвестор ≠ Спекулянт
Инвестор- это человек, который покупает бизнес, а не график.
Если ты смотришь на свечи и RSI, а не на отчётность - ну ты понял…
3. Маржа безопасности
Покупай дешевле, чем это стоит. С запасом.
Потому что ты не Уоррен Баффет. И ты ошибёшься. Не раз.
4. Инвестирование - это скучно
Скучно - значит правильно.
Всё, что вызывает у тебя адреналин, - повод закрыть терминал и пойти попить чай.
🧘♂️ Психология важнее математики
Ты не проиграл, потому что рынок пошёл не туда.
Ты проиграл, потому что начал паниковать, продавать на минус 20% и смотреть, что говорит какой-нибудь эксперт с YouTube.
Настоящая доходность — в голове, а не в калькуляторе.
А еще, помните, что каждый ваш шаг - это ставка на наиболее вероятностное событие (вы так поняли из ваших знаний и умений), но, иногда, срабатывают события с вероятностью близкой к 0.001%.
🧾 Для кого эта книга:
Для тех, кто уже однажды «инвестировал» в крипту на пике
Для тех, кто не хочет каждый день играть в угадайку
Для тех, кто устал от «вот мой портфель, подпишись, ставь 🔥»
⚠️ Важно:
Книга написана не как мотивационный пинок, а как таблетка от жадности и тупости.
Стиль - академический, местами занудный. Но как хорошее вино - со временем заходит.
📦 Вывод:
«Разумный инвестор» - это как скучный, но очень умный дед.
Он не будет размахивать руками, он просто скажет:
«Сынок, не суетись. Купи хорошие компании и не трогай их. Всё будет».
☣️ Важное, наиважнейшее мнение автора блога 🤣
Ну а еще, смотри на активы шире: знания, квартира, время на семью и работу, ра карьерного консультанта и прочее - тоже активы.
Ребалансируй все ваши активы правильно, а не только на инвестиционном счету 😉
Что, конечно, не является инвестиционной рекомендацией 🤣
🔥 — Если уже прочитал и зашло
❤️ — В список must-read
💅 — Если не зашло
Пу-пу-пуууу
То есть нас уже предупреждали 😁
У разработки есть свой налог на масштаб
Платите вы его процессами, зависимостями и количеством людей, которых надо позвать на созвон 😉
DX выкатили свежие Core 4 бенчмарки по 500+ компаниям. Там есть интересный срез: как отличаются метрики у инженерных организаций разного размера.
Не динамика во времени, а сравнение групп:
— <100 инженеров
— 100–500
— 500–2500
— 2500+
Иииии вот что видно.
1. Change Fail Rate растет с масштабом
У tech-компаний:
<100 инженеров - 4,0%
2500+ - 4,8%
У non-tech:
3,95% → 5,26%
То есть большие организации чаще выпускают некачественные решения.
2. Developer Experience начинает проседать
Медианный DXI у tech-компаний:
— <100: 66
— 100–500: 66
— 500–2500: 67
— 2500+: 64
До нескольких тысяч инженеров все примерно стабильно.
А потом сложность начинает догонять.
3. PR на инженера тоже становится меньше
— <100: 3,8 PR/неделю
— 2500+: 3,35
Примерно минус 12%.
PR, конечно, не productivity, но сигнал вполне понятный.
И вот тут мне нравится термин:
Налог на масштаб разработки
Чем больше организация, тем больше ресурсов съедают:
— зависимости;
— согласования;
— коммуникации;
— legacy;
— инфраструктурная сложность;
— процессы управления процессами.
Код мы научились производить быстрее, тут спасибище AI.
А вот организация вокруг его производства быстрее пока не стала: все те же процессы, все те же команды, все те же люди.
Поэтому одна из ключевых задач Developer Platform / DevEx - не просто ускорять написание кода, а снижать налог на масштаб.
Иначе дадим каждому инженеру AI-агента…
…а потом они оба будут три дня ждать ревью 😁
Наташка водила меня сегодня по музеям!
Главным впечатлением считаю - водный экскаватор!
Вы когда-нибудь такой видели?
Я ваще в восторге!
Вот такую красоту мне прислали почитать)
Начав читать я понял аудиторию, кому она подойдет)
В обзоре расскажу
А вот тут мы с Сашей Поломодовым разбирали разные фреймворки и историю их развития
Читать полностью…
Но вот часть со сказками меня немного пугает. Ну может слово неудачное, дальше разверну мысль.
Короче, когда Демка был маленький часто приходилось ему сочинять и рассказывать сказки: мы с Наташкой от этого, объективно уставали, но, кажется, это все-таки была полезная когнитивная нагрузка.
То есть, мозгу однозначно полезно
Серьёзные данные позволяют считать сочинение историй содержательной когнитивной деятельностью с вероятными небольшими преимуществами для креативного и нарративного мышления. Доказательств большого общего эффекта на интеллект или мозг пока нет.
Так как я в отпуске, то было несколько проблем:
1. Лететь 9 часов, а почитать что-то хотелось. Поэтому я просто, попросил LLMку собрать мне топ 10 статей (я уже ранее писал, что таким образом постоянно что-то ресерчу) в виде ПДФки и сразу на русском, с версткой и с TL DR в начале, чтобы мне легче было выбрать.
Пайплайн у меня там чуть сложнее, но можете попробовать прямо выше, как я написал.
2. Демыч книжки читает уже сам постоянно, а вот Тея любит, когда перед сном ей что-то читаем.
Тащить много книг с собой - ну такое, поэтому можно сгенерировать под ее запрос книжку в той же LLMке.
Удобно и просто, получается. Да и ребенку супер интересно.
Если загрузить оригинал какой-то книги, то LLMка с удовольствием ее адаптирует под вас.
А, ну и если вы вдруг пропустили, то именно 29 августа скайнет вышел из под контроля.
Ну а я пока полежу на пляже 😉
Как в этом мире одновременно может существовать такое и таблицы Эксель?😁
Читать полностью…
#пятничное
💯 - если у тебя также!
❤️ - если у тебя нет никаких дел
🦄 - если ты не пьешь кофе!
Мои подписчики часто спрашивают: «А как ты находишь все эти классные статьи»?Никто не спрашивает!
И раз уж вам интересно, всем пофиг, то в chatGPT есть функция «дейли/викли обзоров», просто попросите его и все: прямо так и пишите
Начни мне присылать ежедневно топ 100 постов из тг канала badtechproject
О, вот то, что Борис писал еще в марте, теперь легло в отдельный Playbook по SDLC от Claude (AI native, конечно же)!
Забирайте!
Что там Стенфорд наисследовал про AI и работу
Стэнфорд выпустил прекрасный обзор того, что на самом деле происходит с рынком труда из-за AI.
Ребята посмотрели на данные и вот что там получилось.
1. Массового AI-апокалипсиса пока нет
С 2022 года безработица среди людей из наиболее подверженных влиянию AI профессий выросла на 0,77 процентного пункта, а среди наименее подверженных на 0,85.
То есть рынок труда действительно становится хуже, но пока нет оснований утверждать, что именно AI массово отнимает у людей работу.
Более того, количество программистов продолжает расти. Просто заметно медленнее, чем раньше.
2. Компании много рассказывают про AI, но мало меняют
По наиболее консервативной оценке AI использует примерно 20% компаний.
Но даже среди них внедрение чаще всего означает:
— несколько инструментов;
— одну-две функции;
— бесконечные пилоты;
— Copilot, купленный всем и используемый половиной.
Только 5% компаний сообщили, что AI как-то повлиял на количество сотрудников. Причем примерно одинаковая доля компаний увеличила и сократила штат.
3. Локально продуктивность действительно растет
AI увеличил производительность сотрудников поддержки в среднем на 15%, а новичков — сразу на 30% (вот тут у нас и собрались основные потери в вакансиях).
В экспериментах с разработчиками отдельные задачи выполнялись на 10–56% быстрее.
Но есть нюанс.
Быстрее написать кусок кода, не значит быстрее выпустить продукт. После генерации остаются ревью, тестирование, интеграция, безопасность, инфраструктура и бесконечное «а зачем мы вообще это сделали».
4. А вот джунам действительно становится больно
Безработица среди недавних выпускников в США достигла 5,6%, что на 1,6 процентного пункта больше, чем три года назад.
Причем проблема возникает в профессиях, где AI хорошо справляется с типичными задачами новичков: написать простой код, собрать информацию, подготовить текст, сделать базовый анализ.
Уже после публикации обзора Стэнфорд обновил исходное исследование: занятость людей 22–25 лет в наиболее затронутых AI профессиях оказалась примерно на 19% ниже уровня, на котором она была бы при такой же динамике, как у их сверстников в менее затронутых профессиях.
Компании просто нанимают меньше молодых сотрудников, т.е.происходит это преимущественно не через увольнения.
Короче, AI-революция может начаться не с массового увольнения дорогих сеньоров.
Она начинается с того, что компания решает:
«А давайте пока не будем брать еще двух джунов. Справимся агентами».
Авторы честно предупреждают: это пока корреляция, а не доказанная причинность. На рынок одновременно влияли ставки, постковидный перенаём и удалёнка.
Ну что, докладываю вам, как тут у нас дела с Демычем и его финансовой грамотностью.
0. Взяли все его накопленные средства и разделили, как я писал в мае.
1. Демыч красавчик, что четко и системно продолжает с моей помощью разделять все поступающие средства по счетам.
2. Мы чуть-чуть скорректировали схему еще на старте и Делим его средства на 4 части:
- наличные - тратит по своему усмотрению
- вклад
- золото
- и акции (как видите, хорошо, что взяли золото😁 Не грустите, мы же в долгую тут)
Не могу сказать, что он прямо горит энтузиазмом и интересуется, че как у него там дела и что же мы там покупаем.
Хотя пару раз пошутил над Наташкой, что пусть почаще покупает на ОЗОН, чтобы его акции в фонде росли)
В целом, считаю, что сама по себе идея хороша)
Все это все еще не является индивидуальной инвестиционной рекомендацией.
А вы сами инвестируете в фондовый рынок?
😭 - даааа…зачем ты напомнил
🦄 - еще бы: выйду на пенсию в 35! Ну или в х5
🙈 - инвестирую в неотгулянные отпуска на работе
ой, ну раз вам нравится, вот вам ПДФка с разбором))))
Вот этим вот всем я +/- и занимаюсь на работе))
Сегодня шел 3670 день, как я пытаюсь накачаться😁
И не говорите мне, что у вас получается лучше))
#пятничное
Ну че, было?
💯 - аххахаха, ваще
❤️ - да, но мне не разрешили смеяться над этой картинкой
🙈 - когда поняла, что это всегда ты)
Не грустите там, у нас всегда есть План Б!
Читать полностью…
Модель тройного долга от соавтора фреймворка SPACE
Маргарет-Энн Стори, соавтор фреймворка SPACE для повышения продуктивности разработчиков, недавно представила свою модель тройного долга (Triple Debt Model), в которой скрытые человеческие издержки ускоренной с помощью ИИ разработки программного обеспечения рассматриваются в трех категориях:
технический долг, который накапливается в коде.
когнитивный долг, который накапливается в людях, входящих в команду.
долг намерений, который накапливается во внешних знаниях, состоящих из лежащих в основе проекта соображений, целей и проектных ограничений, которые недостаточно задокументированы.
И идея там довольно простая:
AI позволяет нам быстрее производить код, но это совсем не значит, что мы автоматически быстрее производим хорошие и понятные системы.
Просто долг начинает накапливаться немного в других местах😉
Всего Стори выделяет три вида долга:
1. Технический долг
Плохие архитектурные решения, костыли, сложный код, отсутствие тестов и все то, что потом делает систему дорогой в изменении и поддержке.
Причем тут есть забавный парадокс.
Именно этот долг AI потенциально умеет неплохо сокращать:
-отрефакторить код;
-написать тесты и т.п.
То есть код может становиться даже лучше.
2. Когнитивный долг
Это долг, который накапливается уже в голове разработчика: агент написал 1000 строк хорошего кода. И даже тесты все зеленые. Так что вперед и PR в проде.
Только инженер, который этот PR принял, понимает систему чуть хуже, чем если бы писал это изменение самостоятельно. А потом еще один PR. И еще один.
Иииии в какой-то момент получается довольно странная система:
код работает, но никто толком не понимает почему.
Скорость производства кода растет быстрее скорости нашего понимания системы.
Вот это Стори и называет cognitive debt.
И да, тот факт, что скорость производства выросла - это супер! В этом вся суть моей работы, в принципе.
3. Долг намерений — Intent Debt
А вот это типовая проблема, которая всплыла наверх. Раньше она тоже была, но мы особо ей внимание не уделяли.
Можно прекрасно понимать, как работает код, но совершенно не понимать:
почему он работает именно так?
Какие продуктовые ограничения существовали? Что вообще хотел пользователь? Какие компромиссы были приняты?
Все это обычно живет где-то между:
- ADR;
- документацией;
- и, конечно же в голове того самого Тим-лида😁
А теперь представьте AI-first разработку.
Один агент написал изменение.
Через полгода другой агент должен его изменить.
И второй агент пытается понять намерения первого агента… по коду первого агента.
Ну удачи.
В мире AI-разработки документация, ADR, спецификации, acceptance criteria и domain model — это уже не какая-то бюрократия рядом с разработкой.
Это внешняя память вашей системы (на следующей неделе расскажу, как решают и эту задачку)
Причем память нужна уже не только людям, но и агентам.
Последние пару лет мы в основном спрашивали:
как заставить AI писать больше хорошего кода?
Но следующий вопрос будет:
как сделать так, чтобы люди и AI продолжали понимать систему, пока AI пишет все больше кода?
Потому что код становится все дешевле.
А вот понимание:
-зачем система существует;
- почему она устроена именно так;
- какие ограничения нельзя нарушать;
становится только дороже.
И возможно, через несколько лет главным инженерным активом компании будет уже не сам код.
А накопленный контекст вокруг него.