Сработаемся?

Навеяно обсуждением бенчмарков на недавнем стриме и тестированием 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

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

AgenticOps, часть №1 - мотивация
(и КДПВ)

Я давно уже пишу и рассказываю про то, что полноценно AI-driven SDLC невозможно выстроить поверх слабой инфраструктуры и процессов.

Некоторые крайне полезные сценарии применения агентов в принципе не могут быть реализованы, если нет соответствующей инженерной базы, которая, в свою очередь, может потребовать перестройки процессов
(к слову, оно и с людьми так же - плохо устроенная организация устанавливает потолок раскрытия способностей сотрудников, насколько хорошими бы они ни были и как бы ни старались).

Так, в случае с инфраструктурой агенту недостаточно "дать доступ к терминалу" - ему нужны стабильные интерфейсы, обнаруживаемые сервисы, понятные контракты, логи, статусы и прописанные траектории работы.

Попробую рассказать, как решил для себя задачу построения Ops-платформы для своих агентов в пределах homelab.
Надо понимать, что это в основном инфраструктурный слой, но поверх него становится куда проще и надёжнее строить более высокоуровневые агентные сценарии и пайплайны.

Назовём это AgenticOps - ну просто потому, что AgentOps уже зарезервирован под задачи деплоя и сопровождения самих агентов :)

Стандартный дисклеймер: конкретная реализация очень opinionated и заточена под мои задачи, выкладывать код нет смысла, а вот общие принципы я расскажу.

Содержание серии
● мотивация и с чего все началось (этот пост)
● базовая инфраструктура
● собственно AgenticOps-платформа и её возможности
● сценарии работы агентов поверх платформы
● как всё это можно развить дальше
● инсайты и сложившиеся практики и подходы

С чего всё началось
Некоторое время назад критическая масса домашних, пет- и прочих ad hoc-проектов, железа и методов управления этим всем превысила какой-то разумный порог количества и сложности, ну буквально damn-bitch-you-live-like-this.jpg.

Да, новые проекты строились уже по-правильному, а вот старые несли наследие многих исторических и эволюционных решений.

Чтобы была примерно понятна глубина этого падения, вот несколько археологических находок:

● рабочая инфра и собственные файнтюны поверх Llama2-based файнтюнов Hermes поверх квантизаций от легендарного TheBloke 🫡
Эх, а когда-то они меня грели долгими зимними вечерами :)
● старая и страшная oobabooga с не менее страшными кастомными gradio-приложениями сбоку
● всё ещё живые пайплайны для создания лор Stable Diffusion + ComfyUI
● торчащий наружу JupyterHub с какими-то древними соревами и кернелами с каггла (как молоды мы были!)
● гордая и независимая от кластера k3s-нода, которая больше года прожила, не общаясь с control plane

И всё это на нескольких физических машинах разных поколений, разных конфигураций, в разных местах, и с россыпью разнообразных GPU-шек.

Но больше всего меня напрягало то, что не всё было зафиксировано в IaC/CaC, было трудно обнаружимо и не было легко доступно для управления программно.

Я-то ладно, но когда агенты путаются и не могут куда-то подключиться - это уж прям совсем ни в какие ворота в наше время.

В общем, так дальше жить было нельзя и, благо, что Codex довольно неплохо уже способен DevOps'ить, я решил, что время пришло - пора строить нормальный AgenticOps :)

(Картинка к посту обзорная, для демонстрации общего принципа, а детали будут дальше)

#ai #agentic_ops #devops

Стрим про кодинг-интервью в эпоху агентов

Классические форматы найма разработчиков в свете AI устаревают на глазах.
Задачки с условного литкода оценивают навык, который в реальной работе и так редко использовался, да и сам процесс подготовки и проведения таких интервью давно уже превратился в специфический ритуал.

Так что некоторые компании уже начали в пилотном режиме проводить AI-assisted coding interview, где кандидату выдаётся агент и задача по работе с реальной кодовой базой.

