Max: AI, Engineering and Startups

Почему я пока не верю в универсальные темные фабрики софта (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

Расскажите про свои пет-проекты До появления вайб-кодинга у меня было 5-6 репозиториев в GitHub. Сейчас их 27 и почти все - кладбище недоделанных пет-проектов. Надеюсь что хотя бы несколько из них будут когда-нибудь доведены до конца. Я уверен, что среди вас есть много тех, кто оказался успешнее в своих пет-проектах. Поделитесь ими в комментариях под этим постом. Расскажите, какие пет-проекты вы делаете, для кого, зачем, какой стек технологий, используете AI инструменты, и если да, то какие? Подписаться

Про мои инструменты и agents.md Я преимущественно использую Antigravity, Codex и Warp для разработки. Каждый из инструментов дает некоторые дополнительно возможности, которых нет у других. С Codex - можно удобно работать c телефона. Antigravity - это полноценное IDE с скилами и Agent Manager. А Warp - классный терминал с AI функциями. Мне важно держать настройки AI агентов синхронизированными. А еще очень важно чтобы спека обновлялась по мере написания кода и тесты обновлялись и запускались. Поэтому, не смотря на то, что для каждого нового проекта я обычно создаю свой Agents.md и WARP.md, есть правила, которые кочуют со мной всегда из одного проекта в другой - это правила обновления документации и тестов, рекомендую: When making changes to this codebase: - Always update documentation and scripts - keep README, WARP.md, AGENTS.md, PRD.md and any relevant scripts and documentation in sync with code changes. - Always update tests and run them - add or modify tests for any changed functionality, then run the tests to verify all tests pass before completing the task. Подписаться

Мы навайбкодили с дочкой игру на праздниках Позавчера дочка (7 лет) спросила можем ли мы сделать игру про ее любимых персонажей. Через пару минут она уже надиктовывала голосом описание первой версии игры. Дальше я закинул её заметки в Replit, попросил его причесать их, он сделал план и через 19 минут и 6.8$ у нас уже была первая задеплоенная версия игры, в которую можно играть. Дочка “потестила” её - нашла пару “багов” и предложила несколько новых улучшений. Я тоже немного вмешался в геймпей и добавил задания, предназначенные для обучения чтению. Результат 5-7 итераций, пары часов и 33$ можно посмотреть на скриншоте или здесь: https://cozy-orbs-home-quest.replit.app. Всех с Новым Годом! 🎄 В комментах было пару важных вопросов: Replit взял, потому что были включенные в подписку кредиты, иначе 33$ - это, на мой взгляд, дорого. Хотя радость ребенка и учеба чтению все равно бесценно. Промпт надиктованный ребенком (все оговорки и ошибки транскрибации я сохранил при генерации приложения) Я хотела это сквишмэлоу чтобы там могли с каждым раундом их было можно разные получать и ещё чтоб можно было менять обои у них ещё чтобы они смогли там жизнь как обычно там ходить в туалетом всякое есть разные кушать всякое разное Подписаться