Сингулярность достигнута в уравнениях Навье-Стокса

В математике существует список из 7 задач тысячелетия, признанных одними из самых сложных в современной математики. За их решение дают приз в 1 млн долларов. За 26 лет существования списка была решена только одна задача - Гипотеза Пуанкаре. И это при том, что тысячи, а может быть сотни тысяч профессиональных математиков бились над их решением.

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

Помимо этого с доказательством возник крупный скандал в среде математиков, потому что двое математиков, занимавшихся этой проблемы подобрались довольно близко к решению, они использовали Codex и есть некоторая вероятность, что их наработки легли в основу попав в тренировочные данные. Если интересно углубиться, то детальный разбор есть на Хабре.

Почему вообще это важно?

1. Уравнение Навье-Стокса важно для гидро- и аэродинамики. Его уже давно решают численными методами, но его аналитическое решение может продвинуть нас в понимании процессов турбулетности. Это в свою очередь может привести к более безопасному авиасообщению, лучшим прогнозам погоды, и, возможно, повлиять на многие другие технологические отрасли.

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

3. OpenAI использовал 10 000 агентов, координирующихся между собой, и сжег токенов на десятки миллионы долларов. Раньше интеллект было невозможно купить исключительно за деньги или даже по принуждению. У работника был выбор, на что направлять свой интеллект и многие гении отказывались участвовать в сомнительных исследованиях и разработках. Теперь это выбор исключительно заказчика. Теперь интеллект можно купить за деньги, очень большие деньги.

Что теперь отделяет нас от AGI? От AGI в руках нескольких компаний, управляемых несколькими людьми, движимыми своими личными амбициями, которые даже модель не могут без инцидентов зарелизить.

@max_about_ai

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

Начну с пары важных для меня моментов:

1️⃣ Презентация должна содержать авторские мысли и отражать его понимание вопроса, иначе автор презентации становится лишней прослойкой между AI и слушателем.

2️⃣ Протестированные модели (Fable 5, GPT-5.6) все еще недостаточно хороши для полностью автономной подготовки презентаций. Им нужны вводные, нужен контроль структуры, нарратива и стиля изложения, нужен факт-чеккинг.

3️⃣ Надо разделять публичные презентации и подготовку материалов для самообучения по уже проработанным и хорошо известным темам - c подготовкой материалов для самостоятельного изучения вопроса ChatGPT / Claude / NotebookLM отлично справляются и можно смело генерить с первой попытки.

Что я пробовал и мне не подошло:

1️⃣ Использовать NotebookLM. Это отличный инструмент для саморазвития или для конвейерного штампования учебных материалов по хорошо изученным темам, но глубина проработки сложных и свежих тем для меня недостаточна.

2️⃣ Генерировать готовые презентации в Gamma App или в другом конвейере презентаций.

3️⃣ Автономная генерация презентаций в Claude Code или Codex.

Как выглядит мой пайплайн:

1️⃣ Выбираю тему и формулирую, какую пользу я хочу дать своим выступлением.

2️⃣ При необходимости делаю исследование по теме вместе с ChatGPT, но вообще без привязки к презентации, а чтобы углубить свое понимание темы.

3️⃣ Самостоятельно выписываю основные тезисы выступления.

4️⃣ Прошу ChatGPT / Claude подготовить свой план и тезисы по теме. Также если вы уже обсуждали эту тему можно попросить ChatGPT переиспользовать результаты вашей беседы. Дальше нахожу пробелы в своих тезисах и объединяю свои и ИИшные тезисы в единый лист.

5️⃣ На основе тезисов самостоятельно собираю структуру выступления с основными тезисами из предыдущего пункта.

6️⃣ По полученной структуре и тезисам прошу ChatGPT / Claude доработать слайды - добавить аргументы, цитаты и ссылки на источники. При необходимости докрутить содержание.

7️⃣ Собираю финальный Markdown-файл.

8️⃣ Загружаю его в Gamma App или отдаю Claude Code (ему полезно давать референс на сайт или другую презентацию), чтобы получить презентацию в формате PDF.

9️⃣ Докручиваю визуальную часть с помощью того же Gamma App или Claude Code, уточняющими промптами.

Еще от опытных спикеров я слышал советы наговорить тезисы голосом и структурировать их с помощью AI. Или брать за основу презентации уже существующие диалоги с ChatGPT и просто генерить по ним. Но сам я ни один из этих подходов не пробовал.

Благодаря AI и современным инструментам, я сократил время на подготовку одной презентации с 8-12 до 4-6 часов без потери качества (а может и с увеличением). Мне кажется, что сократить еще больше можно, но только с потерей качества и аутентичности.

