Comments 13
Т.е., заранее понимаю, что качество кода, сгенерированное нейросетью, не особо высоко, и более того, не обязательно решай даже поставленную перед сетью задачу, мы, вместо того, чтобы посадить туда толкового разработчика, либо как-то до обучить сеть, тупо обвешивает её кучей тестов, и долби все до последнего, пока тесты не пройдут?
Смысл конечно в этом есть, однако же, мы понимаем, что нейросеть не решает напрямую задачу поставленную перед ней - она решает некую языковую задачку, которая, возможно, в итоге даст запускаемый код. В итоге, нам нужны очень хорошие тесты, которые покажут не просто наличие кода "на входе" проверки, и не просто подтвердят, что этот код запускается, ну и проверит все-все-все-все-все подробности работы этого кода. На глазок, кажется, что написание подобного теста не сильно проще, чем написание проверяемого кода.
Если честно, на условном самолёте, для которого код будет писать такая вот связка, летайте, пожалуйста сами! Кажется, нам ещё не хватило истории с боингами и разработкой критического кода и компоновок "на аутсорсе" – и вот мы решили отдать разработку "не знамо чего" вообще "не знаем чему".
Зато экономия на разработчиках весомая, правда?
Доведем логическую цепочку: из-за таких вот экономии число разработчиков в этом или следующем или ещё следующем поколении айтишников станет ещё меньше, и когда пойдёт обратная волна (откат) и мы решим что для критических вещей нам всё-таки нужны грамотные люди и прямые руки, грамотных людей прямых рук в доступности к найму будет ещё меньше.
(Юнит) тесты нужно писать в любом случае (уже жду споры о том что это не так и код должен работать на честном слове, хотя казалось бы 2025 год на дворе). В конце концов, если код написанный ИИ и код написанный человеком проходит один и тот же набор тестов, то какая разница, кто его писал? Да нужно сделать рефакторинг и т.п. И да, написание (хороших) тестов не проще чем реализация. Если не хватает уверенности - можно использовать фаззинг и PBT.
Вообще, писать код и писать тесты по-хорошему должны разные люди, но это невозможно в TDD (если это не парное программирование).
При написании кода условного самолета используют более строгие методы проверки качества, чем тестирование, вроде формальной верификации - только так можно проверить, что код соответствует спецификации (что не защищает от ошибок в самой спецификации).
Я полностью согласен, что в тупую генерировать код критически важных систем нельзя. И пока в таких делах полагаться на LLM явно преждевременно.
Но, если подумать, то говоря о критически важных системах (вроде условного самолета), мне бы хотелось чтобы там действительно было очень много очень хороших тестов, которые проверяют все-все-все. И сказать, что мне было бы спокойнее от того, что в самолете какой-то код недостаточно покрыт тестами, но его писал человек, ситуацию не облегчает.
Но, как мне кажется, сейчас вопрос будет стоять несколько по другому. Код-ассистенты неизбежно будут использоваться в подобных компаниях в том числе. И с этим надо будет как-то жить. Я сейчас пробежался глазами по сайтам некоторых код-ассистентов и там нет производителей самолетов, но у GitHub Copilot в списке клиентов числится, например, BMW. Тоже ничего так.
Ну а грамотным людям с прямыми руками я думаю появление мощных инструментов разработки уж точно никак не угрожает.
К тому же, большой минус в том, что текущие инструменты не совсем приспособлены к такому подходу.
Aider такое умеет. Делаешь в его консоли `/run <your-toolchain> tests` , он запускает тесты, и если они не прошли - предлагает отправить вывод в модель и пофиксить. Обычно справляется.
Другое дело что он очень opinionated в плане ui/ux и не многим подойдёт.
Тоже про такое думаю (процесс LLM+TDD) для написания тестов, так как это полезное практическое применение на данном уровне развития.
Implement only the minimal code necessary to pass the provided tests.
Так точно, капитан!
if (we_in_test_environment) {
do_behavior_to_do_green();
} else {
do_any_crap_behavior();
}
А чтобы выйти из этой неприятной ситуации нужны не юнит-тесты с мок объектами, а полноценные интеграционные - которые писать кратно сложнее, окружение для них кратно тяжелее и выполняются они кратно дольше. Так что картинка про отладку в 24ч кода нейросети актуальна как никогда.
до сих пор нет единого мнения о ее эффективности.
Нет, не так. Нет доказанных измерений ее эффективности. Вот вы же их тоже не привели, не заметили?
Т.е. типичная статья, агитирующая за применение TDD, выглядит как-то так: "А у меня получилось повысить эффективность при внедрении TDD". А я смотрю на это, и понимаю, что никаких выводов про свою работу и свой проект сделать не могу. Потому что те задачи, которые призвана решать методика TDD, я давно и достаточно успешно решаю другими способами, и мне не нужен тест, чтобы описать, что должен делать код - я это способен держать в голове. Ну или я сразу пишу кусок кода, который будет пользоваться другим куском кода - вместо теста.
Разумеется, я это не интерполирую на других, кому-то другому методика может быть помогает. Но я без измерений ее внедрять не буду. А измерять производительность программистов, так чтобы это измерение было применимо к другим программистам, другой квалификации, опыта и т.п., почти никто не умеет, потому что это тупо сложно.
Удивительно, как люди советующие самим летать на AI-разработанных самолетах пользуются бытовыми приборами собранными на полностью автоматизированных производственных линиях, ах, да, это же другое...
А теперь по делу. Разработкой TDD с AI пользуюсь довольно давно. И прийти к этому довольно просто, надеюсь, что даже самые отъявленные скептики, вероятно задумаются.
Грубо про TDD - есть четко представленная идея / тех задание. Пишем тест на тех задание, представив, что реализация уже есть. После написания теста, пишем реализацию проходящую тест.
Удивительно, но есть работающий пример, как создания теста под "тех задание" так и создания собственно самого кода: это код-генератор клиента и сервера почти на на любом языке по описанию из yaml. Сомневаетесь что это работает? - зайдите на editor.swagger.io
Из текста в код... не находите аналогий со статьей?
Далее. проще. Задача написать хорошую yaml-схему. Тоже довольно просто, поскольку есть отличные YAML валидаторы и какая-никакая спека OpenAPI (кстати новая версия вышла, Arrazo называется) для проверки корректности смысла схемы.
А вот тут LLM просто прекрасно справляются. Поскольку это не код и yaml-схема не может работать или не работать. Это текст. Проверить корректность описания endpoint-a довольно просто визуально.
В итоге в моем примере, LLM, плюс линтеры по тех заданию клепают yaml, а после какой-нибудь connexion генерит код. В моей работе я не могу вспомнить примеры с ноября 2023, когда это не cработало. Тогда Мы/Я в команде начали использовать codewhisperer/codeium для этого.
Да, немного не в стиле идеи статьи, поскольку у нас по тех заданию сразу генерится клиент сервер приложение, а не тесты. Сейчас уже 420 api, работают как часы. Продолжим.
Наш следующий шаг в использовании произошел прошлым летом, когда в codewhisperer появились конвейеры проверяющие верность сгенерированного кода прежде, чем выдать ответ на промпт. Да, обычно это здорово тормозит генерацию ответа, но убыстряет путь к рабочему решению.
Так вот. Вернемся к статье.
Машина не должна писать тесты. Тесты - зона ответственности программиста.
Это утверждение я поставил под сомнение: оказывается, машина может писать тесты. Точнее llm пишет задание генератору кода, а с лета 2024 агент научился запускать кодгенератор и предлагать граничные условия для тестов, часто более качественно или подробно, чем это сделал бы я. Например https://github.com/django/django/blob/main/tests/utils_tests/test_numberformat.py - набор случаев созданных человеком ранее не включал большое отрицательное число записанное через e.форму. Уже поправили.
Ну так вот, по поводу писать тесты самому: мой промпт на TDD обсуждался в чате одного из Code-assistant. выглядит примерно так:
Please generate TDD tests for Django project according to this specification:
Дальше текст тех задания на разработку.
Да, предварительный контекст для модели тоже используется, больше похож на codestyleguide проекта и мои личные предпочтения по коду (например, на питоне писать генераторами без использования [] ). И на мой взгляд, наш ассистент справляется очень хорошо: Тесты работают сразу, граничные условия более продуманные, я часто потом уменьшаю их количество, типа - "тут одного хватит"
Так вот. Я к тому, что задача, которую должна выполнить модель - это сформировать по моему нечеткому тз декларативный документ для запуска кодогенерации. А самих код генераторов вагон и тележка. И они выдают результат работающий без сомнений.
Верить или нет коду от LLM, конечно, решать в итоге разработчику. Но вот сократить время разработки LLM точно могут. И кстати, на мой взгляд, с LLM подход TDD, скорее всего, станет не нужен.
Сравнить AI с автоматизированными линиями, мда. Автоматизированная линия гарантировано выдаст одну и ту же продукцию.
ну если совсем "душнить", то я сравнивал результаты производства (самолет и бытовые приборы) не способы. Так вот. В автоматизированных линиях есть допустимый процент брака в районе 5%. Потому гарантированность одного и того же результата в районе 95%.
Если с AI я достиг того же - одинаковый результат в 95% случаев - то инженерная задача решена. Или нет?
AI бояться - на BMW не ездить. Там уже давно тестируют роботов.
AI-driven TDD — используем Code-LLM на максимум