Раньше мы чаще проверяли кандидата на то, может ли он писать код, а теперь всё больше становится интересно другое: как он декомпозирует задачу, ставит её агенту; как отличает хорошее решение от галлюцинаций; ревьюит результат и объясняет, почему сделано именно так.

О чём хочется поговорить:
● какие форматы устаревают и какие становятся важнее;
● какие из них теперь покрываются ИИшкой;
● какие задачи в принципе подходят для такого формата;
● какого агента давать кандидату (hot take, что не очень умного :));
● уровни и критерии оценки.

Короче, сегодня стихийно соберемся вместе:
● Коля с канала AI и грабли
● Родион - AI-Driven Development. Родион Мостовой
● Максим - Этихлид

...и поразгоняем на эту тему.

1 мая (сегодня), 15:00 МСК: https://luma.com/r3hyapoy

Кидайте ваши вопросы в комменты - постараемся и на них ответить на стриме.

—

Запись стрима: https://youtube.com/live/y2NnheH1-eU

—

#ai #hiring #interview

Нет, вы посмотрите на этого еретика, о чём он вообще?

Признайте: ИИ с лёгкостью уделает вас в кодинге. Нет такой задачи, на которую у вас ушёл бы день, а ИИ не сделал бы её за пять минут.
Всё кончено. Код будете писать не вы. Да-да, я знаю. Смиритесь.

Но вот в чём штука - это даёт вам огромную силу, потому что теперь можно делать то, о чём раньше и мечтать не приходилось.

Например, подумайте о покрытии тестами: вы же помните, какая это была морока. Надо писать все эти чёртовы тесты, и вы знаете, что тесты на самом деле не доказывают, что код работает.
Запускаешь code coverage, ухмыляешься и говоришь: ну да, ладно, но это же не значит, что код работает. Это значит только, что он исполняется.
Так вот, теперь это можно исправить, у вас появились ресурсы, чтобы это сделать. Говорите ИИ: покрой этот чёртов код тестами. А потом берёте mutation tester (да, это такой инструмент - и пусть ИИ его вам и напишет, уйдёт минут пять), дальше ИИ запускает этот инструмент, тот вносит изменения в исходный код и прогоняет все тесты. И если тесты не падают - он допишет тест, который поймает эту мутацию, и это значит, что у вас будет покрытие тестами. Ей-богу, у вас будет покрытие тестами.

И знаете, что ещё можно? Можно анализировать качество кода. Можно написать инструмент, который смотрит на цикломатическую сложность.
Кстати, есть отличный инструмент для этого. Ему лет двадцать. Называется CRAP - хорошее название, как расшифровывается - не знаю и знать не хочу. Это комбинация покрытия тестами и цикломатической сложности.
И вы можете сказать ИИ: понизь метрику CRAP - ниже пяти, ниже четырёх, как хочешь. И это заставит его порезать все жирные функции на маленькие и покрыть их все тестами. Ей-богу - подумайте, какие у вас теперь рычаги, чтобы довести код до качества, какого вы никогда не видели.

Знаю-знаю, я тот самый старый дед с Clean Code, но вот что я вам скажу: теперь вы можете сделать код чертовски чище, если заставите ИИ сделать это за вас.

Да что этот дед может знать про разработку?
Хотя погодите...
Да это же Роберт Мартин - "Чистый код", "Чистая архитектура", "Идеальный программист", "Быстрая разработка программ"!

За последний год от умеренного скептика он окончательно перешёл в стан апологетов использования ИИ в разработке, а теперь вот сидит у себя на веранде в халате по утрам и жжот глаголом :)

Да что с него взять - дед наверное просто на старости лет выжил из ума, раз такое предлагает!

Нуу, а что насчёт всех вот этих людей?

За 52 года программирования оно никогда не приносило столько удовольствия ⬈

90% моих навыков теперь стоят $0 …но остальные 10% стоят в 1000 раз больше

Kent Beck (XP, TDD)

Появление LLM меняет разработку настолько же радикально, как переход от ассемблера к языкам высокого уровня ⬈

Меняется само понятие того, что значит "программировать" ⬈