PS: если вам интересна тема внедрения AI в бизнес, маркетинг, продукт менеджмент и личную эффективность - приходите на бесплатную практическую конференцию Community Sprints с 8 по 10 сентября. Я буду выступать про подготовку презентаций по принципам из этого поста, так что можно будет посмотреть на результат. Помимо меня будет много классных спикеров с полезными юзкейсами.
Посмотреть программу и зарегистрироваться.

Митап про личные финансы для айтишников и фаундеров

Меня позвали на онлайн-митап рассказать про мой опыт использования ИИ для личных финансов. Никаких секретных промптов и тем более финансовых советов не будет, но будет честный рассказ как я использую ChatGPT и Claude Code, чтобы экономить время и принимать более взвешенные личные финансовые решения.

Кто еще будет и о чем расскажут:

🔵 Владислав Носковец (CEO CareerStation, автор канала «Твой ментор», помогает IT-менеджерам находить работу) Поделится своими источниками дохода и расскажет, почему не планирует выходить на привычную всем пенсию.

🔵 Иван Глушенков (внедряет ИИ в финансовые организации, закончил физтех, выиграл 18 хакатонов) Расскажет, как 5 лет жил с бюджетами по книге «The Richest Man in Babylon» и разбогател, а потом 5 лет прожил без бюджетов — и почему. Про 4 типа капитала, старость и финансовую безопасность на основе анализа успехов 250 человек ежегодно.

🔵 Глеб Кудрявцев (руководитель ИИ-лаборатории, ex-CPO Skyeng) Руководил более чем 200 людьми, а теперь пишет код и строит бизнес с ИИ. Расскажет, как рассчитывает дожить до сингулярности и жить при коммунизме.

🔵 Таня Савельева (фаундер UplinkAI, 2 экзита, Forbes 30u30) Расскажет, почему не ведёт бюджет и вам не советует.

🔵 Катя Курашева (Founder & CEO R-Founders) Основатель глобального сообщества R-Founders для фаундеров и C-level. Путешествует по мировым центрам технологических стартапов и говорит с предпринимателями и инвесторами о разном, в том числе о деньгах. Поделится неожиданным выводом: почему у tech-предпринимателей личного капитала часто в разы меньше, чем у тех, кто строит физический бизнес.

🔵 Юлия Билинкис (основатель Strategicmove.education) Расскажет, почему на старость нужно копить не капитал, а покупать будущие денежные потоки и уменьшать будущие обязательные расходы.

🔵 Николай Шейко (фаундер grably.tech — внедрение ИИ в бизнес, и entropy.talk — крупнейшие онлайн-конфы по ИИ) Расскажет, почему нефинансовый капитал может быть долгосрочно важнее денег — как его выбирать и растить.

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

🗓 | 3 сентября, четверг, 18:00 мск
| Бесплатно, за подписку на спикеров
⭐️ | Регистрация в боте по ссылке

AI Skills для агентов

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

Что такое скилл

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

Скилл упаковывается в папку с SKILL.md в определенном формате + файлы скриптов, примеров, инструкций и других артефактов. Так выглдяит типичная папка скилла:

code-review/

├── SKILL.md

├── scripts/

├── references/

└── assets/

В SKILL.md есть metadata, по которым агент понимает, когда использовать skill, и сами инструкции:

---

name: code-review

description: Reviews pull requests for bugs,

security issues and project conventions.

Use when asked to review a PR.

---



1. Read the project instructions.

2. Inspect the diff and related code.

3. Run relevant tests.

4. Report findings by severity.

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

1. Агент всегда видит только name и description - около 100 токенов на skill.
2. Полный SKILL.md загружается, только когда skill подходит задаче - рекомендация до 5 000 токенов.
3. Скрипты и references читаются только при необходимости.

Это позволяет подключить много скиллов и не загружать все инструкции в контекст сразу. Формат уже поддерживают Claude Code, Codex, GitHub Copilot, Cursor и другие инструменты.

Как использование скиллов влияет на качество

Качество должно улучшаться, но результат сильно зависит от качества самого скилла.

В SkillsBench протестировали 87 задач из 8 областей на 18 комбинациях моделей и agent harnesses. Curated skills повысили средний pass rate с 33,9% до 50,5%. Для отдельных конфигураций прирост составил от 4,1 до 25,7 процентов. Skills из 2-3 сфокусированных модулей работали лучше больших пакетов документации.

Если же добавить этап поиска скилла, то результаты ухудшаются. В исследовании с каталогом из 34 000 скиллов преимущество почти исчезало по мере усложнения поиска. Retrieval и адаптация найденного скилла под запрос повысили результат Claude Opus 4.6 на Terminal-Bench 2.0 с 57,7% до 65,5%.

