Дмитрий Долгов Рабочее демо — это 1% работы. Продукт — это девятки после запятой. AI для физического мира создавать принципиально сложнее, чем обычный софт. В интернете можно следовать принципу move fast and break things: выпустить достаточно хорошую версию, собрать ошибки пользователей и быстро её улучшить. Но когда AI управляет автомобилем, роботом или другим физическим объектом, цена ошибки совсем другая. Здесь нужно не ship fast, а ship safely. Безопасность нельзя добавить после запуска — она должна быть фундаментом системы с первого дня. Долгов выделил четыре разрыва между обычным и физическим AI: 1. Цена ошибки. Неверный ответ чат-бота раздражает. Неверное действие машины может стоить жизни. 2. Задержка. Решение нужно принимать не через несколько секунд, а практически мгновенно. 3. Данные. Самые опасные ситуации случаются редко, поэтому реальных примеров недостаточно. 4. Валидация. В цифровом продукте крайние случаи могут найти пользователи. В физическом мире нельзя поручить клиентам тестирование безопасности. Отсюда главный тезис: работающий прототип — лишь начало. Если система должна ошибаться не чаще одного раза на миллион, каждая следующая девятка надёжности требует примерно в десять раз больше усилий. Поэтому ещё до разработки важно понимать: сколько девяток действительно требует ваш продукт? Одна из ключевых технологий Waymo — симулятор. Он позволяет не только проверить действие автомобиля, но и исследовать контрфактические сценарии: что произошло бы, если бы машина затормозила раньше, выбрала другую траекторию или иначе отреагировала на участника движения. Получается не одна модель, а целая обучающаяся система: агент действует → симулятор моделирует последствия → критик проверяет решение → реальные поездки создают новые данные → данные улучшают симулятор и следующую версию агента. Это, пожалуй, самый важный урок и для нынешней волны AI-агентов. Недостаточно построить умного исполнителя. Нужны ещё среда, в которой он может безопасно практиковаться, и независимая система, способная оценить его работу. Иными словами: > Не просто создавайте AI-агента. Создавайте экосистему, которая учит его действовать, проверяет последствия и с каждым циклом делает всю систему надёжнее. Отдельно запомнилась мысль Долгова о технологиях. Железо будет меняться, компоненты — дешеветь и превращаться в массовый товар. Поэтому главное преимущество команды — не умение идеально использовать одну сегодняшнюю технологию, а способность снова и снова осваивать следующие технологические волны. Победит не тот, у кого сегодня самое эффектное демо. Победит тот, кто построит систему, способную безопасно учиться, проверять себя и становиться надёжнее после каждого реального действия.

Борис Черный Главная мысль его выступления: продукты на базе AI теперь строятся не как обычный софт, а почти как экспериментальная наука. Каждое новое поколение моделей ведёт себя иначе. Поэтому нельзя заранее придумать огромный system prompt и сложную архитектуру, а потом годами их улучшать. Сначала нужно убрать почти всё, дать модели сложную реальную задачу и посмотреть, где она действительно ломается. Инструкцию стоит добавлять только тогда, когда одна и та же ошибка повторяется. Именно так команда Claude Code удалила около 80% system prompt для новой модели: большая часть старых правил компенсировала ограничения, которых у неё уже не было. Иногда модель без этих инструкций работала даже лучше. Борис назвал главную возможность для стартапов «product overhang»: современные модели уже умеют гораздо больше, чем позволяют существующие продукты. Мы часто сами ограничиваем AI — дробим работу на слишком маленькие шаги, подробно диктуем способ решения и не даём достаточно инструментов и свободы. Правильный подход — поставить задачу немного сложнее, чем кажется возможным, задать ограничения и критерий завершения, дать инструменты для самопроверки и позволить модели самой найти путь. Ключевой элемент здесь — не промпт, а верификация. Claude смог 11 дней переписывать runtime Bun с Zig на Rust, потому что у проекта был сильный набор тестов. Другой агент уже больше двух недель переписывает Electron-приложение на Swift, постоянно запускает результат и сравнивает интерфейс по скриншотам. Долгая автономная работа становится возможной, когда система сама понимает, приблизилась ли она к правильному результату. Ещё один сдвиг — тысячи агентов становятся новой формой вычисления. Они могут параллельно исследовать варианты, писать код, проверять друг друга и собирать итог. А постоянные routines уже ежедневно поддерживают кодовую базу Anthropic: удаляют мёртвый код, закрывают эксперименты, улучшают тесты и объединяют дублирующиеся абстракции. Мой главный вывод: в эпоху агентов выигрывает не тот, кто написал самый сложный промпт. Выигрывает тот, кто умеет дать модели настоящую работу, достаточную свободу и объективный способ доказать, что работа действительно выполнена. Коротко: ставьте более сложные задачи, меньше диктуйте способ решения и инвестируйте в проверяемость результата.