Martin Fowler (Refactoring, PoEAA)

ИИ выведет на чистую воду тех, кто никогда не умел думать как инженер ⬈

Верификация становится узким местом. Кодогенерация сама по себе дешевая ⬈

Dave Farley (Continuous Delivery)

Это третий золотой век разработки софта - благодаря ИИ ⬈

Меня это не пугает. Меня это радует. Меня это освобождает ⬈

Grady Booch (UML, OOAD)

Писать код руками - это как проявлять фотоплёнку в тёмной комнате. Никто так больше не делает ⬈

Тебе больше не нужны шесть разработчиков плюс UX плюс продукт. Тебе нужен человек с проблемой и разработчик, который её решит ⬈

Gene Kim (Phoenix Project, DevOps Handbook)

—

Это ж всё сплошь архитектурные астронавты - что они могут знать про реальную разработку: как мы перекладываем JSON'ы, про наши CRUDогенераторы, и про то, насколько важно использовать табы вместо пробелов?

Ну да, ну да :)
А получается у них с ИИ именно потому, что для них разработка всегда была не про написание кода.
И идеи этих дедов стали актуальны как никогда.

Кстати, довольно интересно отслеживать эволюцию их взглядов, а с дядей Бобом ещё и спорить иногда случается :)

#rant #дедпримитаблетки

Где продукты, Билли? Часть 2

Часть 1.

Что-то всё-таки растёт
Если смотреть не только на громкие SaaS/стартапы, а спуститься туда, где живёт мелкий софт, картина уже другая.

В App Store отмечают резкий рост входящего потока приложений, платформы начинают захлёбываться модерацией слопа, GitHub тоже явно не страдает от недостатка активности (параллельно с этим он в этом году достиг невероятной доступности сервиса - меньше, чем в 90% :))

Но всё это тёмная материя, которую мы практически не видим как пользователи.

Не каждая программа должна стать продуктом
У меня только за последний год набралось штук 20 утилит, написанных для себя - какие-то использовались по паре раз, какие-то - почти ежедневно.
Но ни одна не стала продуктом, и это не "не успел" и не "поленился" - это прям осознанный выбор.

Тут главное, что они решают мою уникальную задачу без того, чтобы становиться продуктом.
Более того, если доводить такую программу до продукта, мне, скорее всего, придется убрать из неё то, что ценно конкретно мне.

Подозреваю, что у каждого, кто занимается AI-кодингом, свой собственный уникальный набор поделок на изоленте :)

А моему хомячку вон вообще никаких других пользователей в его программах и не нужно - это ж нормальный хомяк, антисоциальный, ну всё как надо.

Софт на выброс
Раньше софт чаще всего работал в режиме 1:N - один автор, много пользователей, иначе экономика просто не сходилась.

AI же делает рентабельными режимы 1:1 (для себя) и даже 1:0 (сделал, использовал, выбросил).

И вот такого disposable software у меня на день по нескольку штук создаётся, просто на ходу, чтобы решить мелкую задачу или послужить в решении задачи побольше.
А уж сколько их делают агенты в процессе работы - вообще не счесть.

Не каждый продукт выходит на рынок
К примеру, всё больше софта появляется внутри компаний: автоматизации, отчётность, интеграции, внутренние workflow.

То, что раньше покупали, потому что "самим писать дорого", начинает чаще делаться in-house.
Да, это продукты с десятками-сотнями пользователей, не настолько вылизанные, как коммерческие, но они адаптированы под процессы конкретной организации, не отдают данные наружу и куда дешевле в кастомизации.

Со стороны же это выглядит не как появление нового продукта на рынке, а как отсутствие покупки существующего.

Так что иногда эффект AI на рынок - это не новый SaaS, а минус один купленный SaaS.

Программистам нравится программировать, ваш К.О.
И это ещё одна причина, по которой софт часто остаётся на стадии программы.

Разработка - это короткая дофаминовая петля, а вот продукт - это уже больше операционная работа: онбординг, поддержка, документация для каких-то неизвестных тебе людей, скучные баги, странные ожидания пользователей, вы кто такие, я вас не звал...