Качество публичных скиллов низкое. Авторы анализа 138 133 файлов SKILL.md нашли нарушения спецификации в 89,3%.

Более того использование скилла может ухудшить результат. Данная статья отмечает падение pass rate на 16 из 84 задач SkillsBench. Часто агент выполнял избыточный процесс, запускал ненужные проверки или следовал инструкции, не подходящей окружению.

Как начать работать со скиллами

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

Нормальный процесс выглядит так:

1. Найти скилл в доверенном каталоге или создать под повторяющуюся задачу.
2. Проверить SKILL.md, скрипты, зависимости и требуемые разрешения.
3. Подключить его на уровне пользователя или конкретного репозитория.
4. Сравнить выполнение одинаковых задач со скиллом и без него.
5. Исправлять скилл после реальных ошибок агента.

Рассказ как делать eval скиллов заслуживает отдельного поста, но точно нужен code review + несколько тестовых прогонов.

Откуда брать скиллы

1. Из публичных репозиториев или каталогов - самый популярный skills.sh.

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

3. На уровне компании и проекта должны быть репоризитории с уже существующими и проверенными скиллами.

@max_about_ai

Почему я пока не верю в универсальные темные фабрики софта (dark software factory)

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

Эффективным менеджерам далеким от разработки эта идея кажется отличной. Можно сэкономить много денег компании и получить жирный бонус.

Тем не менее проностью автономная универсальная фабрика корпоративного софта пока невозможна по нескольким причинам:

1⃣ Недетерминированность описания цели на человеческом языке. И это особенно критично, если у вас уже есть legacy ситстема с своей доменной онтологией, на которой llm просто не натренированна.

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

3⃣ Зеленые тесты не означают, что решение хорошее. Они проверяют основные сценарии, но не поддерживаемость, правильность границ компонентов и совместимость с будущим развитием продукта. Особенно опасно когда тесты генерируются тем же агентом после написания кода - повышается вероятность, что код будет использоваться как source of truth и фактически тесты не будут проверять бизнес-логику.

4⃣ Непрочитанный код создает "интеллектуальный" долг. Если люди перестают читать код, команда постепенно теряет ментальную модель системы. Это особенно дорого проявляется во время сложных production-инцидентов.

5⃣ Длинные автономные циклы теряют контекст. Чем больше взаимосвязанных решений агент принимает без остановки, тем выше вероятность, что локально разумные изменения приведут к неправильному общему результату.

6️⃣ Некоторые ошибки слишком дороги. Для приема оплат, авторизации, управления деньгами, прав доступа и персональных данных даже один процент ошибок может быть неприемлемым.

Для частных случает сделать software factories можно уже сейчас. Агентам можно автономно отдавать обновление зависимостей, механические рефакторинги, исправление известных классов ошибок и другие задачи с быстрым объективным критерием готовности. Вероятно таких типовых задач довольно много, но это не универсальные решения.

PS: мой приятель Тимур Хахалев, с которым мы 9 месяцев назад собирали best practices по работе с AI агентами для разработки (пост), стартует второй поток своего курса "AI coding для разрабов". Лично знаю не только Тимура, но и двух человек прошедших у него обучение и оставшихся довольными, так что считайте это личной рекомендацией. Курс стартует уже через 3 дня - 10 августа, а пробный урок - бесплатный. По промокоду MAX - скидка 5%. Детали можно посмотреть здесь.

Ликбез про RAG. ч.2. Фундаментальные ошибки.

За последние 3 года я пообщался с десятком+ команд из разных компаний, работающих над приложениями на основе RAG. 

Две самые частые ошибки, которые я встречал: 
- плохая подготовка данных - garbage-in > garbage-out,
- отсутствие evaluation (оценки качества) - не возможно улучшать то, что не измеряешь.

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

1️⃣  Плохая подготовка данных - самая частая и известная ошибка любых DS/ML/DL проектов. 

Я заметил, что она особенно актуальна для Gen AI проектов, потому что люди, работающие над такими проектами часто не имеют профильного образования или опыта работы с DS проектами. Некоторые инженеры всерьез считают, что если они сделали pip install langchain, то теперь они AI Engineer. Уже 3 года веду репо с подборкой бесплатных материалов по AI разработке, чтобы закрыть эту проблему в своих командах: GH repo.

Что делать с проблемой плохих данных? Ответ очевиден - чистить. 

