Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Пет проекты вредная штука потому что внушают ложную уверенность.
Сначала хотел спросить как часто программа ломает внешнее поведение, контракты и привычки, ломает данные и какой ущерб это принесло. С пет проекта не спросить за ущерб.
Ну, я не один же проект пишу. Этот просто самый масштабный. В моей практике прям таки ущерба от применения нейронок допущено не было
Могу только сделать вывод, что код при отсутствии факторов сдерживания способен быстро расширяться и даже что-то делать. Вопрос, способен ли он делать то что нужно заказчику, а не по галлюцинациям LLM о намерениях и ценностях. Способен ли меняться куда надо и давать нужные гарантии. Можно ли это смоделировать в пет без psycho bias?
Если, скажем, вы пишете спецификации после кода или подгоняете намерения под реализацию, то нет. Не сможете.
Из конструктивного: попробуйте смоделировать роль заказчика и чтобы она не пересекалась с командой разработчиков. Заказчик, эксплуатация, KPI, надёжность - вот это вот всё
Кстати, об этом. Когда мы запускали позиционер, а это здоровенная многотонная дура, с алгоритмом, написанным нейронкой, у меня уверенности в коде было куда как больше, чем в те времена, когда я писал сам.
Мы вылизали код до идеального блеска. И запустились с первого раза.
В статье полностью отсутствует ориентация на бизнес, потребителя. Только технологии.
Значит, в энтерпрайз вам точно нельзя. Тиражируемое программное обеспечение (игры?) или SAAS - возможно. Но это не мой профиль. Если вы там, то можете меня не слушать (ну а я вас) - мы не пересекаемся
Хорошее эссе, по психологии агента подписываюсь под каждым пунктом, особенно про буквальное понимание и оптимизацию репозитория под агента.
По тестам поспорю мягко. У меня обратный опыт: пишу компилятор с агентами, юнит и регресс-тесты (около 2000) держат как раз то, что интеграционные и визуальные не ловят - тихие поломки в уже работавших местах. Агент закрыл план, регрессия красная - план не закрыт. Без этого барьера агенты накапливают незаметные регрессии очень быстро. Возможно зависит от типа проекта: у компилятора цена тихой поломки высокая, визуально её не увидишь.
Многоагентность - да, на старте у меня тоже эхо-камера получалась, дорого и без толку. Но когда ревьюеры с разным фокусом и контекстом, выхлоп оправдывает.
У меня не было тезиса, что тесты больше не работают. Тезис был, что тесты защищают гипотезу агента.
И защищают по прежнему хорошо. В моих проектах тесты переодически ловят регрессы, и тогда агент корректирует... Или код или тесты под новое поведение. С ними всё нормально. Но я ими по большей части не занимаюсь. Тестами ведает агент.
Многоагентность да. Это штука хорошая. Я мультиагентами в полностью автоматическом режиме пару софтин построил. Больше теста ради, но заметно, что мультиагенты могут делать прям большие штуки. Но это за рамками статьи
Принято, видимо я неправильно прочитал тезис. Тогда мы согласны больше чем я думал: тесты защищают гипотезу агента, и работают. У меня агент тоже сам пишет и чинит тесты, я больше слежу за тем что именно проверяется, руками не пишу.
Расхождение тогда только в акценте. У меня регресс-барьер жёсткий: красный тест блокирует закрытие плана автоматически, агент не может проскочить. Видимо у вас агент сам решает, чинить код или тест под новое поведение - чуть больше доверия агенту на этом шаге.
Про мультиагенты интересно, что вы их в полностью автоматическом режиме гоняли. У меня всё-таки человек в петле на ключевых решениях. Было бы любопытно почитать отдельно, если соберётесь написать.
Да я даже когда тесты красные не ругаюсь. Я считаю это необходимым злом при ударной разработке. Но в какой-то момент мы садимся и начинаем все упавшие тесты разбирать.
Я достаточно хорошо понимаю, что происходит в проекте, чтобы не переживать о чём-то что временно отвалилось.
Но это именно по нынешней ударной стройке. Так-то у нас все тесты зелёные. Агент за ними вполне себе следит. А если не следит, это отлавливает ci и тогда я пинаю агента. Он смотрит гит и чинит. И тесты снова становятся зелёные.
Мультиагентов я именно что в тестовом режиме гонял. Чисто на пробу. Так что пока писать не о чем. Впринципе, я использую многоагентные сценарии "в продакшне", но оркестратором выступаю сам.
Джин из волшебной коробки
Поколение «фэнтези» вошло в IT и никак не хочет принять то, что Гарри Поттера не существует.
В моём нынешнем пэт-проекте двести пятьдесят тысяч строк. … Мы сделали это за четыре месяца, не особенно напрягаясь. Объём кодовых правок — шестьдесят тысяч строк в типовую неделю. Впрочем, все знают, что вайбкодеры быстро пишут.
60к строк в неделю за 4 месяца дадут более миллиона строк кода. Т.е. проект переписан более 4х раз полностью. А среднее время жизни строчки кода - месяц.
А если учесть что там не один разраб (судя по “Мы сделали это”), то эти цифры умножаются на число разработчиков (вспоминая другие сообщения пользователя, 60к строк - это на одного вайбкодера).
P.S. статья интересная и полезная. Написано с юмором. Но я бы не масштабировал ее результаты, тем более на продакшен-код - явно куча скрытых нюансов, как и в любой истории успеха.
Мы - это я и агенты. Всё верно. Меня тоже очень интересует эта арифметика. 60 000 на 4 неделе в месяце и на 4 месяца - это около миллиона, а у нас 250 тысяч. Большая часть правок действительно относится к переписыванию кода, а не к написанию нового. Об этом, собственно и та часть статьи, что говорит про рефакторинг.
Проект пережил две огромных миграции. Переписывания движка с пайтон на си - это первая. Потом было еще разбиение получившегося монолита на библиотеки. А ещё мы переписывались с PyQt на собственный UI фреймворк.
Скорее всего суммарный объём правок даже больше. Я как-то видел 130 kloc на горячей неделе, и думаю, что это не самое большое число. Не то чтобы я активно следил за этой метрикой.
Проект меняется сумашедшими темпами.
Проблема в масштабировании этого результата на продакшн - сохранение совместимости. Тут я могу и несколько раз уже так делал - писать и выкидывать огромные подсистемы просто потому, что они мне не нравятся. На существующий продакшн это не распространить, хотя, на работе масштабный рефакторинг наших легаси-монолитов я начал. Но там приходится работать сильно аккуратнее
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Здравствуйте, я мистер Мисикс. Практические заметки о психологии вашего искина