Точнее до настроят. При обучении, если корректно применять этот термин, обучаемый логически рассуждает и понимает смысл того чему обучается. У модели LLM при "обучении" понятийные рассуждения отсутствуют (другая алгоритмика) и, следовательно, смысла из обучаемого материала она не извлекает. А раз не понимает смысла, то сама и не знает как сделать лучше. Надо снова до настраивать и так далее без конца.
Вся изложенная автором технология (и ей подобные) рассчитана исключительно на нежелающих и неумеющих думать, так и на думающих, с целью постепенного атрофирования у них способности самостоятельного мышления и принятия решений.
Вообще-то для профессионала (не путать с кодером! ) НЕТ такого понятия как "писать код". Есть понятие "разрабатывать программный код". Писать можно письмо, статью, комментарий или даже ниписать книгу. Давно (полвека уж точно) у профессионалов сложилась аналогия 1в1 проектирования и разработки ПО как сложного технического изделия. Все стадии разработки и жизненные циклы повторяются 1в1. Разработка кода программой единицы (процедуры, функции) соотносится с изготовлением рабочим конкретной детали по разработанному технологом технологическому процессу. Автогенератор выдаёт программный код. Он может быть верным, а может и содержать ошибки. Это может определить только его тщательное тестирование и время эксплуатации. Есть один нюанс, который отличает программный код от детали. Даже если он прошёл успешное тестирование, все равно требуется его верификация и документирование алгоритма его работы для будущей возможной модификации или нахождения вдруг возникшей ошибки. Разобраться в чужом программном коде из более чем 100 строк ЯП далеко не тривильная задача, тут прежде всего требуется большой практический опыт программирования и не КАЖДЫЙ эту работу сможет выполнить профессионально. А главное тоже требуется время. Если вы используете автогенераторы для своих личных целей никто вас не отговаривает делать это. Как говорится, бог в помощь. Если же разрабатывается серьёзное ПО с десятками и сотнями тысяч строк на ЯП, то тут "на арапа" с автогенератором проскочить будет не так просто. Допустим, что он вам все "сгенерит" в несколько раз быстрее, чем бы разрабатывалось вручную. Собрали, прогнали, вроде все работает, Ок. Через некоторое время (скажем через полгода) выплывают ошибки (без них не бывает даже у автогенераторов), как их будете искать и устранять если у вас на руках от вайб-кодера на память остались лишь задания-промпты для автогенератора? Это конечно при условии, что верификации и документировании не было. Найти ошибку в недокументированном программном коде и/или его модифицировать будет не так просто. Повторяю, что эту работу НЕ каждый сможет выполнить качественно. Без верификации и без доработки под свои стандарты ни одна ответственная ИТ компания сгенерированный программный код использовать не будет. Поэтому довод в пользу резкого сокращения общего времени разработки ПО при "написания кода" автогенератором сомнителен. Да, "сгенерится" все быстро, но сколько времени и какой квалификации потребуется чтобы во всем этом разобраться и довести до ума.
Вообще-то в статье и в комментах речь идёт об вайб-кодинге и автоматизации генерации программного кода с помощью современных ИИ-технологий. А на счёт того что "юристы, бухгалтерия, аналитики, инженеры.. и т.д." скоро "на выход", так эти фантазии лучше оставьте при себе.
Я предложил коллеге (на примере своего коммента) занять позицию конструктивного критика и просветителя. Это не луддизм, а профессиональная позиция по обсуждаемой в статье важной темы. Вы, уважаемый, возможно поняли, что я призываю в том числе и к НЕ обоснованной профессионально голосовой критике, т.е. заняться луддизмом. Это не так.
Во первых это профессионально обоснованная критика, а не голое и абсолютное отрицание всего. Давайте против нее свои контр аргументы потом и потолкуем. Если их нет, то луддизм будет с вашей стороны против обоснованной критики.
А это, уважаемый, и от Вашей текущей позиции тоже зависит: покорно будете на это созерцать и во всем смиряться или просвящать несведущих и активно противостоять
А Вы не пробовали на все это, помимо поднятого хайпа для скорейшей монетизации таких творений, посмотреть с позиции профессионала и разглядеть, что этот балаган затеян не иначе как преднамеренная (сознательно или нет это отдельная тема) попытка постепенного лишения вас способности самостоятельно мыслить и принимать решения, а по сути деквалифицирования и профессионального обнуления как специалиста? А таких "менеджеров" поменьше слушайте и сторонитесь.
Цель подобных переводных "статей" обозначить ложные ориентиры в проверенную и отлаженную практикой технологию разработки ПО. Верификация чужого программного кода, разработанного человеком или созданного автогенератором, по сложности (начиная от 1000 строк ЯП) сложнее, чем написание его самостоятельно. И не каждый разработчик сможет ее выполнить квалифицированно, тут важен прежде всего личный практический опыт в программировании. Помимо проверки кода требуется его документирование и доработка на надёжность. Например, на уровне отдельных процедур проверка на допустимость значений вх. параметров, обработки исключений с записью их в системный errors.log и многое чего другого, не говоря о выдерживании принятого в компании стандарта на программный код.
Значительно было бы лучше все наоборот: код разработанный человеком проверяет автомат-ИИ и выявляет в нем ошибки. Это действительно ускорило бы процесс разработки кода и повысило его надежность. Но фундаментальная проблема моделей ИИ построенных по технологии LLM заключается в том, что они НЕ понимают смысла создаваемого им контента. Применительно к обсуждаемой теме это смысл генерируемого программного кода. Ибо их "мышление" НЕ моделирует 1в1 процесс восприятия и логического мышления человека, а, упрощенно говоря, представляет алгоритмическую генерацию контента либо по уже известному примеру, либо путем конкатенации предыдущего контента со следующим, который выбирается согласно настройкам вероятностных корреляций между параметрами модели, сформированными по обучаемому материалу. Для того, чтобы модель-ИИ понимала смысл своего результата, необходимо чтобы она понимала смысл того чему её обучают.
Но это вовсе НЕ означает, что автогенераторы программного кода надо напроч игнорировать. Тут дело личного вкуса и условий в которых их можно применять с умом. Скорее всего эта технология для повышения качества результата будет специализироваться под конкретные задачи. Но профессиональные архитекторы и разработчики ПО никуда не денутся.
Разумное, а главное, своевременное решение. По большому счету, вся публичная информация, полученная и/или сформированная с применением ИИ-технологий должна помечаться её авторами как "в соавторстве с ИИ".
А эти лллмки понимают что сами пишут? Квалифицированно проверить (точнее верифицировать) логику чужого программного кода (более 1000 строк ЯП) намного сложнее чем его разработать самому.
Мышление - логическая функция мозга человека, генератор мысли (интуиции, идеи), своего рода CPU.
Язык - инструмент выражения мысли и логики, своего рода Output.
Мышление ПЕРВИЧНО, а язык помощник, да да помощник, ВТОРИЧЕН.
LLM модель обучается (точнее настраивается) на текстах, используя их семантику, оперируя словами и синтаксисом, но НЕ извлекает из текста смысла и логического содержания. Поэтому, когда работает, то для получения результата оперирует только запомненным текстом, его единицами и установленными между ними связями - алгоритмически выполняя необходимую конкатенацию элементов генерируемого текста НЕ понимая его смысл. Мышлением тут и близко не пахнет.
Точнее до настроят. При обучении, если корректно применять этот термин, обучаемый логически рассуждает и понимает смысл того чему обучается. У модели LLM при "обучении" понятийные рассуждения отсутствуют (другая алгоритмика) и, следовательно, смысла из обучаемого материала она не извлекает. А раз не понимает смысла, то сама и не знает как сделать лучше. Надо снова до настраивать и так далее без конца.
Если понимают их смысл.
Вся изложенная автором технология (и ей подобные) рассчитана исключительно на нежелающих и неумеющих думать, так и на думающих, с целью постепенного атрофирования у них способности самостоятельного мышления и принятия решений.
Вообще-то для профессионала (не путать с кодером! ) НЕТ такого понятия как "писать код". Есть понятие "разрабатывать программный код". Писать можно письмо, статью, комментарий или даже ниписать книгу. Давно (полвека уж точно) у профессионалов сложилась аналогия 1в1 проектирования и разработки ПО как сложного технического изделия. Все стадии разработки и жизненные циклы повторяются 1в1. Разработка кода программой единицы (процедуры, функции) соотносится с изготовлением рабочим конкретной детали по разработанному технологом технологическому процессу. Автогенератор выдаёт программный код. Он может быть верным, а может и содержать ошибки. Это может определить только его тщательное тестирование и время эксплуатации. Есть один нюанс, который отличает программный код от детали. Даже если он прошёл успешное тестирование, все равно требуется его верификация и документирование алгоритма его работы для будущей возможной модификации или нахождения вдруг возникшей ошибки. Разобраться в чужом программном коде из более чем 100 строк ЯП далеко не тривильная задача, тут прежде всего требуется большой практический опыт программирования и не КАЖДЫЙ эту работу сможет выполнить профессионально. А главное тоже требуется время. Если вы используете автогенераторы для своих личных целей никто вас не отговаривает делать это. Как говорится, бог в помощь. Если же разрабатывается серьёзное ПО с десятками и сотнями тысяч строк на ЯП, то тут "на арапа" с автогенератором проскочить будет не так просто. Допустим, что он вам все "сгенерит" в несколько раз быстрее, чем бы разрабатывалось вручную. Собрали, прогнали, вроде все работает, Ок. Через некоторое время (скажем через полгода) выплывают ошибки (без них не бывает даже у автогенераторов), как их будете искать и устранять если у вас на руках от вайб-кодера на память остались лишь задания-промпты для автогенератора? Это конечно при условии, что верификации и документировании не было. Найти ошибку в недокументированном программном коде и/или его модифицировать будет не так просто. Повторяю, что эту работу НЕ каждый сможет выполнить качественно. Без верификации и без доработки под свои стандарты ни одна ответственная ИТ компания сгенерированный программный код использовать не будет. Поэтому довод в пользу резкого сокращения общего времени разработки ПО при "написания кода" автогенератором сомнителен. Да, "сгенерится" все быстро, но сколько времени и какой квалификации потребуется чтобы во всем этом разобраться и довести до ума.
Вообще-то в статье и в комментах речь идёт об вайб-кодинге и автоматизации генерации программного кода с помощью современных ИИ-технологий. А на счёт того что "юристы, бухгалтерия, аналитики, инженеры.. и т.д." скоро "на выход", так эти фантазии лучше оставьте при себе.
Я предложил коллеге (на примере своего коммента) занять позицию конструктивного критика и просветителя. Это не луддизм, а профессиональная позиция по обсуждаемой в статье важной темы. Вы, уважаемый, возможно поняли, что я призываю в том числе и к НЕ обоснованной профессионально голосовой критике, т.е. заняться луддизмом. Это не так.
Подобные рассуждения в той или иной вариации приходилось слушать от ИИ-оракулов и 60, и 50, и 40 лет назад. Пластинка долгоиграющая оказалась.
Отрицательный результат на НЕ здраво мыслящих гарантирован абсолютно.
Во первых это профессионально обоснованная критика, а не голое и абсолютное отрицание всего. Давайте против нее свои контр аргументы потом и потолкуем. Если их нет, то луддизм будет с вашей стороны против обоснованной критики.
А это, уважаемый, и от Вашей текущей позиции тоже зависит: покорно будете на это созерцать и во всем смиряться или просвящать несведущих и активно противостоять
А Вы не пробовали на все это, помимо поднятого хайпа для скорейшей монетизации таких творений, посмотреть с позиции профессионала и разглядеть, что этот балаган затеян не иначе как преднамеренная (сознательно или нет это отдельная тема) попытка постепенного лишения вас способности самостоятельно мыслить и принимать решения, а по сути деквалифицирования и профессионального обнуления как специалиста? А таких "менеджеров" поменьше слушайте и сторонитесь.
Цель подобных переводных "статей" обозначить ложные ориентиры в проверенную и отлаженную практикой технологию разработки ПО. Верификация чужого программного кода, разработанного человеком или созданного автогенератором, по сложности (начиная от 1000 строк ЯП) сложнее, чем написание его самостоятельно. И не каждый разработчик сможет ее выполнить квалифицированно, тут важен прежде всего личный практический опыт в программировании. Помимо проверки кода требуется его документирование и доработка на надёжность. Например, на уровне отдельных процедур проверка на допустимость значений вх. параметров, обработки исключений с записью их в системный errors.log и многое чего другого, не говоря о выдерживании принятого в компании стандарта на программный код.
Значительно было бы лучше все наоборот: код разработанный человеком проверяет автомат-ИИ и выявляет в нем ошибки. Это действительно ускорило бы процесс разработки кода и повысило его надежность. Но фундаментальная проблема моделей ИИ построенных по технологии LLM заключается в том, что они НЕ понимают смысла создаваемого им контента. Применительно к обсуждаемой теме это смысл генерируемого программного кода. Ибо их "мышление" НЕ моделирует 1в1 процесс восприятия и логического мышления человека, а, упрощенно говоря, представляет алгоритмическую генерацию контента либо по уже известному примеру, либо путем конкатенации предыдущего контента со следующим, который выбирается согласно настройкам вероятностных корреляций между параметрами модели, сформированными по обучаемому материалу. Для того, чтобы модель-ИИ понимала смысл своего результата, необходимо чтобы она понимала смысл того чему её обучают.
Но это вовсе НЕ означает, что автогенераторы программного кода надо напроч игнорировать. Тут дело личного вкуса и условий в которых их можно применять с умом. Скорее всего эта технология для повышения качества результата будет специализироваться под конкретные задачи. Но профессиональные архитекторы и разработчики ПО никуда не денутся.
Фундаментальная причина в непонимании смысла своего результата.
Автор(ы) обязан(ы) делать примечание, что контент сформирован частично или полностью с помощью ИИ-технологии.
Разумное, а главное, своевременное решение. По большому счету, вся публичная информация, полученная и/или сформированная с применением ИИ-технологий должна помечаться её авторами как "в соавторстве с ИИ".
А эти лллмки понимают что сами пишут? Квалифицированно проверить (точнее верифицировать) логику чужого программного кода (более 1000 строк ЯП) намного сложнее чем его разработать самому.
Нет того факта, а есть только статья, автор которой специализируется на пиаре ИИ.
Вы мне все вопросы да советы даёте, а где контр аргументы ? Без них это забалтывание.
В "бутылку полезли", значит требуется ликбез.
Мышление - логическая функция мозга человека, генератор мысли (интуиции, идеи), своего рода CPU.
Язык - инструмент выражения мысли и логики, своего рода Output.
Мышление ПЕРВИЧНО, а язык помощник, да да помощник, ВТОРИЧЕН.
LLM модель обучается (точнее настраивается) на текстах, используя их семантику, оперируя словами и синтаксисом, но НЕ извлекает из текста смысла и логического содержания. Поэтому, когда работает, то для получения результата оперирует только запомненным текстом, его единицами и установленными между ними связями - алгоритмически выполняя необходимую конкатенацию элементов генерируемого текста НЕ понимая его смысл. Мышлением тут и близко не пахнет.
Я тоже, ответил выше почему.