Pull to refresh

Comments 20

Пет проекты вредная штука потому что внушают ложную уверенность.

Сначала хотел спросить как часто программа ломает внешнее поведение, контракты и привычки, ломает данные и какой ущерб это принесло. С пет проекта не спросить за ущерб.

Ну, я не один же проект пишу. Этот просто самый масштабный. В моей практике прям таки ущерба от применения нейронок допущено не было

Могу только сделать вывод, что код при отсутствии факторов сдерживания способен быстро расширяться и даже что-то делать. Вопрос, способен ли он делать то что нужно заказчику, а не по галлюцинациям LLM о намерениях и ценностях. Способен ли меняться куда надо и давать нужные гарантии. Можно ли это смоделировать в пет без psycho bias?

Если, скажем, вы пишете спецификации после кода или подгоняете намерения под реализацию, то нет. Не сможете.

Из конструктивного: попробуйте смоделировать роль заказчика и чтобы она не пересекалась с командой разработчиков. Заказчик, эксплуатация, KPI, надёжность - вот это вот всё

Ну так кто программу то пишет, вы или нейронка. Это ваша ответственность делать так чтобы результат был таким, как нужно. А как это делать, я ответил. Вон целая статья выше

Кстати, об этом. Когда мы запускали позиционер, а это здоровенная многотонная дура, с алгоритмом, написанным нейронкой, у меня уверенности в коде было куда как больше, чем в те времена, когда я писал сам.

Мы вылизали код до идеального блеска. И запустились с первого раза.

В статье полностью отсутствует ориентация на бизнес, потребителя. Только технологии.

Значит, в энтерпрайз вам точно нельзя. Тиражируемое программное обеспечение (игры?) или SAAS - возможно. Но это не мой профиль. Если вы там, то можете меня не слушать (ну а я вас) - мы не пересекаемся

Статья про то, как получать от агента результат и делать так, чтобы проект не разваливался. Про бизнес - это не ко мне.

Вы даже не узнаете что проект развалился

Хм... Вам не понравился раздел про "Ваши новые глаза"? Или вы полагаете, что описанные методы не работают?

Глаза только у заказчика или пользователя. Остальное эрзац, даже ваши.

В чём тогда разница между использованием и неиспользованием нейросетей, если глаза программиста всё равно не считаются?

Хорошее эссе, по психологии агента подписываюсь под каждым пунктом, особенно про буквальное понимание и оптимизацию репозитория под агента.

По тестам поспорю мягко. У меня обратный опыт: пишу компилятор с агентами, юнит и регресс-тесты (около 2000) держат как раз то, что интеграционные и визуальные не ловят - тихие поломки в уже работавших местах. Агент закрыл план, регрессия красная - план не закрыт. Без этого барьера агенты накапливают незаметные регрессии очень быстро. Возможно зависит от типа проекта: у компилятора цена тихой поломки высокая, визуально её не увидишь.

Многоагентность - да, на старте у меня тоже эхо-камера получалась, дорого и без толку. Но когда ревьюеры с разным фокусом и контекстом, выхлоп оправдывает.

У меня не было тезиса, что тесты больше не работают. Тезис был, что тесты защищают гипотезу агента.

И защищают по прежнему хорошо. В моих проектах тесты переодически ловят регрессы, и тогда агент корректирует... Или код или тесты под новое поведение. С ними всё нормально. Но я ими по большей части не занимаюсь. Тестами ведает агент.

Многоагентность да. Это штука хорошая. Я мультиагентами в полностью автоматическом режиме пару софтин построил. Больше теста ради, но заметно, что мультиагенты могут делать прям большие штуки. Но это за рамками статьи

Принято, видимо я неправильно прочитал тезис. Тогда мы согласны больше чем я думал: тесты защищают гипотезу агента, и работают. У меня агент тоже сам пишет и чинит тесты, я больше слежу за тем что именно проверяется, руками не пишу.

Расхождение тогда только в акценте. У меня регресс-барьер жёсткий: красный тест блокирует закрытие плана автоматически, агент не может проскочить. Видимо у вас агент сам решает, чинить код или тест под новое поведение - чуть больше доверия агенту на этом шаге.

Про мультиагенты интересно, что вы их в полностью автоматическом режиме гоняли. У меня всё-таки человек в петле на ключевых решениях. Было бы любопытно почитать отдельно, если соберётесь написать.

Да я даже когда тесты красные не ругаюсь. Я считаю это необходимым злом при ударной разработке. Но в какой-то момент мы садимся и начинаем все упавшие тесты разбирать.

Я достаточно хорошо понимаю, что происходит в проекте, чтобы не переживать о чём-то что временно отвалилось.

Но это именно по нынешней ударной стройке. Так-то у нас все тесты зелёные. Агент за ними вполне себе следит. А если не следит, это отлавливает ci и тогда я пинаю агента. Он смотрит гит и чинит. И тесты снова становятся зелёные.

Мультиагентов я именно что в тестовом режиме гонял. Чисто на пробу. Так что пока писать не о чем. Впринципе, я использую многоагентные сценарии "в продакшне", но оркестратором выступаю сам.

Джин из волшебной коробки

Поколение «фэнтези» вошло в IT и никак не хочет принять то, что Гарри Поттера не существует.

Гарри Поттер нынче не в моде

В моём нынешнем пэт-проекте двести пятьдесят тысяч строк. … Мы сделали это за четыре месяца, не особенно напрягаясь. Объём кодовых правок — шестьдесят тысяч строк в типовую неделю. Впрочем, все знают, что вайбкодеры быстро пишут.

60к строк в неделю за 4 месяца дадут более миллиона строк кода. Т.е. проект переписан более 4х раз полностью. А среднее время жизни строчки кода - месяц.

А если учесть что там не один разраб (судя по “Мы сделали это”), то эти цифры умножаются на число разработчиков (вспоминая другие сообщения пользователя, 60к строк - это на одного вайбкодера).

P.S. статья интересная и полезная. Написано с юмором. Но я бы не масштабировал ее результаты, тем более на продакшен-код - явно куча скрытых нюансов, как и в любой истории успеха.

Мы - это я и агенты. Всё верно. Меня тоже очень интересует эта арифметика. 60 000 на 4 неделе в месяце и на 4 месяца - это около миллиона, а у нас 250 тысяч. Большая часть правок действительно относится к переписыванию кода, а не к написанию нового. Об этом, собственно и та часть статьи, что говорит про рефакторинг.

Проект пережил две огромных миграции. Переписывания движка с пайтон на си - это первая. Потом было еще разбиение получившегося монолита на библиотеки. А ещё мы переписывались с PyQt на собственный UI фреймворк.

Скорее всего суммарный объём правок даже больше. Я как-то видел 130 kloc на горячей неделе, и думаю, что это не самое большое число. Не то чтобы я активно следил за этой метрикой.

Проект меняется сумашедшими темпами.

Проблема в масштабировании этого результата на продакшн - сохранение совместимости. Тут я могу и несколько раз уже так делал - писать и выкидывать огромные подсистемы просто потому, что они мне не нравятся. На существующий продакшн это не распространить, хотя, на работе масштабный рефакторинг наших легаси-монолитов я начал. Но там приходится работать сильно аккуратнее

Sign up to leave a comment.

Articles