Справедливо) Уборка это неудачное слово: contract-шаг (DROP COLUMN) и есть настоящее ломающее изменение, тут да. Я назвал его так потому, что команды часто к нему так и относятся, как к финальной зачистке, на которую не закладывают ни времени, ни внимания. В этом и ловушка: главным считают expand, а ломает как раз «уборка». Мы про одно и то же)
А расскажите, на каких задачах вы его гоняете? код, документы, планирование? И как: чистый чат или с какой-то обвязкой?
Я сейчас всё через скиллы и жёсткие правила в проекте и поведение другое: меньше самодеятельности, меньше «предположу, хотя просили не предполагать». Я про этот подход писал тут: https://habr.com/ru/articles/1041296/ как раз про то, что у агента эрудиция принципала, а суждения джуна, и что с этим делать
Справедливо, заголовок получился громкий :) Но в защиту скажу, что там ни одного придуманного факта: и история с закрытым доступом для Apple/Google/Microsoft, и дедлайн 22 июня- всё из офф анонса. Просто сама история такая, что её сложно рассказать скучно
О, а вот это интересно)) Anthropic заявляет меньше 5% сессий. На каких задачах ловите? Если что-то около секьюрити то да, это ровно та зона, ради которой намордник и надевали. А если триггерится на обычном коде,то это уже фейл роутера и тянет на отдельный разбор. Накидайте пару примеров промптов?
Так в том и парадокс этого релиза: нейросеть как раз получилась слишком хорошей, настолько, что ее два месяца не выпускали. Цензура тут не вместо качества, а из-за него. Другое дело, что от фоллбеков страдают и легитимные задачи, вон ниже в комментах человек пишет, что у него ограничение срабатывает постоянно))
Интересно! Ваш кейс с планом, который модель раскритиковала, не заметив, что критика уже проработана внутри плана, это похоже не на цензуру, а на деградацию внимания к контексту. Подскажите, какой длины примерно был план и кидали вы его файлом или текстом в чат? Я пока не натыкался на какие-то сложности, использую Opus 4.8
Так они и до этого генерировались миллионами, просто теперь будут с правильным контрастом и без сломанной мобильной версии 😄 А если серьёзно, мне интереснее, что будет с легаси и тд. Миграция Ruby-базы у Stripe за дни вместо двух месяцев это интересно
Ну, наполовину :) Маркетинг тут точно есть «слишком опасная модель» продаёт себя сама. Но Project Glasswing был настоящим: Apple, Google и Microsoft два месяца реально патчили свои системы по находкам модели. Вряд ли их инженеры участвовали бы в чужой рекламной кампании. Хотя согласен… Anthropic выжала из этой истории максимум хайпа)
Про «пирамиду в отрыве от архитектуры» перечитайте концовку: я как раз не перешёл на black-box и не предлагаю всем переписываться. Я забрал одну дисциплину - тест как клиент. Это не про форму пирамиды, это про то, к чему тест прилеплен: к контракту или к потрохам. Архитектура тут не контраргумент, а ровно та причина по которой моки и оказываются хрупкими
Так в этом и весь тезис. Если польза теста зависит от того, насколько виртуозно я накрутил моки, тест проверяет мою сборку моков, а не поведение системы. Чем лучше я «владею моками», тем точнее я фиксирую текущую реализацию и тем громче всё краснеет на первом же рефакторинге без единого изменения поведения. Это не аргумент за юниты, это диагноз))
Единый контекст в Spring делается: один @SpringBootTestконфиг на всех, запрет @MockBean/@DirtiesContext, мок на HTTP-границе. Тогда приложение поднимается один раз и в классике старт перестаёт быть статьей расхода
И БД у black-box общая, вы правы: один сервис + одна база, никаких реплик. Просто её не чистят между тестами и изоляция по уникальному testRunId в данных, а не через TRUNCATE. И вся разница в скорости отсюда: она не от HTTP-границы, а от параллельности. Классика гоняется в один поток, потому что тесты дерутся за общее состояние и чистят таблицы; убрали очистку, ушли в уникальные ID и общую базу можно молотить потоками одновременно
Так что скорость не свойство black-box как такового, а связки «один контекст + параллель + изоляция по ID», и она прекрасно воспроизводится в обычных Spring-тестах
Что еще black-box даёт сверху и что в классике приходится держать на дисциплине он по построению запрещает лезть в кишки: нет инжекта бинов/DAO, и команда физически не может срастить тест с внутренностями в обход HTTP-границы. Она даже не знает что там за стек. В @SpringBootTest это держится только на договорённости
Старт приложения и поднятие зависимостей это разовая штука, в обоих подходах одинаковая
Дело не в тяжести приложения. В классике контекст Spring часто перетряхивается прямо посреди прогона: разные конфигурации тестов, @MockBean, @DirtiesContext и приложение поднимается заново по нескольку раз за сюит. А JUnit всё это обычно гоняет в один поток, так что переподнятия складываются в те самые «минуты»
В BlackBox тесты идут параллельно: сервис поднят один раз, и тесты молотят его по HTTP пачкой одновременно, как обычные внешние клиенты. Им не нужен общий Spring-контекст, нечему мешать друг другу , поэтому распараллеливание честное и почти линейное отсюда и секунды. В классике так не разогнаться: общий контекст и общая БД заставляют тесты толкаться и сваливаться в последовательный прогон
Ресёрч - разобраться в незнакомой области/библиотеке/чужом куске системы, собрать варианты решения с плюсами-минусами, прежде чем писать хоть строчку
ADR-ы - формулирую проблему, агент помогает оформить решение и альтернативы так, чтобы через полгода было понятно, почему сделали именно так
Архитектурные решения с контекстом БД - он видит реальную схему репозитория базы (через MCP-подключение к боевой/тестовой БД), поэтому предлагает не «в вакууме», а с учётом существующих таблиц, связей и индексов
Код по конкретной задаче - да, обычная продуктовая разработка, но в рамках моих правил (стайлгайд, архитектурные ограничения, линтеры/тесты как «кнут» — ровно как в статье)
Свои пет-проекты / продукты - отдельные штуки пилю целиком с ним
Управление командой - рутина тимлида: формулировки, разбор, подготовка решений
Разбор прод-алертов - приходит алерт, агент по скрипту лезет в кластер, собирает логи/состояние подов в окне инцидента, классифицирует причину (OOM / упавший upstream / БД / Kafka) и готовит постмортем с конкретными action items.
Заведение задач в Jira - создание и оформление тикетов из обсуждения/контекста
Статьи в Confluence - внутренняя документация, командные страницы.
И помощь со статьями сюда же, на Хабр 🙂
Ключевое не «оно само», а связка: контекст (CLAUDE.md), правила (.claude/rules), доступ к реальной БД и инфре, плюс линтеры/тесты, которые не дают ему накостылить. Тогда это уже не генератор CRUD-а, а рабочий инструмент почти по всему циклу
Риски есть, не спорю. Но их не игнорируют, компании как раз выстраивают вокруг AI нормальные автоматизированные пайплайны: ревью, тесты, линтеры на уровне платформы. Про это уже выходят статьи и выстраиваются бест практисы
Про «по карману только крупным» - да, у больших и ресурсов больше. Но сам базовый воркфлоу (правила + линтеры + тесты + ревью и тд) спокойно крутится и у соло-разработчика: Claude Code + один md-файл + пол бакса за вопрос. Дисциплина масштабируется и вниз, не только вверх
Про утечки вопрос реальный, и тут многое на стороне платформы: zero-retention, enterprise-договоры, локальные модели для секретного. По сути ты выбираешь инструмент под чувствительность данных. Это отдельная история от того, работает ли AI-разработка как подход
Звучит как интересная схема, но похоже, ты вручную изобретаешь велик. Твой цикл «Sonnet реализует до победного» это случайно не что-то типа Ralph loop (даже официальный плагин Claude Code от Anthropic есть), а «Opus-архитектор раздаёт phase dump’ы ->спека -> задачи» это BMAD-METHOD / Taskmaster / Spec Kit.
Так "вдумчиво разбирать, что нагенерил агент" - это не контраргумент, это и есть мой процесс. Никто не подписывается вслепую: для того и правила, линтеры, тесты и двойное ревью. Подпись под результатом ставится не вместо проверки, а после неё
А "80-90% руками, ИИ на рутину" - это уже устаревшая позиция. Крупные компании вроде GitLab и Anthropic давно вынесли ИИ за рамки «рыбы под тесты»: он пишет значительную долю кода и подключён к ревью на уровне платформы, встроенной в процессы компании. Человек владеет результатом и отвечает за него, но не набивает 90% руками
То, что в статье это верхушка айсберга. Под ней уже формируются best practices по внедрению ИИ во всю компанию. Так что вопрос не «fine and dandy или нет», а кто быстрее перестроит процессы под это
Справедливо) Уборка это неудачное слово: contract-шаг (DROP COLUMN) и есть настоящее ломающее изменение, тут да. Я назвал его так потому, что команды часто к нему так и относятся, как к финальной зачистке, на которую не закладывают ни времени, ни внимания. В этом и ловушка: главным считают expand, а ломает как раз «уборка». Мы про одно и то же)
Кайф, можно было не ждать, а на Опусе прогнать то же самое
У меня поднимаются брови:
вопросы по кибербезопасности и биологии автоматически уходят на старую OpusА расскажите, на каких задачах вы его гоняете? код, документы, планирование? И как: чистый чат или с какой-то обвязкой?
Я сейчас всё через скиллы и жёсткие правила в проекте и поведение другое: меньше самодеятельности, меньше «предположу, хотя просили не предполагать». Я про этот подход писал тут: https://habr.com/ru/articles/1041296/ как раз про то, что у агента эрудиция принципала, а суждения джуна, и что с этим делать
Справедливо, заголовок получился громкий :) Но в защиту скажу, что там ни одного придуманного факта: и история с закрытым доступом для Apple/Google/Microsoft, и дедлайн 22 июня- всё из офф анонса. Просто сама история такая, что её сложно рассказать скучно
О, а вот это интересно)) Anthropic заявляет меньше 5% сессий. На каких задачах ловите? Если что-то около секьюрити то да, это ровно та зона, ради которой намордник и надевали. А если триггерится на обычном коде,то это уже фейл роутера и тянет на отдельный разбор. Накидайте пару примеров промптов?
Так в том и парадокс этого релиза: нейросеть как раз получилась слишком хорошей, настолько, что ее два месяца не выпускали. Цензура тут не вместо качества, а из-за него. Другое дело, что от фоллбеков страдают и легитимные задачи, вон ниже в комментах человек пишет, что у него ограничение срабатывает постоянно))
Интересно! Ваш кейс с планом, который модель раскритиковала, не заметив, что критика уже проработана внутри плана, это похоже не на цензуру, а на деградацию внимания к контексту. Подскажите, какой длины примерно был план и кидали вы его файлом или текстом в чат? Я пока не натыкался на какие-то сложности, использую Opus 4.8
Так они и до этого генерировались миллионами, просто теперь будут с правильным контрастом и без сломанной мобильной версии 😄 А если серьёзно, мне интереснее, что будет с легаси и тд. Миграция Ruby-базы у Stripe за дни вместо двух месяцев это интересно
Ну, наполовину :) Маркетинг тут точно есть «слишком опасная модель» продаёт себя сама. Но Project Glasswing был настоящим: Apple, Google и Microsoft два месяца реально патчили свои системы по находкам модели. Вряд ли их инженеры участвовали бы в чужой рекламной кампании. Хотя согласен… Anthropic выжала из этой истории максимум хайпа)
Про «пирамиду в отрыве от архитектуры» перечитайте концовку: я как раз не перешёл на black-box и не предлагаю всем переписываться. Я забрал одну дисциплину - тест как клиент. Это не про форму пирамиды, это про то, к чему тест прилеплен: к контракту или к потрохам. Архитектура тут не контраргумент, а ровно та причина по которой моки и оказываются хрупкими
Так в этом и весь тезис. Если польза теста зависит от того, насколько виртуозно я накрутил моки, тест проверяет мою сборку моков, а не поведение системы. Чем лучше я «владею моками», тем точнее я фиксирую текущую реализацию и тем громче всё краснеет на первом же рефакторинге без единого изменения поведения. Это не аргумент за юниты, это диагноз))
Согласен почти со всем это и есть мысль статьи
Единый контекст в Spring делается: один @SpringBootTestконфиг на всех, запрет @MockBean/@DirtiesContext, мок на HTTP-границе. Тогда приложение поднимается один раз и в классике старт перестаёт быть статьей расхода
И БД у black-box общая, вы правы: один сервис + одна база, никаких реплик. Просто её не чистят между тестами и изоляция по уникальному testRunId в данных, а не через TRUNCATE. И вся разница в скорости отсюда: она не от HTTP-границы, а от параллельности. Классика гоняется в один поток, потому что тесты дерутся за общее состояние и чистят таблицы; убрали очистку, ушли в уникальные ID и общую базу можно молотить потоками одновременно
Так что скорость не свойство black-box как такового, а связки «один контекст + параллель + изоляция по ID», и она прекрасно воспроизводится в обычных Spring-тестах
Что еще black-box даёт сверху и что в классике приходится держать на дисциплине он по построению запрещает лезть в кишки: нет инжекта бинов/DAO, и команда физически не может срастить тест с внутренностями в обход HTTP-границы. Она даже не знает что там за стек. В @SpringBootTest это держится только на договорённости
Старт приложения и поднятие зависимостей это разовая штука, в обоих подходах одинаковая
Дело не в тяжести приложения. В классике контекст Spring часто перетряхивается прямо посреди прогона: разные конфигурации тестов, @MockBean, @DirtiesContext и приложение поднимается заново по нескольку раз за сюит. А JUnit всё это обычно гоняет в один поток, так что переподнятия складываются в те самые «минуты»
В BlackBox тесты идут параллельно: сервис поднят один раз, и тесты молотят его по HTTP пачкой одновременно, как обычные внешние клиенты. Им не нужен общий Spring-контекст, нечему мешать друг другу , поэтому распараллеливание честное и почти линейное отсюда и секунды. В классике так не разогнаться: общий контекст и общая БД заставляют тесты толкаться и сваливаться в последовательный прогон
Это на отдельном своем проекте, там мини апп в тг с маленьким кол-вом фичей)
Ресёрч - разобраться в незнакомой области/библиотеке/чужом куске системы, собрать варианты решения с плюсами-минусами, прежде чем писать хоть строчку
ADR-ы - формулирую проблему, агент помогает оформить решение и альтернативы так, чтобы через полгода было понятно, почему сделали именно так
Архитектурные решения с контекстом БД - он видит реальную схему репозитория базы (через MCP-подключение к боевой/тестовой БД), поэтому предлагает не «в вакууме», а с учётом существующих таблиц, связей и индексов
Код по конкретной задаче - да, обычная продуктовая разработка, но в рамках моих правил (стайлгайд, архитектурные ограничения, линтеры/тесты как «кнут» — ровно как в статье)
Свои пет-проекты / продукты - отдельные штуки пилю целиком с ним
Управление командой - рутина тимлида: формулировки, разбор, подготовка решений
Разбор прод-алертов - приходит алерт, агент по скрипту лезет в кластер, собирает логи/состояние подов в окне инцидента, классифицирует причину (OOM / упавший upstream / БД / Kafka) и готовит постмортем с конкретными action items.
Заведение задач в Jira - создание и оформление тикетов из обсуждения/контекста
Статьи в Confluence - внутренняя документация, командные страницы.
И помощь со статьями сюда же, на Хабр 🙂
Ключевое не «оно само», а связка: контекст (CLAUDE.md), правила (.claude/rules), доступ к реальной БД и инфре, плюс линтеры/тесты, которые не дают ему накостылить. Тогда это уже не генератор CRUD-а, а рабочий инструмент почти по всему циклу
Риски есть, не спорю. Но их не игнорируют, компании как раз выстраивают вокруг AI нормальные автоматизированные пайплайны: ревью, тесты, линтеры на уровне платформы. Про это уже выходят статьи и выстраиваются бест практисы
Про «по карману только крупным» - да, у больших и ресурсов больше. Но сам базовый воркфлоу (правила + линтеры + тесты + ревью и тд) спокойно крутится и у соло-разработчика: Claude Code + один md-файл + пол бакса за вопрос. Дисциплина масштабируется и вниз, не только вверх
Про утечки вопрос реальный, и тут многое на стороне платформы: zero-retention, enterprise-договоры, локальные модели для секретного. По сути ты выбираешь инструмент под чувствительность данных. Это отдельная история от того, работает ли AI-разработка как подход
понял, принял! Интересно будет посмотреть :)
Звучит как интересная схема, но похоже, ты вручную изобретаешь велик. Твой цикл «Sonnet реализует до победного» это случайно не что-то типа Ralph loop (даже официальный плагин Claude Code от Anthropic есть), а «Opus-архитектор раздаёт phase dump’ы ->спека -> задачи» это BMAD-METHOD / Taskmaster / Spec Kit.
Ralph (Anthropic): https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum
BMAD-METHOD: https://github.com/bmad-code-org/BMAD-METHOD
Taskmaster: https://github.com/eyaltoledano/claude-task-master
Может, проще взять готовое за основу, чем городить с нуля. Интересно сравнить с твоим -отпишись, как попробуешь)
Так "вдумчиво разбирать, что нагенерил агент" - это не контраргумент, это и есть мой процесс. Никто не подписывается вслепую: для того и правила, линтеры, тесты и двойное ревью. Подпись под результатом ставится не вместо проверки, а после неё
А "80-90% руками, ИИ на рутину" - это уже устаревшая позиция. Крупные компании вроде GitLab и Anthropic давно вынесли ИИ за рамки «рыбы под тесты»: он пишет значительную долю кода и подключён к ревью на уровне платформы, встроенной в процессы компании. Человек владеет результатом и отвечает за него, но не набивает 90% руками
То, что в статье это верхушка айсберга. Под ней уже формируются best practices по внедрению ИИ во всю компанию. Так что вопрос не «fine and dandy или нет», а кто быстрее перестроит процессы под это