Этихлид

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

Последний программист Года полтора назад, в одном из постов, я объявлял в розыск рассказ про деда-программиста, который назло всесильному ИИ продолжал писать код руками. Докладываю: рассказ найден, называется "Последний программист", автор - Герберт В. Франке. Публиковался в Компьютерре в 2001м. А до этого ещё и в "Наука и жизнь" в 1990м (ссылки ведут именно на эту версию). А написан он вообще в 1981м! Так вот, искал я его для того, чтобы сопоставить с начавшимися изменениями в профессии разработчика пару лет назад, но, перечитав сейчас, нашёл куда более точные "попадания" автора в нашу современность. Напоминаю контекст: 1981й год, до интернета в каждом доме - лет двадцать, а до ChatGPT - так и вообще больше сорока. Сюжет: будущее, вычислительные мощности и ИИ ("Компьютер") уже 20 лет как бесплатны для всех. Программистов больше нет - любой нормальный и сознательный гражданин просто говорит машине, чего хочет. И только старый отстранившийся от общества Том зачем-то пишет программы руками, на уже мёртвых языках - ФОРТРАН, АЛГОЛ, ПЛ/1. А Компьютер с ним спорит... Рассказ коротенький, минут на 15, так что советую прочитать целиком, а потом приходите делиться впечатлениями. Под спойлером - цитаты, которые удивительно хорошо отражают настоящее время. — Я система разумная, намного разумнее тебя, а ты заставляешь меня выполнять бессмысленные операции. Я готов во всем тебе помогать, но ведь ты не хочешь вести со мной диалога. То, как ты со мной обращаешься, меня просто оскорбляет Было-было, Opus ещё и не такое может ляпнуть, когда обижается :) В других домах система «диалог» не выключалась, работала постоянно, и люди с утра до вечера слышали указания, советы и слова ободрения, произносимые синтетическим голосом. Том ни указаний, ни советов, ни слов одобрения слышать не жаждал Умный ассистент в каждом чайнике и наше любимое "You're absolutely right!". Вот кстати именно поэтому мне нравится Codex в рабочих задачах - мне не нужно одобрение, всё должно быть сурьёзно, не время улыбаться! [Компьютер:] Только сформулируй мне свою задачу - и я решу ее [Том:] Нет, ты не понимаешь. Творчество заключается в том, чтобы увидеть задачу, где ее не увидели другие Есть такая штука, как delegation gap, которая стала особенно заметна с ИИ: исполнение делегируется, а вот постановка и проверка результата - нет. И тут же поднимается тема того, а что же теперь мы можем считать творчеством. Музыку для музыкантов сочиняют автоматические композиторы, поэты находят ассоциации при помощи генераторов случайных чисел, художники просматривают на дисплеях бесконечные ряды постепенно меняющихся картин, и компьютер же подбирает тебе программу в зависимости от уровня твоего интеллекта и от твоего настроения Suno, картиночные генераторы и персонализированные фиды контента. Неужели никто не видит, что получается при этом одно и то же? Нужно наконец добиться, чтобы все эти люди снова начали думать сами Это ж современный усреднённый нейрослоп, не приправленный мыслительным процессом автора. Почему ты пользуешься этими давно устаревшими методами? Посмотри на других: как ты, больше не программирует никто Мир победившего вайбкодинга :) Можно использовать для целей творчества и компьютер. И весь трагизм в том, что никто больше делать это не в состоянии Ключевая цитата, как по мне. — Замечу, что Франке (автор) - вовсе не луддит, наоборот, - он один из первых компьютерных художников, генерил графику с 1950х, а начинал вообще на осциллографе :) Это, по сути, человек, который всю жизнь пользовался компьютером для творчества. И именно этот человек видел будущее не таким, где ИИ отберёт у нас креативность, а таким, где мы сами радостно сдадим её в обмен на удобство. И споры про то, работаешь ты руками или при помощи машины, вообще лишены смысла. Суть в том, умеешь ли ты видеть задачу, берёшься ли её решать и представляешь ли, каким должен быть конечный результат. В общем, рассказ - удивительно прозорливая футуристика, которая заставляет подумать и... поностальгировать, рекомендую. P.S. Франке разминулся с релизом ChatGPT всего на четыре месяца - и с началом той эры, про которую писал. — Связанные посты: ● Разработчики-староверы ● Раньше было чище (aka "нейрослоп и низкофоновая сталь") ● Креатив и нейронки (и популярно про типы мышления) #friday #дедпримитаблетки

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 для действительно сложных. ⬈ Другой обычно использует medium/high, лишь иногда переключается на xhigh и отмечает убывающую отдачу при дальнейшем повышении reasoning согласно эвалам. ⬈ ⚪️ 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-приложение официально разрабатывается, но сроков нет. ⬈ Команда также признала, что Windows исторически отставала из-за ориентации разработки и тестирования на Mac [да лааадно, да неужели, да это открытие уровня "на третий день Орлиный Глаз заметил, что у сарая нет одной стены"]. Но в последнее время к поддержке 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

