Как раз наоборот, я придерживаюсь такого подхода, при котором, даже пришедший джун мог быстро разобраться в том, что написано, а не взрывать свои и мой мозг в надежде разобраться во взаимосвязи кучи модулей, которые настроили до него, по принципу тетриса на самой высокой скорости.
Я рад за Ваши успехи, но контекст проектов, с которыми я работал и работаю, это сотни( тысячи) листов А4, которые изменяются и дописываются в отличие от правил покера, т.к. появляются новые хотелки, обновляются инструменты, изменяется законодательство, политическая и экономическая ситуация в мире и т.д. И еще один интересный вопрос : каким кухонным комбайном лучше обработать печень рыбы фугу и кто, если что, понесет ответственность? А также насколько критична скорость обработки?
Такая бюрократия не всегда хорошо, так как много времени отнимает, то есть нужно нанимать промп-инженеров, которые по цене как разработчики, но только промт-инженеры. Опытному разработчику задача понятна по 2-3 предложениям из таска, на крайний случай 1 созвон на 5-10 мин. Будет ли такая задача понятна промт-инженеру для генерации нужного промта, сомневаюсь. В общем, тут много скользких моментов, а профита маловато, если вообще есть.
LLM - это костыль, костыль может быть инструментом, но остается костылем.
У ИИ ограничен контекст и у человека ограничен, ИИ не выдаст сразу "конфетку", но и новый в проекте человек тоже не выдаст и т.д. и т.п.
Тут интересно. Новый человек может загрузить себе в мозг основной контекст и держать его, это сложно, но можно. То же самое можно сделать и с нейросетью. Не с LLM, а отдельной локальной специализированной неросетью, под конкретный проект, тогда ей уже можно давать задачи как обычному разработчику, без развернутой документации. Утверждать ничего не буду, еще не пробовал, все руки не доходят.
Для написания кода LLM не использую, так как не ощущаю никакого профита, для решения отдельных задач некоторые алгоритмы машинного обучения справляются неплохо, те же нейросети, но больше нравятся эволюционные вычисления. Как такового ИИ пока не существует в принципе. Его можно создать на основе экспертных систем, что позволит получать достоверные знания, а не гадать как LLM. Вообще, я за искуственный разум, а не интелект.
Это и есть распиливание слона на запчасти - в итоге: куча документации и размывание общей картины в лучшем случае, в худшем - комок грязи (мы переварили слона, мы молодцы). Также стоит заметить, что этого слона нужно грамотно разделать, иначе будет очень неприятно его есть из-за горькой желчи, либо привкуса фикалий, а для этого нужно знать, что такое слон из чего он состоит
От наивности автора аж скулы сводит. Ваше светлое ИИшное уже разбивается о пятую точку реальности, а заработают на этой "золотой лихорадке" только продавцы лопат.
Резать и пилить у нас в стране все умеют, а что в итоге то? А в итоге вы получите ласкутное одеяло, вместо собранного из частей слона, которое разваливается на ходу. Плавали, знаем.
а иногда лучше написать "доку", разбить ее на части, оперируя бизнес логикой, а дальше...ничем не отличается от ревью МРа джуна.
Сомнительно, но окей. Тут две проблемы для большого проекта: либо описывай кучу функционала в больших задачах, либо кучу задач с маленьких функционалом. И там и там куча функционала, а значит и документации. И опять же, как это все потом будет вместе работать - не понятно. Весь проект у вас в мозги ИИ не влезет, отсюда еще одна проблема, кто вам эту портянку из документации валидировать будет, все ли там согласовано или нет. А с учетом галюнов, то на сколько эта валидация будет корректна. То, что автор указал в качестве архитектуры проекта - типичный хэлоуворд и только для такой архитектуры применим описанный в статье принцип разработки ПО, о чем и был первый мой комментарий.
А я работаю с решениями в несколько десятков(бавало даже сотен) проектов на разных языках(в основном С/C++, C#) и фреймворках, несколько таких решений написал и спроектировал сам, и есть у меня такое ощущение, что я буду дольше такую доку писать, чем сам проект, это без учета проверки и отладки того, что нагенерировалось, еще есть ощущение, что то, что нагенериться для онбординга будет полным мусором. Если вы думаете, что написать код ручками сложно - нет, не сложно, сложно его поддерживать, оптимизировать, расширять и делать понятным. У вас просто таких потребностей нет, так как пишете отдельные, небольшие, одноразовые проекты.
Да вроде не сложно, критерий простой. Если просто закинул в проект, не глядя, не вникая в суть, и заработало - вот он, вайбкодер. Если осмыслил, переработал, сделал задел на будующее, в общем, интегрировал в свой проект - не вайбкодер. Тут смысл простой - если не хочешь вникать в код, будешь вайбкодером и твой проект будет похож на ласкутное одеяло, а в последствии на вермишели. Видал не мало таких франкинштейнов. Если вникаешь, то пытаешься по максимуму сделать разумно и понятно. Работоспособность, отказоустойчивость, расширяемость и т.д. оставим в сторонке, как и сложность проекта.
Мысли у вас скачуть, сложно вас понять. Определение есть: вайбкодинг - процесс написания кода пр вайбу, а не в рамках инженерного подхода. LLM - новый инструмент для вайбкодинга
Не согласен. Вайбкодинг существовал и до LLM, по сути это методология написания работающего говнокода, не важно как, главное чтобы работало сейчас, какие там вермишели на выходе - никого не волнует. Просто это не инженерный подход. Для маленьких сайтиков и приложух сойдет и то на время. Ассемблер, IDE и т.д. - это набор инструментов для инженера. LLM - это мультитул-дерьмогенератор для вайбкодера.
Как раз наоборот, я придерживаюсь такого подхода, при котором, даже пришедший джун мог быстро разобраться в том, что написано, а не взрывать свои и мой мозг в надежде разобраться во взаимосвязи кучи модулей, которые настроили до него, по принципу тетриса на самой высокой скорости.
Да что Вы говорите, если у Вас не получается, это не значит, что у других нет. Чего я не понимаю, объясните, а не делайте голословных заявлений
Я рад за Ваши успехи, но контекст проектов, с которыми я работал и работаю, это сотни( тысячи) листов А4, которые изменяются и дописываются в отличие от правил покера, т.к. появляются новые хотелки, обновляются инструменты, изменяется законодательство, политическая и экономическая ситуация в мире и т.д. И еще один интересный вопрос : каким кухонным комбайном лучше обработать печень рыбы фугу и кто, если что, понесет ответственность? А также насколько критична скорость обработки?
Такая бюрократия не всегда хорошо, так как много времени отнимает, то есть нужно нанимать промп-инженеров, которые по цене как разработчики, но только промт-инженеры. Опытному разработчику задача понятна по 2-3 предложениям из таска, на крайний случай 1 созвон на 5-10 мин. Будет ли такая задача понятна промт-инженеру для генерации нужного промта, сомневаюсь. В общем, тут много скользких моментов, а профита маловато, если вообще есть.
LLM - это костыль, костыль может быть инструментом, но остается костылем.
Тут интересно. Новый человек может загрузить себе в мозг основной контекст и держать его, это сложно, но можно. То же самое можно сделать и с нейросетью. Не с LLM, а отдельной локальной специализированной неросетью, под конкретный проект, тогда ей уже можно давать задачи как обычному разработчику, без развернутой документации. Утверждать ничего не буду, еще не пробовал, все руки не доходят.
Для написания кода LLM не использую, так как не ощущаю никакого профита, для решения отдельных задач некоторые алгоритмы машинного обучения справляются неплохо, те же нейросети, но больше нравятся эволюционные вычисления. Как такового ИИ пока не существует в принципе. Его можно создать на основе экспертных систем, что позволит получать достоверные знания, а не гадать как LLM. Вообще, я за искуственный разум, а не интелект.
Это и есть распиливание слона на запчасти - в итоге: куча документации и размывание общей картины в лучшем случае, в худшем - комок грязи (мы переварили слона, мы молодцы). Также стоит заметить, что этого слона нужно грамотно разделать, иначе будет очень неприятно его есть из-за горькой желчи, либо привкуса фикалий, а для этого нужно знать, что такое слон из чего он состоит
От наивности автора аж скулы сводит. Ваше светлое ИИшное уже разбивается о пятую точку реальности, а заработают на этой "золотой лихорадке" только продавцы лопат.
Резать и пилить у нас в стране все умеют, а что в итоге то? А в итоге вы получите ласкутное одеяло, вместо собранного из частей слона, которое разваливается на ходу. Плавали, знаем.
Сомнительно, но окей. Тут две проблемы для большого проекта: либо описывай кучу функционала в больших задачах, либо кучу задач с маленьких функционалом. И там и там куча функционала, а значит и документации. И опять же, как это все потом будет вместе работать - не понятно. Весь проект у вас в мозги ИИ не влезет, отсюда еще одна проблема, кто вам эту портянку из документации валидировать будет, все ли там согласовано или нет. А с учетом галюнов, то на сколько эта валидация будет корректна. То, что автор указал в качестве архитектуры проекта - типичный хэлоуворд и только для такой архитектуры применим описанный в статье принцип разработки ПО, о чем и был первый мой комментарий.
А я работаю с решениями в несколько десятков(бавало даже сотен) проектов на разных языках(в основном С/C++, C#) и фреймворках, несколько таких решений написал и спроектировал сам, и есть у меня такое ощущение, что я буду дольше такую доку писать, чем сам проект, это без учета проверки и отладки того, что нагенерировалось, еще есть ощущение, что то, что нагенериться для онбординга будет полным мусором. Если вы думаете, что написать код ручками сложно - нет, не сложно, сложно его поддерживать, оптимизировать, расширять и делать понятным. У вас просто таких потребностей нет, так как пишете отдельные, небольшие, одноразовые проекты.
Для хеллоувордов сойдет, не более
Ох уж эти сказки, ох уж эти сказочники
Хотим и бухтим, что не так-то? Или уже рты нам во славу вашего ии затыкать будете?
В такое время живем, все меньше натуралов
Вот тут, согласен
Да вроде не сложно, критерий простой. Если просто закинул в проект, не глядя, не вникая в суть, и заработало - вот он, вайбкодер. Если осмыслил, переработал, сделал задел на будующее, в общем, интегрировал в свой проект - не вайбкодер. Тут смысл простой - если не хочешь вникать в код, будешь вайбкодером и твой проект будет похож на ласкутное одеяло, а в последствии на вермишели. Видал не мало таких франкинштейнов. Если вникаешь, то пытаешься по максимуму сделать разумно и понятно. Работоспособность, отказоустойчивость, расширяемость и т.д. оставим в сторонке, как и сложность проекта.
Мысли у вас скачуть, сложно вас понять. Определение есть: вайбкодинг - процесс написания кода пр вайбу, а не в рамках инженерного подхода. LLM - новый инструмент для вайбкодинга
Не согласен. Вайбкодинг существовал и до LLM, по сути это методология написания работающего говнокода, не важно как, главное чтобы работало сейчас, какие там вермишели на выходе - никого не волнует. Просто это не инженерный подход. Для маленьких сайтиков и приложух сойдет и то на время. Ассемблер, IDE и т.д. - это набор инструментов для инженера. LLM - это мультитул-дерьмогенератор для вайбкодера.
Это ваше искаженное восприятие говорит?
Скоро вайбкодинг превратиться в воуккодинг, а программистов-натуралов начнут притеснять
Не туда закомеентил, сорри
Странная у вас логика, но это ваши проблемы.