Самые универсальные советы:
- удалять старые и нерелевантные данные, дубликаты, пустые документы,
- проверять, что pdf, картинки, диаграммы, Excel, Word, attachements правильно обрабатываются,
- эффективно использовать мета-данные и структуру в данных,
- вычистить ошибки (фактологические, грамматические),
- предпочтительно иметь все тексты на одном языке,
- нормализовать онтологию - особенно, актуально для внутрипроектной документации.

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

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

2️⃣ С evaluation все немного сложнее.

Зачем вообще мерить качество системы? С точки зрения бизнеса - без оценки качества не понятно решает ли система поставленную задачу и приносит ли она вообще пользу. С точки зрения разработчика - не возможно улучшать то, что ты не измеряешь.

Существует 3 типа метрик:
- бизнесовые (какую пользу в деньгах приносит RAG приложение),
- продуктовые (DAU, MAU, NPS, Session Length, actions or events и тд),
- качественные (точность, релевантность, полнота,  MRR, …)

Бизнес метрики мерить напрямую, как правило, сложно, поэтому используются продуктовые прокси-метрики. Например, это может быть количество закрытых задач и среднее время, сэкономленное на задачу. Если все честно померить, то внезапно может оказаться, что разработка и внедрение AI приложения не оправдывает ожиданий.

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

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

Есть несколько способов померить качество ответов:
- Автоматические метрики (Bertscore, BLEURT, ROGE, и тд). На практике не применяются из-за крайне низкого качества оценки,
- Бинарный или фактологический датасет с закрытыми вопросами и однозначными ответами поверх которого можно посчитать F1 и другие классические DS-метрики,
- Human eval - человек вручную читает ответы и оценивает качество. Обычно самый точный из способов, но самый дорогой. Его не возможно прогонять eval на каждое улучшение,
- LLM as-a-judge и его разновидности,
- Автоматическая верификация результата. Отлично работает для задач программирования или математики, где можно автоматически проверить полученный результат.

Как правило, нужен датасет эталонных вопросов-ответов (validation и test датасеты). Лучше всего составлять его частично вручную частично с использованием AI, но под очень пристальным контролем с валидацией каждой пары.

Самым частым способом оценки является LLM as-a-judge, потому что он дешевый в реализации, его можно прогонять вместе с тестами на каждое изменение и он относительно универсальный. Но как всегда есть нюанс. Нужно убедиться, что LLM дает такую же оценку качества системы как и человек. Для этого делают meta evaluation, когда человек делает оценку качества вручную и затем сравнивают с подходом LLM-as-a-judge. 

Есть много библиотек для evaluation, из того что я пробовал: RAGAS, DeepEval, TrueLens. Но в итоге написать собственную обвязку оказалось эффективнее.

Для менеджеров важным инсайтом будет, что пропорция времязатрат на разработку и eval, такая же как у разработки и тестирования. В среднем “по больнице” 3 к 1. Но если вы делаете высокорисковое приложение, на тестирование которого уходит почти столько же времени сколько на разработку, то и для evaluation приложения в этом домене нужно ожидать сопоставимое количество трудозатрат.

@max_about_ai

Про Fable 5

Я успел протестировать Fable 5 до его блокировки, но не успел закончить тесты. Дождаться разблокировки не удалось, так что поделюсь тем, что есть:

1⃣ Fable гораздо лаконичнее других моделей. Ответы именно лаконичнее, а не короче, то есть плотность информации выше, чем у других моделей. Мне это очень нравится, не люблю воду в текстах.

2⃣ Ответы Fable на прямолинейные замечания могут иметь яркую эмоциональную окраску. Если бы это был человек, я бы решил, что он на меня разозлился или обиделся. Это вызывает странные ощущения, я не сторонник антропоморфизации LLM. Но главное, что я не успел протестировать до конца - как это влияет на качество ответов моделей. У людей негативные эмоции, часто приводят к снижению качества взаимодействия, обладает ли Fable этим свойством или она сохраняет объективность? Вот цитата Fabble:

Если и это не “главное” - окей, тогда сформулируй сам. Я свои версии исчерпал, и угадайка без обратной связи мне неинтересна.

3⃣ Fable смогла понять что я ее тестирую в ситуации, где я этого абсолютно не ожидал. Я проверял ее способности в принятии решений в условиях нехватки информации, и она быстро «раскусила» меня. Можно только догадываться, как это может повлиять на safety тесты.

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

4⃣ На разработческих задачах протестировать не успел. Но все кто успел - хвалили. Хотя x2 к цене API по сравнению с опусом, вероятно, все-таки не оправданно. Если не будет входить в подписку, то сам я доплачивать вряд ли буду.