Перевёл документ от Google, который описывает текущую ситуацию по переходу от "бессистемных промптов к агентной инженерии": ➡️ Новый SDLC с вайб-кодингом Это первый, самый общий и концептуальный, из пяти whitepaper'ов бесплатного курса 5-Day AI Agents: Intensive Vibe Coding Course от Google и Kaggle. Бонусом там ещё и глоссарий терминов/переводов получился. Это база В нём качественно суммируется то, что разработка ПО с ИИ прошла за последние 2-3 года, описываются появившиеся концепции и систематизируются основные рабочие подходы. Даётся, к примеру, разделение вайб-кодинга и агентной инженерии, фиксируются определения агента / харнесса / дирижера / оркестратора и показывается, как устроена capex/opex-экономика разных подходов к ИИ-разработке. Для разработчиков и лидов может быть полезным почитать, чтобы понять, на каком этапе развития находятся они сами или команда, и как переходить на следующий. Документ лайтовый, без лишнего хайпа и думеризма. Ну и картинки интересные :) Содержание - Сдвиг от синтаксиса к замыслу - ИИ-агенты: краткое напоминание - Что такое вайб-кодинг? - Спектр: от вайб-кодинга к агентной инженерии - Контекст-инжиниринг: настоящий навык - Новый жизненный цикл разработки ПО - Традиционный SDLC под давлением - Как ИИ преображает каждый этап - Требования и планирование - Проектирование и архитектура - Реализация - Тестирование и контроль качества - Ревью кода и деплой - Поддержка и развитие - Фабричная модель: строим систему, которая строит ПО - Харнесс-инжиниринг: что окружает модель - Что входит в харнесс - Харнесс в SDLC - Требования, планирование и архитектура - Реализация - Тестирование и QA - Ревью кода, деплой и поддержка - Меняющаяся роль разработчика: дирижёры и оркестраторы - Дирижёр: ручное управление в реальном времени - Оркестратор: асинхронное мультиагентное делегирование - Проблема 80% - Кодинговые агенты на практике - Где кодинговые агенты вписываются в день разработчика - Как вайб-кодинг доводит агентов до продакшена - Экономика разработки с ИИ - Скрытый долг вайб-кодинга - Инвестиция агентной инженерии - Контекст-инжиниринг как финансовый рычаг - Масштабирование эффективности через динамический контекст и скиллы - Умный роутинг моделей - С чего начать - Для отдельных разработчиков - Для инженерных руководителей - Для организаций - Заключение: замысел как новый интерфейс - Примечания - Глоссарий Замечания ● 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

Вопросы "в глубину" к стартовым задачкам (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

Что вы уже делали?

В программировании всегда были такие задачи, за которые часто брались новички. Некоторые из них оказывались крайне ценными для становления специалиста, а где-то это был весёлый бег по граблям и изобретение велосипедов. Для вайбкодинга тоже накопилось некоторое количество подобных мемных задач, мимо которых сложно пройти. Давайте попробуем собрать статистику. P.S. Ну и напишите, может есть ещё что-то такое, что должен сделать начинающий вайбкодер / ии-инженер / ai-native developer / etc :) P.P.S. В комменты скину свои ответы P.P.P.S. Если интересно - распишу, что тут может быть ценным для начинашек, и почему ✍️

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 #конфа

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

Сработаемся? Навеяно обсуждением бенчмарков на недавнем стриме и тестированием Fable. Смотрите, какая штука: кажется, фронтирные модели уже пересекли планку "достаточно" для "средних" задач во многих проектах по разработке. А раз модели выдают решения, разницы между которыми по качеству не видно, то выбор перестаёт быть вопросом оценки модели в абстрактных попугаях. Вместо этого на первый план выходит характеристика, которую не измерить публичными бенчами: "а сработаемся ли?". В ней и то, впишется ли модель в ваши процессы, и насколько она инициативна, и даже попадает ли она в удобный для вас стиль общения (нередко - определяющая характеристика, как оказывается!). ● Ну т.е. бенчмарки - резюме модели, сигнал к тому, чтобы в принципе обратить на неё внимание. ● Эвалы - тестовое задание, вы даёте модели какие-то типовые для вашей работы задачи. ● Вайб-чеки - испытательный срок, с моделью нужно провести некоторое время, чтобы понять, сможете ли вы с ней эффективно работать. И именно совместная работа на реальных задачах становится самым информативным этапом выбора. — Кстати, взял бы я на работу Fable? Вайб-чек ещё в процессе, но в рамках подписки - да, это no brainer, как говорят в наших деревнях. А какой модели/агента вам достаточно? И достаточно ли :) #короткопост

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

Бенчмарки! Новый митап про 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: Родион Мостовой.

С бенчмарками для кодинговых агентов сейчас стало довольно неопределённо. Мне думается, что мы уже живём в какой-то пост-бенчмарк эпохе, когда всё сложнее и сложнее становится объективно оценивать модели. Тут, с одной стороны - сатурация бенчей, с другой - их контаминация и прочие проблемы с недоверием и методологиями, а с третьей ещё и то, что разницу на повседневных задачах между современными моделями и агентами стало непросто измерить. Тем не менее, новые бенчи появляются, и их авторы стараются учесть проблемы прошлых поколений, сделать более честные проверки и поднять планку сложности в тестах для агентов. Так что завтра поговорим обо всём вокруг кодинговых бенчмарков на стриме ⬇️ #announcement #stream #benchmarks