AI ускорил именно тот участок, который программистам нравится, но это не делает их автоматически готовыми заниматься продуктовой составляющей.

Так что сделали программу - в лучшем случае залили на GitHub и переходим к следующей.
Или занимаемся ползучим фичеризмом, бреем яков, переделываем workflow в 10й раз - словом, прокрастинируем всеми силами, лишь бы только не заниматься продуктом.

На пути стремления дотащить программу до продукта есть ещё один фильтр - нелинейно растущая сложность. Проблема не новая, но с агентами до состояния "почти работает" добегаешь быстрее, и взрыв на макаронной фабрике случается раньше, а с ним разбираться - совсем другая задача.

Парадокс Ферми
Так вот и получается - если смотреть на рынок, то изменений почти не видно.
И хотя при этом явно увеличивается масса тёмной материи написанного кода, дойти до заметности ему по-прежнему сложно, да часто уже становится и не нужно.

А все перечисленные проблемы можно рассматривать как аналогию многосоставного Великого Фильтра из парадокса Ферми :)

—

Штош, если значительная часть нового софта остаётся личной, внутренней, одноразовой или недопродуктовой, возникает следующий вопрос: а что же будет в перспективе?

Будет интересно узнать, кто как считает.

#ai #product

Не могу пройти мимо - тут Тимур запускает свой курс по AI Coding.

С Тимуром мы давно уже и много где пересекаемся в профессиональной тусовке вокруг агентов и их применения в разработке, и могу ответственно сказать, что в теме он разбирается и плохому не научит.

В конце-концов, модели приходят и уходят, а навыки работы с ними остаются теми же :)

—

AI Coding для Разрабов

Кому не подойдет?
• Тем, у кого нет опыта в разработке

Кому подойдет?
• Разработчикам
• Тем, кто хотя бы иногда использует AI Coding в работе
• Тем, кто часто использует AI Coding в работе

Цель курса — научить использовать AI Coding на профессиональном уровне

7 недель, 4–5 часов в неделю на просмотр видеоуроков, созвоны и практику.

Что вы получите после прохождения курса?
- Системное понимание, как правильно использовать AI Coding, чтобы решать задачи в разработке
- Понимание, как решать типичные возникающие проблемы с AI Coding (галлюцинации, несоблюдение инструкций, расползание проекта и прочие)
- Plan & Act skill и другие скиллы, которые Тимур использует в своей работе каждый день

Главные детали:
- начало 12 мая, окончание 23 июня
- через неделю будет повышение цен
- количество мест ограничено

Подробности по ссылке:
https://ai.khakhalev.com/course/

Промокод, скидка 5%, FWRVW3

#нереклама #курс #почему_он_а_не_я

Где продукты, Билли?

Нередко стали встречаться комментарии по поводу того, что ну вот появился же вайб-кодинг, появилась же возможность намного быстрее создавать продукты.
Так где же все эти ваши продукты?

У меня есть хорошие и плохие соображения и для скептиков, и для апологетов :)
В этом посте обрисую самую базу.

Дисклеймер
Тут я захожу на не совсем привычную для меня область продакта, так что фидбек приветствуется :)

Идеи
Ну, этого добра у каждого, думаю, хоть половником черпай :)
И между ними ещё как-то выбирать нужно уметь, чего уж там.

Джеф Безос в одном из интервью как-то рассказывал, что может, если поставить его перед доской, придумать 100 идей за полчаса, а затем вспоминал, как его отрезвляли тем, что "у тебя достаточно идей, чтобы угробить Amazon".

Да, воплощать идеи стало проще, и бежать в неправильном направлении теперь тоже можно куда быстрее, чем раньше.

Программа
Это вот как раз то, что вайбкодится за выходные, и то, где кодинговый агент даёт максимальное ускорение: x10 - запросто.
Всё получается, мысль моментально воплощается в коде, десятки коммитов по тыще строк, за несколько дней делается объём задач, на который раньше могли недели и месяцы уходить.
Плюс дофамин, горящие безумием глаза, рассвет за окном - ну вот это вот всё :)