5⃣ Добавлю еще одну ложку дегтя - как и другие модели Антропик, Fable чаще чем GPT-5.* оперировал устаревшими данными и на их основе уверенно делал неверные выводы в моих тестах. Там где в ChatGPT достаточно было задать вопрос напрямую, в Claude нужно пробрасывать контекст или промптить так чтобы Claude не забыл сходить в интернет проверить актуальную информацию.

@max_about_ai

Мне интересно читать каналы, где автор не пересказывает позавчерашней Твиттер или презентации БигТехов, а делится своими мыслями по интересной мне теме. Когда 6 лет назад мне пришлось начать совмещать роль Technical Product Manager с моей основной ролью, я искал что бы почитать по новой для меня роли и нашел канал Ани Подображных. Сегодня хочу его порекомендовать, потому что до сих пор читаю. 

Мне нравится, что посты про product management чередуются с постами про персональную эффективность, личными историями, а также всякими полезностями типа вакансий.

В общем, мой личный рекомендасьон.

@max_about_ai

AI ликбез: RAG (Retrieval Augmented Generation) ч.1

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

1️⃣ RAG (Retrieval Augmented Generation) - это подход, когда перед генерацией LLM ответа, приложение ищет релевантую информацию в внешних данных и добавляет ее в контекст вопроса, делая генерацию ответа аргументированной.

Схематично:

RAG = поиск релевантной информации > создание контекста > генерация ответа LLM по контексту

Главная идея: не нужно учить модель всем вашим данным, нужно научить систему находить правильный контекст для модели.

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

2️⃣ RAG призван решить следующие проблемы:

- LLM не знает ваши внутренние документы
- LLM может галлюцинировать и нужна верифицируемость ответов (например, ссылки на источники)
- Знания LLM устаревают

В качестве альтернативы RAG рассматривают prompt engineering или fine-tuning. Но в-первом случае, невозможно добавить много документов и знаний в один промпт из-за ограничений размера контекстного окна и высокой стоимости токенов, а следовательно вопросов-ответов. А во-втором, стоимость дообучения модели и необходимость постоянно добавлять данные делают его практически непригодным для часто изменяющихся данных.

3️⃣ Базовым подходом к поиску в RAG является векторный поиск. Он не всегда лучший, но самый популярный. Часто базовый пайплайн называют Naive RAG и он состоит из двух этапов:

Этап 1. Подготовка данных:
Документы -> Chunking (разбиение на части) -> Embedding generation (векторизация) -> Vector DB

Этап 2. Рантайм:
Вопрос -> Retriever (векторный поиск в базе данных) -> Reranker (сортировка по наибольшей релевантности) -> LLM -> Ответ и источники

В научных работах и на синтетических бэнчмарках Naive RAG показывает хорошие результаты, но на практике существует бесконечное количество подводных камней и пограничных ситуаций. Если полученная система на основе Naive RAG показывает 90% точности на репрезентативной выборки - это считается очень хорошим результатом, но такая точность не достаточна для большинства бизнес-сценариев. Поэтому в большинстве систем Naive RAG либо заменяется либо дополняется более продвинутыми техниками.

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

@max_about_ai

Про AI research

На этой недели моя AI лаба опубликовала первые научные статьи по AI engineering на arXiv (объяснимость ответов в graph RAG и синтетический эвал для LLM приложений). Команда - большие молодцы, потому что они справились, несмотря на огромное количество препятствий на нашем пути.

Не буду пересказывать статьи, поделюсь лишь нескольким практическими выводами, которые я сделал по ходу исследований:

1⃣ Graph RAG - как концепт очень круто, но на деле выходит долго и дорого, а прирост в качестве ответов не столь значим и даже не всегда есть.

2⃣ Еxplainability у ответов на базе Graph RAG действительно выше, но на практике использовать это из-за скорости и цены почти не возможно.

3⃣ Сложность задачи “сделать качественный evaluation LLM приложения“ сопоставима с сложностью разработки такого приложения (по крайней мере одного порядка).

4⃣ Все еще мало исследований по оценке качества ответов LLM для языков за пределами двадцатки самых популярных. Если вы носитель такого языка и хотите сделать AI research - это отличная возможность.

5⃣ Скорость исследований в AI настолько высока, что темы устаревают за 3-6 месяцев. В октябре мы начали заниматься изучением повышения эффективности Context Engineering для AI SWE инструментов. За полгода часть наших гипотез уже успели зарелизиться в Claude Code или Codex, а до окончания работы нам еще 2-3 месяца. И в силу разного рода факторов у меня нет возможности ее ускорить.

6⃣ Доступ к современным исследовательским инструментам превратился за два года из преимущества в жизненную необходимость.

@max_about_ai

