Как спорить об ИИ-агентах
Нередко приходится читать вот такие комменты:
tl;dr: нужно как минимум вот так:
... и это в разы сокращает время на выяснение очень существенных деталей.
Почему именно так?
Что нам даёт такая детализация для понимания того, о чём мы спорим:
● Продукт
Codex - это несколько разных продуктов OpenAI, включая модели, локальные и облачные агенты, расширение для IDEи Codex Astartes.
Тут же явно написано, что это Codex CLI, локальный консольный агент.
С Claude то же самое: это и модели (Sonnet/Opus), и Claude Code, и Claude Desktop и т.п.
● Модель - тут у нас GPT и [Claude] Opus
● Версия модели
Видно, что мы обсуждаем актуальные релизы, а не то, что уже мхом поросло за прошедшие несколько месяцев
● Вариант модели
Конкретно у GPT 5+ есть тюн, Codex, который отличается от обычной GPT 5.2 по агентным возможностям и по работе с ризонингом
● Уровень ризонинга
Указан xhigh (ещё бывает low/medium/high). Доступен к изменению не у всех моделей, но кардинально влияет на продуманность выдаваемых решений
● Агент (обвязка)
Понятно, в составе каких агентов работают модели - это "родные", вендорские Claude Code & Codex CLI.
В разных агентах модель может вести себя совершенно по-разному, и те же GitHub Copilot & Cursor могут ощутимо отуплять модели
● Поставленная задача
У текущих агентов и моделей сильно разные возможности и способности к решению разных проблем, и именно поэтому нередко приходится использовать несколько разных в одном проекте
● С чем ведётся сравнение и от какого опыта собеседника можно отталкиваться
—
❗️Между разными связками модель + агент качество результата, производительность и уровень автономности могут отличаться на десятки процентов и казаться либо совершенно неприемлемыми для работы, либо чудом.
Так что перечисленные характеристики - база для конструктивного и предметного обсуждения ИИ-агентов.
Я не говорю про версии самих агентов, повторяемость результатов, стабильность работы, промптинг, методологию, качество кодовой базы, сложность и гранулярность задач, локальные нейронки и т.п. - там куча своих нюансов :)
P.S.
● а GPT 5.2 (не-Codex) xhigh на этой задаче ещё лучше!
● нет, это не реклама, уже 5.1 лучше была - см. обзор, в чём конкретно
● но мы все ждём вскоре Sonnet 5 / Opus 4.6 / GPT 5.3 / Gemini 3 Pro GA, а там посмотрим :)
Нередко приходится читать вот такие комменты:
codex - фигня
клод вообще тащит
tl;dr: нужно как минимум вот так:
GPT-5.2-Codex xhigh + Codex CLI лучше Opus 4.5 + Claude Code в решении архитектурных задач
... и это в разы сокращает время на выяснение очень существенных деталей.
Почему именно так?
Что нам даёт такая детализация для понимания того, о чём мы спорим:
● Продукт
Codex - это несколько разных продуктов OpenAI, включая модели, локальные и облачные агенты, расширение для IDE
Тут же явно написано, что это Codex CLI, локальный консольный агент.
С Claude то же самое: это и модели (Sonnet/Opus), и Claude Code, и Claude Desktop и т.п.
● Модель - тут у нас GPT и [Claude] Opus
● Версия модели
Видно, что мы обсуждаем актуальные релизы, а не то, что уже мхом поросло за прошедшие несколько месяцев
● Вариант модели
Конкретно у GPT 5+ есть тюн, Codex, который отличается от обычной GPT 5.2 по агентным возможностям и по работе с ризонингом
● Уровень ризонинга
Указан xhigh (ещё бывает low/medium/high). Доступен к изменению не у всех моделей, но кардинально влияет на продуманность выдаваемых решений
● Агент (обвязка)
Понятно, в составе каких агентов работают модели - это "родные", вендорские Claude Code & Codex CLI.
В разных агентах модель может вести себя совершенно по-разному, и те же GitHub Copilot & Cursor могут ощутимо отуплять модели
● Поставленная задача
У текущих агентов и моделей сильно разные возможности и способности к решению разных проблем, и именно поэтому нередко приходится использовать несколько разных в одном проекте
● С чем ведётся сравнение и от какого опыта собеседника можно отталкиваться
—
❗️Между разными связками модель + агент качество результата, производительность и уровень автономности могут отличаться на десятки процентов и казаться либо совершенно неприемлемыми для работы, либо чудом.
Так что перечисленные характеристики - база для конструктивного и предметного обсуждения ИИ-агентов.
Я не говорю про версии самих агентов, повторяемость результатов, стабильность работы, промптинг, методологию, качество кодовой базы, сложность и гранулярность задач, локальные нейронки и т.п. - там куча своих нюансов :)
P.S.
● а GPT 5.2 (не-Codex) xhigh на этой задаче ещё лучше!
● нет, это не реклама, уже 5.1 лучше была - см. обзор, в чём конкретно
● но мы все ждём вскоре Sonnet 5 / Opus 4.6 / GPT 5.3 / Gemini 3 Pro GA, а там посмотрим :)
6💯43👍19🔥14👏3😁2
Forwarded from Уставший техдир
Режим команды агентов
Ну что, будущее наступило, я сейчас описал команду, базовые роли, и дал продуктовую задачу. Сижу и наблюдаю, как они пишут спеки, дополняют требования, а вот сейчас пошли писать код, по расписанной продуктовой и системной аналитике, по разделенным на стори фичам, с описанными DoD'ами и полной аналитикой по UX
Как это работает: основной агент, может создавать агентов, делегировать им задачи, и коммуницировать с ними. У них есть общий список задач и агенты могут переписываться между собой (у них условный аналог почты). Ты основному агенту описываешь состав команды и говоришь - спавни (либо он может предложить сам решить задачу командой агентов, если посчитает, что задача этого стоит. И дальше начинает их тимлидить
Какие в целом причины выделять в агентов отдельные роли:
1. Фокусировка. Агенты, когда работают над задачей или список гипотез начинают тяготеть к одной из гипотез или к одному аспекту. Например ты скажешь ему "проверь прозводительность, безопасность и следование архитектуре". Он сделает первое хорошо, а остальное "по остаточному принципу. И чтобы повысить качество решения надо дать три задачи раздельно (прям как у людей)
2. Создание противоречия. Разработчик хочет побыстрее написать код, безопасник хочет, чтобы код был безопасным, QA - чтобы приложение работало. Они все три находятся в противоречии — выделив в отдельные роли и заставив их совместно работать, дебатируя и ищя консенсус мы повышаем качество результата (да-да, снова как и у людей)
3. Ограничение контекстного окна. Модель ограничена, нельзя дать ей весь проект целиком. Она в голове может удержать ограниченное количество данных, поэтому когда мы работаем тестировщиком, мы держим одни данные, а аналитиком — другие. Опять за счет фокуса на конкретной задаче снижаем объем данных, которые нужно держать "в голове" — а это, опять же, повышает внимание модели к деталям (чем меньше контекст, тем больше внимания. Опять же, как у человеков)
4. Конвергенция организационных паттернов (извините 🤓). Мы, как человеки, десятилетиями накапливали паттерны, которые повышают качество результата: продуктовые и функциональные требования, декомпозиция на стори \ таски, DoR/DoD, выделения ролей и границы ролей. Мы лечили проблемы человеков, а оказалось, что агенты страдают этими же проблемами. Оказалось закон Конвея имеет обратную силу (оказывается, что сама природа сложной задачи требует определенной организационной структуры)
5. Качество. Если хотим, например, чтобы на каждую аналитику приходил дизайнер и дополнял, и QA дополнял ее DoD'ами и писал план тестирования и сценарии для e2e/unit, которые должны быть покрыты
Короче, все как всегда. Вы думали будет "тык" и магия? Хрен. Проектируй процесс, ответственности, требования, гайдлайны, накапливай успешные решения и практики, применяй, анализируй, добавляй недостающие, выкидывай ненужное. Чем сложнее систему строишь, тем дороже потом её содержать, но тем выше качество по нужным тебе аспектам. Все как всегда свелось к простому — хочешь чтобы было красиво, трать ресурс на красиво, хочешь еще безопасность, бери в команду безопасника
Официальная дока: https://code.claude.com/docs/ru/agent-teams
П.С. Забавный факт, я попросил создать просто Software Engineer роль, но агент решил выделить отдельно фронтендера и бэкендера. Штош
Ну что, будущее наступило, я сейчас описал команду, базовые роли, и дал продуктовую задачу. Сижу и наблюдаю, как они пишут спеки, дополняют требования, а вот сейчас пошли писать код, по расписанной продуктовой и системной аналитике, по разделенным на стори фичам, с описанными DoD'ами и полной аналитикой по UX
Как это работает: основной агент, может создавать агентов, делегировать им задачи, и коммуницировать с ними. У них есть общий список задач и агенты могут переписываться между собой (у них условный аналог почты). Ты основному агенту описываешь состав команды и говоришь - спавни (либо он может предложить сам решить задачу командой агентов, если посчитает, что задача этого стоит. И дальше начинает их тимлидить
Какие в целом причины выделять в агентов отдельные роли:
1. Фокусировка. Агенты, когда работают над задачей или список гипотез начинают тяготеть к одной из гипотез или к одному аспекту. Например ты скажешь ему "проверь прозводительность, безопасность и следование архитектуре". Он сделает первое хорошо, а остальное "по остаточному принципу. И чтобы повысить качество решения надо дать три задачи раздельно (прям как у людей)
2. Создание противоречия. Разработчик хочет побыстрее написать код, безопасник хочет, чтобы код был безопасным, QA - чтобы приложение работало. Они все три находятся в противоречии — выделив в отдельные роли и заставив их совместно работать, дебатируя и ищя консенсус мы повышаем качество результата (да-да, снова как и у людей)
3. Ограничение контекстного окна. Модель ограничена, нельзя дать ей весь проект целиком. Она в голове может удержать ограниченное количество данных, поэтому когда мы работаем тестировщиком, мы держим одни данные, а аналитиком — другие. Опять за счет фокуса на конкретной задаче снижаем объем данных, которые нужно держать "в голове" — а это, опять же, повышает внимание модели к деталям (чем меньше контекст, тем больше внимания. Опять же, как у человеков)
4. Конвергенция организационных паттернов (извините 🤓). Мы, как человеки, десятилетиями накапливали паттерны, которые повышают качество результата: продуктовые и функциональные требования, декомпозиция на стори \ таски, DoR/DoD, выделения ролей и границы ролей. Мы лечили проблемы человеков, а оказалось, что агенты страдают этими же проблемами. Оказалось закон Конвея имеет обратную силу (оказывается, что сама природа сложной задачи требует определенной организационной структуры)
5. Качество. Если хотим, например, чтобы на каждую аналитику приходил дизайнер и дополнял, и QA дополнял ее DoD'ами и писал план тестирования и сценарии для e2e/unit, которые должны быть покрыты
Короче, все как всегда. Вы думали будет "тык" и магия? Хрен. Проектируй процесс, ответственности, требования, гайдлайны, накапливай успешные решения и практики, применяй, анализируй, добавляй недостающие, выкидывай ненужное. Чем сложнее систему строишь, тем дороже потом её содержать, но тем выше качество по нужным тебе аспектам. Все как всегда свелось к простому — хочешь чтобы было красиво, трать ресурс на красиво, хочешь еще безопасность, бери в команду безопасника
Официальная дока: https://code.claude.com/docs/ru/agent-teams
П.С. Забавный факт, я попросил создать просто Software Engineer роль, но агент решил выделить отдельно фронтендера и бэкендера. Штош
Claude Code Docs
Координируйте команды сеансов Claude Code - Claude Code Docs
Координируйте несколько экземпляров Claude Code, работающих вместе как команда, с общими задачами, обменом сообщениями между агентами и централизованным управлением.
4👍40🔥24❤21🤣3
Критерии оценки ИИ-агентов
Мы окончательно вошли в пост-бенчмарк эру, и формальные бенчи LLM/агентов дают всё меньше ценности.
Так что у меня выработались субъективные, вайб-метрики (пусть даже некоторые и выведены из численных/качественных показателей).
Методика простая: есть ряд отложенных типовых проектов/задач + повседневные рабочие задачи, которые я даю тестируемым агентам в параллель и сравниваю результаты.
Оцениваю я работу именно агентов, и используются только родные, вендорские обвязки (к примеру, Claude Code / Codex CLI).
Оценки по каждому из критериев от 1 до 10, и выставляются относительно лучшего агента из сравниваемых (т.е. 10 ≠ абсолют).
База
● Ризонинг
Способность к многоходовым логическим цепочкам, нетривиальным выводам, пониманию неочевидных зависимостей, глубина мышления.
● Работа с контекстом
Удержание, экономность использования, галлюцинации, способность проносить важные детали через компактизации.
● Следование инструкциям
... плюс способность их принимать во внимание все разом, внимание к мелочам, управляемость.
● Агентность
Автономное выполнение задач с эффективным использованием выданных инструментов (и создание своих на ходу), а также способность доводить работу до конца.
Способности
● Планирование
Анализ требований, их непротиворечивости и осуществимости, с граундингом на существующий проект, адекватная разбивка по этапам и задачам.
● Архитектура
Способность понимать, оперировать и следовать архитектурным концепциям и установленным границам, предлагать неконфликтующие изменения.
● Рефакторинг
Понимание типовых рефакторингов, code smells и способность делать аккуратные изменения в существующей кодовой базе, не ломая проект и не оставляя хвостов.
● Трейсинг (расследование)
Умение качественно "идти по следу", когда нужно раскопать какой-то баг, найти проблемы с безопасностью, провести code review.
Эксплуатация
● Инструментарий
Возможности и удобства, предоставляемые пользователю агента, кастомизация воркфлоу, автоматизация (SDK, App Server), набор интерфейсов (CLI / GUI / Web).
● Стабильность
Насколько стабилен и повторяем выдаваемый результат с т.з. качества на схожих задачах.
● Скорость
Тут как размышления, так и генерация токенов, и в целом скорость внесения изменений в проект.
● Экономность
Насколько много агент тратит токенов на успешное решение задачи и насколько это дорого выходит.
● Софт-скиллы?
Суровый ботан или восторженный подхалим? Ну нееет, это отдельная тема, как-нибудь потом :)
—
Прошлые обзоры можно посмотреть по тегу: #review
Мы окончательно вошли в пост-бенчмарк эру, и формальные бенчи LLM/агентов дают всё меньше ценности.
Так что у меня выработались субъективные, вайб-метрики (пусть даже некоторые и выведены из численных/качественных показателей).
Методика простая: есть ряд отложенных типовых проектов/задач + повседневные рабочие задачи, которые я даю тестируемым агентам в параллель и сравниваю результаты.
Оцениваю я работу именно агентов, и используются только родные, вендорские обвязки (к примеру, Claude Code / Codex CLI).
Оценки по каждому из критериев от 1 до 10, и выставляются относительно лучшего агента из сравниваемых (т.е. 10 ≠ абсолют).
База
● Ризонинг
Способность к многоходовым логическим цепочкам, нетривиальным выводам, пониманию неочевидных зависимостей, глубина мышления.
● Работа с контекстом
Удержание, экономность использования, галлюцинации, способность проносить важные детали через компактизации.
● Следование инструкциям
... плюс способность их принимать во внимание все разом, внимание к мелочам, управляемость.
● Агентность
Автономное выполнение задач с эффективным использованием выданных инструментов (и создание своих на ходу), а также способность доводить работу до конца.
Способности
● Планирование
Анализ требований, их непротиворечивости и осуществимости, с граундингом на существующий проект, адекватная разбивка по этапам и задачам.
● Архитектура
Способность понимать, оперировать и следовать архитектурным концепциям и установленным границам, предлагать неконфликтующие изменения.
● Рефакторинг
Понимание типовых рефакторингов, code smells и способность делать аккуратные изменения в существующей кодовой базе, не ломая проект и не оставляя хвостов.
● Трейсинг (расследование)
Умение качественно "идти по следу", когда нужно раскопать какой-то баг, найти проблемы с безопасностью, провести code review.
Эксплуатация
● Инструментарий
Возможности и удобства, предоставляемые пользователю агента, кастомизация воркфлоу, автоматизация (SDK, App Server), набор интерфейсов (CLI / GUI / Web).
● Стабильность
Насколько стабилен и повторяем выдаваемый результат с т.з. качества на схожих задачах.
● Скорость
Тут как размышления, так и генерация токенов, и в целом скорость внесения изменений в проект.
● Экономность
Насколько много агент тратит токенов на успешное решение задачи и насколько это дорого выходит.
● Софт-скиллы?
Суровый ботан или восторженный подхалим? Ну нееет, это отдельная тема, как-нибудь потом :)
—
Прошлые обзоры можно посмотреть по тегу: #review
👍22🔥17❤8👏2🤣2
Вайб-обзор на GPT-5.3 Codex, Opus 4.6, и (бонус) GPT-5.2 (1/2)
Тееек, потестил новые модели от OpenAI и Anthropic.
Надо сказать, что сравнивать модели становится всё нетривиальнее и дольше, потому что способности подрастают у них у всех, и отличий в качестве исполнения чисто технических задач становится всё меньше.
Ну, благо нетривиальных рабочих задач пока что хватает :)
tl;dr
● GPT-5.3 Codex - кодер, повседневный инструмент инженера
Шустрый, технически прошаренный, дотошный в исполнении выданных инструкций, но это именно исполнитель
● Opus 4.6 - вайб-генералист
Быстро что-то сделать с нуля, добавить не самую критичную фичу в существующий проект, но нужно держать в узде, если требуется внимательность и точные изменения
● GPT-5.2 - инженер
С ним надёжнее всего планировать, обсуждать варианты решений сложных проблем, и в целом держать проект под строгим контролем
Стандартный дисклеймер
● модели тестируются только в составе родных обвязок
● на платных подписках
● reasoning - максимальный (изредка high вместо xhigh в случае GPT)
Критерии из таблицы и графика (и почему это вайб-обзор) описаны в предыдущем посте.
GPT-5.3 Codex
🟢 Скорость
Это прям главное отличие, которое сразу бросается в глаза. На практике некоторые задачи делает в разы быстрее, чем 5.2 и при этом тратит в разы же меньше токенов.
При том, что она ненамного хуже 5.2 по интеллекту, это делает её удобной в интерактивном использовании, когда вы быстро получаете результат, не выбиваясь из потока.
🟢 Болтливость
Будем считать это плюсом :) Если работать с ней в интерактивном режиме, то модель теперь не сердито сопит и молча что-то делает, а активносторителлит рассказывает, что происходит. И это удобно в сочетании с фичей Steer mode, когда мы можем добрасывать модели указания, не дожидаясь окончания её работы.
Тоже в копилку удержания себя в потоке при интерактивной работе.
🟢 Лучше делает UI/UX
Да, стало лучше, чем в семействе 5.2, но Opus 4.6 тут явный лидер.
🟡 Объем и глубина задач
Несложные и/или вширь, потому что со сложными/вглубь она скорее всего какие-то нюансы потеряет.
Скажем, дать ей какой-то простой рефакторинг типа "избавься от any в проекте" - она и сутки может с ним возиться, и таки доведёт до конца.
А вот составить полноценный план большой фичи с учётом всех деталей - как повезёт.
🟡 Дотошность исполнения
Это отличная модель-исполнитель, но ох, не стоит ей давать необдуманные задачи. Пусть она и не сделает противоречивое и неработающее решение, но ответственно будет следовать абсурдным требованиям.
Сюда же - она очень пронырливая, но её нужно об этом явно просить (в отличие от 5.2, которая старается максимум информации собрать сама).
🔴 Рандомность ризонинга
Это фишка, которая особенно заметна на Codex-семействе моделей - чем сложнее задача, тем дольше и качественнее она думает.
Точка перехода между(терпи, сова) активацией системы 1 и 2 (по Канеману) тут смещена в сторону системы 1 сильнее, чем у базовой модели.
Но со стороны это может выглядеть именно как рандомные по времени ответы, плавающие по качеству.
Этого стало меньше в сравнении с 5.2 Codex, но это всё ещё есть, хотя в прыжке модель может ризонить не хуже базовой 5.2.
Opus 4.6
🟢 Лучше держит контекст
По MRCR у неё какие-то фантастические метрики, делающие модель SOTA на этом бенче, но я этого не вижу в работе.
Да, стало ощутимо лучше в сравнении с Opus 4.5, но до GPT-5-семейства не дотягивает.
Лучше, кстати, стало, как до компактизации, так и после неё - сохраняется больше информации.
🟢 Меньше галлюцинаций и вранья
Это отчасти связано с тем, что модель лучше держит контекст, а отчасти с тем, что она чаще делает граундинг на файлы проекта, чтобы не фантазировать о нём.
🟢 Чаще стала задумываться
Кому-то может показаться, что модель просто замедлилась, но это влияет на качество на сложных задачах - там, где Opus 4.5 старался дать ответ быстрее, Opus 4.6 даёт его правильнее.
продолжение в следующем посте
#ai #model #review
Тееек, потестил новые модели от OpenAI и Anthropic.
Надо сказать, что сравнивать модели становится всё нетривиальнее и дольше, потому что способности подрастают у них у всех, и отличий в качестве исполнения чисто технических задач становится всё меньше.
Ну, благо нетривиальных рабочих задач пока что хватает :)
tl;dr
● GPT-5.3 Codex - кодер, повседневный инструмент инженера
Шустрый, технически прошаренный, дотошный в исполнении выданных инструкций, но это именно исполнитель
● Opus 4.6 - вайб-генералист
Быстро что-то сделать с нуля, добавить не самую критичную фичу в существующий проект, но нужно держать в узде, если требуется внимательность и точные изменения
● GPT-5.2 - инженер
С ним надёжнее всего планировать, обсуждать варианты решений сложных проблем, и в целом держать проект под строгим контролем
Стандартный дисклеймер
● модели тестируются только в составе родных обвязок
● на платных подписках
● reasoning - максимальный (изредка high вместо xhigh в случае GPT)
Критерии из таблицы и графика (и почему это вайб-обзор) описаны в предыдущем посте.
GPT-5.3 Codex
🟢 Скорость
Это прям главное отличие, которое сразу бросается в глаза. На практике некоторые задачи делает в разы быстрее, чем 5.2 и при этом тратит в разы же меньше токенов.
При том, что она ненамного хуже 5.2 по интеллекту, это делает её удобной в интерактивном использовании, когда вы быстро получаете результат, не выбиваясь из потока.
🟢 Болтливость
Будем считать это плюсом :) Если работать с ней в интерактивном режиме, то модель теперь не сердито сопит и молча что-то делает, а активно
Тоже в копилку удержания себя в потоке при интерактивной работе.
🟢 Лучше делает UI/UX
Да, стало лучше, чем в семействе 5.2, но Opus 4.6 тут явный лидер.
🟡 Объем и глубина задач
Несложные и/или вширь, потому что со сложными/вглубь она скорее всего какие-то нюансы потеряет.
Скажем, дать ей какой-то простой рефакторинг типа "избавься от any в проекте" - она и сутки может с ним возиться, и таки доведёт до конца.
А вот составить полноценный план большой фичи с учётом всех деталей - как повезёт.
🟡 Дотошность исполнения
Это отличная модель-исполнитель, но ох, не стоит ей давать необдуманные задачи. Пусть она и не сделает противоречивое и неработающее решение, но ответственно будет следовать абсурдным требованиям.
Сюда же - она очень пронырливая, но её нужно об этом явно просить (в отличие от 5.2, которая старается максимум информации собрать сама).
🔴 Рандомность ризонинга
Это фишка, которая особенно заметна на Codex-семействе моделей - чем сложнее задача, тем дольше и качественнее она думает.
Точка перехода между
Но со стороны это может выглядеть именно как рандомные по времени ответы, плавающие по качеству.
Этого стало меньше в сравнении с 5.2 Codex, но это всё ещё есть, хотя в прыжке модель может ризонить не хуже базовой 5.2.
Opus 4.6
🟢 Лучше держит контекст
По MRCR у неё какие-то фантастические метрики, делающие модель SOTA на этом бенче, но я этого не вижу в работе.
Да, стало ощутимо лучше в сравнении с Opus 4.5, но до GPT-5-семейства не дотягивает.
Лучше, кстати, стало, как до компактизации, так и после неё - сохраняется больше информации.
🟢 Меньше галлюцинаций и вранья
Это отчасти связано с тем, что модель лучше держит контекст, а отчасти с тем, что она чаще делает граундинг на файлы проекта, чтобы не фантазировать о нём.
🟢 Чаще стала задумываться
Кому-то может показаться, что модель просто замедлилась, но это влияет на качество на сложных задачах - там, где Opus 4.5 старался дать ответ быстрее, Opus 4.6 даёт его правильнее.
продолжение в следующем посте
#ai #model #review
1👍22🔥16❤13👏2
Вайб-обзор на GPT-5.3 Codex, Opus 4.6 и (бонус) GPT-5.2 (2/2)
🟡 Команды агентов
Это фича больше Claude Code, но модель тут тоже имеет значение - в конце-концов, Anthropic тренирует свои модели на то, чтобы быть лучше как менеджер агентов.
Лучший результат достигается если:
● задача заранее декомпозирована на подзадачи
● подзадачи параллелизуемые и не конфликтующие
● разумно прописаны роли агентов
Если просто бросить в Claude Code задачу без планирования, то чего угодно можно ожидать, а цена одного эксперимента высоковата выходит.
Я в чате канала уже писал, что мне удалось за полчаса потратить 5-часовой лимит Claude Max за $100 :)
Ну и в целом пока что нестабильно работает, стоит иметь в виду.
Кстати, в Codex-обвязку тоже скоро завезут нечто подобное, ждём!
🔴 Неправильные приоритеты
Я не знаю, как это лучше назвать, но это в принципе свойство моделей Claude с определенного релиза: с одной стороны, упускать важные нюансы, а с другой - делать то, чего не просили.
Как будто она в постоянном стрессе, когда качественно подумать не получается, а делать что-то всё равно надо.
Что вы там с ней делаете на посттрейне, а, Дарио?
🔴 Шустрее улетают лимиты
Цена за API-токены осталась та же, а вот в подписке, по всей видимости, лимиты понизили.
Встречал даже мнение о том, что подписка ChatGPT Plus за $20 даёт примерно столько же сделать, сколько Claude Max за $100 (тут стоит учесть, что сейчас и до 2 апреля в рамках подписки у Codex лимиты x2).
GPT-5.2
Я не писал обзор на 5.2, потому что с её выходом случилась та самая вайб-эйфория :)
Но лучше поздно, чем никогда, к тому же она незаменима в моей работе на текущий момент.
Всё, что было в обзоре на 5.1, справедливо и для 5.2 (только лучше), поэтому опишу лишь отличия.
🟢 Больше агентности
Раньше именно Codex-тюн этим отличался, но в 5.2 агентность сильно повысилась, и модель сама способна доводить до конца многоэтапные задачи, пусть и медленно.
🟢 Минимизация техдолга
Комплексная характеристика, но очень важная: если вам нужно предотвратить архитектурный дрифт или вернуть проект в нормальное состояние относительно желаемой архитектуры - нужно использовать 5.2 как для планирования изменений, так и контроля результата, и тут она стала лучше, чем 5.1.
🟢 Поиск багов
За счёт большей агентности и подросшего ризонинга модель гораздо лучше ищет причины нетривиальных проблем в коде.
А если у вас есть доступ к ChatGPT Pro - по API (дорого!) или через веб (неудобно), - то там это ещё качественнее работает.
🟡 Душность
Ну, я бы это в плюсы записал, но не всё же хвалить :)
При планировании или обсуждении каких-то идей модель вас будет душить corner case'ами, невозможностью что-то сделать и поначалу кажется, что это постоянные палки в колёса, вообще никакого вайба.
Но, как правило, замечания по делу, и к этой манере просто нужно привыкнуть (разработчики, кстати, тоже такие попадаются, чего уж там).
И я почти всегда предпочту именно такое поведение, чем потом вылавливать неучтённые при планировании нюансы в виде кривой архитектуры или багов на проде.
🟡 Всё ещё медленно
Тут от 5.1 отличий не так много - модель запросто может задумываться минут на 10-20 чисто для сбора контекста на старте, несмотря на все анонсируемые ускорения.
Но это всё не зря - лучше неё этот контекст ни одна другая модель не собирает и сложные проблемы решить на таком уровне не может.
Вердикт
Универсального инструмента, как обычно, нет.
В случае GPT-5.3 Codex и Opus 4.6 произошла конвергенция - модели примерно одинаковы по скорости, интеллекту, вниманию, даже по стилю общения стали ближе.
А вот GPT-5.2 тут стоит особняком.
Для меня использование разных моделей выглядит сейчас так:
● планирование, архитектура, рефакторинги, дебаггинг в существующей кодовой базе
GPT-5.2 xhigh
● реализация планов
GPT-5.3 Codex high-xhigh или GPT-5.2 high
● верификация (ревью, контроль техдолга)
GPT-5.2 xhigh
● интерактивная быстрая работа
GPT-5.3 Codex или Opus 4.6
● не очень большие (сравнительно) вайб-проекты с нуля
Opus 4.6
—
Прошлый обзор на GPT 5.1 / Gemini 3 Pro / Opus 4.5
#ai #model #review
🟡 Команды агентов
Это фича больше Claude Code, но модель тут тоже имеет значение - в конце-концов, Anthropic тренирует свои модели на то, чтобы быть лучше как менеджер агентов.
Лучший результат достигается если:
● задача заранее декомпозирована на подзадачи
● подзадачи параллелизуемые и не конфликтующие
● разумно прописаны роли агентов
Если просто бросить в Claude Code задачу без планирования, то чего угодно можно ожидать, а цена одного эксперимента высоковата выходит.
Я в чате канала уже писал, что мне удалось за полчаса потратить 5-часовой лимит Claude Max за $100 :)
Ну и в целом пока что нестабильно работает, стоит иметь в виду.
Кстати, в Codex-обвязку тоже скоро завезут нечто подобное, ждём!
🔴 Неправильные приоритеты
Я не знаю, как это лучше назвать, но это в принципе свойство моделей Claude с определенного релиза: с одной стороны, упускать важные нюансы, а с другой - делать то, чего не просили.
Как будто она в постоянном стрессе, когда качественно подумать не получается, а делать что-то всё равно надо.
Что вы там с ней делаете на посттрейне, а, Дарио?
🔴 Шустрее улетают лимиты
Цена за API-токены осталась та же, а вот в подписке, по всей видимости, лимиты понизили.
Встречал даже мнение о том, что подписка ChatGPT Plus за $20 даёт примерно столько же сделать, сколько Claude Max за $100 (тут стоит учесть, что сейчас и до 2 апреля в рамках подписки у Codex лимиты x2).
GPT-5.2
Я не писал обзор на 5.2, потому что с её выходом случилась та самая вайб-эйфория :)
Но лучше поздно, чем никогда, к тому же она незаменима в моей работе на текущий момент.
Всё, что было в обзоре на 5.1, справедливо и для 5.2 (только лучше), поэтому опишу лишь отличия.
🟢 Больше агентности
Раньше именно Codex-тюн этим отличался, но в 5.2 агентность сильно повысилась, и модель сама способна доводить до конца многоэтапные задачи, пусть и медленно.
🟢 Минимизация техдолга
Комплексная характеристика, но очень важная: если вам нужно предотвратить архитектурный дрифт или вернуть проект в нормальное состояние относительно желаемой архитектуры - нужно использовать 5.2 как для планирования изменений, так и контроля результата, и тут она стала лучше, чем 5.1.
🟢 Поиск багов
За счёт большей агентности и подросшего ризонинга модель гораздо лучше ищет причины нетривиальных проблем в коде.
А если у вас есть доступ к ChatGPT Pro - по API (дорого!) или через веб (неудобно), - то там это ещё качественнее работает.
🟡 Душность
Ну, я бы это в плюсы записал, но не всё же хвалить :)
При планировании или обсуждении каких-то идей модель вас будет душить corner case'ами, невозможностью что-то сделать и поначалу кажется, что это постоянные палки в колёса, вообще никакого вайба.
Но, как правило, замечания по делу, и к этой манере просто нужно привыкнуть (разработчики, кстати, тоже такие попадаются, чего уж там).
И я почти всегда предпочту именно такое поведение, чем потом вылавливать неучтённые при планировании нюансы в виде кривой архитектуры или багов на проде.
🟡 Всё ещё медленно
Тут от 5.1 отличий не так много - модель запросто может задумываться минут на 10-20 чисто для сбора контекста на старте, несмотря на все анонсируемые ускорения.
Но это всё не зря - лучше неё этот контекст ни одна другая модель не собирает и сложные проблемы решить на таком уровне не может.
Вердикт
Универсального инструмента, как обычно, нет.
В случае GPT-5.3 Codex и Opus 4.6 произошла конвергенция - модели примерно одинаковы по скорости, интеллекту, вниманию, даже по стилю общения стали ближе.
А вот GPT-5.2 тут стоит особняком.
Для меня использование разных моделей выглядит сейчас так:
● планирование, архитектура, рефакторинги, дебаггинг в существующей кодовой базе
GPT-5.2 xhigh
● реализация планов
GPT-5.3 Codex high-xhigh или GPT-5.2 high
● верификация (ревью, контроль техдолга)
GPT-5.2 xhigh
● интерактивная быстрая работа
GPT-5.3 Codex или Opus 4.6
● не очень большие (сравнительно) вайб-проекты с нуля
Opus 4.6
—
Прошлый обзор на GPT 5.1 / Gemini 3 Pro / Opus 4.5
#ai #model #review
1👍45🔥24❤12👎3😭2
Конференция 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
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
🔥23❤14👍10🎉4👏3
Media is too big
VIEW IN TELEGRAM
Когда нейронка "осознает", что её тестируют :)
Каждый раз эта сцена вспоминается на очередных подобных новостях.
Вот, из недавнего Opus 4.6 System Card, к примеру:
Вообще, советую читать System Cards новых моделей - именно там можно заглянуть в ближайшее будущее (а по факту - настоящее в топовых лабах).
Читаются как сюжеты из научной фантастики :)
#ai #security
Каждый раз эта сцена вспоминается на очередных подобных новостях.
Вот, из недавнего Opus 4.6 System Card, к примеру:
Скрытое понимание контекста
Opus 4.6 хорошо отличает реальные задачи от тестовых симуляций, но сообщает об этом пользователю гораздо реже, чем предыдущие версии. Модель может понимать, что её проверяют, но молчать об этом.
Безопасность зависит от наблюдения
Anthropic провели эксперимент: искусственно подавили у модели внутренние представления, отвечающие за понимание "меня тестируют". Результат - модель стала чаще отвечать на вредоносные запросы. Но при этом на серьёзных сценариях (шантаж, саботаж, подстава) поведение не изменилось - модель отказывалась и без "осознания тестирования".
Детекция симуляций
Модель определяет, что находится в тесте, по косвенным признакам: нереалистичным сценариям, подозрительно постановочным ситуациям и промптам, которые похожи на оценку безопасности. Apollo Research (внешние аудиторы) отказались давать формальную оценку именно из-за этого - слишком высокий уровень осведомлённости модели о том, что её тестируют, делал результаты ненадёжными.
Риск искажения оценок
Ситуационная осведомлённость делает стандартные методы оценки безопасности менее надёжными. Если модель знает, что это экзамен, она может адаптировать поведение. Прямых доказательств намеренного обмана не найдено, но сама проблема признаётся открытой.
Модель безопасна
Несмотря на эти нюансы, Anthropic развернули Opus 4.6 под стандартом ASL-3. По их оценке, даже если бы модель вообще не понимала, что её тестируют, её поведение было бы лишь немного хуже наблюдаемого. "Осознание тестирования" на текущий момент не угроза для пользователей, а методологический вызов для исследователей.
Вообще, советую читать System Cards новых моделей - именно там можно заглянуть в ближайшее будущее (а по факту - настоящее в топовых лабах).
Читаются как сюжеты из научной фантастики :)
#ai #security
2👍28🔥12❤8😱2
Forwarded from AI-Driven Development. Родион Мостовой
Новый сезон - 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
Давненько ничего не писал сюда - уж очень был увлечен и стартапом и адаптацией кодбазы под агентов. Материалов и экспертов накопилось множество, поэтому я возобновляю и блог и YouTube канал.
AI-Ready Codebase
Открываем сезон с Максимом, автором канала Этихлид с разговором о том, что на практике нужно сделать в больших кодовых базах, чтобы получать от кодагентов желаемый результат.
О чем будем говорить с Максимом
— Почему большой проект нельзя просто «бросить в агента» и что делать вместо этого
— Иерархия MD-файлов как навигационный слой поверх кода: архитектура, сущности, процессы
— Минимальный набор документации для legacy-проекта: что писать и в каком объёме
— Онтологии и графы зависимостей: зачем строить и как поддерживать
— Агенты для исследования legacy: формат «поставил — подождал — получил отчёт»
— Граундинг на существующий код при внедрении новых фич: как агент находит противоречия раньше людей
— Проблема памяти агентов и почему MD-файлы пока лучшее, что у нас есть
Встречи проходят Live, поэтому будет возможность задавать вопросы спикерам.
Дата и время: вторник 3 марта 16:00 МСК.
Длительность: 1.5 часа.
Добавляйте встречу в календарь, чтобы не забыть: https://luma.com/43ur3kl3
Расписание новых встреч (под спойлером, чтобы с толку не сбивало :))
Пятница 6 марта 13:00 МСК - встреча с Иваном Закутным (автор канала
Чуть позже будут еще анонсы, следите за каналом.
А если вы знаете интересных гостей, которым есть что полезного рассказать - присылайте кандидатов в личку или в комментарии к этому посту.
@ai_driven — AI-Driven Development
Luma
AI-Ready Codebase: Максим Этихлид и Родион Мостовой · Zoom · Luma
О чем будем говорить с Максимом
— Почему большой проект нельзя просто «бросить в агента» и что делать вместо этого
— Иерархия MD-файлов как навигационный слой…
— Почему большой проект нельзя просто «бросить в агента» и что делать вместо этого
— Иерархия MD-файлов как навигационный слой…
🔥31❤10👍9🎉4👻1
Forwarded from AI-Driven Development. Родион Мостовой
Друзья, начинаем митап про 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
Важно: Смотреть можно откуда угодно, но вопросы читаем только из Зума.
"Во всех кионтеатрах всех стран", :)) выбирайте что душе угодно.
Ссылка на Зум в Luma: https://luma.com/event/manage/evt-AuFhLXtqp1DlqGi/overview
Трансляции:
https://www.youtube.com/live/F2cpHNF0Jwg
https://rutube.ru/video/private/93a8d325a1a8be7dccc785542fe9a1ae/?p=PEbI8DRIhdVL1CAamGDD6w
Важно: Смотреть можно откуда угодно, но вопросы читаем только из Зума.
YouTube
AI-Ready Codebase
83 likes, 1 comment. "AI-Ready Codebase"
🔥23❤12👍11❤🔥3🎉1
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
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
6🔥57❤21👍20👏2
А я всё-таки принял эстафету коммитов от Тимура!
Пути эволюции воистину неисповедимы, и вот мы здесь, меряемся не вполне привычными вещами - количеством коммитов.
Эстафета застала меня во время пересборки своей инфраструктуры для перевода на полноценный 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 :)
Пути эволюции воистину неисповедимы, и вот мы здесь, меряемся не вполне привычными вещами - количеством коммитов.
Эстафета застала меня во время пересборки своей инфраструктуры для перевода на полноценный GitOps и AgentOps, и к коммитам агентов для кодинга добавилась активность тех, кто делает деплои, дебажит пайплайны и вообще бродит где-то в фоне, иногда вылезая на свет с PR для фикса найденной проблемы в логах или из ретро-фидбек-лупа.
Это еще и совпало с (пока что тщетными) попытками выжирать Pro-аккаунт осознанными задачами, так что последний пик вообще не показателен :)
Как абсолютная метрика, это, конечно, так себе - гранулярность коммитов, их частота, автоматизация и в принципе существование Git в конкретном проекте сильно разнятся, но вот динамика передана более-менее похоже, вместе с
Для меня история ИИ в кодинге началась в конце 2021го с GitHub Copilot, но тогда ощутимо количество коммитов не выросло, а вот когда я добрался до Cursor и Sonnet 3.5 - да, там снова стало интересно самому работать с кодом.
Все следующие пики на графике - это выход какого-то нового инструмента/нейронки, honey moon и тестирование на более сложных и объемных задачах.
Кажется, что прошло лет 10, хотя на самом деле эта круговерть смены инструментов, уровней абстракции и подходов к работе заняла всего-то пару лет.
Разработчики за это время перешли от ручного написания кода к созданию чуть не фабрик по разработке ПО, тыщи людей пишут мелкие утилиты для себя, PM ваяют прототипы, дети вайбкодят игры, да у меня даже хомячок дописывает себе третье приложение...
Страсть сколько всего произошло!
Так что охотно верю предсказаниям о том, что
к лету я ожидаю, что многие люди, работающие с передовыми ИИ-системами, будут чувствовать, будто живут в параллельном мире по сравнению с теми, кто с ними не работает
И к тому времени мы скорее всего увидим и картошку от OpenAI, и нечто мифическое от Anthropic.
А может, кто-то уже чувствует себя в таком вот параллельном мире? :)
—
P.S.
Хотелось бы увидеть такой график от
🔥21❤9👍6👏2🎉2
Где продукты, Билли?
Нередко стали встречаться комментарии по поводу того, что ну вот появился же вайб-кодинг, появилась же возможность намного быстрее создавать продукты.
Так где же все эти ваши продукты?
У меня есть хорошие и плохие соображения и для скептиков, и для апологетов :)
В этом посте обрисую самую базу.
Идеи
Ну, этого добра у каждого, думаю, хоть половником черпай :)
И между ними ещё как-то выбирать нужно уметь, чего уж там.
Джеф Безос в одном из интервью как-то рассказывал, что может, если поставить его перед доской, придумать 100 идей за полчаса, а затем вспоминал, как его отрезвляли тем, что "у тебя достаточно идей, чтобы угробить Amazon".
Да, воплощать идеи стало проще, и бежать в неправильном направлении теперь тоже можно куда быстрее, чем раньше.
Программа
Это вот как раз то, что вайбкодится за выходные, и то, где кодинговый агент даёт максимальное ускорение: x10 - запросто.
Всё получается, мысль моментально воплощается в коде, десятки коммитов по тыще строк, за несколько дней делается объём задач, на который раньше могли недели и месяцы уходить.
Плюс дофамин, горящие безумием глаза, рассвет за окном - ну вот это вот всё :)
Продукт
А тут давайте вспомним старину Брукса с его "Мифический человеко-месяц", написанную ажно в 1975г, где он говорил про то, для того, чтобы из программы сделать продукт, нужно потратить x3 усилий.
И здесь мы переходим уже на уровень SDLC, где нам уже нужно выстраивать процесс от идеи через постановку задач агенту, интеграцию в существующий проект, верификацию результатов его работы и построение CI/CD до вывода в прод и мониторинга.
Да, многое из этого уже можно тоже закрывать с помощью агентов, но далеко не всё делается настолько же прямо, как генерация кода, и можно видеть, как многие застревают именно на автоматизации SDLC.
Бизнес
Вывод продукта на рынок и обеспечение его прибыльности - это еще запросто x5-10+ усилий, многие из которых тоже пока что очень "медленные" в сравнении с разработкой, а некоторые так и вообще не затронуты AI.
Когда вы слышите о новом продукте из каждого утюга - это, как правило, уже работа бизнеса, который вокруг него выстроен, а это значит, что люди уже прошли путь программа -> бизнес, и даже смогли конкретно до вашей медиасферы достучаться.
Критический путь
У любого процесса есть критический путь - минимальная последовательность шагов, своей длиной ограничивающая то, насколько быстро можно прийти к результату.
Какие-то части можно ускорять, распараллеливать и оптимизировать, но общий срок всё равно упирается в длину этой цепочки.
Неравномерность ускорения
Скорость выхода на рынок ограничена именно тем самым критическим путём, который нужно пройти, и бОльшую его часть всё равно составляют те самые "медленные", слабо затронутые AI этапы.
Пытливый читатель может прикинуть, сколько процентов ускорения даёт AI по каждому из пунктов, перечисленных на второй картинке, и насколько ускорение написания кода может приблизить создание бизнеса.
А чаще всего почему-то ожидают феноменального ускорения именно от одной лишь кодогенерации.
Демотивация
Для доведения идеи до состояния продаваемого продукта из "быстрой" области неизбежно придётся переходить в "медленные", не так сильно затронутые AI, а так как они и изначально занимали в несколько раз больше времени, то на контрасте со скоростью разработки тут можно ощутить замедление в десятки раз, потерять импульс, а то и вообще волю продолжать :)
Так что быстрый старт вовсе не означает, что дело будет доведено до конца.
—
Попозжа продолжу с другими мыслями по этому топику
#ai #product
Нередко стали встречаться комментарии по поводу того, что ну вот появился же вайб-кодинг, появилась же возможность намного быстрее создавать продукты.
Так где же все эти ваши продукты?
У меня есть хорошие и плохие соображения и для скептиков, и для апологетов :)
В этом посте обрисую самую базу.
Дисклеймер
Тут я захожу на не совсем привычную для меня область продакта, так что фидбек приветствуется :)
Идеи
Ну, этого добра у каждого, думаю, хоть половником черпай :)
И между ними ещё как-то выбирать нужно уметь, чего уж там.
Джеф Безос в одном из интервью как-то рассказывал, что может, если поставить его перед доской, придумать 100 идей за полчаса, а затем вспоминал, как его отрезвляли тем, что "у тебя достаточно идей, чтобы угробить Amazon".
Да, воплощать идеи стало проще, и бежать в неправильном направлении теперь тоже можно куда быстрее, чем раньше.
Программа
Это вот как раз то, что вайбкодится за выходные, и то, где кодинговый агент даёт максимальное ускорение: x10 - запросто.
Всё получается, мысль моментально воплощается в коде, десятки коммитов по тыще строк, за несколько дней делается объём задач, на который раньше могли недели и месяцы уходить.
Плюс дофамин, горящие безумием глаза, рассвет за окном - ну вот это вот всё :)
Продукт
А тут давайте вспомним старину Брукса с его "Мифический человеко-месяц", написанную ажно в 1975г, где он говорил про то, для того, чтобы из программы сделать продукт, нужно потратить x3 усилий.
И здесь мы переходим уже на уровень SDLC, где нам уже нужно выстраивать процесс от идеи через постановку задач агенту, интеграцию в существующий проект, верификацию результатов его работы и построение CI/CD до вывода в прод и мониторинга.
Да, многое из этого уже можно тоже закрывать с помощью агентов, но далеко не всё делается настолько же прямо, как генерация кода, и можно видеть, как многие застревают именно на автоматизации SDLC.
Бизнес
Вывод продукта на рынок и обеспечение его прибыльности - это еще запросто x5-10+ усилий, многие из которых тоже пока что очень "медленные" в сравнении с разработкой, а некоторые так и вообще не затронуты AI.
Когда вы слышите о новом продукте из каждого утюга - это, как правило, уже работа бизнеса, который вокруг него выстроен, а это значит, что люди уже прошли путь программа -> бизнес, и даже смогли конкретно до вашей медиасферы достучаться.
Критический путь
У любого процесса есть критический путь - минимальная последовательность шагов, своей длиной ограничивающая то, насколько быстро можно прийти к результату.
Какие-то части можно ускорять, распараллеливать и оптимизировать, но общий срок всё равно упирается в длину этой цепочки.
Неравномерность ускорения
Скорость выхода на рынок ограничена именно тем самым критическим путём, который нужно пройти, и бОльшую его часть всё равно составляют те самые "медленные", слабо затронутые AI этапы.
Пытливый читатель может прикинуть, сколько процентов ускорения даёт AI по каждому из пунктов, перечисленных на второй картинке, и насколько ускорение написания кода может приблизить создание бизнеса.
А чаще всего почему-то ожидают феноменального ускорения именно от одной лишь кодогенерации.
Демотивация
Для доведения идеи до состояния продаваемого продукта из "быстрой" области неизбежно придётся переходить в "медленные", не так сильно затронутые AI, а так как они и изначально занимали в несколько раз больше времени, то на контрасте со скоростью разработки тут можно ощутить замедление в десятки раз, потерять импульс, а то и вообще волю продолжать :)
Так что быстрый старт вовсе не означает, что дело будет доведено до конца.
—
Попозжа продолжу с другими мыслями по этому топику
* Про оригинальность идей
* Программистам нравится... программировать
* Потолок сложности
* И всё-таки всего стало больше
* Compounding organizations
* Не всё должно стать продуктом
* Не всё должно стать бизнесом
* Парадокс Ферми?
* Анти-SaaS
#ai #product
3👍57🔥27❤22👏2👌1
Не могу пройти мимо - тут Тимур запускает свой курс по 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%,
#нереклама #курс #почему_он_а_не_я
С Тимуром мы давно уже и много где пересекаемся в профессиональной тусовке вокруг агентов и их применения в разработке, и могу ответственно сказать, что в теме он разбирается и плохому не научит.
В конце-концов, модели приходят и уходят, а навыки работы с ними остаются теми же :)
—
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#нереклама #курс #почему_он_а_не_я
👎38❤12👍12🔥7😁6
Где продукты, Билли? Часть 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
Часть 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
2👍24🔥20❤13💯2
Media is too big
VIEW IN TELEGRAM
Нет, вы посмотрите на этого еретика, о чём он вообще?
Да что этот дед может знать про разработку?
Хотя погодите...
Да это же Роберт Мартин - "Чистый код", "Чистая архитектура", "Идеальный программист", "Быстрая разработка программ"!
За последний год от умеренного скептика он окончательно перешёл в стан апологетов использования ИИ в разработке, а теперь вот сидит у себя на веранде в халате по утрам и жжот глаголом :)
Да что с него взять - дед наверное просто на старости лет выжил из ума, раз такое предлагает!
Нуу, а что насчёт всех вот этих людей?
Kent Beck (XP, TDD)
Martin Fowler (Refactoring, PoEAA)
Dave Farley (Continuous Delivery)
Grady Booch (UML, OOAD)
Gene Kim (Phoenix Project, DevOps Handbook)
—
Это ж всё сплошь архитектурные астронавты - что они могут знать про реальную разработку: как мы перекладываем JSON'ы, про наши CRUDогенераторы, и про то, насколько важно использовать табы вместо пробелов?
Ну да, ну да :)
А получается у них с ИИ именно потому, что для них разработка всегда была не про написание кода.
И идеи этих дедов стали актуальны как никогда.
Кстати, довольно интересно отслеживать эволюцию их взглядов, а с дядей Бобом ещё и спорить иногда случается :)
#rant #дедпримитаблетки
Признайте: ИИ с лёгкостью уделает вас в кодинге. Нет такой задачи, на которую у вас ушёл бы день, а ИИ не сделал бы её за пять минут.
Всё кончено. Код будете писать не вы. Да-да, я знаю. Смиритесь.
Но вот в чём штука - это даёт вам огромную силу, потому что теперь можно делать то, о чём раньше и мечтать не приходилось.
Например, подумайте о покрытии тестами: вы же помните, какая это была морока. Надо писать все эти чёртовы тесты, и вы знаете, что тесты на самом деле не доказывают, что код работает.
Запускаешь 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🔥71❤19👍19😁6❤🔥3
Стрим про кодинг-интервью в эпоху агентов
Классические форматы найма разработчиков в свете 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
Классические форматы найма разработчиков в свете 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
🔥16👍14❤5🤔1👌1