Pull to refresh

Comments 30

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

В статье сказано: не выдержит стиль. Мне доводилось читать и поддерживать код, написанный 5 разными разработчиками с разным представлением о прекрасном. Каждый отдельный кусочек был прекрасен. но всё вместе это было читать очень тяжело.

Плюс мне он пишет код... в студенческом стиле, что ли. Вопросы читаемости и расширяемости его вообще не волнуют.

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

Самое смешное, что именно эти требования машине выполнить проще всего. Ещё до llm были линтеры с проверкой стиля кода, автоматизированные проверки безопасности, тесты производительности, да и асимптотический анализ (чтоб не всадить на ровном месте O(n²)) сделать может.

Вы упускаете две важные проблемы. Во-первых, результаты LLM ближе к результатам человека, чем машины. Во-вторых, одних линтеров для контроля нефункциональных требований категорически недостаточно - они с этим помогают, берут на себя какие-то рутинные проверки, но эти проверки закрывают незначительную часть нефункциональных требований. Иными словами, если на проекте настроены линтеры и автоматизированные тесты производительности, то LLM (в режиме агента) вполне в состоянии выдавать код, который эти тесты проходит. Но между этим и соблюдением нефункциональных требований проекта - пропасть.

Обучить их выполнять конкретно этот набор требований – imho заметно проще, чем обучить выполнять функциональные требования. Просто в это не вложили столько усилий.

Это не так. Для выполнения функциональных обычно нужен очень небольшой контекст, плюс их легко проконтролировать тестами. А для нефункциональных всё ровно наоборот: контекст громадный, тесты фиг напишешь.

Я говорил конкретно про те требования, которые вы привели в качестве примера. Понятно, что есть более сложные и менее формализованные, с ними будет куда хуже.

результаты LLM ближе к результатам человека, чем машины

И близко нет. Это выхлоп марковского скрипта-генератора, по большому счёту.

Не важно, что там внутри, важен результат работы.

Буквально из свежего, ИИ не сделает сам:

  1. Профилирование, в широком смысле. Если вы знаете, как работает ваше решение, вы накидываете диаграмму последовательности всего вашего решения, оцениваете жизненный цикл объектов, решаете, где к примеру, можно реализовать слабые ссылки, чтобы сборщик мусора их собрал в первом проходе, и за счет этого уменьшаете расход памяти и повышаете скорость. Вы можете попросить это сделать LLM. Но есть две проблемы: не всегда корректно помещается весь контекст приложения. И ошибка на этом этапе может приводить к специфическим трудноуловимым багам (процент галлюцинаций никто не отменял). То есть если нужна производительность, надежность, то вам нужно через себя все пропускать.

  2. UI. В плане взаимодействия с интерфейсом только у вас и ваших коллег есть понимание, как обеспечить комфортную работу пользователя: информирование, органы управления, отсутствие перегрузки интерфейса, допустимые тайминги. ИИ сам здесь ничего глубокого не предложит.

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

  4. Проблема с узкими доменами все ещё остается. Если вы пишете для специфического API (САПР, например) то процент галлюцинаций в подсказках заметно выше.

По сути: если вам нужен результат на пятерку (в плане производительности, безопасности, пользовательского опыта), то ИИ только предлагает концепции, дает справку и накидывает методы. Все остальное должно было у вас в фокусе.

Очень, я бы сказала, широко расписали. Спасибо!
У меня были попытки разобраться с нишевыми решениями в ИИ (проходила курсы, в тестах были не совсем понятные вопросы, забивала в ИИ, причём, в разные нейросети - кто во что горазд и ни один не попал), но результата, о котором так часто говорят вайб-кодеры, я не увидела.
Я склоняюсь к тому, что ИИ хорош для образовательных задач в ИТ - поясни, найти косяк в маленьком куске и всё в этом духе.

Да, как учитель 24/7 очень хорош) удобно для этой цели использовать пункт Проекты в ChatGPT, кстати, тогда чаты по папкам как бы раскладываются

Спросите у LLM, чем отличается разработчик ПО от копипаст кодера

Смотря какую цель вы приследуете! Пишут же на zero-code, и норм. Тут аналогично.

Я писал парсера быстро, тоже с ИИ.. Потом надо было все поправить. Оно работало, все ок, но не долго.. 😁 Начал править, понял что руками переписать быстрее. Так как у меня усиановлен плагин который следит за временем, я четко знал сколько затратил тогда и сейчас. Руками оказалось не медленнее.. 😁 Хотя я был уверен что генерить в разы быстрее..

Проект пришлось полностью переписать..

Банально оно индексы кривые на лепило в ORM.. Пока генерилось, чет не думал.. А потом прошло 3 месяца, открыл, стало плохо.. 😂

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

UFO landed and left these words here

Мой знакомый, не программист (он бизнесмен, но как заказчик IT-проектов имеет больше 20 лет опыта), успешно реализовал вполне коммерческий проект используя ChatGPT в июле 2023. Т.е. это, вероятно, была модель GPT-4. Полностью самостоятельно, за 3 недели, в режиме копи-паста кода и инструкций по его деплою из чата, без понимания что первого что второго. Т.е. это был совершенно типичный вайб-кодинг. Проект до сих пор работает и развивается в том же режиме вайб-кодинга, плюс приносит деньги. Единственный нюанс - это было 4-е переписывание проекта, т.е. у него было очень хорошее представление о том, что и как проект (не) должен делать. Ну и это не хайлоад, конечно.

Вангую, что это до первой серьёзной нагрузки или атаки. По поводу атаки - не надо думать, что «мой проект мелкий, кому я надо». Там есть свои нюансы.

По нагрузке - я не знаю, как пишет Ваш знакомый, расскажу ща свой опыт. Нейронка очень по-своему воспринимает некоторые части. Я just for fun накидал простенькую браузерную игру с помощью нейронки. Так вот, во время общения складывалось ощущение, что мы на одной волне, что гпт понимает «ваще все, шо тока надо». По итогу выдал мне экран для прокачки персонажа с надписью «Тапа сюда!» вместо задранной картинки.

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

Не все, но… не знаю, не доверяю я проектам, собранным полностью на нейронках.

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

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

Но накинуть то нужно)

вайб-кодингу примерно год. Как он мог им два года заниматься ?

Год за два в условиях крайнего севера:)

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

Мне почему-то кажется, что за 2 года вайбкодинга просто так сесть и начать писать хороший код, - сложно. Чувак просто пиарится на том, что какой-то там основатель и его код не как у абы-кого код, но в целом проверить его код некому.

Так это же решаемая проблема. Прочитал код, нашел косяки, обозначил проблему ИИ, он написал план, я поправил план, а дальше пусть рефакторит. А если надо сделать какой-нибудь небольшой инструмент, то можно и навайбкодить.

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

Ещё постоянно заставляю ллм вычищать костыли в большом проект, которые происходят от незнания контекстов. Приходится строить дерево контекстов и правила back pressure для документации и состояния кодовой базы.

Если обобщить, то получится что ИИ пригоден для создания чего-то мелкого и/или не требовательных задач. А так же для создания заготовок которые необходимо доработать "напильником" в ручную. Или же для сборки из готовых кирпичиков-заготовок, опять таки с дальнейшим "напилингом".

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

Просто надо проверять результат на каждом этапе и просить подправить.

Sign up to leave a comment.

Other news