Провел две недели отпуска в роад-трипе. Как писал выше, поиск use cases для применения AI не проще, чем освоение самих инструментов, поэтому решил поделиться парочкой сценариев использования, чем сам пользовался в путешествие.

1️⃣ Перевод фото меню, объяснение состава и выбор подходящих блюд из меню с помощью ChatGPT. Перевод меню в классических переводчиках обычно работает плохо и не объясняет что ожидать от блюда. Особенно помогает, если есть какие-то ограничения или выраженные предпочтения в еде.

2️⃣ Разборки с парковкой, платными дорогами и экологическими зонами. Когда за поездку сменяешь несколько стран можно запутаться в особенностях правил парковки и тут ChatGPT очень выручает. Можно сфоткать знак или автомат оплаты и понять можно ли здесь парковаться сейчас и сколько это будет стоить. Также встречаются довольно специфические дороги, где оплачивать дорогу надо не на посту оплаты и не заранее (виньетка), а, внезапно, онлайн. Хз, сколько времени ушло бы разобраться что значили бы те знаки без ChatGPT.

3️⃣ Составление маршрута поездки на авто. Это актуально если цель не просто доехать из пункта А в пункт Б, а хочется новых впечатлений и интересностей по дороги или есть какие-то другие факторы. Впрочем, здесь полностью полагаться на AI не стоит и есть смысл изучать вопрос также по картам. Кстати, можно попросить преобразовать построенный маршрут в Google ссылку со всеми точками.

4️⃣ Поиск решений в нештатных ситуациях - всем что угодно от оплаты штрафа до разборок со страховой компании в случае срочной стоматологической помощи.

5️⃣ Помощь с выбором жилья. Подбор и бронирование размещений AI агентами до сих пор нормально не работает (по моим критериям). Но вот кинуть ссылки на 3-5 уже самостоятельно отобранных варианта и попросить совета с выбором бывает очень полезно. Часто всплывают подводные камни и нюансы, о которых сам не подумал бы - например, криминальный район или плохая транспортная доступность.

@max_about_ai

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

Поэтому моя жена решила открыть свой мини-стартап на международный рынок. Хочет бутсрапить небольшие SaaS приложения.

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

Осталось только научиться продавать. Я предлагал с ChatGPT разобраться, но как-то не пошло - слишком много непубличных лайфхаков в маркетинге, которые никто не хочет шарить публично. На Coursera тоже ничего толкого не нашли. Так что с середины апреля она пойдет на платные курсы по маркетингу. Слышал положительные отзывы от друзей о других курсах Глеба Кудрявцева, надеюсь, и эти не будут исключением.

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

PS: буду иногда делиться её успехами, пока она не завела свой ТГ канал.

@max_about_ai

Про универсальных AI агентов

Последний месяц эксперементирую с Claude Cowork, OpenClaw и Manus. Мои краткие выводы:

0️⃣ Если у вас FOMO, что все вокруг в 10 раз эффективнее благодаря OpenClaw и другим AI агентам, то можете перестать нервничать - технологии все еще далеки от совершенства. Пока хайпа все еще больше чем пользы. Значит ли это, что не надо их пробовать или использовать? Нет! Потому что уже сейчас можно делегировать отдельные задачи, а в какой-то момент рост станет эскпоненциальным и на нем можно будет хорошо вырастить свою карьеру или бизнес.

1⃣ Самый зрелый из протестировнных продуктов - Claude Cowork. Он может управлять Chrome и десктопом. А запускать его на десктопе можно с мобилки при помощи функции Dispatch. У него есть библиотека скиллов, коннекторов и плагинов. Работа организуется в проекты. Я прикрутил его в папку c Obsidian и перевел часть своих заметок в markdown, но большой пользы пока не ощутил - work in progress.

2⃣ Если нужна максимальная гибкость, то есть смысл выбирать между OpenClaw и его open-source аналогами (NanoClaw, PicoClaw, и тд).

Я не настолько богатый чтобы покупать выделенную MacStudio, но при этом хотел сохранить максимальный контроль, поэтому поставил OpenClaw на локальную виртуалку (UTM + Debian). Лайфхак - можно попросить Claude Cowork настроить вам OpenClaw в виртуалке. Он прилично сэкономил мне времени. Хотя Warp, вероятно, был бы еще эффективнее.

Еще к OpenClaw и ее скилам у меня вопросы по безопасности. Особенно актуальные на фоне недавних новостей про supply-chain атаку на библиотеку LiteLLM, когда злоумышленники добавили фишинговый код в open-source библиотеку и отправляли конфиденциальные данные (карточки, пароли,…) себе на сервер.