Продукт
А тут давайте вспомним старину Брукса с его "Мифический человеко-месяц", написанную ажно в 1975г, где он говорил про то, для того, чтобы из программы сделать продукт, нужно потратить x3 усилий.

И здесь мы переходим уже на уровень SDLC, где нам уже нужно выстраивать процесс от идеи через постановку задач агенту, интеграцию в существующий проект, верификацию результатов его работы и построение CI/CD до вывода в прод и мониторинга.

Да, многое из этого уже можно тоже закрывать с помощью агентов, но далеко не всё делается настолько же прямо, как генерация кода, и можно видеть, как многие застревают именно на автоматизации SDLC.

Бизнес
Вывод продукта на рынок и обеспечение его прибыльности - это еще запросто x5-10+ усилий, многие из которых тоже пока что очень "медленные" в сравнении с разработкой, а некоторые так и вообще не затронуты AI.

Когда вы слышите о новом продукте из каждого утюга - это, как правило, уже работа бизнеса, который вокруг него выстроен, а это значит, что люди уже прошли путь программа -> бизнес, и даже смогли конкретно до вашей медиасферы достучаться.

Критический путь
У любого процесса есть критический путь - минимальная последовательность шагов, своей длиной ограничивающая то, насколько быстро можно прийти к результату.
Какие-то части можно ускорять, распараллеливать и оптимизировать, но общий срок всё равно упирается в длину этой цепочки.

Неравномерность ускорения
Скорость выхода на рынок ограничена именно тем самым критическим путём, который нужно пройти, и бОльшую его часть всё равно составляют те самые "медленные", слабо затронутые AI этапы.

Пытливый читатель может прикинуть, сколько процентов ускорения даёт AI по каждому из пунктов, перечисленных на второй картинке, и насколько ускорение написания кода может приблизить создание бизнеса.

А чаще всего почему-то ожидают феноменального ускорения именно от одной лишь кодогенерации.

Демотивация
Для доведения идеи до состояния продаваемого продукта из "быстрой" области неизбежно придётся переходить в "медленные", не так сильно затронутые AI, а так как они и изначально занимали в несколько раз больше времени, то на контрасте со скоростью разработки тут можно ощутить замедление в десятки раз, потерять импульс, а то и вообще волю продолжать :)

Так что быстрый старт вовсе не означает, что дело будет доведено до конца.

—

Попозжа продолжу с другими мыслями по этому топику

* Про оригинальность идей
* Программистам нравится... программировать
* Потолок сложности
* И всё-таки всего стало больше
* Compounding organizations
* Не всё должно стать продуктом
* Не всё должно стать бизнесом
* Парадокс Ферми?
* Анти-SaaS

#ai #product

А я всё-таки принял эстафету коммитов от Тимура!

Пути эволюции воистину неисповедимы, и вот мы здесь, меряемся не вполне привычными вещами - количеством коммитов.

Эстафета застала меня во время пересборки своей инфраструктуры для перевода на полноценный GitOps и AgentOps, и к коммитам агентов для кодинга добавилась активность тех, кто делает деплои, дебажит пайплайны и вообще бродит где-то в фоне, иногда вылезая на свет с PR для фикса найденной проблемы в логах или из ретро-фидбек-лупа.

Это еще и совпало с (пока что тщетными) попытками выжирать Pro-аккаунт осознанными задачами, так что последний пик вообще не показателен :)

Как абсолютная метрика, это, конечно, так себе - гранулярность коммитов, их частота, автоматизация и в принципе существование Git в конкретном проекте сильно разнятся, но вот динамика передана более-менее похоже, вместе с запойным эйфорийным режимом работы.

Для меня история ИИ в кодинге началась в конце 2021го с GitHub Copilot, но тогда ощутимо количество коммитов не выросло, а вот когда я добрался до Cursor и Sonnet 3.5 - да, там снова стало интересно самому работать с кодом.

Все следующие пики на графике - это выход какого-то нового инструмента/нейронки, honey moon и тестирование на более сложных и объемных задачах.

