Да, я действительно по-другому, нежели вы, понимаю, как работает JS runtime. Но вы лично, и любой другой, можете повторить то, что я написал выше. Это скриншоты, а не нейрогенерёнка. Это повторяемо.
Размещать что-либо прикладное в globals после 2015-го года - это не олдскульно, а архаично.
console.log=null
Вы, так-то изменили не объект, который мой контейнер генерирует, а окружение, в котором мой контейнер работает. Надеюсь, вы понимаете разницу :) К моим прикладным объектам (и самому контейнеру) из консоли у вас доступа нет.
У нас с вами, коллега, очень сильно разное чувство прекрасного. Моё, например, страдает от такой картины:
И это только с $hyoo_, а ещё с $mol_ не меньше
Разработчики языка специально в ES6 сделали возможность ограничивать область видимости объектов (let vs var). Понимали, что чем менее доступен объект, тем меньше поверхность атаки на него.
А разработчик $mol всё выложил в globals - скучное техническое решение с весёлыми последствиями. Каждый-всякий-любой может на странице https://mol.hyoo.ru/ сделать вот такое (в консоли или скриптом):
window.$mol_view=null
и получить такое после клика на любой ссылке:
Любой скрипт на странице может "убить" $mol
А ведь, при желании, можно не просто тупо грохать приложение, а обернуть любой $mol-объект собственным кодом прямо с консоли браузера. Можно это представить как непревзойдённую расширяемость, а можно - как дыру для утечки конфиденциальных данных.
А попробуйте-ка с консоли получить доступ к моему контейнеру и его объектам хотя бы вот в этой демке (к этой статье). Ну как? О!
ES6-модули рулят с 2015-го года:
<script type="module">
но ваша архитектура до сих пор тупо лезет в глобалс и подставляется через него :(
А что касается бойлерплейта, то в наш век автоматизации разработки ПО этот аргумент звучит жалко.
Скоростью. Он очень быстрый. Очень. И исполнительностью - будет максимально придерживаться заданных инструкций, несмотря на весь свой "предыдущий опыт".
Агентский кодинг - это когда ты ставишь задачу, а агент сам декомпозирует её, пишет, тестирует, фиксит ошибки, и приходит к тебе с результатом.
Это так не работает. Особенно с "декомпозирует". Агента нужно "загонять в рамки", а иначе он с результатом-то придёт, но результат будет не совсем тот, что ожидался. Творческий будет результат, а не инженерный.
Ну, вот, например, конструктивная критика. Вводная в самом начале:
Эта статья предлагает ... фундаментальную философскую гипотезу о природе реальности, утверждающую, что первичной является динамика отношений и напряжений, а материя, энергия, поля и сознание — эмерджентные формы её проявления. .
Отношения и напряжения не существуют вне чего-либо. Отношения и напряжения существуют между кем-то или чем-то. Вы вывели "материю, энергию, поле и сознание" за рамки того, что "относится и напрягается" - у вас это всё "эмерджентные формы проявления динамики отношений и напряжений". Я бы сказал, что это уже "вторая производная" от "нечто существующего". Что-то должно существовать, (само)относиться и (само)напрягаться, а уже динамика отношений и напряжений порождает всё остальное.
Так что же лежит в фундаменте вашей философской гипотезы о природе реальности?
Я уверен, что где-то примерно так ПО уже сейчас и разрабатывают. Одни агенты пишут код, а другие его тестируют и пишут тикеты, которые первые разбирают и фиксят.
Это уже реальность. Где-то краем глаза видел про такой подход. Не запомнил, где именно. Я пока что считаю, что участие человека в контуре принятия решений (оценки результата) обязательным. Хотя бы при постановке задачи. Но лучше - при оценке результата (обучение, самое, что ни на есть) и ещё лучше - не в одно лицо, а массово ("судом присяжных"), а ещё лучше - если "все эти люди" заинтересованы в результатах правильной работы кода, который они оценивают.
Да, в такой "карусели" программисты действительно становятся не очень сильно нужными.
Однако практика показывает, что LLM как черный ящик не может даже просто повторить, что раньше уже корректно работало.
Возможно, у этого метода есть свои границы применимости и вы за них вышли?
LLM - это же вероятностная штука, если она даёт хотя бы 10% подходящих вариантов, то просто используйте подходящие варианты и не используйте неподходящие. У вас же есть критерии "корректно работало" - даёте на вход LLM битый код, критерии корректности и сообщение об ошибке. Потом отсекаете 90% неверных вариантов и используете первый попавшийся из "корректно работает". При соответствующем pipeline агент и сам делает то же самое.
А смысл повторяемость в том, чтобы один и тот же рабочий промпт
А это вам зачем? Вам же рабочий код нужен? Вернее даже - результат работы этого кода. Вам нужны дырки, а не свёрла.
100%-ю уверенность в том, что "дырки" получаются, как надо, даёт только практика (прод) - и ничего более. Тесты позволяют получить эту уверенность дешевле и безболезненнее (хотя уже и не на 100%). А вера в то, что ваш код работает так, как и планировалось... ну, у меня она, по-моему, в первый же год профдеятельности пропала. Но я не с железом дело имел, а с живыми пользователями. Они очень непредсказуемые. LLM на них чем-то похожи :)
function add(a, b) {
return a + b;
}
const add = function(a, b) {
return a + b;
};
const add = (a, b) => a + b;
Это разный JS-код или повторяющийся?
Мы фиксируем название, вход и выход (интерфейс) для некоторой функции и делаем набор тестов, которые описывают требуемое поведение (тестирование "чёрного ящика") - насколько велик может быть этот "чёрный ящик"?
Если совместить опыт Magento, GitHub/JIRA-тикеты и кодогенерацию, то, в пределе, LLM-агенты могут в автомате (!) обновлять кодовую базу на проде по тикетам конечных пользователей.
Меня тут сейчас начнут пинать ногами за такие слова. Но это просто от недостатка воображения. Это действительно можно. Уже сейчас. Без всякого AGI :)
TDD - сначала тесты, потом код. Код подгоняется под тесты, а не тесты под код.
Более того, тесты не всегда код (ручное тестирование). Более того, есть smoke tests, которые не зависят от сложности "под капотом" - их не нужно переписывать часто. Ну и наконец, есть пользователи, которые "тестируют на проде". Вы, может, будете смеяться, но я из экосистемы Magento - там это вполне себе нормальное явление. Протоптанные пользователями маршруты работают как часы, но шаг в сторону - и бага на баге.
А если вы сами пишите код, то вы его сразу пишите правильно и без ошибок? Или тоже пишете сценарии его проверки? Своего собственного кода?
Ну так вот, в случае кодогенерации через промпты вам нужно сделать только половину работы - написать тесты. Причём не на все сценарии, а лишь на важные конкретно для этого результата. Впрочем, 100% code coverage уже давно не в моде, насколько мне известно. IMHO, profit.
О назначении этого кода, бро. О задачах, которые он должен выполнять.
Нам не нужен одинаковый код, нам нужен одинаковый результат работы этого кода.
Вам же всё равно, как называются переменные в коде? Особенно, если вам его ни дебажить не надо, ни даже читать. Более того, вам всё равно какие алгоритмы используются внутри, если результат работы кода вас устраивает. Вам нужна повторяемость не на уровне кода, а на уровне результата.
Если промпт даёт повторяемость на уровне результата - то вот и вот.
А если нам результат работы кода нужен вообще один раз? Параметризированный промпт, который создаёт одноразовые программы. Возможно даже на разных ЯП.
Повторяемость чего? На каком уровне? С какими допусками?
Я уверен, что и сказки, и былины изустно передавали без повторяемости и с повторяемостью одновременно. Форма подачи менялась быстрее, передаваемый смысл - медленнее.
Повторяемость - не самоцель. Вы свою публикацию "Главная проблема использования ИИ (Иллюзии Интеллекта) при разработке ПО" могли написать другими словами. Более того, вы её точно напИшите другими словами, если попробуете изложить те же мысли ещё раз.
Если говорить за повторяемость результата, то для передачи одних и тех же идей разным людям вообще, иногда, нужно использовать разные формы (слова) - например, объяснить "как пройти в библиотеку" русскому, англичанину и французу.
Люди вскоре поделятся (уже делятся) на 2 категории - кто может читать "нейрослоп" и кто не может. Нейронка уже работает как валидатор и корректор стиля и семантики (типа, валидации грамматики и пунктуации в офисных пакетах). Но она же добавляет свой собственный стиль и свои собственные термины. Люди, по сути, через нейронки согласуют свой образ мышления. Причём на разных языках. Это круто. Но не все смогут.
Да, что-то типа. Карманный ИИ может и здоровый образ жизни пропагандировать, и внушить уверенность в безопасности "переноса в кремний". Особенно на бесплатных тарифах.
Все остальное не имеет смысла по той же причине, по которой не разводят хищников на мясо.
А как же экономия ресурсов планеты? Когда хищников становится слишком много их отстреливают не для того, чтобы использовать их самих, а чтобы использовать то, что не используют отстрелянные хищники.
Я вообще считаю мотив "экономии ресурсов" основным в этом (почти) фантастическом сценарии. Когда я ходил в школу, нас учили, что на планете есть 4 млрд. человек.
Трансплантология. А если предположить, что ИИ будет у каждого "в кармане" и будет ежедневно давать "персональные" советы (а это возможно уже на текущем техническом уровне), то "убеждать к переселению" можно хоть "под заказ" - с такими-то генами к такой-то дате. Достаточно просто ещё слегка усилить разделение по качеству образования - "элитарное" и "доступное".
Сейчас 5 из 21 верят в возможность переноса (см. опрос в конце поста). Но ведь может стать и наоброт - только 5 из 21 не будут верить в возможность переноса. Например, вот такие.
Джорд Сорос. 95 лет. Бодр и весел.
Представляете, какой выбор возможных вариантов открывается у людей?
Сегодня кто что "знает" или во что "верит" определяется твоим уровнем образования, а буквально уже завтра - тарифным планом твоего ChatGPT.
Также "безмозглые тушки" могут пригодиться для тестирования новых медицинских препаратов. И даже не важно, что на самом деле делается с мозгом (превращается ли он в желе при переносе или остаётся нетронутым), главное - общественный договор, позволяющий одним распоряжаться телами других на совершенно законной основе. Это когда-то людей в рабстве удерживали силой, что было довольно затратно, теперь это дело можно сделать совершенно добровольным.
Ну и, конечно же, эффект, вынесенный в заголовок публикации - это тоже немаловажно. Как решить проблему "всего на всех не хватает", если всех много, а всего мало? А вот так, например. И если "тушка" не нужна ни на органы, ни на опыты, тогда, да - на удобрения. Основной профит - сэкономленные ресурсы планеты.
Да, я действительно по-другому, нежели вы, понимаю, как работает JS runtime. Но вы лично, и любой другой, можете повторить то, что я написал выше. Это скриншоты, а не нейрогенерёнка. Это повторяемо.
Размещать что-либо прикладное в globals после 2015-го года - это не олдскульно, а архаично.
Вы, так-то изменили не объект, который мой контейнер генерирует, а окружение, в котором мой контейнер работает. Надеюсь, вы понимаете разницу :) К моим прикладным объектам (и самому контейнеру) из консоли у вас доступа нет.
У нас с вами, коллега, очень сильно разное чувство прекрасного. Моё, например, страдает от такой картины:
$hyoo_, а ещё с$mol_не меньшеРазработчики языка специально в ES6 сделали возможность ограничивать область видимости объектов (let vs var). Понимали, что чем менее доступен объект, тем меньше поверхность атаки на него.
А разработчик
$molвсё выложил вglobals- скучное техническое решение с весёлыми последствиями. Каждый-всякий-любой может на странице https://mol.hyoo.ru/ сделать вот такое (в консоли или скриптом):и получить такое после клика на любой ссылке:
А ведь, при желании, можно не просто тупо грохать приложение, а обернуть любой $mol-объект собственным кодом прямо с консоли браузера. Можно это представить как непревзойдённую расширяемость, а можно - как дыру для утечки конфиденциальных данных.
А попробуйте-ка с консоли получить доступ к моему контейнеру и его объектам хотя бы вот в этой демке (к этой статье). Ну как? О!
ES6-модули рулят с 2015-го года:
но ваша архитектура до сих пор тупо лезет в глобалс и подставляется через него :(
А что касается бойлерплейта, то в наш век автоматизации разработки ПО этот аргумент звучит жалко.
А вы, коллега, правда считаете, что придумать декоратор - это круто?
Я, вот, например, считаю, что круто - это обойтись без декоратора. Так, чтобы работало на уровне базы ;)
Коллега, вы как жили в мире розовых пони (
@mem), так там и живёте. Не выходите оттуда. Я с вами уже говорил на эту тему.Скоростью. Он очень быстрый. Очень. И исполнительностью - будет максимально придерживаться заданных инструкций, несмотря на весь свой "предыдущий опыт".
Это так не работает. Особенно с "декомпозирует". Агента нужно "загонять в рамки", а иначе он с результатом-то придёт, но результат будет не совсем тот, что ожидался. Творческий будет результат, а не инженерный.
Ну, вот, например, конструктивная критика. Вводная в самом начале:
Отношения и напряжения не существуют вне чего-либо. Отношения и напряжения существуют между кем-то или чем-то. Вы вывели "материю, энергию, поле и сознание" за рамки того, что "относится и напрягается" - у вас это всё "эмерджентные формы проявления динамики отношений и напряжений". Я бы сказал, что это уже "вторая производная" от "нечто существующего". Что-то должно существовать, (само)относиться и (само)напрягаться, а уже динамика отношений и напряжений порождает всё остальное.
Так что же лежит в фундаменте вашей философской гипотезы о природе реальности?
Я уверен, что где-то примерно так ПО уже сейчас и разрабатывают. Одни агенты пишут код, а другие его тестируют и пишут тикеты, которые первые разбирают и фиксят.
Это уже реальность. Где-то краем глаза видел про такой подход. Не запомнил, где именно. Я пока что считаю, что участие человека в контуре принятия решений (оценки результата) обязательным. Хотя бы при постановке задачи. Но лучше - при оценке результата (обучение, самое, что ни на есть) и ещё лучше - не в одно лицо, а массово ("судом присяжных"), а ещё лучше - если "все эти люди" заинтересованы в результатах правильной работы кода, который они оценивают.
Да, в такой "карусели" программисты действительно становятся не очень сильно нужными.
Возможно, у этого метода есть свои границы применимости и вы за них вышли?
LLM - это же вероятностная штука, если она даёт хотя бы 10% подходящих вариантов, то просто используйте подходящие варианты и не используйте неподходящие. У вас же есть критерии "корректно работало" - даёте на вход LLM битый код, критерии корректности и сообщение об ошибке. Потом отсекаете 90% неверных вариантов и используете первый попавшийся из "корректно работает". При соответствующем pipeline агент и сам делает то же самое.
А это вам зачем? Вам же рабочий код нужен? Вернее даже - результат работы этого кода. Вам нужны дырки, а не свёрла.
100%-ю уверенность в том, что "дырки" получаются, как надо, даёт только практика (прод) - и ничего более. Тесты позволяют получить эту уверенность дешевле и безболезненнее (хотя уже и не на 100%). А вера в то, что ваш код работает так, как и планировалось... ну, у меня она, по-моему, в первый же год профдеятельности пропала. Но я не с железом дело имел, а с живыми пользователями. Они очень непредсказуемые. LLM на них чем-то похожи :)
ОК, давайте попробуем настроится на одну волну:
Это разный JS-код или повторяющийся?
Мы фиксируем название, вход и выход (интерфейс) для некоторой функции и делаем набор тестов, которые описывают требуемое поведение (тестирование "чёрного ящика") - насколько велик может быть этот "чёрный ящик"?
Что для вас есть "повторяемость кода"?
Если совместить опыт Magento, GitHub/JIRA-тикеты и кодогенерацию, то, в пределе, LLM-агенты могут в автомате (!) обновлять кодовую базу на проде по тикетам конечных пользователей.
Меня тут сейчас начнут пинать ногами за такие слова. Но это просто от недостатка воображения. Это действительно можно. Уже сейчас. Без всякого AGI :)
TDD - сначала тесты, потом код. Код подгоняется под тесты, а не тесты под код.
Более того, тесты не всегда код (ручное тестирование). Более того, есть smoke tests, которые не зависят от сложности "под капотом" - их не нужно переписывать часто. Ну и наконец, есть пользователи, которые "тестируют на проде". Вы, может, будете смеяться, но я из экосистемы Magento - там это вполне себе нормальное явление. Протоптанные пользователями маршруты работают как часы, но шаг в сторону - и бага на баге.
А если вы сами пишите код, то вы его сразу пишите правильно и без ошибок? Или тоже пишете сценарии его проверки? Своего собственного кода?
Ну так вот, в случае кодогенерации через промпты вам нужно сделать только половину работы - написать тесты. Причём не на все сценарии, а лишь на важные конкретно для этого результата. Впрочем, 100% code coverage уже давно не в моде, насколько мне известно. IMHO, profit.
Запустить тесты? Я угадал?
К такому?
О назначении этого кода, бро. О задачах, которые он должен выполнять.
Нам не нужен одинаковый код, нам нужен одинаковый результат работы этого кода.
Вам же всё равно, как называются переменные в коде? Особенно, если вам его ни дебажить не надо, ни даже читать. Более того, вам всё равно какие алгоритмы используются внутри, если результат работы кода вас устраивает. Вам нужна повторяемость не на уровне кода, а на уровне результата.
Если промпт даёт повторяемость на уровне результата - то вот и вот.
А если нам результат работы кода нужен вообще один раз? Параметризированный промпт, который создаёт одноразовые программы. Возможно даже на разных ЯП.
Повторяемость чего? На каком уровне? С какими допусками?
Я уверен, что и сказки, и былины изустно передавали без повторяемости и с повторяемостью одновременно. Форма подачи менялась быстрее, передаваемый смысл - медленнее.
Повторяемость - не самоцель. Вы свою публикацию "Главная проблема использования ИИ (Иллюзии Интеллекта) при разработке ПО" могли написать другими словами. Более того, вы её точно напИшите другими словами, если попробуете изложить те же мысли ещё раз.
Если говорить за повторяемость результата, то для передачи одних и тех же идей разным людям вообще, иногда, нужно использовать разные формы (слова) - например, объяснить "как пройти в библиотеку" русскому, англичанину и французу.
Абсолютная повторяемость переоценена.
Люди вскоре поделятся (уже делятся) на 2 категории - кто может читать "нейрослоп" и кто не может. Нейронка уже работает как валидатор и корректор стиля и семантики (типа, валидации грамматики и пунктуации в офисных пакетах). Но она же добавляет свой собственный стиль и свои собственные термины. Люди, по сути, через нейронки согласуют свой образ мышления. Причём на разных языках. Это круто. Но не все смогут.
Да, что-то типа. Карманный ИИ может и здоровый образ жизни пропагандировать, и внушить уверенность в безопасности "переноса в кремний". Особенно на бесплатных тарифах.
А как же экономия ресурсов планеты? Когда хищников становится слишком много их отстреливают не для того, чтобы использовать их самих, а чтобы использовать то, что не используют отстрелянные хищники.
Я вообще считаю мотив "экономии ресурсов" основным в этом (почти) фантастическом сценарии. Когда я ходил в школу, нас учили, что на планете есть 4 млрд. человек.
Трансплантология. А если предположить, что ИИ будет у каждого "в кармане" и будет ежедневно давать "персональные" советы (а это возможно уже на текущем техническом уровне), то "убеждать к переселению" можно хоть "под заказ" - с такими-то генами к такой-то дате. Достаточно просто ещё слегка усилить разделение по качеству образования - "элитарное" и "доступное".
Сейчас 5 из 21 верят в возможность переноса (см. опрос в конце поста). Но ведь может стать и наоброт - только 5 из 21 не будут верить в возможность переноса. Например, вот такие.
Представляете, какой выбор возможных вариантов открывается у людей?
Сегодня кто что "знает" или во что "верит" определяется твоим уровнем образования, а буквально уже завтра - тарифным планом твоего ChatGPT.
Также "безмозглые тушки" могут пригодиться для тестирования новых медицинских препаратов. И даже не важно, что на самом деле делается с мозгом (превращается ли он в желе при переносе или остаётся нетронутым), главное - общественный договор, позволяющий одним распоряжаться телами других на совершенно законной основе. Это когда-то людей в рабстве удерживали силой, что было довольно затратно, теперь это дело можно сделать совершенно добровольным.
Ну и, конечно же, эффект, вынесенный в заголовок публикации - это тоже немаловажно. Как решить проблему "всего на всех не хватает", если всех много, а всего мало? А вот так, например. И если "тушка" не нужна ни на органы, ни на опыты, тогда, да - на удобрения. Основной профит - сэкономленные ресурсы планеты.