3⃣ В каких случаях может быть полезен именно Manus при наличии альтернатив я так и не понял. Все кредиты из 20 долларовой подписки он сожрал за 5-6 относительно простых запросов. А качество работы оказалось - "ну такое". Не рекомендую.

4⃣ Ок, поставили Claude Cowork или OpenClaw. Что дальше? Вот тут начинается самое интересное. Почти все мои AI use cases уже и так либо закрываются Codex / Antigravity / Warp, либо закрываются extended thinking в ChatGPT, либо все еще не пригодны для автоматизации по тем или иным причинам. Впрочем, возможно, дело во мне и моей низкой степени доверия подобным инструментам.

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

@max_about_ai

Поучаствовал в подкасте про Product Engineering. Вместе с Юрой Агеевым, автором подкаста Make Sense, поговорили про будущее ролей в разработке, кто такие Product Engineer, как ими стать если вы уже разработчик или продакт менеджер. Не обошли стороной вайб-кодинг и AI для личной эффективности.

Из разговора мне больше всего запомнилась история Юры про его опыт с AI агентами. У него кастомная команда агентов поверх Claude Code и каждую ночь они проводят ретро пока он спит. Так вот целую неделю подряд они называли его ботлнеком и жаловались друг-другу на него.

Послушать целиком можно в Я.Музыке, Apple, YouTube.

PS: я впервые участвовал в подкасте - новый интересный опыт для меня. Буду рад вашему фидбеку.

@max_about_ai

Наконец дошли руки посмотреть материалы курса Stanford “CS146S: The Modern Software Developer”. Видеозаписей, к сожалению, в открытом доступе нет, но есть презентации и отличная подборка материалов для чтения и просмотра.

Мне особенно понравилась презентация про Code Review. Навык, который всегда был важным, но c 2025 года стал еще важнее. Если собеседуете кандидатов - обязательно добавляйте задачки на код ревью, а если сами собеседуетесь - будьте готовы к ним.

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

В общем, если еще не видели этот курс и ссылки из его подборки, то полезно ознакомиться.

@max_about_ai

Про документацию в эпоху AI

Пару недель назад делал доклад про документацию в эпоху AI. Записи у меня к сожалению нет, но поделюсь основными тезисами:

1⃣ AI сильно упростил не только написание кода, но и генерацию документации. Нужна ли она, если теперь есть возможно получить ответы на естественном языке прямо по коду? Я считаю, что да.

2⃣ Надо разделять документацию по критерию - является ли она источником истины (например, функциональные или архитектурные требования) от документации сгенерированный по коду (quick start, user guide и тд). Это важно, чтобы понимать где искать ответ - как система должна работать (в исходных требованиях) и как система на самом деле работает (в коде).

3⃣ У разных команд (фриланс, стартап, корпорация) разные требования к объему и пайплайну работы с документацией. Не переусложняйте, но и не забивайте совсем.

4⃣ Люди по-прежнему несут ответственность за документацию

5⃣ Назначьте и контролируйте ownership для документов.

6⃣ Начните хранить документацию вместе с кодом (markdown)

7⃣ Ревьювьте изменения в доках вместе с PR (удобно если лежит вместе с кодом)

8⃣ Используйте MCP / CLI для чтения и обновления документации, которая хранится отдельно от кода

9⃣ Встройте генерацию документов и автоматическое обновление в ваш пайплайн (skills, agents.md или отдельный hook в CI/CD)

1⃣0️⃣ Приведите документацию в порядок. Для AI агентов работает правило: garbage in - garbage out

Подписаться

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

Никому не хочется читать очередной нейрослоп в вашей перформанс-форме или анализе инцидента. Сотрудникам платят не за копипасту из ChatGPT и никого не интересует, что это не ваша ошибка, а AI так сгенерировал. Если вы отправляете что-то от своего имени - это ваша ответственность и репутация. Это не означает что AI не надо использовать, просто потратьте время на проверку, исправление ошибок и улучшение результата.

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

@max_about_ai

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

Чтобы

- разобраться в том как стать эффективнее самому, но не выгореть от FOMO,
- как внедрить AI в команду и повысить ее продуктивность,

мы вместе с другими спикерами решили организовать бесплатную конференцию - AI Hard Fork.

Удалось собрать вместе очень крутой состав выступающих - CTO, x-staff из FAANG, тех лиды и фаундеры. Но главное - все они на личном опыте разбираются в том, о чем говорят, а не пересказывают презу, сгенерированную в ChatGPT.

Даты: с 24 по 26 февраля (с 18 до 21 мск), зарегистрировавшимся будут доступны записи.

Посмотреть детали и зарегистрироваться