Если не видели, Anthropic выложили руководство по контексту для моделей 5 серии, раз уж и Opus присоединился к их числу. В принципе, это обобщенные правила из документации соответствующих моделей и в целом рекомендации можно свести к удалению большого количества нормативных правил, удалению примеров (новые модели склонны воспринимать их не как иллюстрации, а как прямые инструкции "Делай только так"), советуют также разделить большие скиллы и промпты на подгружаемые части. Представлена также новая команда Claude Code — /doctor или claude doctor из командной строки, — она инспектирует имеющиеся настройки и скиллы и предлагает их реструктуризацию. Только не относитесь к рекомендациям, как к догме — у меня она предложила удалить скиллы, которые ни разу не использовались за последние несколько дней, что в целом разумно, но в их число попали как скиллы для работы с Obsidian (просто реально на этой неделе именно Claude Code туда не ходил) и скиллы model-invocable — их вызов моделью на уровне субагентов может не триггерить счетчики. https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

У Сбера есть интересный whitepaper где он описывает технологию разработки продукта с помощью агентных циклов. Можно сколько угодно не любить корпоратов, но игнорировать тренд, который формируется у нас на глазах - это просто глупо. Хотим мы этого или нет, но основой работы для инженеров становится архитектура агентных циклов, умение выстраивать процессы, делать оценку качества, вносить и контролировать метрики качества. Это работает потому что бизнесу интересно выпускать фичи в 2-3 раза быстрее, даже за счет дополнительных издержек на производство этих фич. Некоторое время еще можно подождать, чтобы убедиться, что тренд устойчив, но, ИМХО, цикл ранних последователей уже скоро закончится.

Как измерять работу программистов CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить? В среде программистов есть много мнений по поводу метрик и нужно ли измерять производительность разработчика. Очевидные метрики, которые придумает HR: - Присутствие на рабочем месте - Количество выполненных задач - Количество часов, затраченных на выполнение этих задач - Уложился ли в план

Неочевидные метрики, которые добавит CTO: - "Бизнес ценность" — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса. - "Стори пойнты" — баллы трудоёмкости. Разработчики собираются на "Покер Планирования" и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32). - Количество багов в коде, написанном разработчиком. - Скорость — любые баллы делим на время. - % отклонения от собственной или командной оценки.

Проблема заключается в том, что индивидуальный разработчик может провалить все эти метрики, но при этом положительно влиять на производительность команды. Или же выполнять план, но демотивировать группу. Рассмотрим роль тимлида в качестве примера: индивидуальная отгрузка ниже среднего, но каждый разработчик под его влиянием работает быстрее и качественнее. Увольнять его на основании общих метрик просто преступно. Программисты под надзором точно работают, без него — состояние неопределённое. Поэтому без внешнего контроля не обойтись. Что с этим делать? - Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку. - Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

