Вы знаете, это не показатель. Ситуации, когда один агент не может разобраться с багом, а второй быстро всё находит - бывают и при переходе от сильных моделей к более слабым. Вот если бы, неудачу потерпели opus, gpt, deepseek, а fable бы быстро нашёл, это бы был более верный эксперимент
Прикольно. Я уже видел этот фокус. При моделирование пространства комплексных чисел через i = e1*e2. Но тут оно поднято на гораздо более высокий уровень.
Проблема в масштабировании этого результата на продакшн - сохранение совместимости. Тут я могу и несколько раз уже так делал - писать и выкидывать огромные подсистемы просто потому, что они мне не нравятся. На существующий продакшн это не распространить, хотя, на работе масштабный рефакторинг наших легаси-монолитов я начал. Но там приходится работать сильно аккуратнее
Мы - это я и агенты. Всё верно. Меня тоже очень интересует эта арифметика. 60 000 на 4 неделе в месяце и на 4 месяца - это около миллиона, а у нас 250 тысяч. Большая часть правок действительно относится к переписыванию кода, а не к написанию нового. Об этом, собственно и та часть статьи, что говорит про рефакторинг.
Проект пережил две огромных миграции. Переписывания движка с пайтон на си - это первая. Потом было еще разбиение получившегося монолита на библиотеки. А ещё мы переписывались с PyQt на собственный UI фреймворк.
Скорее всего суммарный объём правок даже больше. Я как-то видел 130 kloc на горячей неделе, и думаю, что это не самое большое число. Не то чтобы я активно следил за этой метрикой.
Четыре тысячи строк всё ещё много. Две тысячи строк - верхняя граница. По хорошему тревогу надо поднимать уже на полутора тысячах. Хорошо, если файл не уходит за тысячу.
У клода есть отдельный пунктик про 2000 строк. До какого-то момента, времён этак 4.5 (надеюсь Антропики это уже починили), клод даже просто разобрать файл свыше двух косарей на части толком не мог. Приходилось других агентов на помощь звать. Но так-то это их общее слабое место.
Да я даже когда тесты красные не ругаюсь. Я считаю это необходимым злом при ударной разработке. Но в какой-то момент мы садимся и начинаем все упавшие тесты разбирать.
Я достаточно хорошо понимаю, что происходит в проекте, чтобы не переживать о чём-то что временно отвалилось.
Но это именно по нынешней ударной стройке. Так-то у нас все тесты зелёные. Агент за ними вполне себе следит. А если не следит, это отлавливает ci и тогда я пинаю агента. Он смотрит гит и чинит. И тесты снова становятся зелёные.
Мультиагентов я именно что в тестовом режиме гонял. Чисто на пробу. Так что пока писать не о чем. Впринципе, я использую многоагентные сценарии "в продакшне", но оркестратором выступаю сам.
У меня не было тезиса, что тесты больше не работают. Тезис был, что тесты защищают гипотезу агента.
И защищают по прежнему хорошо. В моих проектах тесты переодически ловят регрессы, и тогда агент корректирует... Или код или тесты под новое поведение. С ними всё нормально. Но я ими по большей части не занимаюсь. Тестами ведает агент.
Многоагентность да. Это штука хорошая. Я мультиагентами в полностью автоматическом режиме пару софтин построил. Больше теста ради, но заметно, что мультиагенты могут делать прям большие штуки. Но это за рамками статьи
Вы знаете, это не показатель. Ситуации, когда один агент не может разобраться с багом, а второй быстро всё находит - бывают и при переходе от сильных моделей к более слабым. Вот если бы, неудачу потерпели opus, gpt, deepseek, а fable бы быстро нашёл, это бы был более верный эксперимент
И всё-таки для моделей qwen надо бы юзать qwen-code. Тем более, что qwen-code - это произведение искусства
А квадратного то зачем?
Точно так же, как с любым другим источником информации
На такое много токенов надо...
Уууу... ИИ и MAX в одной статье... А вы смелый.
Ути, какая знакомая платформа :) . Прошло пятнадцать лет, а на ней как собирали, так и собирают :)
Полезная штука.
В принципе с поиском дублей справляются и сами нейронки, но их в ci встраивать ещё проблемнее. Вообще, пора подобными инструментами обвешиваться.
Вау... Нет, пожалуй, это перебор.
У меня четыре монитора стоят, чтобы делать одну задачу :)
Сколько же понадобится для двух...
Прикольно. Я уже видел этот фокус. При моделирование пространства комплексных чисел через i = e1*e2. Но тут оно поднято на гораздо более высокий уровень.
Комментарий оставить хочется, но по теме что сказать - пока ещё не знаю.
Поэтому докладаю, что статья прикольно написана. Выверенный язык, авторский голос... Приятно читать.
Проблема в масштабировании этого результата на продакшн - сохранение совместимости. Тут я могу и несколько раз уже так делал - писать и выкидывать огромные подсистемы просто потому, что они мне не нравятся. На существующий продакшн это не распространить, хотя, на работе масштабный рефакторинг наших легаси-монолитов я начал. Но там приходится работать сильно аккуратнее
Мы - это я и агенты. Всё верно. Меня тоже очень интересует эта арифметика. 60 000 на 4 неделе в месяце и на 4 месяца - это около миллиона, а у нас 250 тысяч. Большая часть правок действительно относится к переписыванию кода, а не к написанию нового. Об этом, собственно и та часть статьи, что говорит про рефакторинг.
Проект пережил две огромных миграции. Переписывания движка с пайтон на си - это первая. Потом было еще разбиение получившегося монолита на библиотеки. А ещё мы переписывались с PyQt на собственный UI фреймворк.
Скорее всего суммарный объём правок даже больше. Я как-то видел 130 kloc на горячей неделе, и думаю, что это не самое большое число. Не то чтобы я активно следил за этой метрикой.
Проект меняется сумашедшими темпами.
Гарри Поттер нынче не в моде
Четыре тысячи строк всё ещё много. Две тысячи строк - верхняя граница. По хорошему тревогу надо поднимать уже на полутора тысячах. Хорошо, если файл не уходит за тысячу.
У клода есть отдельный пунктик про 2000 строк. До какого-то момента, времён этак 4.5 (надеюсь Антропики это уже починили), клод даже просто разобрать файл свыше двух косарей на части толком не мог. Приходилось других агентов на помощь звать. Но так-то это их общее слабое место.
Да я даже когда тесты красные не ругаюсь. Я считаю это необходимым злом при ударной разработке. Но в какой-то момент мы садимся и начинаем все упавшие тесты разбирать.
Я достаточно хорошо понимаю, что происходит в проекте, чтобы не переживать о чём-то что временно отвалилось.
Но это именно по нынешней ударной стройке. Так-то у нас все тесты зелёные. Агент за ними вполне себе следит. А если не следит, это отлавливает ci и тогда я пинаю агента. Он смотрит гит и чинит. И тесты снова становятся зелёные.
Мультиагентов я именно что в тестовом режиме гонял. Чисто на пробу. Так что пока писать не о чем. Впринципе, я использую многоагентные сценарии "в продакшне", но оркестратором выступаю сам.
У меня не было тезиса, что тесты больше не работают. Тезис был, что тесты защищают гипотезу агента.
И защищают по прежнему хорошо. В моих проектах тесты переодически ловят регрессы, и тогда агент корректирует... Или код или тесты под новое поведение. С ними всё нормально. Но я ими по большей части не занимаюсь. Тестами ведает агент.
Многоагентность да. Это штука хорошая. Я мультиагентами в полностью автоматическом режиме пару софтин построил. Больше теста ради, но заметно, что мультиагенты могут делать прям большие штуки. Но это за рамками статьи
В чём тогда разница между использованием и неиспользованием нейросетей, если глаза программиста всё равно не считаются?
Хм... Вам не понравился раздел про "Ваши новые глаза"? Или вы полагаете, что описанные методы не работают?