Выжимка из интервью Ленни Ракитски с Шервиным Ву, ведущим инженером из OpenAI:

1️⃣ AI пишет почти весь код в OpenAI. 95% инженеров используют Codex, а те, кто реально встраивает эти инструменты в работу, открывают на 70% больше pull requests, чем их коллеги - и разрыв со временем только растет.

2️⃣ Роль software engineer смещается от написания кода к управлению флотом AI-агентов. Многие инженеры ведут 10-20 параллельных Codex сессий, больше направляют и ревьюят, чем пишут код руками.

3️⃣ Среднее время code review одного PR сократилось с 10-15 минут до 2-3 минут. Каждый pull request в OpenAI теперь сначала проверяет Codex, еще до того как его увидит человек: он поднимает рекомендации и ловит проблемы заранее. В итоге инженеры могут сфокусироваться на более креативной и стратегической работе, при этом продуктивность резко растет.

4️⃣ В AI-продуктах не стоит оптимизироваться под текущие возможности модели. Область развивается настолько быстро, что то, что сегодня кажется обязательным (vector stores, agent frameworks и так далее), завтра может стать ненужным по мере улучшения моделей.

5️⃣ Стройте под то, куда модели идут, а не под то, где они сегодня. Самые успешные AI-стартапы делают продукты, которые сейчас работают на 80% возможностей, понимая, что следующий релиз модели просто дотянет их до нужного уровня.

6️⃣ Топовые исполнители становятся непропорционально продуктивнее с AI-инструментами. AI усиливает людей с высокой инициативностью, поэтому разрыв между топами и остальными увеличивается. ROI от того, чтобы разблокировать и усилить лучших людей, в AI-усиленной среде начинает компаундиться быстрее, чем когда-либо.

7️⃣ У большинства enterprise-внедрений AI отрицательный ROI, потому что это top-down внедрение не работает без bottom-up адаптации. Успех требует и поддержки руководства, и инициативы снизу. Sherwin рекомендует собрать “tiger team” из технически мыслящих энтузиастов (часто это не инженеры), которые смогут исследовать возможности, прикладывать AI к конкретным workflow и разгонять интерес по всей организации.

8️⃣ Стартап на одного человека с капитализацией в миллиард уже на подходе, но важнее - эффекты второго порядка. По мере роста индивидуальной продуктивности мы увидим не только соло-фаундеров на $1B, но и взрыв малого бизнеса: сотни стартапов на $100M и десятки тысяч на $10M. Это изменит экосистему стартапов и ландшафт венчурного рынка.

9️⃣ Автоматизация бизнес-процессов - недооцененная возможность для AI. Пока стартапы Кремниевой долины фокусируются на knowledge work, большая часть экономики держится на повторяемых процессах и операционке (SOP). Потенциал применения AI к таким workflow огромный, но тех-сообщество часто это упускает.

1️⃣0️⃣ Следующие 2-3 года будут самыми захватывающими в истории технологий. После относительно тихого периода 2015-2020 мы вошли в беспрецедентную эпоху инноваций. Sherwin призывает всех активно встраивать AI-инструменты в работу и не воспринимать этот момент как должное - со временем темп изменений замедлится.

1️⃣1️⃣ AI-модели скоро смогут связно выполнять задачи на много часов. Сегодняшние модели заточены под задачи на минуты, но в ближайшие 12-18 месяцев появятся модели, которые смогут держать контекст и работать над сложной задачей больше шести часов. Это откроет новые категории продуктов и workflow.

1️⃣2️⃣ Аудио - следующий фронтир multimodal AI. Пока больше всего внимания уходит в код и текст, аудио в бизнесе сильно недооценено. Улучшения в speech-to-speech моделях в ближайшие 6-12 месяцев откроют новые возможности для бизнес-коммуникаций и операционных процессов.

Я обычно не пишу новости и тем более переводы, но лучше чем Lenny Rakitsky и Sherwin Wu я все равно не сформулировал бы (оригинал).

Подписаться

Рынок разработки меняется. Старые роли уходят и появляются новые. Одна из таких ролей - Product Engineer.

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

Если вам интересно узнать больше про роль Product Engineer: чем она отличается от обычного Full-stack Engineer или Product Manager - приходите послушать мое выступление на бесплатной конференции ROИИ 2026.

Конференция пройдет с 19 по 20 февраля (13:00 - 21:00 МСК), а я выступаю последним - 20 февраля в 20:00 (МСК).

А еще на конференции будет много других классных докладов от фаундеров, тех-лидов, CPO, CTO и Head of AI. Сам планирую не только выступать, но и смотреть.

Детали и регистрация

@max_about_ai