Закончилась эпоха Недавно Дядюшка Боб (автор книг "Чистый код", "Чистая архитектура" и т.д.) заявил, что вообще не читает код, который пишет LLM, вместо этого он использует ограничения в виде автоматизированных тестов и других проверок. Подобных заявлений с каждым днем становится все больше и количество будет только расти. Можно возразить, мол "а как же качество?". На самом деле за последние два года качество генерации сильно возросло, если грамотно гранулировать задачу, можно обойти многие ограничения ИИ (например, дублирование функций и классов, если их нет в контексте, и тому подобные вещи). Фокус ушел на AiSDLC и описание архитектуры проекта. Мне кажется, в моменте мы переживаем этап взросления разработки, когда от написания кода мы уходим к архитектуре и идеям. В этом смысле Роберт Мартин не изменяет своим принципам – он всегда топил за более высокоуровневый взгляд на программирование, и теперь ему стало делать это чуть проще. Но что будет с кодом? Мне кажется, что примерно то же, что произошло с ассемблером: как рабочий инструмент его мало кто использует, но интерес к пониманию того, как все работает, остался, многие смотрят видео по низкому уровню просто из любопытства, из-за того вайба, который дает погружение в инженерию. Поэтому код не исчезнет, просто заниматься им будут по желанию, из любопытства, а не потому что надо.

Попробовал я эту вашу разработку с субагентами, скилами, хуками и прочим. Объектвино, более бесполезной и тупой вещи я в жизни не видел. Для соло разработки худшее что вы можете сделать - это настроить агентский цикл с разбором задачи, исполнением, тестированием, ревью и прочей шелухой. Скорость разработки падает в разы. Простая задача по интергрированию 2 ручек в проект и созданием одной таблицы начинает занимать час, а то и более. Я буквально сам сделал бы это быстрее. Количество токенов растет так же в каких-то гигантских масштабах. Столько лимитов, сколько жрет 1 проект у меня не жрало 3 проекта параллельно. В итоге главные преимущества работы с нейронкой сводятся на нет. Да, скорее всего я ее неверно настроил, и надо будеь попробовать нормально. Как то ранжировать задачи, что бы мелкие не прогонять по всему пайплайну, а крупные наоборот гонять по всему пайпу

Все советы Anthropic по разработке за "лето" Студентам советую раз в неделю читать что выходило свежего у OpenAI/Anthropic по разработке с помощью ИИ. На мой взгляд это сейчас самый передний край и проверенное. Лучше всяких ютюб-блогеров. Внутри у них ~80% смерженного кода уже пишет ИИ, инженеры шипят в 8 раз больше, чем в 2021–2025. И они довольно подробно рассказывают, как это устроено. Вот что, имхо, самое полезное было (в PDF подробно, можете почитать и отдать ИИ) 1. Узкое место теперь не написание кода, а проверка. Агенты генерят быстрее, чем люди ревьюят, поэтому все инвестиции – в верификацию. Практически: выписываете всё, что повторно исправляете за моделью, и кодируете в скиллы-проверки (.claude/skills) – агент сам гоняет тесты и чинит до сдачи. Сама команда Claude Code гоняет цепочку /code-review → /simplify → /verify, а потом те же проверки гейтом на каждый PR. 2. CLAUDE.md – короче 200 строк и без очевидного. Только точные команды тестов по подкаталогам (иначе модель запускает полный сьют на 40 минут) и то, что противоречит дефолтам модели. И пересматривать раз в 3–6 месяцев – правила под старые модели душат новые. 3. Разделение простое: пожелание – в CLAUDE.md, процедура – в скилл, закон – в хук. Линтер после каждой правки и блокировка rm -rf – только хуками, скилл модель может и забыть вызвать. 4. Ревью переразделили: ИИ – стиль, линтинг, отлов багов, тесты (несколько узких агентов, с каждой находки требуют доказательств – доля содержательных комментариев выросла с 16% до 54%). Люди – security, границы доверия, продукт. Автономному агенту – минимум прав: их инцидент-бот умеет писать доки и читать логи, деплоить – нет. 5. Самый огненный кейс – миграции. Bun перевели с Zig на Rust: миллион строк за 2 недели и ~$165k в токенах (раньше такое стоило $3–4 млн и 4 года). Рецепт: сначала тесты против обеих кодовых баз, потом rulebook правил перевода, дальше дешёвые модели переводят, дорогие ревьюят. Главный принцип – повторяющийся фейл это баг правила, а не файла: правишь rulebook и перегенерируешь, руками не патчишь. Я так переписывал gtfs.guru, скоро выложу мажорный релиз https://claude.com/blog