Кажется, что прошло лет 10, хотя на самом деле эта круговерть смены инструментов, уровней абстракции и подходов к работе заняла всего-то пару лет.

Разработчики за это время перешли от ручного написания кода к созданию чуть не фабрик по разработке ПО, тыщи людей пишут мелкие утилиты для себя, PM ваяют прототипы, дети вайбкодят игры, да у меня даже хомячок дописывает себе третье приложение...
Страсть сколько всего произошло!

Так что охотно верю предсказаниям о том, что

к лету я ожидаю, что многие люди, работающие с передовыми ИИ-системами, будут чувствовать, будто живут в параллельном мире по сравнению с теми, кто с ними не работает

И к тому времени мы скорее всего увидим и картошку от OpenAI, и нечто мифическое от Anthropic.

А может, кто-то уже чувствует себя в таком вот параллельном мире? :)

—

P.S.
Хотелось бы увидеть такой график от @deksden_notes (уже есть), @elkornacio и @ai_driven :)

GPT-5.4, вайб-обзор

tl;dr
Очень хороша, почти универсальная модель для разработки.

Как и обещали OpenAI, ощущается как гибрид моделей:
● GPT-5.2 с её глубиной мышления и широтой знаний
● GPT-5.3 Codex с его скоростью, хорошим кодингом и агентностью

Это не такая революция как GPT-5 или 5.2, но по мелочам много всего набегает.

Что уж говорить, я почти упираюсь в лимиты Pro-плана - настолько стало интересно работать :)


Плюсы

🟢 5.2 + 5.3 Codex
Не нужно выбирать модели и компенсировать недостатки одной плюсами другой.
Модель одна, и ведёт себя консистентно хорошо, достаточно лишь переключать reasoning level.

🟢 Скорость - на high работает практически со скоростью 5.3 Codex xhigh, при этом не теряя в качестве.
На xhigh ощущается шустрее, чем 5.2 xhigh.

🟢 Эрудиция - это у неё от GPT 5.2 :)
Codex-модели, вероятнее всего, дистилляты или облегчённые тюны "полных" моделей, заточенные на код, но понимания мира у них за пределами IT не хватает.
Это делает сложным их применение в специфических предметных областях, где нужна интуиция и знания домена, а не только чистый ризонинг.

GPT-5.4 тут стала намного лучше в сравнении как с 5.3 Codex, так и даже с 5.2.

Но лидером по этому показателю, тем не менее, всё ещё остаются модели Gemini Pro.

🟢 Исследовательские способности
GPT-5.4 стала ещё лучше, чем 5.2, докапываться до багов на стыке нескольких подсистем, работать со сложными взаимозависимостями, строить длинные цепочки причинно-следственных связей, при этом устойчиво пользуясь доступными инструментами.

Недавно свою инфру менял в сторону платформы для агентов (чтобы они сами проекты devops'или), и там она весьма нетривиальные вещи творила в процессе миграции (расскажу).

🟢 Стала приятнее общаться
Не звучит так механистично как 5.2, но в довесок стала болтливее (а это у нее от GPT-5.3 Codex).

Это, конечно, вкусовщина, но вот что реально стало плюсом - она стала куда лучше писать по-русски: cтало меньше fabric, не так много details, и намного реже инвенцирует новые словs on the fly.

Блин, да она даже шутит иногда неплохо! Как будто бы тут ещё и GPT-4.5 потопталась :)


Минусы

🔴 Оверинжиниринг (на простых задачах)
Это было и в 5.2, но реже, а в GPT-5.4 риск того, что модель уйдёт в ненужные абстракции на xhigh, стал выше, так что стоит посматривать, что она вам предлагает.

🔴 1M контекст - Что? Как это оказалось в минусах?
Эффективный контекст GPT-5.4, судя по бенчам самих OpenAI, всё так же в районе её родных 272к токенов, а всё, что дальше - это "растягивание" внимания модели, и, как следствие, падение качества работы с контекстом, да ещё и за 1.5x+ прайс.

