Возросло, но не кратно. В целом, чек-листы оказались одним из самых неоднозначных решений: вроде бы дорефачить до конца я бы мог и сам, это дело пары минут, а потребление токенов при этом сильно выше. Но, поскольку этап ревью предполагает чтение кода, мне очень важно было, чтобы код был легко читаем. Ну и мне не нравится оставлять на человека то, что можно автоматизировать.
Подскажите пожалуйста, как по вашим ощущениям выросло время исполнения средней задачки на фреймворке против "наивного промпт-вайб-кодинга"?
Да бог его знает. Раза в 3-4, наверное.
НУ и прожорливость по токенам...
По моим ощущениям оно растет прям кратно, ну то есть это цифры порядка х5... х10
Я бы тоже в таких порядках оценил. Там больше всего жрут чек-листы, по которым Фреймворк проходит.
До внедрения чек-листов мне хватало $100 подписки и в параллель я вёл 3-4 сессии. После - впритык $200 и 6 сессий. Значит, одни только чек-листы увеличили потребление токенов в 5 раз и время исполнения - в 2 раза.
ревьюить каждую строчку нейрокода человеками - безумие не меньшее.
Ну почему же) вот я 3 месяца так и делаю, вполне рабочий вариант.
У меня процесс сейчас: отпустил поработать, поревьюил, поправил косяки, отправил дальше. Если б косяков не было, я бы спокойно отпускал гулять на подольше, но косяки есть, поэтому пока только так.
Есть ли возможность сделать процесс сильно более автономным? Наверное. Но
Потребление токенов там совсем другое. Мне 200 баксов в месяц хватает впритык на текущий процесс.
Это требует усилий по разработке такого процесса. Сейчас пытаются сделать что-то подобное, см Gas Town и Weaving Look. Но это не готово.
IMHO, нет смысла человеку ревьюить нейрокод. На край, можно поручить это другой нейронке, но тоже такое - могут вступить в сговор. А вот делать приёмочные тесты (интеграционные) - смысл, наоборот, есть. Но это и с людьми так.
Это понятное замечание, но давайте я конкретнее объясню: неужели хорошая идея на 1000 приёмочных тестов писать ещё 1000 таких же, но перезагружающих приложение, чтобы проверить, что ллм все, что должна была, сохранила в базе, а не в стейте приложения? Я видел, как она делает нечто подобное. И ещё десятки других глупых ошибок, которые тестами вылавливать - натуральное безумие.
Да, где-то к таким цифрам я и пришёл. Но это мои личные наблюдения, не рекомендую их за догму принимать.
Ну а баги в самых неожиданных местах прячутся.
Мне кажется, баги чаще всего прячутся в неожиданных местах независимо от того, кто автор. Все, что прячутся в ожидаемых местах, обычно правят до ревью 😉
Да, перечитал и понял, что недостаточно понятно объяснил. Не стоит валидацию в тесте привязывать к базе. Конечно, приложение на стенде должно ходить в тестовый инстанс базы, но имелось в виду, что все взаимодействие с приложением должно происходить через публичные интерфейсы приложения.
Только что узнал кстати, что в SkyEng ребята на PHP практикуют TDD, CD и XP. Там пока открытых вакансий на разработчика не вижу, но, если очень интересно, то рекомендую им написать. Обычно работодатели инициативу ценят :)
Это, в принципе, редкость, не только для php. Как я писал в статье - таких всего 7%. Есть примеры pivotal, thoughtworks, Google, Amazon и ещё кучи компаний, где к автоматическому тестированию относятся очень серьёзно.
В России таких компаний исчезающе мало. Я видел, что подобным хватаются в додо. Есть ещё редкие компании, где это делают на уровне всей компании. В остальных местах подобные практики выполняются либо на уровне отдельных команд энтузиастов, либо отсутствуют вовсе.
Ну, я в статье несколько раз упоминал, что нет одного правильного способа. Просто потому что нет исследований, которые бы подтвердили, что одно правильнее другого. Поэтому смело можно брать тот вариант, который кажется сейчас правильнее. Потом все равно поток новых знаний заставит скорректировать взгляды.
По поводу вопроса:
Я не припомню, когда в последний раз нам требовалось мучиться с огромным количеством полей, которые бы могли меняться все без исключения. Что-то похожее решаем ломбоком с публичными сеттерами, если никакой валидации при изменении не требуется. Если требуется - это отдельный разговор.
Возросло, но не кратно. В целом, чек-листы оказались одним из самых неоднозначных решений: вроде бы дорефачить до конца я бы мог и сам, это дело пары минут, а потребление токенов при этом сильно выше. Но, поскольку этап ревью предполагает чтение кода, мне очень важно было, чтобы код был легко читаем. Ну и мне не нравится оставлять на человека то, что можно автоматизировать.
Привет. Да, меня уже попросили сделать демо, так что будет видос очень скоро.
Прикольно, подумаю, можно ли применить тут)
Да, у меня тоже такие ощущения, но я все равно стараюсь делать компактизацию на больших контекстах, полагая, что свежая модель справится лучше.
Да бог его знает. Раза в 3-4, наверное.
Я бы тоже в таких порядках оценил. Там больше всего жрут чек-листы, по которым Фреймворк проходит.
До внедрения чек-листов мне хватало $100 подписки и в параллель я вёл 3-4 сессии. После - впритык $200 и 6 сессий. Значит, одни только чек-листы увеличили потребление токенов в 5 раз и время исполнения - в 2 раза.
Спасибо!
100%
Ну почему же) вот я 3 месяца так и делаю, вполне рабочий вариант.
У меня процесс сейчас: отпустил поработать, поревьюил, поправил косяки, отправил дальше. Если б косяков не было, я бы спокойно отпускал гулять на подольше, но косяки есть, поэтому пока только так.
Есть ли возможность сделать процесс сильно более автономным? Наверное. Но
Потребление токенов там совсем другое. Мне 200 баксов в месяц хватает впритык на текущий процесс.
Это требует усилий по разработке такого процесса. Сейчас пытаются сделать что-то подобное, см Gas Town и Weaving Look. Но это не готово.
Жиза, сейчас, пока пилю пример Фреймворка, понимаю, насколько ллмкам нелегко на новых кодовых базах, когда ещё нет накатанных рельс.
Это понятное замечание, но давайте я конкретнее объясню: неужели хорошая идея на 1000 приёмочных тестов писать ещё 1000 таких же, но перезагружающих приложение, чтобы проверить, что ллм все, что должна была, сохранила в базе, а не в стейте приложения? Я видел, как она делает нечто подобное. И ещё десятки других глупых ошибок, которые тестами вылавливать - натуральное безумие.
Да, где-то к таким цифрам я и пришёл. Но это мои личные наблюдения, не рекомендую их за догму принимать.
Мне кажется, баги чаще всего прячутся в неожиданных местах независимо от того, кто автор. Все, что прячутся в ожидаемых местах, обычно правят до ревью 😉
Готово, залетайте:
https://t.me/RakovskyXP/59
Да, когда руки дойдут, опубликую
В каком смысле? Мы используем XP. Точнее только те его практики, которые у нас прижились)
Да, перечитал и понял, что недостаточно понятно объяснил. Не стоит валидацию в тесте привязывать к базе. Конечно, приложение на стенде должно ходить в тестовый инстанс базы, но имелось в виду, что все взаимодействие с приложением должно происходить через публичные интерфейсы приложения.
Как неправильно:
Создали через апи сущность
Сделали селект и увидели, что сущность создана
Как правильно:
Создали через апи сущность
Запросили сущности через апи
Проверили, что созданная вернулась.
Только что узнал кстати, что в SkyEng ребята на PHP практикуют TDD, CD и XP. Там пока открытых вакансий на разработчика не вижу, но, если очень интересно, то рекомендую им написать. Обычно работодатели инициативу ценят :)
Пром - калька с production environment, "промышленная среда". Используются во всяких банках. Написал по привычке, исправил не везде.
Это первая часть из цикла. Остальные две части дадут больше ответов. В ближайшие пару недель опубликую и их.
Это, в принципе, редкость, не только для php. Как я писал в статье - таких всего 7%. Есть примеры pivotal, thoughtworks, Google, Amazon и ещё кучи компаний, где к автоматическому тестированию относятся очень серьёзно.
В России таких компаний исчезающе мало. Я видел, что подобным хватаются в додо. Есть ещё редкие компании, где это делают на уровне всей компании. В остальных местах подобные практики выполняются либо на уровне отдельных команд энтузиастов, либо отсутствуют вовсе.
Конкретно про пхп, к сожалению, не подскажу.
Ну, я в статье несколько раз упоминал, что нет одного правильного способа. Просто потому что нет исследований, которые бы подтвердили, что одно правильнее другого. Поэтому смело можно брать тот вариант, который кажется сейчас правильнее. Потом все равно поток новых знаний заставит скорректировать взгляды.
По поводу вопроса:
Я не припомню, когда в последний раз нам требовалось мучиться с огромным количеством полей, которые бы могли меняться все без исключения. Что-то похожее решаем ломбоком с публичными сеттерами, если никакой валидации при изменении не требуется. Если требуется - это отдельный разговор.