Comments 100
Я для себя решил, что можем: агент точно делает лучше, чем среднестатистический человек, и спорить с этим нет смысла.
Проблема в том, что команда среднестатистических разработчиков (миддлов!) большинство нетривиальных проектов не тянет, даже если умный архитект даст им доку с рекомендациями по архитектуре. А ИИ в автономном режиме (когда сам и пишет и тестирует и ревьювит) работает на уровне миддла - механически реализуя запрошенный функционал не вникая в суть того, что он делает и как это скажется на проекте в целом (на нефункциональных требованиях - безопасность, надёжность, производительность, etc. - ровно то, что Вы насчитали как увеличение количества "технических багов", причём факт в том, что Вы нашли далеко не все гонки, дыры в безопасности и т.п.).
про миддлов Вы зря так - в их случае "не тянут" будет означать, что они пойдут к архитектору плакаться что "не шмогла" надо больше подсказок. По крайней мере возникнет явный блокер. Уж точно они не ринутся писать решение, статистически наиболее подходящее. В случае с ИИ это большая проблема, потому что он обучен писать так, что подвох заметишь не сразу
В тот момент, когда миддлы осознают, что они не тянут - проект обычно пора закапывать, а консультации у архитекта ему уже как мёртвому припарки. Да, архитект где-то точечно самые громкие проблемы поможет решить, но это просто оттягивание неизбежного.
А как у вас тогда вытягивают нетривиальные проекты: сеньоры пишут сами или архитектор ревьюит каждый МР? Интересно, где у вас граница, что можно отдать мидлу/агенту, а что нет
Критичный функционал всегда ревьювит сениор/лид/архитект. Критичный ли он обычно понятно по таске. Если таска механическая или делается по аналогии с уже существующим кодом, то с такими миддлы отлично справляются без надзора. Со временем большинство задач попадают в эту категорию, но поначалу жёсткие/обучающие ревью позволяют настроить миддлов на адекватный подход к текущему проекту.
А по каким правилам ревьюит сеньор, лид или архитектор: по тем, что у него в голове, по Confluence или по правилам в самом проекте? Что он сравнивает? Код и документацию описанную в Jira/Confluence?
Если правила где-то записаны, почему не перенести их в анализаторы, тесты и ArchUnit, а остальное хотя бы общими правилами отдать на ревью Claude Code с Opus ссылаясь на доку с ADR/RFC + PRF? Он и с базовым скиллом ревьюит довольно сильно, а у нас к нему добавлены свои проверки, собранные из ревью всех, кто работает на проекте
Поэтому не очень понимаю, что в критичном функционале агент может пропустить, а архитектор увидит. Чем агент тут хуже?
По своему представлению о том, как должно быть, разумеется. И нередко после ревью кода правится не код, а та самая дока в Jira/Confluence - именно потому, что источник истины не дока, а сотрудники имеющие представление о проекте (причём представление живое, развивающееся и изменяющееся вместе с проектом). И да, это ревью в любом случае делается уже после того, как все проверки, которые можно было автоматизировать (включая ревью от ИИ), уже прошли. И всегда остаётся ещё куча нюансов, которые автоматизировать не получилось.
Чем агент тут хуже?
Тем, что делает ревью на уровне миддла - который вполне может заметить какие-то неочевидные технические моменты, но совершенно упускает из виду влияние этого кода на проект в целом.
Может быть да, но и то я думаю можно скилл ревью поправить, чтобы он включал продуктовое мышление и дабл чекал логику бизнесовую, но лучше это делать левее по процессу производста, думаю, на процессе груммингов и ресерча PRD с продуктом
Кажется после написания кода уже поздно и где-то процесс поломан, если такое происходит
Если смотреть формально по логике - да, безусловно, Вы правы: если код демонстрирует некорректное понимание задачи, то задача не была полноценно поставлена.
Если бы можно было всё знать заранее, то большей части проблем можно было бы легко избежать. Но мы заранее не знаем, и именно поэтому проблема вылезает аж на этапе ревью код (и ещё хорошо, если на этапе ревью, а не уже в проде). На самом деле часть упущений в постановке задачи вылезает раньше, когда приступают к её реализации, но далеко не все. А на 100% полная спецификация задачи, которая не оставляет возможностей для ошибок и разночтений - это сам код.
Я сейчас не отсылку к известному комиксу делаю, а пишу про суть: сам по себе процесс написания кода, по определению, это процесс перевода недетерминированных требований в детерминированную реализацию. И этот процесс подразумевает, что требования в принципе неполные и неоднозначные - иначе их бы не требовалось переводить в код, они бы сами были кодом и обрабатывались бы не людьми а компиляторами. Концепция заранее выдать ИИ всю необходимую информацию подразумевает преобразование недетермированных требований в детерминированные, т.е. в код - заранее, ещё до выдачи задачи ИИ. И тут не имеет значения, на каком языке этот код будет написан - на русском или питоне - факт в том что это должен быть именно код на одном языке, который можно будет автоматически конвертировать в код на другом (тот же питон или машинные коды).
Поэтому мы и не пытаемся выдать агенту все заранее: ADR и контракты до кода, а дальше итерации, где ревью ловит то, что не договорили. Разница в том, что итерация с агентом сильно дешевле. А замечать недосказанность пока может только человек, тут вы правы, поэтому у нас есть и ручное ревью в добавок к ревью агентскому
Как сказал Фил Ранжин: "разработчики считали что смогут заменить кого угодно, в итоге создали ИИ и заменили сами себя" =))
И да - ИИ это удар по мидлам, а кто такие мидлы? - правильно, "ростки сеньоров", не будет мидлов и через 5-10 лет закончатся сеньоры.
Он не обучен писать с подвохом. Он обучен писать так, как в среднем пишем все мы: на Stack Overflow, GitHub, GitLab, книгах, статьях и всем открытом коде. Подвохи у него те же, что у среднего разработчика, поэтому и ловим их теми же способами!
Дока с рекомендациями сама по себе ничего не дает, это методичка, которую мидлы могут не соблюдать, как и агент. В большом проекте агент тоже может не посмотреть в правила и, например отправить событие в топик напрямую мимо outbox, потому что забился контекст или еще по каким-то своим соображениям) Поэтому правила мы не только пишем, но и проверяем: статические анализаторы, ArchUnit, тесты, которые валят сборку. Но не каждый архитектурный подход так проверишь, поэтому важен shift-left: решение обсуждаем на уровне RFC или ADR, и разработчик его защищает
Все гонки не нашел никто, не только я. У нас из 96 багов на проде гонок 4, и до прода не поймали ни одной. Только это вопрос не к агенту, а к тому, кто и как гонки ищет, и при ручном коде их пропускают так же
Я для себя решил, что можем: агент точно делает лучше, чем среднестатистический человек, и спорить с этим нет смысла
Тем, у кого ии головного мозга уже сложно что-то объяснить. Даже то, что большинство специалистов со временем растут и развиваются.
Растут, согласен) Только растут теперь в сторону архитектуры и продукта, а не скорости набора кода. Код пишет агент, а человек решает, что строить и как проверить, что агент не накосячил
Дак набор кода это 10%-15% процентов от работы. Есть ли смысл генерить говнокод и потом с ним мучаться? Есть мнение (мое), что со временем, сплособность проверять код ослабляется, если не пишешь свой и человек просто будет апппувить мержреквесты, которые со временем приведут к увеличение количества неприятных инценденов на проде. Мясных прокладок становиться все больше и это становиться проблемой.
Почему сразу говнокод?)) В статье про это есть: статические анализаторы, ArchUnit и общие правила, которые валят сборку, если агент пишет плохо. И почему код Claude это говнокод, а код разработчика шедевр? Claude учился на коде, который писали люди, на том же Stack Overflow. Так что говнокод пишут как раз люди) И чтобы его было меньше нужно теперь работать над пайплайном его генерации и качества
Навык проверять код, наверное, правда слабеет: выходит много нового, и ты уже не так в контексте. Зато в контексте Claude, и это надо принять. Конкурировать с ним я смысла не вижу. В Anthropic инженеры команды прямо пишут, что Claude пишет код лучше них, и мне такой подход нравится. Не надо считать себя умнее машинки))
Не надо считать себя умнее машинки
Это уже что-то на Геббельсовском.
Так что говнокод пишут как раз люди)
Безусловно! Более того, одна из ключевых причин текущего качества результатов ИИ как раз в том, что ИИ обучался на всём существующем коде без понимания какой код хороший а какой говно и почему. Если бы кто-то сумел адекватно оценить весь существующий код и разметить его где что сделано хорошо, где говнокод, и почему то, что считается хорошим кодом и говнокодом в одном проекте может оцениваться прямо противоположным образом в другом проекте - то вполне возможно что ИИ начал бы работать как сениор, а не миддл.
Проблема в том, что ни для кого не новость, что если набрать на проект одних только миддлов-говнокодеров, то проект не взлетит. А вот насчёт ИИ на эту тему ещё сохраняются иллюзии.
Про 10-15% похоже на правду, погуглил: у Microsoft вышло около 11% времени на код (https://arxiv.org/abs/2502.15287), у IDC 16%. Только агенты у нас не только набирают код: они тестируют, участвуют в деплое и дежурствах, с ними я пишу ADR
Ну у меня автотесты, скрипты для диплоя и т.п., все тоже автоматизированно, в чем преимущество ваших агентов?
Скрипт делает то, что в нем закодировано. Агент умеет думать: если что-то пошло не по сценарию, он сам разбирается, смотрит зависимости, логи и метрики и решает, что делать дальше, а если не уверен, спрашивает. Все случаи в скрипте не учтешь. Скрипты у нас тоже есть, агент работает поверх них
Например, на релизе он собирает задачи из тега и по ним говорит, какие флаги переключить и какие индексы сделать заранее, а на канарейке смотрит метрики и логи
Ну это сказки какие-то вы рассказываете, начиная с того, что агент думать умеет.
если что-то пошло не по сценарию, он сам разбирается, смотрит зависимости, логи и метрики и решает, что делать дальше, а если не уверен, спрашивает.
А кому не повезло, всю инфаструктуру сносит? Со словами: "Так вам и надо кожанные!!!"
>Меня зовут Игорь Симаков, я тимлид,
Обычно пишут вгде. Неужели стыдно?
>агент точно делает лучше, чем среднестатистический человек, и спорить с этим нет смысла
а у агента есть имя? если это fable какой-нибудь, то пожалуй да, но вы очень богатые. а если, упаси боже, онпремное kimi и подобное, то смешно, просто смешно.
Боюсь, тут все упирается в понятие среднестатистического человека. Возможно, если взять прям совсем всех - то он и строчки кода написать не сможет
Простите, а что, кими настолько плох?
Kimi K3 очень даже хорош. Особенно в код-вевью мне понравился - практически все замечания по делу и правильно оценена их важность.
Вообще, китайские модели за лето сильно выросли.
Тут много можно рассуждать, но если не хочется, как говориться, shoot yourself in the dick, то на нормальную сложную кодбазу пускать что-то кроме sol 6.1/opus 5.5 я крайне не советую.
Говорю как человек с безлимитной GLM 5.3, давать более слабым моделям ревьюить код или прогонять ручками e2e мне нравится, давать им писать код - через пару итераций всплывёт какая-то дичь которую придётся в панике чинить.
Дичи через пару итераций у нас не всплывает: по статистике в статье выросли только те баги, которые были и раньше, и выросли вместе с объемом кода. Новых видов дефектов агент не принес. А Sol 6.1 в чем у вас лучше Opus?
Ну это вы пока не заметили, либо вы делаете код ревью глазками. Для слепой разработки без полноценного ревью(кроме агентского, я стремлюсь к этому в своей разработке) кими/глм/квен не подходят, как и гемини и многие другие модели, в целом.
Sol лучше тем что OpenAI реже банит аккаунты)) и у них бизнес план лучше, у Claude в бизнес акке надо платить api rate, что дорого, у chatGPT standard/premium это по сути те же plus/pro x5, просто чуть дороже если платить помесячно. И с точки зрения ревью кода, sol/astra стабильнее находят косяки в коде. А, и ещё, за opus 5.5 было замечено что он умеет ломать вещи, т.е. дропнуть SQL базу как нефиг делать, астра/мол таким страдают сильно реже. С точки зрения именно кода, opus 5.5 будет получше sol 6.1.
Ревью глазами у нас тоже есть, агентское идет в дополнение. А чтобы ничего не дропнул, к базе у агента доступ только на чтение и то не в проде. Sol на ревью попробую, спасибо. Получается у вас код пишет Opus, а ревьюит Sol?
Пытаюсь сделать так, но недавно нам побанили акки антропика рабочие, так что astra + sol прямо сейчас. Скопилось ресетов и сейчас Тибо ресетит кодекс через день в любом случае, я не успеваю тратить лимиты). Прям щас в работе веселый mr - полный рефактор всего приложения на плагинную архитектуру, сижу развлекаюсь в 5 параллельных тредов астры...
Opus + ревью sol работает лучше, и ответы opus сильно приятнее читаюся, иногда приходится переспрашивать астру/сола, че там они имели ввиду.
Это от задачи зависит. Если задача мелкая и типовая, то её и DeepSeek V4 Flash пишет не хуже Opus. Но чем больше или нетривиальней задача тем больше разница в качестве и, соответственно, больше усилий требуется от человека на ревью и доведение результата до требуемого уровня.
Ну смотри, пару дней назад вышел Gemini 4 Argon, который по всем метрикам сильнее дипсика. На ревью видео от theo можно посмотреть, как модель от большой лабы сделала mr на мелкий фикс (там было 30 строчек от опуса в итоге), гемини сделала этот фикс на 1к LoC. Смотря на это, я не хочу использовать модели типо DS v4.1/GLM 5.3 вообще ни для чего. Из личного - GLM 5.3 смогла не сделать с двух тул коллов "повтори комманду в tmux что там была запущена до этого", даже зная что за команда там была из логов slurm, ds v4 flash 0731 - я лично наблюдал и чинил в нашем харнессе зацикливание ризонинга. Так что по факту эти модели могут лажать даже мелкие задачи, просто не часто, но зачем мне рисковать и не пользоваться нормальной моделью?..
На этот вопрос всегда один ответ: деньги. Если бы Opus стоил как DeepSeek, то не было бы ни одной причины использовать DeepSeek.
Если брать подписку, то опус/сол не сильно дороже дипсика) Цифры могут быть не совсем точные, но там разница не настоько большая как кажется если просто сравнивать api ценник.
3 месяца назад на подписке Claude Pro за $20 лимит 5-ти часового окна съедался примерно за 2 часа плотной работы одного агента. Дальше либо 3 часа ждать, либо переключиться на тот же DeepSeek, у которого таких лимитов нет в принципе.
Да, такое было, сейчас на своих пет проектах с opus 5.5 я проблем не замечаю.
Ну и тут есть вопросы, если для работы, то мне на работе оплачивают 100$ акк по выбору (claude/chatgpt), это разве не норма?
Если для хобби - 20$ с opus 5.5/sol 6.1 даёт более чем достаточный лимит, у меня без проблем прошел датамайн предметов/пассивок в last epoch за ночь, лимитов не встретилось. Хотя у меня есть персональный chatgpt pro тоже, и в целом рассматриваю возможность апнуть claude до 100$ подписки, но это так, у меня много пет проектов и готовлюсь менять место работы, так что прокачиваю скиллы.
Я предпочитаю смотреть на месячный/недельный лимит все же. Учитывая token efficiency и лишнее количество работы, которое нужно делать за дипсиком, в итоге рабочего кода из дипсика выйдет меньше. Да, нет лимитов на 5 часов, но это не значит что вы за 20$ api сможете работать больше, просто быстрее потратите лимит.
(тут стоит отметить, что замечательные люди из opencode дают 80$ api ds 4.1 flash в подписке за 10$, и вроде псевдобезлимитный если на 200к контекста. Пользоваться я им все равно не буду для написания кода в прод, ибо я больше времени потрачу на разгребание всех проблем от него)
Uzum Market, ничего стыдного. В статье не стал писать тимлид такой-то компании, потому что это сразу выглядит как реклама
Агент Claude Code с последним Opus (сейчас 5.5), его с головой хватает. Fable норм модель, но ест дофига)
это достаточно важно, потому что тим лид в ноу-нейме и в фаанге это совершенно разные уровни. Как и среднестатистический сотрудник для этих компаний
Во первых, opus 5.5 тоже дорогой, чтобы у "мы уже полгода не пишем код" сходилась экономика, надо сначала наделать каких-то откровенных глупостей, типа: набрали кучу балласта, а потом смотрите опусня 24/7 стоит меньше/так же, а делает в 3 раза больше.
Во вторых, последнее время opus 5.5 любит сказать: cyber. вот тебе opus 4.8. (триггерится на корпоративном софте). Про полные баны молчу.
Надеюсь у любителей "мы уже не пишем код" есть план Б )
В третьих, опус 5.5 только так допускает баги и недоделки. До обогнал средних кожмешков - как до луны. opus 4.8 вообще фу.
Соглашусь. Тут уже на уровень мидла его тянут, а по моим ощущениям это выпускник курсов "java за 48 часов " ))
Что интересного заметил: эта сволочь любит копировать код. И если у вас в проекте куча легаси, то и свежий код от него тоже будет такой же. На моем проекте игнорирует что это 17-й jdk и пишет циклы вместо stream. Несмотря на то что уже в правила добавил... Просто проект с 7 jdk и легаси тут дофига...
Странно ругать за это агента. Придет к вам новый джун или мидл и точно так же напишет цикл вместо stream, особенно если вокруг легаси. Правило в промпте или в доке не поможет ни тому, ни другому. Помогает только статический анализатор, который валит сборку и не дает смержить. У нас так и сделано, про это и статья. А у вас анализаторы валят сборку или только предупреждают? И вы на ревью ревьювитестиль кода? ну это же путь не туда
Про экономику: мы агентом никого не заменяли, люди те же, просто делают больше. А вы как ее считаете: токены против зарплаты или против того, сколько команда успевает сделать?
Про cyber не сталкивался, на каком коде у вас срабатывает? тут не могу ничего сказать
План Б есть: руки никуда не делись ахах)
Про баги: а люди не допускают? Агент на людях и учился) У нас за полгода функциональных багов не прибавилось, хотя кода стало втрое больше. Технических стало больше вместе с кодом, но это те же баги, что были и до агентов, про это и статья
Я для себя решил, что можем: агент точно делает лучше, чем среднестатистический человек, и спорить с этим нет смысла. Чем быстрее мы это примем, тем быстрее пойдем вперед, тягаться с этим уже бессмысленно
Какое уверенное ЯСКОЗАЛ
Ну да, так я сказал) Это моя позиция по опыту наших команд за полгода. Спорить с ней можно, для этого и писал. А как в ваших командах?
Я пишу свое мнение, а не доказательную базу, пока выкладыввал статью, тут антропик дропнули свою, стоит почитать, интересное чтиво. Anthropic кстати и прислали доказательства )
Все инженеры команды, которая делала их систему контроля версий, говорят, что Claude пишет код лучше них: “would now rate Claude as better at writing code than them” https://www.anthropic.com/engineering/redesigning-source-control
Все инженеры команды, которая делала их систему контроля версий, говорят, что Claude пишет код лучше них
Знаете такое слово "ангожированность"?
Тем не менее, они не отказались от человеческого ревью. Да, они пишут что смотрят не столько код, сколько суть изменений
Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code.
но чтобы увидеть этот intent всё-равно нужно достаточно внимательно проглядеть код. Да, одни изменения по диагонали, другие вообще можно не смотреть, но местами очень внимательно - потому что лажа в этих местах означает некорректное понимание ИИ сути задачи или проекта, т.е. необходимость дополнения или изменения контекста (AGENTS.md, скиллов, доки, инструкций в чате текущей задачи). Другой ИИ делая ревью на базе существующего контекста не может ни увидеть такую лажу ни принять решение о необходимости коррекции контекста.
Ну тут согласен да, когда на ревью видно, что агент не понял задачу или проект, правим не только код, но и контекст, правила в репо докидываем, доки правим, идем к продакту. У вас такое часто бывает что после ревью идете доку переписывать? У нас единичные случаи
Не часто, но тут как со сложным процентом: если это делать даже раз в неделю, то это позволяет поддерживать общий уровень качества проекта, а если этого не делать вообще (как следствие исключения квалифицированного человека из ревью), то начнётся прогрессирующее падение качества (за счёт того, что один раз прошедшая лажа будет во время следующих задач восприниматься как эталонный корректный код подход которого нужно стараться соблюдать в проекте).
Нет какого-то смысла ревьюить код, когда ты его сам руками не пишешь, ну если ты, конечно, не гений какой-то особенный, который может учить практический навык без собственно практики. Это же касается и дизайна системы и архитектуры, можно долго об этих вещах размышлять и планировать, однако покуда ты отдален от непосредственно реализации, результат будет не очень предсказуемым. Тут важная оговорка - я не предлагаю всем системным архитекторам поголовно самостоятельно создавать системы, которые они спроектировали, я предлагаю лишь изредка спускаться по уровню абстракций и хоть немного что-то для себя писать, но это лирика.
Тенденция на универсализацию вместо специализации тоже является очень интересным феноменом. Некогда такой подход уже проиграл, но почему-то господа решают, что новый инструмент определенно изменит положение вещей.
Ну а передача владения продуктом и собственно контроля над ним на аутсорс к поставщикам LLM - заведомо разрушительное решение, о чем намекает статистика прямо из этой статьи. Я уже несколько раз видел к чему это приводит и пару раз участвовал в исправлении последствий сей трансформации. Никого не отговариваю, но хочу все же напомнить, что количество строк кода, коммитов, MR’ов, фичей, эпиков и всего, что только можно придумать в качестве метрики, не обязательно будет коррелировать с качеством и уж тем более с выручкой. Иногда юзерстори лучше не реализовывать, по крайней мере в имеющемся виде, однако, чем больше задач берется в работу без раздумья, ибо агент всё напишет, тем меньше скепсиса. И в то же время, чем больше агент реализовывает, и чем меньше человек думает, тем выше шанс того, что задача не пройдет фильтр пригодности.
На ревью все равно видно, каких практик держится команда. Если агент от них уходит, отдельным MR правим анализаторы и ArchUnit, дописываем тесты, чтобы сборка падала, и агент так больше сделать не может. Так проект не расползается в разные практики
Код сейчас писать/генировать дешево. Но за ним все еще стоит наша работа: какая архитектура будет в задаче, как реализовать ее в существующем или новом сервисе, какой домен, как пойдет взаимодействие, синхронно или нет. Сейчас это делает каждый инженер. Инженер становится архитектором и немного продактом (в Авито сейчас вроже это продуктовый инженер называется). На написании кода мы почти не тратим время, а на продумывании решения, ADR и ревью дольше
Салют.
Совсем недавно начал изучать языки программирования, и писать. Пожалуйста, направь "малыша", как впереди идущий в вопросе реализации задуманной архитектуры в программе, чтобы обрести твёрдое и чёткое понимание этого процесса. К примеру, сейчас практикуюсь в теме, по конкуренции и гонкам... реализаций их купирования Масса, так же как возможностей использования их во благо. Отсюда вопрос: как подбираете нужный вариант? Как он вписывается в общую архитектуру и стиль? Или как используются новые фичи языка, которые только вышли? Если их игнорировать до момента дообучения модели, проект может потерять актуальность - или сами обучаете модель? В таком случае нужны ресурсы - деньги...как минимум.
Спасибо!
Модель мы не обучаем (по крайней мере пока что). Лично я не вижу в этом смысла. Этим занимается Anthropic, в нее вкладывают миллиарды долларов одни из самых богатых людей планеты, тягаться с ними бессмысленно. Они впереди и знают, что делают, так что можно расслабиться и брать готовое
Про выбор архитектуры. Сейчас главное уметь видеть проблемные места, знать альтернативы и их плюсы и минусы. Как научиться этому сразу, честно, не знаю. Мы всегда шли от меньшего к большему: от объявления переменных к архитектуре распределенных систем. Переменные теперь отлично создает агент, а сразу разобраться в распределенных системах сложно. Я бы начал с того, чтобы разобраться, где в распределенной системе обычно болит, чем это лечат и как выбрать из нескольких вариантов. Тут помогают статьи и книги. С уклоном в Java могу посоветовать “Микросервисы. Паттерны разработки и рефакторинга” Криса Ричардсона: там и что такое архитектура, и саги, и плюсы и минусы конкретных решений
Про новые фичи языка. Модели обновляются быстро и свежие фичи уже используют. Проблема будет в другом: на большинстве проектов до сих пор Java 11, где-то 17, редко 21, а последняя уже 27. Новые фичи не получится использовать не потому, что модель их не знает, а потому, что на проекте старый стек
Во многом соглашусь, и от себя добавлю, что агент он как веник - раз подмел хорошо, но по углам осталось надо еще раз им пройти, ну и контрольный раз тоже не помешает. Ведь если бы агент был прям хорош, то делая само ревью не находил бы острых углов.
Почему "больше тестировать" не поможет
Нанимать умных не пробовали? Говорят, помогает.
Пробовали! Первое, что они сделали, это написали агенту правила, чтобы больше не тестировать руками
Если человек считает, что «агент всегда‑всегда делает ровно то, что ему сказали, и никогда не нарушает правил», то у меня для него плохие новости.
Так что «умными» я таких человеков назвать не могу — скорее, доверчивыми.
всегда-всегда
никогда
Чтобы быть полезным, достаточно делать то, что нужно в достаточной степени.
Так что «умными» я таких человеков назвать не могу — скорее, доверчивыми.
Ход работы ни одного инструмента не предсказуем на 100% ⇒ ни один человек не умный ⇒ этот способ исключения из людей из списка умных совершенно бесполезен.
Чтобы быть полезным, достаточно делать то, что нужно в достаточной степени.
Вот только иногда выясняется, что степень была недостаточной, когда самолёт уже горит на земле.
Один и тот же конкретный самолёт умные пилоты из аварийной ситуации вполне себе вытащили, а неумные — таки довели до цугундера.
Ход работы ни одного инструмента не предсказуем на 100%
Быстро Вы, аднака, к нейронкам привыкли. У нормальных людей именно что «ход работы инструмента предсказуем на 100%» — а если инструмент ВНЕЗАПНО начал выполнять непредсказуемые эволюции — то его того, в ремонт нада.
Это была шутка)) в статье целый раздел про то, чем проверяем агента. Правило в промпте агент может нарушить, поэтому все важное проверяет сборка: ArchUnit, анализаторы, тесты с мутацией. Нарушил, сборка красная, до мержа не дошло
А где для вас граница: что можно отдать агенту под такие проверки, а что только руками?
а какая критичность была этих багов за год?
багов стало больше, это факт, но если они еще и с высокой критичностью или блокирующие, то стоит ли потеря денег и репутации компании всего этого эксперимента?
Критичных и блокеров среди багов на проде было 23 из 96. Но критичность в Jira не равна потере денег и репутации. Например, OOM: под падает, кубер его перезапускает, пользователь ничего не замечает. Или обратно несовместимый релиз с переименованием колонок, я про него писал отдельно: недоступность была, но 1-2 ручек. У наших команд не было случаев, чтобы баг сильно ударил по бизнесу. И это не эксперимент, мы так работаем уже полгода))
у вас как считают цену бага: по деньгам, по времени недоступности или по обращениям в поддержку?
По сгоревшим космонавтам в КА. Спросите у разработчиков батискафа "Титан" как они тестиолвали свой аппарат. Скорее всего примерно так же как вы
Думаю агент код “Титана” не писал. Батискаф погиб в июне 2023 года (вроде бы), тогда агентов, которые сами пишут код, еще не было
Да вроде и не код а корпус подвел
Кстати если были бы агенты, может быть удалось бы обойти? Мы это не узнаем :)
собеседования
Зачем теперь вам это? Зачем расширять штат если есть ИИ?
Сколько кода выпускают две команды
Циферки выросли. Логично, но количество кода, это же не показатель, мы не в Индии 2000х где платили за каждую строчку кода. Или у вас KPI на это завязан?
Вы бы развили тему, компания получила новый функционал, используют его 100т миллионов пользователей и тд.
ИИ пишет код, но продумать решение, проверить и довести до прода все равно должен человек. В Anthropic, кстати, пишут то же самое: инженеры не стали менее ценными, поменялась их работа https://www.anthropic.com/engineering/redesigning-source-control
но продумать решение
Архитектор, Лид.
Все остальные все равно отдадут придумывания решения на откуп ИИ
проверить
Тесты пройдены, ИИ проверил сам себя, сомневаюсь что разработчики, проверяют все тысячи строк кода, погружаются в логику и тд. Пробежался, нечего критичного не заметил, тесты проходят, норм.
Может тогда не разработчики а тестеры нужны?
Я посчитал его, чтобы сравнить с багами: технических багов на проде стало больше, и рост сопоставим с ростом кода
Логично же.
Но если напишите что это реально дало/принесло компании, будет вообще хорошо.
P.S. Вам тут написали посмотрите как тестировали, а вы снова про ИИ
Думаю агент код “Титана” не писал. Батискаф погиб в июне 2023 года (вроде бы), тогда агентов, которые сами пишут код, еще не было
P.S. А так удачи вам, посмотрим что у вас получится построить. Главное инфоструктуру по быстрее переносите в Узбекистан.
Про пользу для компании: я сужу по своим командам. Посмотрим, что получится по всей компании, тут нужно время на раскатку везде
Инфраструктуру уже перенесли) Инцидент закрыли, переезд сделали за два дня. Команда отработала супер быстро, красавчики, всем могу пожелать такую команду! Спасибо за пожелания!
Объем кода не KPI. Я посчитал его, чтобы сравнить с багами: технических багов на проде стало больше, и рост сопоставим с ростом кода
Кода стало втрое больше, багов на проде вчетверо, разработчики уже не всегда понимают, что выпускают. Зато агентам доверяем все больше. Раньше мы отвечали за код, который написали сами. Теперь отвечаем за код, который даже прочитать не успели. Забавная эволюция инженерной ответственности...
Получается, что мы автоматизировали разработку быстрее, чем научились отвечать за ее последствия?
По сути да, статья как раз про это) Код ускорился сразу, а проверки за ним не успели. Уточню только: вчетверо выросли технические баги, функциональных не прибавилось
Теперь догоняем: мутации, анализаторы, нагрузка на stage. Ответственность никуда не делась, просто отвечаешь теперь за то, чем код проверяется. Anthropic сами так пишут код: мержат больше 30 тысяч изменений в день, и в команде из их статьи человек проверяет намерение изменения, а не читает построчно
Агенты зачастую довольно многословные, а если идти по SDD, то число строк вообще не показательно. У вас есть графики с числом доставленных фичей?
А вот интересно, кода стало больше втрое, а продукта?
Сдвиг в сторону инженерного тестирования и написания пайплайнов вместо кликанья кнопок - это логичный шаг.
Но кажется, что ИИ-агенты сейчас просто подсветили старую проблему: классическое ручное тестирование никогда не умело ловить race condition или утечки памяти под нагрузкой.
Интересно, планируете ли вы внедрять полностью автономных ИИ-агентов для нагрузочного тестирования, или генерацию профиля нагрузки на Stage вы всё же валидируете руками?
Все так, гонки и утечки под нагрузкой руками почти не поймать, поэтому упор сейчас на инженерные проверки
Полностью автономных агентов внедрять планируем, сейчас как раз выбираем модели. Они будут подешевле, думаю что-то уже можно булет им отдавать
Как сейчас делают профиль нагрузочные тестировщики, надо уточнить у ребят. Но на своем кейсе убедился, что через агента это делается легко: он сам собирает профиль по НФТ, сразу нагружает, видит, где проседает, и чинит. Удобно
Полгода не пишем код руками. Посчитал, что стало с багами