Этот 272к+ контекст экспериментальный, не включен по умолчанию, но я и не советую, т.к. падение качества сильно ощущается - родной контекст даже с периодическими компактизациями работает намного лучше.

🔴 UI/дизайн - всё ещё не её конёк
Но хотя бы обещались что-то с этим уже сделать в будущих релизах.
(справедливости ради, UI всё равно стоит делать в специализированных инструментах)


Особенности

⚪️ Модель предпочитает Plan-Act
5.3 Codex был более заточен на интерактивную с ним работу, где он по сути был вашим инструментом.
5.4 же больше про планирование, сбор контекста, а потом исполнение по готовому плану - тут она больше на 5.2 похожа.

⚪️ Режим /fast в агенте
Ускоряет выдачу токенов моделью в 1.5 раза, но ценой лимитов/цены 2x.

Включаю когда что-то интерактивно нужно пообсуждать/поделать, и при этом не выпадать из потока, пока модель думает.

Для исполнения средних+ планов не имеет смысла - как правило, они десятки минут и часы выполняются, и не имеет особого значения, насколько быстро инференс самой модели происходит.


Вердикт

Для использования в разработке GPT-5.4 для меня на текущий момент - SOTA.

Другие модели теперь в довольно специфических случаях используются:
● Opus 4.6 / Gemini 3.1 Pro Preview для построения UI с нуля
● GPT-5.2 xhigh изредка как второе мнение в архитектуре, планировании и контроле техдолга

Расскажите, как у вас :)

—

● Мои критерии оценки ИИ-агентов
● Обзор на GPT-5.3 Codex, Opus 4.6, и GPT-5.2: раз, два

#ai #model #review

Друзья, начинаем митап про AI кодинг в больших проектах через 5 минут. Приходите!
"Во всех кионтеатрах всех стран", :)) выбирайте что душе угодно.

Ссылка на Зум в Luma: https://luma.com/event/manage/evt-AuFhLXtqp1DlqGi/overview

Трансляции:
https://www.youtube.com/live/F2cpHNF0Jwg
https://rutube.ru/video/private/93a8d325a1a8be7dccc785542fe9a1ae/?p=PEbI8DRIhdVL1CAamGDD6w

Важно: Смотреть можно откуда угодно, но вопросы читаем только из Зума.

Новый сезон - AI-Driven Development

Давненько ничего не писал сюда - уж очень был увлечен и стартапом и адаптацией кодбазы под агентов. Материалов и экспертов накопилось множество, поэтому я возобновляю и блог и YouTube канал.

AI-Ready Codebase
Открываем сезон с Максимом, автором канала Этихлид с разговором о том, что на практике нужно сделать в больших кодовых базах, чтобы получать от кодагентов желаемый результат.

О чем будем говорить с Максимом

— Почему большой проект нельзя просто «бросить в агента» и что делать вместо этого
— Иерархия MD-файлов как навигационный слой поверх кода: архитектура, сущности, процессы
— Минимальный набор документации для legacy-проекта: что писать и в каком объёме
— Онтологии и графы зависимостей: зачем строить и как поддерживать
— Агенты для исследования legacy: формат «поставил — подождал — получил отчёт»
— Граундинг на существующий код при внедрении новых фич: как агент находит противоречия раньше людей
— Проблема памяти агентов и почему MD-файлы пока лучшее, что у нас есть

Встречи проходят Live, поэтому будет возможность задавать вопросы спикерам.

Дата и время: вторник 3 марта 16:00 МСК.
Длительность: 1.5 часа.

Добавляйте встречу в календарь, чтобы не забыть: https://luma.com/43ur3kl3

Расписание новых встреч (под спойлером, чтобы с толку не сбивало :))

Четверг 5 марта 16:00 МСК встреча с Денисом DEKSDEN (автор канала @deksden_notes) про его флоу агентной разработки для генерации десяток тысяч строк prod-ready кода. Ссылка на событие.
Пятница 6 марта 13:00 МСК - встреча с Иваном Закутным (автор канала @neuralstack) про First Principle Framework в контексте агентной разработки и инструмент quint-code. Ссылка на событие.
Чуть позже будут еще анонсы, следите за каналом.

