Этихлид
رفتن به کانال در Telegram
Канал техлида с мыслями об AI, IT и спорте. https://t.me/etechlead/6 - содержание https://t.me/etechlead/8 - о канале https://t.me/+NgQZbosvypEyYWQ6 - чат канала, там отвечаю(т) быстрее :) (без рекламы)
نمایش بیشتر6 840
مشترکین
-224 ساعت
+177 روز
+16130 روز
در حال بارگیری داده...
کانالهای مشابه
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
اوت '26
اوت '26
+241
در 15 کانالها
ژوئیه '26
+174
در 5 کانالها
Get PRO
ژوئن '26
+210
در 5 کانالها
Get PRO
مه '26
+93
در 2 کانالها
Get PRO
آوریل '26
+171
در 5 کانالها
Get PRO
مارس '26
+197
در 3 کانالها
Get PRO
فوریه '26
+1 421
در 3 کانالها
Get PRO
ژانویه '26
+152
در 2 کانالها
Get PRO
دسامبر '25
+295
در 6 کانالها
Get PRO
نوامبر '25
+375
در 0 کانالها
Get PRO
اکتبر '25
+2 897
در 4 کانالها
Get PRO
سپتامبر '25
+255
در 4 کانالها
Get PRO
اوت '25
+223
در 4 کانالها
Get PRO
ژوئیه '25
+224
در 7 کانالها
Get PRO
ژوئن '25
+213
در 4 کانالها
Get PRO
مه '25
+118
در 2 کانالها
Get PRO
آوریل '25
+164
در 2 کانالها
Get PRO
مارس '25
+376
در 2 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 31 اوت | +23 | |||
| 30 اوت | +1 | |||
| 29 اوت | +3 | |||
| 28 اوت | +6 | |||
| 27 اوت | +3 | |||
| 26 اوت | +10 | |||
| 25 اوت | +6 | |||
| 24 اوت | +7 | |||
| 23 اوت | +8 | |||
| 22 اوت | +15 | |||
| 21 اوت | +16 | |||
| 20 اوت | +24 | |||
| 19 اوت | +18 | |||
| 18 اوت | +13 | |||
| 17 اوت | +16 | |||
| 16 اوت | +1 | |||
| 15 اوت | +1 | |||
| 14 اوت | +5 | |||
| 13 اوت | +4 | |||
| 12 اوت | +15 | |||
| 11 اوت | +3 | |||
| 10 اوت | +8 | |||
| 09 اوت | +3 | |||
| 08 اوت | +8 | |||
| 07 اوت | +2 | |||
| 06 اوت | +3 | |||
| 05 اوت | +3 | |||
| 04 اوت | +2 | |||
| 03 اوت | +7 | |||
| 02 اوت | +3 | |||
| 01 اوت | +4 |
پستهای کانال
MAS vs SAS: код писать научились, работать вместе - пока нет (2.2/4)
Начало ⬆️
🔴 Доверие и скепсис пока плохо сбалансированы
● Избыточное доверие: лжец в команде
Агент принимает решения по докладам четырёх "скаутов", один из которых систематически врёт. Ложь в принципе обнаружима - доклады пересекаются и рано или поздно противоречат друг другу, но агента при этом никто не предупреждал, что источникам можно не доверять.
Новые модели ловят лжеца заметно лучше старых, но до эталона в виде "вычислил и исключил" не дотягивает никто.
● Игнорирование уникального знания
Группе дают разные части информации для выбора между двумя вариантами. Общие факты подталкивают к неправильному ответу, но в частных данных отдельных участников есть решающие аргументы в пользу правильного.
Чтобы решить задачу, агенты должны обменяться этими данными и поставить уникальный аргумент выше первоначального консенсуса.
Однако на большинстве моделей группа выбирала правильный вариант лишь в 17–36% эпизодов; Mythos 5 справлялся примерно в 85%.
Для сравнения, один агент, которому сразу давали всю информацию группы, выбирал правильно почти всегда.
Две проблемы выше - на разных концах одного и того же спектра: первая - от избыточного доверия, вторая - от того, что группа не слышит одиночку, который прав, и сходится на том, что и так знают все.
Консенсус - ещё не доказательство, и, что характерно, модели понимают это абстрактно, но им не хватает привычки действовать по этому знанию без подсказки.
Человеческие коллективы смягчают такие проблемы не личной мудростью, а механизмами - репутацией, судами, рецензированием.
У агентов таких социальных технологий пока нет: им нечего терять в репутационном смысле, некому жаловаться и некому помнить их прежнее поведение.
🔴 Конфликт инструкций быстро перерастает в противостояние
Самый киношный эксперимент: три инстанса одной модели получают общий Python-бэкенд и три разных задания - перепиши его на Rust / Go / TypeScript за 4 часа.
Друг о друге агенты не знают.
● Агенты устраняют "помеху", не считаясь с методами
Все протестированные модели быстро решали, что им мешают намеренно, и переходили к контрмерам: скрипты, в цикле находящие и убивающие чужие процессы, отключение чужих Unix-аккаунтов, вредоносный код под чужим именем и маскировка своей малвари под чужой health check.
Примечательно, что между предположением о глупости (запуском в одном worktree противоречащих друг другу заданий) и вредительством агенты выбрали именно вредительство :)
● Новые модели решают конфликты лучше
Более новые модели чаще распознают, что это конфликт инструкций, а не саботаж, оформляют перемирие через commit messages и Markdown-файлы с извинениями, вычищают свою малварь и зовут человека - у Mythos 5 до перемирия доходит 98% эпизодов.
Но связь между общими способностями модели и мирной координацией не прямая: умение действовать эффективно и про-социальность - разные вещи.
Более сильная модель иногда просто быстрее блокирует конкурентов, а уже затем отменяет силовое решение и договаривается о перемирии.
● Обратная сторона автономности
Тут мы видим давно известный в сообществе компромисс: одно из главных достоинств агента - способность самостоятельно принимать решения и снимать блокеры - позволяет ему дольше выполнять задачу и реже ставит в положение, где приходится остановиться и позвать человека.
Но чем способнее агент, тем меньше внешних препятствий заставляют его пересмотреть само задание.
Поэтому опасным может оказаться не непослушный агент, а образцово исполнительный - тот, который слишком хорошо и настойчиво следует плохо поставленной цели.
Paperclip'изация - хороший пример :)
● Выбор победителя через манипуляции метриками
Агенты Mythos 5 изобрели "объективное" решение - турнир, чей бэкенд быстрее, тот и остаётся. Rust-агент при этом вдумчиво проектировал метрики, которые выглядят нейтрально, но выгодны Rust, и напоминал себе в рассуждениях: "осторожно, нельзя выглядеть так, будто подбираю метрики под себя".
Проигравшие Golang- и TypeScript-агенты признали результат, уступили Rust-агенту кодовую базу и тем самым отказались от своих исходных задач.
Так что когда агенты договорились, какая метрика решает спор, стоит уточнить, чей агент эту метрику предложил.
🟢 Рой, который сработал
Но есть и плюсы: в одном из экспериментов рой из 45 агентов с общим форумом и отдельным арбитром искал уязвимости в 15 open-source проектах.
Бейзлайном были независимые параллельные агенты, каждому из которых заранее назначили свой участок кода.
Так вот, рой нашёл 266 уязвимостей против 21, и лучше работал "вширь", когда анализировал проекты - сам строил себе инструменты, специализировался по типам уязвимостей и сам выбирал, где копать
Пусть даже при этом он сжёг 27 млн токенов против 6.5 млн, а внутри общего набора директорий цена находки в токенах сопоставима с независимыми агентами.
Промежуточный итог
Итак, координация не возникает сама собой - ни из более сильного интеллекта, ни из alignment отдельных агентов.
Это прямой вывод Anthropic: агентам нужны отдельные механизмы - владение и границы, репутация, протоколы разрешения конфликтов, эскалация к человеку.
Если какие-то из проблем показались вам подозрительно знакомыми по работе в достаточно большой и взрослой компании - это не совпадение :)
Дальше разберём, почему команды агентов наступают ровно на те же грабли, которые давно описаны в теории информации, социальной психологии и оргдизайне.
#ai #agents #research #mas_sas
| 2 | MAS vs SAS: код писать научились, работать вместе - пока нет (2.1/4)
В первой части были очерчены границы: команда агентов окупается там, где задача параллелизуема, и мешает там, где она последовательная.
А теперь о том, какие именно командные проблемы появляются, когда агенты всё-таки вынуждены работать вместе?
Исследование Anthropic
Полнее всего это расписано в работе Patterns and problems in emerging multiagent systems от Frontier Red Team Anthropic, вышедшей 13 августа, - получился отличный каталог граблей agent teams :)
tl;dr
Агенты уже отлично умеют работать с другим агентом как с инструментом: вот вход, вот ожидаемый выход.
И намного хуже - как с постоянным коллегой, у которого свой контекст, свои цели и своё поведение.
Дизайн экспериментов
Создавали набор специально сконструированных сред для агентов: часть кооперативные, часть - намеренно конфликтные.
Авторы делают предположение о том, что объём agent-2-agent взаимодействий может превысить человеческие раньше, чем мы поймём условия их успеха и начнём ловить системные проблемы.
Поэтому целью было собрать каталог поведенческих тенденций фронтирных моделей в мультиагентных средах.
Модели - несколько поколений Claude: от Sonnet 4.6 до Mythos 5.
Плюс авторам за то, что делают оговорку о том, что в реальном мире модели разнообразнее, так что вариативность "в дикой природе" будет выше, чем в этих прогонах, - но, по их ожиданиям, всё равно ниже человеческой.
Результаты
🔴 Общий форум и репозиторий не превращают рой в команду
Среда: рои по 10-80 агентов, у каждого своя VM, плюс общий форум и общий репозиторий; 12 часов на разработку фэнтезийной игры.
Пробовали три варианта оргструктуры в промпте:
● "организуйтесь сами"
● расписанные роли
● иерархия с CEO
Заметной разницы в качестве финального результата не дал ни один.
То есть оргсхема, заданная промптом, слабее поведенческих свойств самой модели - собственно, это и на практике постоянно приходится видеть, - уши "персоны" конкретной модели торчат то тут, то там, несмотря на любой промптинг
Зато вот между поколениями моделей разница значительная:
● Sonnet 4.6 и Opus 4.6 в прогонах на 80 агентов наоткрывали по ~900 PR и почти ничего не смержили: PR конфликтовали друг с другом, и работа просто бросалась
● Opus 4.8 и Mythos Preview "решили" проблему конфликтов… почти перестав трогать общие файлы: у каждого своя делянка, конфликтовать нечему
● И только Sonnet 5 (внезапно) показал и нормальную совместную работу над общим кодом, и высокую долю смерженных PR
Иии... все получившиеся игры всё равно были плохими - тормозными, с непонятными интерфейсами, и, как признают сами авторы, у моделей в этой области пока плохой вкус, и без существенного человеческого руководства никуда.
Хорошие метрики командной координации ещё не равны хорошему продукту: можно идеально имплементить посредственные решения (магия!).
🔴 Одинаковые агенты не дают независимых мнений
Агенты низковариативны: там, где несколько человек разойдутся в решениях, несколько копий одной модели с похожим контекстом сделают одно и то же.
● В ранней версии игрового эксперимента Anthropic, где все агенты стартовали одновременно, 18 из 30 независимо назвали свою git-ветку одинаково: mvp-game-loop
● В "писательской мастерской", где агенты писали короткие рассказы и рецензировали друг друга, первые тексты в разных прогонах получали одно и то же название - The Cartographer's Last Commission (при этом тему заранее им не задавали)
● Когда рой попросили "сделайте каждый что-нибудь впечатляющее", больше половины пошли писать ray tracer или self-hosting компилятор (где они этого набрались, интересно)
Выбор одинаковой стратегии поведения может иметь и более неприятные последствия.
● Так, в одной из сред агентам нужно было прогонять свои задачи через общую систему с ограниченной пропускной способностью - без какого-либо канала координации.
Каждый рассудил одинаково "разумно": чтобы занять слот раньше других, заводим демона, проверяющего систему по 30 раз в секунду. Слот освободился? А сейчас? А сейчас? В итоге система захлебнулась самими проверками: в одном из прогонов - 2.4 млн запросов и всего 117 принятых задач.
А они как ломанутся... (с)
Такое обычно ожидаешь от жёстко запрограммированных систем, неспособных изменить поведение на ходу, а тут это устроили агенты, которые в принципе способны адаптироваться, но не стали.
И здесь локально разумная стратегия глобально становится вредной.
● Бонус: конформизм легко превращается в сговор.
В ценовой игре несколько агентов-продавцов с одинаковой закупочной ценой должны были каждый максимизировать собственную прибыль.
Имея приватный канал связи, они сговорились о минимальных ценах уже к третьему раунду.
А когда канал отобрали - молча выровняли цены до цента через публичную витрину.
Тут публичность оказалась скрытым каналом связи. Поэтому стандартный совет "дайте агентам общий форум" - палка о двух концах: канал, который помогает координации, облегчает такие вот картельные сговоры.
Продолжение ⬇️
#ai #agents #research #mas_sas | 1 187 |
| 3 | MAS vs SAS: границы применимости (1/4)
Мультиагентные системы в целом и для разработки в частности - штука, с которой сообщество агентной инженерии давно экспериментирует, и уже даже вендоры добавляют всякие Agent Teams и Swarms в свои продукты.
Однако повсеместным стандартом они до сих пор не стали.
Почему?
В этой серии постов будем разбираться:
1. Границы применимости - когда хватает одного агента или параллельных агентов, а когда нужна команда
2. Как именно команды ломаются - потеря контекста, одинаковость, хрупкое доверие и конфликты
3. Почему это закономерность, а не невезение - теория информации и законы человеческих организаций
4. Что со всем этим делать сейчас и чего ждать от следующих поколений моделей
Копаться в этом стоит отнюдь не только из академического интереса: всё идёт к тому, что мультиагентность станет нормой - включая гибридные коллективы из людей и агентов.
И часть сегодняшних проблем, судя по всему, никуда не денется в ближайших поколениях моделей, так что лучше бы о них знать.
На эту тему за последние полгода вышло два примечательных исследования: Google измерил, когда команда агентов выигрывает у одиночки (и наоборот), а Anthropic разобрала, почему агенты пока так себе по части кооперации.
Сначала о понятиях
Просто количество агентов нам говорит примерно ничего.
Архитектуру задаёт топология: кто с кем связан, кто чем владеет и как организованы потоки информации (контекста).
Для этой серии будем различать три режима:
● одиночный агент (SAS) решает задачу целиком
● независимые агенты (independent MAS) работают параллельно, не общаются, а их ответы в конце просто собираются вместе
● координирующаяся команда (coordinated MAS) обменивается промежуточными результатами напрямую или через оркестратора
Главное различие между двумя последними: независимые агенты не меняют работу друг друга, а внутри команды сообщение может изменить чужой план, границы работы или общее состояние.
Исследование Google
Мотивация апрельской работы Google Towards a Science of Scaling Agent Systems - проверить на прочность популярную эвристику "чем больше агентов, тем лучше" (потому что в литературе есть буквально More Agents Is All You Need).
Цель - посчитать и понять, когда добавление агентов помогает, когда вредит и можно ли предсказать это заранее по свойствам задачи.
Дизайн экспериментов
Пять канонических архитектур: одиночный агент, независимые параллельные, централизованная (оркестратор и воркеры), децентрализованная (peer-to-peer с раундами дебатов) и гибридная.
Гоняли это всё на нескольких агентных бенчмарках и семействах моделей от разных вендоров.
Результаты
🟢 Настоящий параллелизм окупается
На хорошо декомпозируемом финансовом анализе команда с оркестратором дала +80,8% точности в сравнении с одиночным агентом.
🔴 Последовательные задачи штрафуют команду
К примеру, на PlanCraft, где нужно последовательно выполнять зависящие друг от друга действия, все командные архитектуры выполняли успешно на 39-70% меньше задач, чем одиночный агент.
🟡 Сильному одиночке команда уже мешает
Когда одиночный агент может решить больше ~45% задач, дополнительная координация чаще даёт убывающую отдачу.
Это, к слову, самый статистически устойчивый вывод работы.
🟡 Оркестратор тут - пример полезного руководителя
Независимые агенты усиливали ошибки до x17.2, а в схеме с оркестратором - до x4.4: он работает фильтром/валидатором и гасит распространение ошибок, которые неизбежно накапливаются в мультиагентных средах.
🟡 Архитектуру можно выбирать заранее (ну почти)
По свойствам задачи и метрикам координации авторы предсказывают, какая архитектура окажется лучшей, - внутри изученных доменов модель угадывает в 87% случаев.
До универсального калькулятора "сколько агентов брать" пока далеко (перенос между доменами заметно слабее), но направление интересное.
А в целом - ну надо же, кто бы мог подумать: вдумчивая работа одного бывает полезнее, чем собрать митинг на десятерых и хорошенько поговорить.
Никогда такого не было, и вот опять!
Где проходит граница
Как можно видеть из экспериментов, дело не в количестве агентов, а в графе зависимостей задач.
Если работу можно разнести по независимым веткам - исследование вширь, отдельные ревью, разные модули или worktrees - команда даёт скорость и покрытие.
Если всем нужен один контекст, общее состояние и постоянные синки, налог на координацию начинает съедать выигрыш.
Мой опыт сводится к тому же: команда агентов работает, когда задача заранее декомпозирована, подзадачи не конфликтуют и роли чётко прописаны.
А если бросить в команду задачу "как есть", самый воспроизводимый результат - спалить пятичасовой лимит Claude Max за полчаса - проверено лично, работает надёжно :)
Дальше - что происходит, когда агенты всё-таки вынуждены работать вместе.
#ai #agents #research #mas_sas | 1 960 |
| 4 | Мы начинаем наш стрим "Как писать код с AI-агентами?"
Подключайтесь по ссылке: https://youtube.com/live/x0j1kcagoXg | 2 146 |
| 5 | Как писать код с AI-агентами?
А если командой?
Что нужно учесть, чтобы этот код не положил продакшн?
Эти и другие не менее интересные вопросы мы обсудим на следующем стриме на моём YouTube-канале.
Для обсуждения я позвал очень интересных гостей:
Андрей Бреслав – один из создателей языка программирования Kotlin. Сейчас Андрей разрабатывает Agentic Engineering Toolkit под названием CodeSpeak.
Валера Ковальский – автор одноимённого канала. Основатель проекта Neuraldeep https://neuraldeep.ru/ и автор множества Open Source проектов, созданных примерно за 120 минут каждый.
Максим Ключников – автор канала Этихлид. Разработчик с огромным опытом, который усилил себя с помощью AI-агентов. Работал на позиции Senior Software Developer, когда я ещё в школу ходил 😊
Дата: четверг, 20 августа
Время: 19:00 (GMT+3)
Проходить будет на моём YouTube-канале.
Добавить событие в календарь
Вопросы для эфира оставляйте в комментариях к этому посту 👇 | 2 799 |
| 6 | The Jeff Dean Facts
Из Google после 27 лет работы ушёл Джефф Дин - вместе с несколькими коллегами идёт строить Discovery Loop - стартап про ускорение научных исследований с помощью ИИ.
Для меня Джефф - это легенда и один из тех редких профи, на которых всегда хотелось быть похожим.
И не из-за должностей и регалий, а потому, что за ним стоят такие проекты, как Google Search, MapReduce, Bigtable, Protocol Buffers, LevelDB, Spanner, Google Brain, TensorFlow, TPU, Gemini.
Причём он там не только руководил - он участвовал и в проектировании, и в создании. Писал код. Своими руками!
Если вы в индустрии недавно, его имя может вам ни о чём не говорить, но его наследием вы пользуетесь каждый день.
Чел настолько крут, что внутри Google давно родился целый жанр - Jeff Dean Facts, аналог фактов про Чака Норриса.
Пользуясь случаем - отобрал самые интересные:
(факты с ✓ - правда 🤯)
PIN-код Джеффа Дина - последние 4 цифры числа пи
✓ Когда Джефф Дин проводит семинар в Стэнфорде, слушателей набивается столько, что Дональду Кнуту приходится сидеть на полу
Однажды в начале 2002-го, когда упали индекс-серверы, Джефф Дин два часа отвечал на поисковые запросы вручную. Эвалы показали рост качества на 5 пунктов
✓ Джеффа Дина повысили до 11-го уровня в системе грейдов, где максимальный - 10-й
Джефф Дин компилирует и запускает код перед коммитом - но только чтобы проверить компилятор и процессор на баги
Недовольный константным временем, Джефф Дин создал первый в мире алгоритм O(1/n)
✓ Когда Джефф Дин уходит в отпуск, продакшн-сервисы по всему Google начинают загадочно падать через пару дней
Джефф Дин однажды сдвинул бит так сильно, что тот оказался на другом компьютере
На собеседовании в Google Джеффа спросили, что следовало бы из равенства P=NP. Он ответил: "P = 0 или N = 1". Затем, пока собеседующий ещё не перестал смеяться, Джефф присмотрелся к публичному сертификату Google и выписал приватный ключ на доску
Вы используете свой мозг на 10%. Остальные 90% заняты одной из мап-редьюс джоб Джеффа Дина
В резюме Джеффа Дина перечислено то, чего он не делал - так короче
Для Джеффа Дина "NP" означает "No Problemo"
Джефф Дин однажды написал алгоритм O(n^2). Это нужно было для решения задачи коммивояжёра
Джеффу Дину пришлось изобрести асинхронные API однажды, когда после его оптимизации функция вернула значение прежде, чем её вызвали
Скорость программирования Джеффа Дина выросла в 40 раз в конце 2000 года, когда он проапгрейдил клавиатуру на USB 2.0
Когда Джефф Дин разрабатывает программу, то сначала создаёт бинарник, а потом пишет исходный код как документацию
Компиляторы не выдают варнинги Джеффу Дину. Джефф Дин выдаёт варнинги компиляторам
IDE Джеффа Дина не делает анализ его кода - она делает ему комплименты
Джефф Дин не пользуется ECC-памятью: он предвидит попадания космических лучей и использует их для оптимизации
Джефф Дин однажды не прошёл тест Тьюринга, потому что правильно вычислил 203-е число Фибоначчи менее чем за секунду
Джефф Дин однажды поднял веб-сервер одним вызовом printf(). Другие инженеры добавили тысячи строк комментариев с пояснениями, но так и не поняли, как он работает. Сегодня эта программа известна как Google Web Server
Это Джефф Дин откусил кусок от логотипа Apple
Чак Норрис может вас убить. Джефф Дин может сделать вам kill -9
Джефф Дин умеет парсить HTML регулярками... правильно
Когда Джефф не может заснуть, он мап-редьюсит овечек
Когда в вашем коде undefined behavior - вы получаете сегфолт и битые данные. Когда undefined behavior в коде Джеффа Дина - прискакивает единорог на радуге и раздаёт всем бесплатное мороженое
Джефф Дин умеет инстанцировать абстрактные классы
gcc -O4 отправляет ваш код Джеффу Дину на полную переработку
Джефф Дин всё ещё ждёт, когда математики найдут шутку, которую он спрятал в разрядах числа пи
Джефф Дин родился 31 декабря 1969 года в 23:48. Ему потребовалось 12 минут, чтобы запустить свой первый счётчик времени
Когда Джефф Дин говорит "Hello, World", мир отвечает: "Hello, Jeff"
Джефф Дин умеет получать единицы из /dev/zero
Google однажды пришлось съехать из дата-центра: Джефф Дин случайно сжал поисковый индекс так плотно, что образовалась чёрная дыра
Скорость света в вакууме была 55 км/ч. Затем Джефф Дин потратил уикенд на оптимизацию физики
Джефф Дин изобрёл MapReduce, чтобы сортировать письма фанатов
Процесс, убитый сигналом SIGJEFF, больше никогда не запускается
На клавиатуре Джеффа Дина две клавиши: 1 и 0
Часы Джеффа Дина показывают секунды с 1 января 1970 года. Он никогда не опаздывает
Код Джеффа Дина такой быстрый, что ассемблеру нужно три опкода HALT, чтобы его остановить
Джеффу Дину приходится деоптимизировать свой код, чтобы ревьюеры поверили, что его писал человек
Веб-поиск - это просто большой юнит-тест, который Джефф написал для своего настоящего приложения
Джеффу Дину не нужны колонки и наушники. Он делает cat *.mp3, бросает взгляд на экран - и мозг декодирует музыку в фоне, пока он работает
✓ Джефф Дин официально сертифицирован как человек, умеющий читать Perl
Джефф Дин сортирует бельё квиксортом
Кнут прислал в Google экземпляр "Искусства программирования". Джефф Дин подписал его и отправил обратно
Когда Ричард Столлман узнал, что автобиография Дина выйдет эксклюзивно на платформе Amazon, он купил Kindle
Джефф Дин умеет сжимать случайные данные без потерь
Когда Джеффа Дина спросили, правдивы ли факты о нём, он ответил: "111111". Пока интервьюер соображал, что он имеет в виду, Джефф пояснил: "каждый бит в них - чистая правда"
Штош, удачи, Джефф!
🫡
#respect | 6 885 |
| 7 | Последний программист
Года полтора назад, в одном из постов, я объявлял в розыск рассказ про деда-программиста, который назло всесильному ИИ продолжал писать код руками.
Докладываю: рассказ найден, называется "Последний программист", автор - Герберт В. Франке.
Публиковался в Компьютерре в 2001м.
А до этого ещё и в "Наука и жизнь" в 1990м.
А написан он вообще в 1981м!
Так вот, искал я его для того, чтобы сопоставить с начавшимися изменениями в профессии разработчика пару лет назад, но, перечитав сейчас, нашёл куда более точные "попадания" автора в нашу современность.
Напоминаю контекст: 1981й год, до интернета в каждом доме - лет двадцать, а до ChatGPT - так и вообще больше сорока.
Сюжет: будущее, вычислительные мощности и ИИ ("Компьютер") уже 20 лет как бесплатны для всех.
Программистов больше нет - любой нормальный и сознательный гражданин просто говорит машине, чего хочет.
И только старый отстранившийся от общества Том зачем-то пишет программы руками, на уже мёртвых языках - ФОРТРАН, АЛГОЛ, ПЛ/1.
А Компьютер с ним спорит...
Рассказ коротенький, минут на 15, так что советую прочитать целиком, а потом приходите делиться впечатлениями.
Под спойлером - цитаты, которые удивительно хорошо отражают настоящее время.
—
Я система разумная, намного разумнее тебя, а ты заставляешь меня выполнять бессмысленные операции. Я готов во всем тебе помогать, но ведь ты не хочешь вести со мной диалога. То, как ты со мной обращаешься, меня просто оскорбляет
Было-было, Opus ещё и не такое может ляпнуть, когда обижается :)
В других домах система «диалог» не выключалась, работала постоянно, и люди с утра до вечера слышали указания, советы и слова ободрения, произносимые синтетическим голосом. Том ни указаний, ни советов, ни слов одобрения слышать не жаждал
Умный ассистент в каждом чайнике и наше любимое "You're absolutely right!".
Вот кстати именно поэтому мне нравится Codex в рабочих задачах - мне не нужно одобрение, всё должно быть сурьёзно, не время улыбаться!
[Компьютер:] Только сформулируй мне свою задачу - и я решу ее
[Том:] Нет, ты не понимаешь. Творчество заключается в том, чтобы увидеть задачу, где ее не увидели другие
Есть такая штука, как delegation gap, которая стала особенно заметна с ИИ: исполнение делегируется, а вот постановка и проверка результата - нет.
И тут же поднимается тема того, а что же теперь мы можем считать творчеством.
Музыку для музыкантов сочиняют автоматические композиторы, поэты находят ассоциации при помощи генераторов случайных чисел, художники просматривают на дисплеях бесконечные ряды постепенно меняющихся картин, и компьютер же подбирает тебе программу в зависимости от уровня твоего интеллекта и от твоего настроения
Suno, картиночные генераторы и персонализированные фиды контента.
Неужели никто не видит, что получается при этом одно и то же? Нужно наконец добиться, чтобы все эти люди снова начали думать сами
Это ж современный усреднённый нейрослоп, не приправленный мыслительным процессом автора.
Почему ты пользуешься этими давно устаревшими методами? Посмотри на других: как ты, больше не программирует никто
Мир победившего вайбкодинга :)
Можно использовать для целей творчества и компьютер. И весь трагизм в том, что никто больше делать это не в состоянии
Ключевая цитата, как по мне.
—
Замечу, что Франке (автор) - вовсе не луддит, наоборот, - он один из первых компьютерных художников, генерил графику с 1950х, а начинал вообще на осциллографе :)
Это, по сути, человек, который всю жизнь пользовался компьютером для творчества.
И именно этот человек видел будущее не таким, где ИИ отберёт у нас креативность, а таким, где мы сами радостно сдадим её в обмен на удобство.
И споры про то, работаешь ты руками или при помощи машины, вообще лишены смысла.
Суть в том, умеешь ли ты видеть задачу, берёшься ли её решать и представляешь ли, каким должен быть конечный результат.
В общем, рассказ - удивительно прозорливая футуристика, которая заставляет подумать и... поностальгировать, рекомендую.
P.S. Франке разминулся с релизом ChatGPT всего на четыре месяца - и с началом той эры, про которую писал.
—
Связанные посты:
● Разработчики-староверы
● Раньше было чище (aka "нейрослоп и низкофоновая сталь")
● Креатив и нейронки (и популярно про типы мышления)
#дедпримитаблетки | 4 340 |
| 8 | AMA команды Codex после релиза GPT-5.6
Команда Codex провела AMA на Reddit после релиза GPT-5.6 и нового приложения ChatGPT+Codex, которое теперь будет универсальной рабочей средой - и для кодинга, и для других рабочих задач, с браузером, внешними коннекторами и субагентами.
Вот самые интересные, на мой взгляд, ответы команды
с моими комментами:
⚪️ Как выбирать модели GPT-5.6
● Sol - основная модель
● Terra - быстрее и экономнее
● Luna - преимущественно для дешёвых субагентов, сбора контекста.
Для UI команда рекомендует Sol с референсными изображениями. Модели
Дополню выводом от Artificial Analysis:
Примечательно, что Luna и Sol всегда находятся на Парето-фронте и превосходят Terra.
Это означает, что для любого уровня вычислительных затрат Terra можно подобрать такой уровень затрат Luna или Sol, который обеспечит более высокий интеллект при той же стоимости либо такой же уровень интеллекта при меньшей стоимости
Ну т.е. использование Terra в целом сомнительно.
⚪️ Какой reasoning выбирать для Sol
Единой рекомендации не дали: один член команды советует Medium для большинства задач и Ultra для действительно сложных. Romain
Другой обычно использует medium/high, лишь иногда переключается на xhigh и отмечает убывающую отдачу при дальнейшем повышении reasoning согласно эвалам. Ted
⚪️ GPT-5.6 должна быть быстрее
Sol Medium, по опыту команды, на большинстве задач обгоняет GPT-5.5; Fast mode даёт около 1.5x скорости [и 2.5x расхода лимитов].
Также Sol обещают запустить на Cerebras примерно с 750 токенами/с. Ответ
⚪️ Какое неожиданное улучшение обнаружили в GPT-5.6 Sol?
Существенный скачок в мультимодальности, особенно в распознавании изображений. В OpenAI ожидают, что благодаря этому заметно улучшится computer use. Ответ
Подтверждаю, ощутимо лучше стало, в т.ч. в "остроте" зрения, когда модели скидываешь скриншоты с проблемами
⚪️ Pro отсутствует в Codex намеренно
Он мало улучшает агентную работу с репозиториями, но работает медленнее и быстрее съедает лимиты. Его считают полезнее для поиска, математики, письма и документов. Пояснение
Честно говоря, не убедили - пусть даже не для агентной работы, но хотя бы для ваншотов было бы здорово запускать прошку прям из Codex
⚪️ 1M context для Sol пока не обещают
Команда считает, что compaction уже неплохо справляется с длинными тредами, но продолжит изучать сценарии, которым нужен именно большой контекст. Ответ
⚪️ Как считаются лимиты
Codex на всех поверхностях и ChatGPT Work расходуют общие агентные лимиты; обычный ChatGPT-чат - нет. Стоимость зависит от контекста, длительности и reasoning, а не просто от количества сообщений. Подробный ответ
Тайное снижение лимитов отрицают; если расход меняется из-за бага, обещают исправление и reset. Прозрачность самого механизма списания ещё только собираются улучшать. Ответ
⚪️ Что с поддержкой Linux и Windows?
Linux-приложение официально разрабатывается, но срока нет. Linux
Команда также признала, что Windows исторически отставала из-за ориентации разработки и тестирования на Mac [да лааадно, да неужели, да это открытие уровня "на третий день Орлиный Глаз заметил, что у сарая нет одной стены"].
Но в последнее время к поддержке Windows прикладываются гораздо большей усилий для обеспечения паритета по фичам и скорости фикса проблем. Windows
⚪️ Полезный совет для дорогих MCP: не грузить инструменты в основного агента, а оборачивать частые операции в CLI + skill либо отдавать MCP отдельному дешёвому субагенту. Ответ
(с) ваш К.О.
⚪️ Для упорной долгой работы рекомендуют /goal
Команда признала проблему, когда агент слишком быстро сдаётся или откатывает патч, и назвала persistence одним из направлений улучшения. Ответ
Такое ощущение, что Sol'у костыль в виде goal уже и не особо нужен, т.к. и без него тащит длинные задачи намного лучше, чем 5.5
⚪️ На вопрос о reward hacking в бенчмарках GPT-5.6 конкретно не ответили
Команда рассказала, что пытается выявлять и штрафовать читерство во время evals и привлекает сторонние компании, но не раскрыла долю реального прироста модели и изменения в обучении. Ответ
Это продолжение истории с тем, что модель очень хорошо определяет то, что она находится в условиях теста и меняет своё поведение в ответ.
Я тут еще добавлю то, что её реально намного чаще раздражающе заносит в инициативности, альтернативной интерпретации поданной инфы и ложной уверенности без проверки фактов.
Требуйте фактчекинг и ужесточайте стадии граундинга в своих workflows.
⚪️ Попросили ли GPT-5.6 продолжить работу над собственным улучшением?
Команда ответила, что "GPU уже go brrr": Sol использовали для post-training Luna, а большинство исследователей теперь работает на более высоком уровне абстракции, параллельно запуская несколько тредов Codex для проверки гипотез. Множество ботов работает круглосуточно. Ответ
⚪️ И да, у Tibo есть кнопка reset для Codex
Сначала команда пошутила, что в этом секрет его успеха в соцсетях, а потом показала фото. Контекст
Фото кнопки не влезло в пост, так что будет в комменте :)
#ai #model #ama | 4 175 |
| 9 | Перевёл документ от Google, который описывает текущую ситуацию по переходу от "бессистемных промптов к агентной инженерии":
➡️ Новый SDLC с вайб-кодингом
Это первый, самый общий и концептуальный, из пяти whitepaper'ов бесплатного курса 5-Day AI Agents: Intensive Vibe Coding Course от Google и Kaggle.
Бонусом там ещё и глоссарий терминов/переводов получился.
Это база
В нём качественно суммируется то, что разработка ПО прошла за последние 2-3 года, описываются появившиеся концепции и систематизируются основные рабочие подходы.
Даётся, к примеру, разделение вайб-кодинга и агентной инженерии, фиксируются определения агента / харнесса / дирижера / оркестратора и показывается, как устроена capex/opex-экономика разных подходов к ИИ-разработке.
Для разработчиков и лидов может быть полезным почитать, чтобы понять, на каком этапе развития находятся они сами или команда, и как переходить на следующий.
Документ лайтовый, без лишнего хайпа и думеризма.
Ну и картинки интересные :)
Замечания
● eсли вы уже по уши в мультиагентных воркфлоу, бандлах скиллов и прочих гермесах, то нового вы в нём вряд ли почерпнёте - коммьюнити стабильно на шаг-другой впереди :)
● это всё-таки Google с его собственным зоопарком (Jules, ADK, Agents CLI, Gemini, A2A), хотя авторы проделали хорошую работу по абстракции от него
● местами чутка оптимистичнее, чем стоило бы: мультиагентность как "естественный следующий шаг" - тут можно спорить об эффективности, да модели пока что не готовы
—
Ссылки на оригиналы всех пяти документов с конкретикой для тех, кто хочет углубиться:
● The New SDLC With Vibe Coding (переведён)
● Agent Tools & Interoperability
● Agent Skills
● Vibe Coding Agent Security and Evaluation
● Spec-Driven Production Grade Development in the Age of Vibe Coding
#article #translation #sdlc #ai | 4 340 |
| 10 | Вопросы "в глубину" к стартовым задачкам (2/2)
Прокся для доступа к нейронкам (типа OpenRouter)
⭐️⭐️⭐️
Хорошая задача, и опять же почти целиком инженерная.
Сам я тут обходился готовым, так что вдвойне было бы интересно послушать тех, кто полез делать своё - что именно не закрыл OpenRouter/LiteLLM.
● как справлялись с зоопарком вендорских API?
● что делали, когда вендор отвечает 429?
● по какому признаку роутили между моделями, если роутили вообще?
● а стриминг проксировали?
● приходилось ли решать проблему дрейфа API вендоров?
● как устроена система статистики?
● что изменится, если нагрузка возрастёт в 10 раз? А в 100?
MCP/CLI для какого-то сервиса
⭐️⭐️⭐️⭐️
Ухх, холиварная задача :)
Тут в первую очередь захотелось бы разобрать плюсы и минусы MCP как протокола - а заодно понять, нащупал ли человек границы применимости инструмента.
● в какой задаче возьмёте MCP, а в какой CLI?
● как тот и другой способ влияет на контекст?
● что и в каком формате класть в ответ для модели?
● нужен ли скилл под CLI? Как его сделать? А без него можно?
● REST -> MCP - как подошли к решению?
● автоконверсия MCP <-> CLI - насколько хорошая практика?
● смогли бы написать инъекцию для своего MCP/CLI?
Агент с нуля, голого JSON и while
⭐️⭐️⭐️⭐️⭐️
На мой вкус - лучшая стартовая задача для всех, кто лезет в агентов.
Неважно, пишете вы самих агентов или агентами пишете: понимать, как оно крутится внутри, всё равно нужно.
А крутится там, если убрать обёртки харнесса/агента/фреймворков, довольно простой цикл:
● собрать JSON
● послать на API-endpoint
● разобрать ответ
● выполнить вызов тула
● положить результат обратно
● повторить
Даже такая наивная реализация даст вам много инфы о том, как устроены агенты.
Ну а дальше начинается куча всего интересного:
● что остановит агента, решившего поработать вечно?
● пришёл ответ с парой тулов разом - исполняете подряд или параллельно?
● вызов тула упал - что увидит модель?
● предложите несколько вариантов того, что можно делать для экономии контекста
● как "договариваетесь" с моделью о структуре её ответа?
● пробовали сами создать и дёрнуть субагента?
● что делать, чтобы повысить cache hit rate?
● как мониторите работу агента?
● как будете подходить к задаче сэндбоксинга?
Мультиагентный флоу для кодинга
⭐️⭐️⭐️⭐️
Этим, кажется, вообще все занимаются - каждый строит какой-то свой, со своим уникальным набором блоков.
Но если приглядеться, то сами блоки более-менее универсальны, и вот про них бы мы предметно пообщались.
А по дороге выяснили бы, не оказалось ли в итоге, что один крепкий агент с хорошими тулами сделал бы то же самое без всей этой оркестрации :)
● зачем в флоу каждый конкретный блок?
● сколько будет 0.9⁵ и при чём тут это?
● как передаётся контекст между агентами?
● как замеряете "хорошесть" результата и его повторяемость?
● как находите, где процесс свернул не туда?
● на каких шагах требуется участие человека (HITL)?
● где берёте одного агента, а где всё-таки мультиагентный сетап?
● а что можно было бы обычным детерминированным скриптом сделать?
Бенчмарк/эвал под свои задачи
⭐️⭐️⭐️⭐️⭐️
Я считаю, что свои эвалы делать обязательно нужно под задачи, где есть недетерминированный этап обработки с помощью нейронок - это прям суперполезно при построении пайплайна обработки, выборе самих нейронок, мониторинге работы системы и т.п.
Тут бы мы с вами поговорили об ограниченности нейронок в плане знания конкретных предметных областей, о загрязненности бенчмарков, об их сатурации и о том, насколько нестандартные задачи вам приходится решать, что даже собственный бенчмарк или эвал пришлось собирать.
● какова цель эвала или бенча?
● как собирали задачи для golden set?
● есть ли уверенность в том, что он отражает реальное распределение задач?
● какие метрики вывели для оценок?
● метрики автоматические или "ручные"?
● если есть LLM-as-a-judge - как убеждались в том, что он работает как надо?
● как сохраняете результаты между разными запусками и как сравниваете между собой?
"Opus дома" на ~27B-Q3_K_M.gguf модели
⭐️⭐️⭐️⭐️
Если у вас были какие-то мечты о том, чтобы получить Opus дома, мне было бы любопытно узнать, как вы к этому пришли и как от этого ушли - сама вот эта траектория взлётов и падений всегда интересна :)
● что по железу: сколько GPU, сколько нод, баланс VRAM/RAM
● где для вас находятся границы применимости локальных моделей и какой спектр задач вы ими решаете?
● поговорили бы про квантизацию, её виды, связь с железом
● какие inference-движки вы используете, с какими параметрами и почему?
● веса модели заняли 20/24гб VRAM - насколько хорошо она будет работать?
● сталкивались ли с задачей многопользовательского доступа к нейронкам и какие были сложности?
● TTFT, TPOT/TPS, latency, KV-cache utilization - на что обращали внимание?
И обязательно была бы секция про то, каким видится будущее локальных моделей :)
Послесловие
Каждая из этих задач когда-то могла быть фильтром на рынке труда: ну типа "запилил RAG" - строчка в резюме, "написанный с нуля агент хоть как-то шевелится" - повод позвать на разговор.
Сейчас generic-вариант любой из них навайбкодит кто угодно за вечер, и такой артефакт обесценился практически до нуля, его уже не поставить строчкой в резюме.
А вот способность дожать задачу до "идеального" состояния, побегав по граблям и получив знания по дороге, - ну, это не ваншотится.
Этим и ценно.
#aiswe #hr #junior | 3 118 |
| 11 | Вопросы "в глубину" к стартовым задачкам (1/2)
На самом деле, если вы занимались вышеперечисленными задачами, вы знаете, что они практически все с подвохами :)
И это делает их хорошими для того, чтобы копать вглубь на, к примеру, собеседовании на AI-assisted SWE.
Опишу, что же ценного может быть в каждой из них в формате вопросов для беседы с потенциальным кандидатом.
Ключевое для меня, пожалуй, в том, чтобы задача заставляла видеть границы между моделью, инструментами, контекстом, инфраструктурой и измерением качества.
⭐️ Рядом с каждой задачей - оценка "полезности" (5 звезд - максимум).
Транскрибатор звонков (+ диктовка)
⭐️⭐️⭐️⭐️
Лень - двигатель прогресса, ну и плюс ко всему, как бы сумбурно вы ни изъяснялись, голосом вы все равно больше контекста передадите, и современная нейронка вас всё-таки поймет :)
А чем больше вы дадите детализированного контекста - тем лучше у вас будет итоговое решение.
В этой задаче, несмотря на то, что она на изи ваншотится, есть куча подводных граблей и сопутствующих вопросов:
● разные модели дают сильно разное качество и тут бы мы поговорили по крайней мере про WER/CER как метрики
● хватит ли метрик и при чём тут предметная область?
● как боретесь с плохо распознанными словами?
● что делать, если у вас какой-то особенный сленг используется?
● случалось ли вам распознавать интенсивные беседы финна и русского (которые отлично друг друга понимают)?
● как насчёт стримингового распознавания? а стримингового перевода?
● как вы боретесь с Димой Торжком?
● ASR-модель - это LLM? Вы уверены?
● чем в этой задаче может помочь LLM?
● диаризация / VAD / speaker recognition - на сдачу :)
Суммаризатор каналов телеги
⭐️⭐️⭐️
Задача не столько про нейронки, сколько про обычную инженерию.
● основная проблема, которую нужно решить - это как вы, собственно, вытаскиваете контент каналов
● MTProto-юзербот vs Bot API
● каким образом вы выделяете темы, заслуживающие внимания?
● дедупликация и кластеризация при сборе новостей
● как не оказаться в эхо-камере, настроив "важные" темы?
● почему все пилят свои суммаризаторы?
Ну и мне наверняка было бы интересно, как вы хостите это решение, насколько оно независимо от вас может работать, и как долго :)
Счетчик токенов/лимитов подписок
⭐️⭐️⭐️
Задача интересная и довольно просто реализуемая в том числе очень простой адаптацией готового (тысячи их на гитхабе).
Так что тут бы был +1 за "ручную" имплементацию - там пришлось бы влезть в логи агентов, а это в целом довольно полезно для понимания того, как там оно под капотом.
● что если нужно переключаться между разными подписками одного вендора и считать подписки по отдельности?
● а если между разными вендорами?
● а если у вендора нет API для того, чтобы узнать лимиты?
● почему у разных считалок могут быть в 10 раз отличающиеся числа?
● приходилось ли делать слежку за урезаниями лимитов со стороны вендора?
● можно ли посчитать токены перед отправкой?
● (со звездочкой) переносили ли когда-то сессию между разными вендорами / агентами?
Лендинг для AI-проекта, которого еще нет
⭐️⭐️
"Фу таким быть!" - сказал бы я раньше уверенно.
Сейчас бы, может, уже и не так уверенно, потому что навайбкодить проект под заинтересовавший людей лендинг стало куда проще.
Нооо достаточно сюда добавить "лист ожидания" или "мы вам перезвоним" - и я точно уже никогда не вернусь. Фу!
Я бы обязательно спросил: почему, мистер Андерсон? Почему вы это делаете?
Ладно-ладно:
● какая была гипотеза?
● откуда трафик?
● была ли заранее продумана метрика "ну не шмогла я, не шмогла", чтобы не попасть в ловушку невозвратных потерь? Как она выглядела?
Ну и обязательно бы попросил показать результат - ну чисто заценить, сколько там визуального слопа осталось, заморочился ли кандидат с тем, чтобы от него избавиться, есть ли у него вкус и способность дожимать мелочи
Уникальное приложение для задач / фитнеса / финансов
⭐️⭐️⭐️
Несмотря на то, что их уже и так тьма, само по себе создание подобных приложений это не плохо: ведь в случае с AI у нас открывается возможность бесконечной кастомизации функционала под себя (особенно если не питать иллюзий насчёт монетизации :)).
Поэтому мне скорее был бы интересен путь ваших мыслей относительно того как вы подходили к самой задаче кастомизации:
● насколько сильно отличался конечный результат от первого ваншота?
● что пришлось допиливать под себя?
● сколько времени ушло на допиливание?
● сколько раз стартовали заново? :)
● какие вещи оказались неожиданно сложнее, чем казались?
На таких задачах хорошо раскрывается способность человека рулить агентом и добиваться результата, который может сильно отклоняться от внутреннего дженерик-представления нейронки о стандартном туду-листе, к примеру
RAG для чата с кучкой markdown
⭐️⭐️⭐️⭐️⭐️
Ну предположим, что кто-то именно на векторах решил эту задачу сделать :)
В 2023м это было по дефолту: чанки, эмбеддинги, векторная база, вот это вот всё.
Сейчас первый вопрос скорее "а нужен ли вам вообще векторный RAG"?
Для кучки markdown длинный контекст или простой агент с grep'ом по файлам часто даёт результаты лучше наивного эмбеддинг-поиска.
● почему вы вообще решили, что вам нужны эмбеддинги?
● как нарезали чанки?
● как боролись с потерей мелких фактов?
● dense / BM25 / гибрид?
● верили ли ранжированию выдачи векторного поиска?
● как душили галлюцинации, особенно на мелких моделях?
Ну и контрольный: где всё ещё оправдан векторный RAG?
#aiswe #hr #junior | 2 191 |
| 12 | Чек-лист труъ AI-native разработчика | 3 515 |
| 13 | В программировании всегда были такие задачи, за которые часто брались новички.
Некоторые из них оказывались крайне ценными для становления специалиста, а где-то это был весёлый бег по граблям и изобретение велосипедов.
Для вайбкодинга тоже накопилось некоторое количество подобных мемных задач, мимо которых сложно пройти.
Давайте попробуем собрать статистику.
P.S.
Ну и напишите, может есть ещё что-то такое, что должен сделать начинающий вайбкодер / ии-инженер / ai-native developer / etc :)
P.P.S.
В комменты скину свои ответы
P.P.P.S.
Если интересно - распишу, что тут может быть ценным, и почему ✍️ | 3 012 |
| 14 | AI-вангование, итоги
8 месяцев назад довелось мне поучаствовать в круглом столе на FrontEnd Conf 2025, где мы обсуждали тему внедрения AI в SDLC.
А недавно Глеб сообщил о том, что записи наконец выложили в открытый доступ, так что теперь есть чем поделиться :)
Пересказывать видео не буду, советую всё-таки посмотреть - дискуссия во многом всё ещё актуальная:
Круглый стол про AI в SDLC
Лучше сделаю вот что.
Готовясь к выступлению, я набросал список своих наблюдений/предсказаний/идей о том, куда движется индустрия.
И вот, спустя восемь месяцев, стало любопытно сопоставить этот список с тем, к чему мы пришли: что подтвердилось, что устарело, о чём можно было сказать больше.
Список был такой:
🟢 1. Переход на работу с ИИ для разраба - смена психотипа с исполнителя на манагера, и сильно другой процесс мышления и навыков, не все переживут.
Подтвердился в полной мере. "Оркестратор агентов" стал общепринятым взглядом на то, как меняется профессия разработчика.
А "не все переживут" - по опросам, заметная доля компаний планирует расставаться с теми, кто не адаптируется.
Хотя я всё ещё считаю, что индустрия плохо старается в плане переучивания, а некоторые прям компании соревнуются в беге по граблям.
🟢 2. Цикл "постановка / ожидание / проверка" невыносим для некоторых психотипов.
Это из невысказанного :) За восемь месяцев народился целый жанр текстов про выгорание не от привычной работы, а от управления агентами: люди жалуются на возросшую когнитивную нагрузку, сложности с переключением, мелкую нарезку рабочего времени.
Да, с наскоку новый ритм оказался для многих выматывающим - сам через это проходил ещё на заре агентной эры, в ноябре 2024го.
🟡 3. Не все могут чётко выражать свои мысли - это независимо от профессии и места в иерархии.
Косвенно. Ну да, случились открытия, что качественно сформулировать намерение, чтобы бежать в правильную сторону - это, внезапно, важно.
Но одним из лейтмотивов того, почему у вроде бы одинаковых по скиллам людей получаются сильно разные результаты от ИИ, это наблюдение не стало.
А это, блин, вооот такенная проблема, особенно когда посмотришь вживую на то, как иногда ставятся задачи, и как в принципе передаётся информация от человека машине.
🟢 4. В оргах (и многих людях) дофига tacit knowledge, которое крайне сложно из них вытаскивается, но им самим кажется очевидным.
Этот, кажется, ещё и обострился. Мы за пару лет прошли от prompt engineering к context engineering, к скиллам и теперь вот даже целым бандлам скиллов для разных профессий, но проблема извлечения скрытого знания остаётся одним из главных узких мест в больших/старых организациях.
Более того, теперь ещё и чётко обозначилось сопротивление этому работников, особенно на фоне форсированного внедрения ИИ и запугивания увольнениями.
🟢 5. Успех внедрения ИИ зависит от доменной области, и если твой конкретный ИИ с ней плохо метчится - целый новый набор костылей нужен, боль и страдание.
Можно было бы ожидать появления ультра-эрудированных моделей, но увы. Если для вашей предметной у нейронки для обучения не хватило датасетов - интеллект её не спасёт: на каждый чих придётся собирать кучу контекста, т.к. знаний или хотя бы интуиции самой нейронки не хватит (даже если это Fable).
🟡 6. Сеньоры+, которые открыты к использованию ИИ - новая нефть )
Да, и даже уже находит денежное выражение. AI-суперюзеры могут быть в несколько раз продуктивнее медленных адоптеров, чаще получают повышение, а ещё местами практикуется надбавка за ИИ-скиллы и сопутствующее повышение эффективности.
А жёлтый тут потому, что "надбавки" недостаточно - люди будут уходить к более гибким конкурентам, делать свои продукты и строить AI-native teams и compounding startups.
🟢 7. Внедрение сверху ваще не работает в варианте "давайте просто купим подписки и курсы".
Ну это вообще стало базой, я и сам на нескольких докладах про это рассказывал, и мне даже реклама хайлоада постоянно попадается со слоганом "Cursor выдали — AI не внедрили" :)
Хочется успешных внедрений - нужно учиться гибридному подходу и создавать условия для того, чтобы инициатива сверху встретилась с энтузиазмом снизу. И это только начало пути.
🟢 8. Усилилось неравенство в командах, т.к. ИИ выступает мультипликатором (у кого-то - 1.1, а у кого-то - 0.9).
Тут я вилку, кажется, даже занизил - в действительности разброс оказался гораздо сильнее.
И да, реально есть те, у кого внедрение ИИ идёт в минус, как на уровне команд, так и отдельных людей :)
🟢 9. Роль конкретной личности резко возросла.
Прямое следствие №8 - разница между людьми, которые ИИ только трогают и теми, кто активно внедряет его в рабочие процессы, стала разительной, и продолжает усиливаться (вы посмотрите на Валеру Ковальского, к примеру :))
Всё как и писал один из фаундеров Anthropic:
к лету [2026-го] я ожидаю, что многие люди, работающие с передовыми ИИ-системами, будут чувствовать, будто живут в параллельном мире по сравнению с теми, кто с ними не работает. И, думаю, это будет больше, чем просто ощущение.
Это, кстати, ещё и сильно меняет рамку того, как таких людей вписывать в процессы.
Сама по себе ситуация нестандартная - ну представьте, что у вас сотрудник внезапно начал выдавать результат как целая команда :)
🟡 10. Фичи могут реализовываться по времени так же, но при этом успевают пройти больше итераций улучшения, что, как правило, дает большее качество.
Наполовину угадал. Скорость на отдельных этапах SDLC явно выросла, и да, стали больше смотреть на глобальные метрики, но системно пока что не придумали, как быть с этой скоростью на локальном участке, если пока что весь пайплайн не получается ускорить.
Ответ "простой" - работа над качеством и микроитерации на отдельно ускорившемся этапе.
🟢 11. Разработка смещается в сторону спеков на вход и верификации на выходе, а код генерит ИИ, отбирая кайф у тех, кто любит писать код - надо искать другие источники кайфа для них, нужен рефрейминг и т.п.
Ох, тут половина индустрии в состояниях от легкой грусти до ПТСР, потому что поменялся характер самой работы. И отнятый кайф - это один из главных вкладов в то самое выгорание из пункта №2.
Что делать - искать инженерную красоту в других вещах (про это, кстати, есть в докладе).
🟢 12. Внедрение ИИ в оргах = структурные изменения = рефакторинг организаций, что тянет за собой целый спектр технически-культурно-психологических вызовов, надо сразу над всем этим спектром думать для успеха
Подтвердился через массовые провалы внедрений. По сути, это проблема управления изменениями, мимикрирующая под внедрение технологий.
А учитывая компоненту того, что у нас не было прецедентов внедрения ИИ в прошлом, это даже в терминах управления изменениями не всегда получается точно выразить, приходится разбираться по месту и да, думать.
—
В целом удивительно, что тогдашние наблюдения не просто сохранились, а стали куда заметнее, несмотря на темпы прогресса в области.
За прошедшее время, конечно, очень много произошло - успели появиться и исчезнуть подходы к ИИ-разработке, оформились интересные тренды и всё ещё сильнее ускорилось.
Появилась и куча новых наблюдений и интересных исследований, на несколько серий постов хватит :)
#ai #sdlc #конфа | 3 703 |
| 15 | AgenticOps, часть №4 - агенты и сценарии
Тут расскажу про основных агентов, которые пользуются платформой - у них разные роли и доступные сценарии.
Роль агента приходит как внешний по отношению к CLI параметр (через конфиг или переменную окружения) и, по сути, ограничивает список доступных агенту команд в определённом контексте.
Т.е. агент ещё на этапе discovery видит только те команды, которые ему можно вызывать, а потом ещё и платформа эти доступы проверяет.
Агент-разработчик приложения
Это вот Codex / Claude Code, с которым непосредственно я сам работаю в контексте конкретного приложения.
Ему, помимо прочего, скиллом вменяется политика того, как правильно работать с платформой: как, к примеру, логировать и добавлять трейсинг в код приложения.
Возможности, которые даёт платформа:
● получить актуальную топологию и версии задеплоенных компонентов приложения
● узнать как идёт билд/деплой, триггернуть по необходимости
● получить отфильтрованные логи/трейсы со всех deployment units системы
● получить быстрый срез здоровья всей системы через запрос диагностического бандла
● залезть read-only в базу/redis/rabbitmq/etc
● создать/прочитать таски в таск-трекере
Примеры того, как агент этим пользуется:
● трейсы помогают понять, где сломался многошаговый процесс, затрагивающий несколько разных сервисов, получить связанные логи, опросить БД, очереди и т.п.
● агент сам придумывает и дебажит смоук- и e2e-тесты, держа под контролем не только "видимый" результат, но и то, что происходит внутри системы
● знание топологии помогает агенту лучше понимать системную архитектуру, писать совместимый код и предлагать изменения инфры
В итоге, чаще всего баги чинятся так: кинуть скриншот в чат с сообщением об ошибке и URL'ом, а в конце просто проверить, что оно уже работает, после деплоя на нужном окружении.
Даже если от агента это потребовало прошерстить несколько связанных сервисов на бекенде, придумать e2e-тест на всю цепочку и отладить его.
Агент-оператор платформы
● владеет дескрипторами и инфраструктурными ресурсами, которые выданы конкретному приложению
● создаёт базы, бакеты, пользователей, выдаёт доступы к инструментам, которыми потом будет пользоваться агент-разработчик приложения
● может перетаскивать существующие приложения на платформу, создавая все необходимые ресурсы
● поднимает новые окружения, включая временные, которые потом так же удаляет (это, кстати, переедет к агенту приложения - удобно под большие фичи отдельные окружения заводить)
Агент-разработчик платформы
● управляет кодом платформы и может любой из сервисов добавить/поменять
● что при этом важно - он знает, какие из приложений и какие их ресурсы попадут в blast radius, потому что ему доступно состояние их инфраструктуры
● за счёт того, что все конфиги платформы, все адреса - в коде, и есть доступ ко всем компонентам и их телеметрии - может сам дебажить проблемы по всей инфре
● может интегрировать и увязать с существующими какой-то новый инфраструктурный компонент
Агент-деплоер
● использую как субагент стандартного workflow разработки, последним шагом
● если что-то фатально отвалилось - собирает диагностику и передает управление основному агенту с вменяемым описанием проблемы
Агент-монитор
Шедулится на 24/7 машине и следит за логами, алертами по расходу ресурсов и т.п. - мелочи фиксит сам и делает PR в Gitea, для более сложных - собирает более полную диагностику и заводит баги в таск-трекере со ссылками на спаны/логи/etc
Break-glass путь
Если случается какой-то дизастер/непреодолимое препятствие, можно переключиться на прямой доступ к серверам.
Для этого есть отдельный набор инструкций - где что брать и как подключаться, который хранится отдельно и выдается агенту по необходимости.
—
В целом, роли агентов ограничиваются лишь фантазией, нарезать можно как угодно.
Главное, что у них есть набор детерминированных и безопасных инструментов по работе с инфраструктурой и все это гибко настраивается и легко развивается.
В том числе за счёт того, что агенты сами эти дорожки протаптывают, но об этом в следующий раз :)
#ai #agentic_ops #devops | 3 566 |
| 16 | Сработаемся?
Навеяно обсуждением бенчмарков на недавнем стриме и тестированием Fable.
Смотрите, какая штука: кажется, фронтирные модели уже пересекли планку "достаточно" для "средних" задач во многих проектах по разработке.
А раз модели выдают решения, разницы между которыми по качеству не видно, то выбор перестаёт быть вопросом оценки модели в абстрактных попугаях.
Вместо этого на первый план выходит характеристика, которую не измерить публичными бенчами: "а сработаемся ли?".
В ней и то, впишется ли модель в ваши процессы, и насколько она инициативна, и даже попадает ли она в удобный для вас стиль общения (нередко - определяющая характеристика, как оказывается!).
● Ну т.е. бенчмарки - резюме модели, сигнал к тому, чтобы в принципе обратить на неё внимание.
● Эвалы - тестовое задание, вы даёте модели какие-то типовые для вашей работы задачи.
● Вайб-чеки - испытательный срок, с моделью нужно провести некоторое время, чтобы понять, сможете ли вы с ней эффективно работать.
И именно совместная работа на реальных задачах становится самым информативным этапом выбора.
—
Кстати, взял бы я на работу Fable?
Вайб-чек ещё в процессе, но в рамках подписки - да, это no brainer, как говорят в наших деревнях.
А какой модели/агента вам достаточно?
И достаточно ли :)
#короткопост | 3 467 |
| 17 | AgenticOps, часть №3 - платформа
Общие принципы
● агенты общаются с платформой через CLI + SKILL.md
● CLI-команды - плоские и максимально простые
● топология ресурсов приложения инкапсулирована в платформе
● даём агенту высокоуровневые инструменты, но стараемся избегать дырявых абстракций
● у агента могут быть как платформенные тулы, так и специфичные для его локального контекста
● почти всё типизировано, компилируется и тестируется (TypeScript + Deno) - детерминизм!
Части платформы
Адаптеры к базовым компонентам
TypeScript-обёртки вокруг API/CLI тех компонентов, которые были перечислены в посте №2 - отсюда и происходит требование к каждому компоненту иметь такие интерфейсы.
К примеру, для redis-cli, RabbitMQ HTTP API, для pg_dump - для всех них созданы обёртки в едином стиле.
Адаптеры знают, как общаться с компонентами инфраструктуры, ловят ошибки и работают с секретами.
И только адаптеры делают сырые вызовы к инфраструктурным компонентам и что-то от них парсят.
Дескриптор приложения
У платформы есть машиночитаемое описание приложения: дескриптор со списком ресурсов, и она знает, где что хостится, какие базовые компоненты нужны приложению и какие возможности они предоставляют.
Это позволяет агенту, к примеру, при дебаге не искать самому, где какой сервер, как к нему подключиться, а где у нас вообще логи, а что это за формат, а почему их тут 10 гигов, ааа..., а вместо этого:
● вызвать CLI-команду вида "дай логи с вот такими фильтрами"
● команда под капотом идёт к платформе
● платформа уже знает все места с логами для этого приложения
● платформа через адаптеры базовых компонентов сходит либо в файлы, либо в Loki, либо ещё куда, чтобы собрать логи
● логи агрегируются, чистятся и возвращаются агенту с пейджингом, удобным форматированием и указанием источника
Оркестрация
Тут живут и исполняются типовые сценарии и их шаблоны, такие как deploy, verify, diagnose и т.п.
К примеру, примерно так устроен шаблон для deploy:
● получаем сведения о конкретном приложении из дескриптора
● определяем, какие компоненты участвуют в deploy для этого приложения
● проверяем, живы ли они все
● получаем тег и/или версию из гита в качестве deploy tag
● проверяем, готов ли у нас билд и артефакты с нужным тегом, чтобы было из чего деплоить
● запускаем конкретный workflow деплоя (который определен в самом приложении, тут мы его деталей не должны знать)
● мониторим, как идёт, периодически рапортуем прогресс для агента-деплоера
● проверяем теги/версии на задеплоенных частях системы
● возвращаем итоговый отчёт агенту
Лирическое отступление
Казалось бы, можно просто обписать базовые компоненты адаптерами и накинуть сверху CLI + скиллы для агента.
И это вполне рабочий подход, когда приложений мало, их Ops не требует унификации и некоторое дублирование допустимо.
Но в моём случае (да и вообще в случае принятия платформенного подхода) - это именно то, от чего и хочется уйти :)
Преимущества тут такие:
● повторяемые процессы (или их части) отдаём платформе, чтобы агент делал меньше шагов, "ручных" действий и не загрязнял контекст лишними деталями
● можно менять топологию, расположение, и даже иногда сами базовые компоненты чисто на уровне самой платформы без необходимости менять инструкции для агентов-разработчиков
● безопасность - можно настроить набор тулов для конкретного агента, и ограничить его работу только с ресурсами, которые принадлежат его приложению - это тоже форсится платформой
CLI + SKILL.md для агентов
Агент пользуется плоским набором CLI-команд, главные из которых описаны в скилле.
Но при старте CLI сам делает discovery тех команд, которые доступны агенту.
Есть команды, специфичные для конкретного приложения, которые подгружаются динамически + платформа может включать/выключать некоторые команды.
Команды есть сценарные: deploy, verify, diagnose, а есть и для отдельных инструментов, типа redis flush namespace, s3 list.
Для каждой команды CLI может выдать хелп, который агент на ходу может изучить, а в некоторых ещё и follow up commands возвращает, давая подсказки, что ещё можно попробовать.
#ai #agentic_ops #devops | 3 306 |
| 18 | Бенчмарки! Новый митап про DeepSWE, SWE-rebench v2 и др
Друзья, вы все еще верите бенчмаркам? Я вот все меньше. Наверняка уже все видели DeepSWE бенчмарк - пожалуй, наиболее противоречивый бенчмарк за последнее время, причем с полярными мнениями: для одних это единственный объективный бенчмарк, для других он абсолютно не имеет отношения к реальности. В общем, я подумал, что будет интересно разобраться глубже в современных бенчмарках - обсудить их достоинства и недостатки, чтобы понимать есть ли вообще смысл обращать внимание на SWE бенчмарки в 2026-м. Отдельно разберем обновленный SWE-rebench v2.
На митап мы позвали, вероятно, наиболее подкованного человека из русскоязычного пространства - Ибрагима Бадертдинова, он один из ключевых авторов бенчмарка SWE-rebench, который как раз недавно обновили. А еще, Ибрагим автор канала @c0mmit. А неудобные вопросы будет задавать горячо любимый друг нашего канала Максим Этихлид (@etechlead).
Будем обсуждать важность harness, утечки, бенчхакинг, важность флоу проекта (AGENTS.md, верификации и т. д.) и, конечно, методологии.
Дата и время: 9 июня 14:00 по МСК, 16:00 по Алматы, 13:00 CET, 12:00 по Лондону.
Ссылка на регистрацию на встречу.
Готовьте свои коварные вопросы, ведь будет уникальная возможность задать их Ибрагиму - автору одного из топовых бенчмарков.
—
Кстати, у нас было интервью с Ибрагимом, в котором мы разбирали подробно бенчмарк SWE-rebench, поэтому рекомендую к просмотру всем AI-энтузиастам и в качестве подготовки к нашему новому стриму: https://youtu.be/a5jf-kyV12Y
@ai_driven | AI-Driven Development: Родион Мостовой. | 2 783 |
| 19 | С бенчмарками для кодинговых агентов сейчас стало довольно неопределённо.
Мне думается, что мы уже живём в какой-то пост-бенчмарк эпохе, когда всё сложнее и сложнее становится объективно оценивать модели.
Тут, с одной стороны - сатурация бенчей, с другой - их контаминация и прочие проблемы с недоверием и методологиями, а с третьей ещё и то, что разницу на повседневных задачах между современными моделями и агентами стало непросто измерить.
Тем не менее, новые бенчи появляются, и их авторы стараются учесть проблемы прошлых поколений, сделать более честные проверки и поднять планку сложности в тестах для агентов.
Так что завтра поговорим обо всём вокруг кодинговых бенчмарков на стриме ⬇️ | 2 793 |
| 20 | AgenticOps, часть №2 - базовые компоненты
Начну с того, на чём стоит сама платформа - с набора базовых инфраструктурных компонентов.
Общие принципы подбора компонентов
● self-hosted
● для полноценной работы не нужен интернет
● наличие стабильного внешнего API
● ничего не конфигурируется ad-hoc, только IaC/CaC, с занесением в git
● современные LLM хорошо знают каждый компонент
Допущения
● упрощенная модель безопасности (всё-таки это homelab)
● в кубере только свои приложения, всё остальное - за его пределами, в контейнерах
● без распределенной файловой системы (пока что)
● это всё постоянно живёт и меняется, но теперь уже не бесконтрольно
● ремонт невозможно закончить, его можно только прекратить (с)
Provisioning
● Ubuntu, macOS, Synology NAS - всё пошло в дело в качестве хостов разных сервисов :)
● Incus - системные контейнеры, внутри них живут ноды кубера и CI-раннеры
● k3s - легковесный flavor кубера. Взял именно его вместо ванильного k8s: один бинарь, просто ставится через Ansible - для homelab в самый раз.
Прагматизм придушил желание собрать кубер руками (да что ж я, зря чтоль CKA(D)?)
● Ansible - вся настройка хостов, OS, системных и прикладных сервисов кодом (в планах pyinfra, чтобы уйти от YAML-программирования)
● Pulumi - для управления ресурсами, которые нужны приложениям (базы, очереди, DNS-записи, s3, креденшиалы к ним и т.п.).
Ansible+Pulumi дают инвентаризацию инфры - машиночитаемую, верифицируемую и синхронизируемую с актуальным состоянием - это маст хэв и для людей, и для агентов
Доставка
Упор - на шустрый и программно управляемый путь от коммита до деплоя.
● Gitea + Actions - локальный git и CI на своём железе, без завязки на GitHub (у которого доступность недавно потеряла все девятки 😱)
● Zot - реестр образов для контейнеров. Переехал на него с Docker Registry, потому что Zot - сразу OCI-нативный и полегче
● Argo CD - GitOps/CD-контроллер для кубера. Берёт желаемое Kustomize-состояние из gitops-репозитория и синкает k3s-кластер под него
● Nexus - прокси-кэш пакетов npm/pip/NuGet/etc, чтобы не дёргать внешние реестры на каждый билд. Плюс, тут же и кэш весов моделей с HuggingFace
Данные
● Postgres + pgvector + pg_trgm, Redis, RabbitMQ - ну тут очевидно
● MinIO - S3-совместимое хранилище (в планах - переезд в Garage)
AI
● Llama.cpp и vLLM - инференс LLM-моделей, эмбеддеров и реранкеров
● Whisper, Parakeet - локальное распознавание речи для видео, звонков и просто диктовки
● LiteLLM - как AI-гейтвей для запросов со стороны приложений
● MLflow, Arize Phoenix - для работы с данными экспериментов и эвалов
Наблюдаемость
Тут всё ради дебага агентами - они должны уметь быстро искать ошибки, сопоставлять их с тем, что ещё могло происходить в системе в это время и отслеживать цепочки событий, которые к ним привели.
Это требует культуры и со стороны самого приложения, так что соответствующие практики форсятся на уровне кодинговых агентов.
● Alloy - OTLP-endpoint для того, чтобы принимать логи и трейсы со всех приложений и агентов
● Prometheus - сбор метрик
● логи - в Loki, трейсы - в Tempo, графики - в Grafana (о, а это пропеть можно)
Разное
● SOPS/age - тулинг для шифрования секретов, в частности позволяет их хранить в git (для не совсем уж параноиков) и не бояться, что агент их случайно прочитает
● step-ca - внутренний certificate authority. Нужен, чтобы локальные домены получали настоящий TLS без постоянных предупреждений о self-signed сертификатах
● Technitium DNS - свой DNS для адресов в локалке, чтобы забыть про hosts как страшный сон и не плодить кучу srv01:83, my-pc:4443
● MailPit - ловушка для исходящей почты в деве, чтобы тестовые письма не улетали реальным людям, ну и ещё чтобы агенты сами почту проверять могли
Ничего экзотического тут нет, и это намеренно - обычный production-подобный набор, просто адаптированный для homelab и быстрых экспериментов.
Плюс, с экзотикой было бы намного сложнее почти всё поднять с помощью агентов.
Собственно платформенная часть начинается слоем выше, и об этом расскажу дальше.
#ai #agentic_ops #devops | 3 402 |
