А не проще заставить ИИ-агента отдавать свой код на валидацию среде разработки до того, как код будет выдан пользователю? И если IDE скажет, что импортирована несуществующая библитека, то LLM-ке придется переделывать. И повторять этот цикл до тех пор, пока валидация не будет пройдена, а уже потом готовый результат отдать пользователю
Но в целом проблему доверия это не решит, все равно нельзя будет использовать написанный нейросетью код не глядя. Ошибки, которые выявляются синтаксическим и статическим анализом, далеко не единственные ошибки, которые могут быть в программе
А если бы прочитали дальше, то поняли бы, что имеется ввиду не буквально "невозможно вообще", а что "возможно, но по цене сопоставимо с запуском целиком, либо близко к этому". И статья про снижение этой самой цены если не на порядки, то хотя бы в разы
Дети познают радости TDD. Оказывается, для этого нужна какая-то приблуда в IDE, а грамотная организация рабочего процесса. Теперь заживём!
Не TDD (я так понял, вы имеете ввиду разработку через тестирование), а Exploratory Development (исследовательская разработка). И по сути статья про то, что будущее за ней
Зря я вообще использовал слово "тестировать", надо было сразу начинать с "ставить опыты". Смысл вроде похожий, но на деле выходит что кардинально разный
Совсем нет. Тестирование появилось одновременно с программированием, а сейчас тестирование очень развито, все части программы можно протестировать до запуска целиком.
Ну я конкретно про возможность ставить опыты над частями программы, а не просто про тесты. Если вы про юнит-тесты, то вот в другом комментарии писал, что это не то.
Это скорее про заказчика, а не про исполнителя в классическом программировании для бизнеса: исполнитель понимает, а заказчик - не факт. А в вайбкодинге исполнитель - ЛЛМ, ЛЛМ - "понимает", а вот вайбкодер - не факт.
Ну я и писал в начале статьи, что вайбкодер это заказчик. Но и действующим программистам ведь тоже довольно часто приходится изучать готовый код, и им нужно правильно понимать, как он работает. Да и свой код можно забыть
а из непонятного - почему вы не поменяете свой арсенал знаний и инструментов, которые держат вас в таких рамках, если видите эти рамки?
Применяю, я ж писал, что описанный в статье инструмент я использую на базе фейковой отладки
Для тех кто пишет что заголовок кликбейт и есть разрыв с содержимым в статье. Ну я понимаю что у каждого свои критерии освоения программирования, но заголовок раскрывается вполне конкретным тезисом в статье (ссылка ведет прямо на него, если кому-то нужен контекст).
...А программирование как раз и изучается опытным путем, путем экспериментов, и если есть способ проводить опыты в сто раз быстрее, то и программирование будет освоено в сто раз быстрее.
Вы можете соглашаться с этим или не соглашаться, и вообще посчитать это полным бредом. Но я и не против, пишите про это, пока что этот тезис вообще никто не прокомментировал и не процитировал даже
Я даже в первых редакциях статьи хотел описать подраздел "почему юнит-тесты не про это", но потом вырезал его. Здесь же речь не просто о тестах, а именно о том, чтобы ставить опыты над разными кусками программы, для чего предназначены не юнит-тесты, а REPL, на концепции которого и основана статья. И в общем то ChatGPT тоже самое скажет, если спросить его, "могут ли юнит тесты заменить REPL?"
Ответ ChatGPT
Юнит-тест не может заменить REPL, потому что они решают разные задачи и служат разным этапам разработки:
REPL (Read-Eval-Print Loop) — это интерактивная среда для исследования, экспериментов и быстрого получения обратной связи. Она помогает:
попробовать идею без необходимости писать всю структуру программы;
исследовать поведение библиотеки или API;
вручную проверить результат выражения;
работать с неопределённостью и гипотезами во время разработки.
Юнит-тесты — это формализованные, автоматические проверки того, что программа ведёт себя ожидаемо. Они:
фиксируют поведение кода на длительное время;
автоматически проверяются при изменениях, предотвращая регрессии;
являются частью документации и защиты от ошибок.
Коротко:
REPL — это живой, исследовательский процесс. Он нужен, когда ты ещё не уверен, что и как должно работать.
Юнит-тест — это способ зафиксировать, что уже работает как надо, и убедиться, что это не сломается позже.
Поэтому REPL — это про познание, юнит-тест — про проверку и контроль. Одно не заменяет другое.
А теперь та же самая ситуация, только этот же механик увидел марсианский корабль в возрасте 7 лет (т.е. отнимем у него знания, умения и опыт с земными механизмах). Ему ваш инструмент будет абсолютно бесполезен.
Он может не осознавать необходимость если привык верить на слово своим догадкам и еще не сталкивался с последствиями такого подхода. У детей такое бывает, но даже тут ребенок ребенку рознь, и если у одного это есть, другой предпочел бы проверить свои размышления на практике
Проблема была и остается в целепологании, уровне зрелости и понимании домена.
А разве не в умении решать задачи? Ниже про это комент оставляли
Брать статью целиком и прогонять через ChatGPT неудобно, поскольку у Хабра свое кастомное форматирование, которое слетит после прогона. Был бы встроенный ассистент я может и попросил бы отредачить. При условии что мне Хабр показал diff до и после
Кстати аналогия с заводом даже лучше будет чем с автомобилем. Но суть остается та же. Даже если брать готовые станки, то попробовать изготовить на них нужную деталь лучше до того, как его поставили на завод. Чтобы не столкнуться с тем, что прочитал описание станка, сделал вывод что он может изготовить то что необходимо, а уже в процессе запуска всей линии оказалось, что не может. При этом внутреннее устройство станка знать действительно не обязательно
Я ее сам не раз вызывал, и там от случая к случаю, сколько кода нужно подготовить. Когда реально много, тогда проще было отладку запустить, но это 30% от всего. А так бывают например функции, которые не принимают параметров, или принимают не сложные. Там я вручную заполнял переменные, которые потом использовал в вызове. И как я писал в спойлере, этот код может быть подготовлен автоматически, и не всегда для этого нужен будет ИИ (он как один из вариантов)
А потом к этому как-то (логика не очень прослеживается) приплетен REPL
Ну как-бы он решает проблему двигателя и машины, но мне ее тут слово в слово пересказать? Это и есть объяснение зачем он. А если оно непонятное, то давайте уже конкретику тогда
можно даже код рабочий за час написать с помощью чатгпт, но только к программированию это отношение имеет примерно такое же, как умение аутиста на память воспроизводить огромные тексты - к умению разговаривать.
Ну так я еще в начале статьи написал что вайб-кодинг не имеет отношения к умению программировать. И речь тут о любом языке шла
Важно не то, сколько процентов кода пишет нейронка (пусть даже и все 100%), а то, сколько процентов из этого кода можно использовать не глядя
Информацию не нужно никуда загружать, базовая теория может быть покрыта beginners-friedly UI, даже нынешний UI IDE ее частично покрывает. Нужно только опытным путем убедится, что все понял правильно, что можно будет сделать в сто раз быстрее
А не проще заставить ИИ-агента отдавать свой код на валидацию среде разработки до того, как код будет выдан пользователю? И если IDE скажет, что импортирована несуществующая библитека, то LLM-ке придется переделывать. И повторять этот цикл до тех пор, пока валидация не будет пройдена, а уже потом готовый результат отдать пользователю
Но в целом проблему доверия это не решит, все равно нельзя будет использовать написанный нейросетью код не глядя. Ошибки, которые выявляются синтаксическим и статическим анализом, далеко не единственные ошибки, которые могут быть в программе
А если бы прочитали дальше, то поняли бы, что имеется ввиду не буквально "невозможно вообще", а что "возможно, но по цене сопоставимо с запуском целиком, либо близко к этому". И статья про снижение этой самой цены если не на порядки, то хотя бы в разы
Не TDD (я так понял, вы имеете ввиду разработку через тестирование), а Exploratory Development (исследовательская разработка). И по сути статья про то, что будущее за ней
Зря я вообще использовал слово "тестировать", надо было сразу начинать с "ставить опыты". Смысл вроде похожий, но на деле выходит что кардинально разный
Ну я конкретно про возможность ставить опыты над частями программы, а не просто про тесты. Если вы про юнит-тесты, то вот в другом комментарии писал, что это не то.
Ну я и писал в начале статьи, что вайбкодер это заказчик. Но и действующим программистам ведь тоже довольно часто приходится изучать готовый код, и им нужно правильно понимать, как он работает. Да и свой код можно забыть
Применяю, я ж писал, что описанный в статье инструмент я использую на базе фейковой отладки
Насчет разрыва названия и содержимого написал закрепленный комент
Для тех кто пишет что заголовок кликбейт и есть разрыв с содержимым в статье. Ну я понимаю что у каждого свои критерии освоения программирования, но заголовок раскрывается вполне конкретным тезисом в статье (ссылка ведет прямо на него, если кому-то нужен контекст).
Вы можете соглашаться с этим или не соглашаться, и вообще посчитать это полным бредом. Но я и не против, пишите про это, пока что этот тезис вообще никто не прокомментировал и не процитировал даже
Я даже в первых редакциях статьи хотел описать подраздел "почему юнит-тесты не про это", но потом вырезал его. Здесь же речь не просто о тестах, а именно о том, чтобы ставить опыты над разными кусками программы, для чего предназначены не юнит-тесты, а REPL, на концепции которого и основана статья. И в общем то ChatGPT тоже самое скажет, если спросить его, "могут ли юнит тесты заменить REPL?"
Ответ ChatGPT
Юнит-тест не может заменить REPL, потому что они решают разные задачи и служат разным этапам разработки:
REPL (Read-Eval-Print Loop) — это интерактивная среда для исследования, экспериментов и быстрого получения обратной связи. Она помогает:
попробовать идею без необходимости писать всю структуру программы;
исследовать поведение библиотеки или API;
вручную проверить результат выражения;
работать с неопределённостью и гипотезами во время разработки.
Юнит-тесты — это формализованные, автоматические проверки того, что программа ведёт себя ожидаемо. Они:
фиксируют поведение кода на длительное время;
автоматически проверяются при изменениях, предотвращая регрессии;
являются частью документации и защиты от ошибок.
Коротко:
REPL — это живой, исследовательский процесс. Он нужен, когда ты ещё не уверен, что и как должно работать.
Юнит-тест — это способ зафиксировать, что уже работает как надо, и убедиться, что это не сломается позже.
Поэтому REPL — это про познание, юнит-тест — про проверку и контроль. Одно не заменяет другое.
Он может не осознавать необходимость если привык верить на слово своим догадкам и еще не сталкивался с последствиями такого подхода. У детей такое бывает, но даже тут ребенок ребенку рознь, и если у одного это есть, другой предпочел бы проверить свои размышления на практике
А разве не в умении решать задачи? Ниже про это комент оставляли
Брать статью целиком и прогонять через ChatGPT неудобно, поскольку у Хабра свое кастомное форматирование, которое слетит после прогона. Был бы встроенный ассистент я может и попросил бы отредачить. При условии что мне Хабр показал diff до и после
Кстати аналогия с заводом даже лучше будет чем с автомобилем. Но суть остается та же. Даже если брать готовые станки, то попробовать изготовить на них нужную деталь лучше до того, как его поставили на завод. Чтобы не столкнуться с тем, что прочитал описание станка, сделал вывод что он может изготовить то что необходимо, а уже в процессе запуска всей линии оказалось, что не может. При этом внутреннее устройство станка знать действительно не обязательно
Как раз таки понимаю, но считаю что в будущем будут изобретены способы помочь отстающим догнать тех, кто впереди
Я ее сам не раз вызывал, и там от случая к случаю, сколько кода нужно подготовить. Когда реально много, тогда проще было отладку запустить, но это 30% от всего. А так бывают например функции, которые не принимают параметров, или принимают не сложные. Там я вручную заполнял переменные, которые потом использовал в вызове. И как я писал в спойлере, этот код может быть подготовлен автоматически, и не всегда для этого нужен будет ИИ (он как один из вариантов)
Ускорит и упросит получение обратной связи, позволит проверять гипотезы
Ну как-бы он решает проблему двигателя и машины, но мне ее тут слово в слово пересказать? Это и есть объяснение зачем он. А если оно непонятное, то давайте уже конкретику тогда
Ну так спрашивайте, что конкретно непонятно в статье
Ну так я еще в начале статьи написал что вайб-кодинг не имеет отношения к умению программировать. И речь тут о любом языке шла
Но статья то не про вайб-кодинг
Оно зависит от того, нужно ли ради этого танцевать с бубнами или нет. Если нужно, то многие предпочтут не копать, им будет просто лень