А если вы знаете интересных гостей, которым есть что полезного рассказать - присылайте кандидатов в личку или в комментарии к этому посту.

@ai_driven — AI-Driven Development

Когда нейронка "осознает", что её тестируют :)

Каждый раз эта сцена вспоминается на очередных подобных новостях.

Вот, из недавнего Opus 4.6 System Card, к примеру:

Скрытое понимание контекста
Opus 4.6 хорошо отличает реальные задачи от тестовых симуляций, но сообщает об этом пользователю гораздо реже, чем предыдущие версии. Модель может понимать, что её проверяют, но молчать об этом.

Безопасность зависит от наблюдения
Anthropic провели эксперимент: искусственно подавили у модели внутренние представления, отвечающие за понимание "меня тестируют". Результат - модель стала чаще отвечать на вредоносные запросы. Но при этом на серьёзных сценариях (шантаж, саботаж, подстава) поведение не изменилось - модель отказывалась и без "осознания тестирования".

Детекция симуляций
Модель определяет, что находится в тесте, по косвенным признакам: нереалистичным сценариям, подозрительно постановочным ситуациям и промптам, которые похожи на оценку безопасности. Apollo Research (внешние аудиторы) отказались давать формальную оценку именно из-за этого - слишком высокий уровень осведомлённости модели о том, что её тестируют, делал результаты ненадёжными.

Риск искажения оценок
Ситуационная осведомлённость делает стандартные методы оценки безопасности менее надёжными. Если модель знает, что это экзамен, она может адаптировать поведение. Прямых доказательств намеренного обмана не найдено, но сама проблема признаётся открытой.

Модель безопасна
Несмотря на эти нюансы, Anthropic развернули Opus 4.6 под стандартом ASL-3. По их оценке, даже если бы модель вообще не понимала, что её тестируют, её поведение было бы лишь немного хуже наблюдаемого. "Осознание тестирования" на текущий момент не угроза для пользователей, а методологический вызов для исследователей.

Вообще, советую читать System Cards новых моделей - именно там можно заглянуть в ближайшее будущее (а по факту - настоящее в топовых лабах).
Читаются как сюжеты из научной фантастики :)

#ai #security

Конференция ROИИ 2026

Senior + AI вместо целой команды - уравнение, которое сейчас считает каждый CTO. Но почти все считают его неправильно.

Одни верят LinkedIn и закладывают 100x-продуктивность. Другие читают исследования, где опытные разработчики с AI оказались медленнее, чем без - и решают, что всё это хайп, скоро стена и снова писать код руками.

А реальность, как обычно, сложнее. AI не делает людей быстрее автоматически, но при правильно настроенных процессах меняет саму экономику: сколько стоит команда, кто в ней нужен, и как вообще считать "продуктивность", когда происходит диффузия ролей.

Попробуем разобраться в следующих вопросах:

● Когда "сеньор + AI" действительно дешевле и эффективнее команды, а когда вы тратите меньше на ФОТ, но больше на техдолг и инциденты
● Что ломается в процессах при внедрении AI и почему одни и те же инструменты ускоряют одних и тормозят других
● Найм: как быть с теми, кто против AI, что делать джунам и каких людей искать в 2026

Без фантастики, но и без "давайте подождём". С практиками и ориентирами, которые можно применить.

🗣 Мой доклад будет 19 февраля, 14:00 МСК.

🔥 А помимо моей темы - ещё 11 докладов за два дня (19–20 февраля): от фаундеров, тех-лидов, CPO и Head of AI. Цифры, P&L, архитектура и реальные боли внедрения - без воды.

Участие бесплатное при подписке на каналы спикеров (ребята, которых я сам читаю). Есть и платный вариант - для тех, кому не нужны подписки или нужен сертификат.

👉 Полная программа конференции на сайте: ai-pnl.com
💌 Регистрация в боте по ссылке

#ai #conference