Волки не пройдут

  Почти все новости сгенерированы нейронками.

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

Школьники делают дз используя их.

Раньше школьники вообще друг у друга списывали. Так что тут прогресс, я считаю. Теперь школьнику нужно как-то объяснить нейронке задание, а потом понять, где у неё ответ.

Мир всегда меняется, некоторые вписываются в новые условия лучше (молодёжь, она без опыта), некоторые хуже (у опытных больше инерция). Так всегда было, есть и будет. Это нормально. Новые возможности несут новые угрозы, так же как и новые угрозы несут новые возможности. Инь и янь, будь они неладны!

Декларация (не)зависимостей для ESM

Я, кстати, могу даже ваш код внутрь своего контейнера пустить. Если дадите адрес, где лежит js с именем типа Evil.js и кодом типа:

export const __deps__ = {
    logger: "Client1_Di_Logger$",
};

export default class App_Evil {

    constructor({ logger }) {
        debugger;
    }

}

Сможете изнутри приложения попытаться logger переопределить.

Декларация (не)зависимостей для ESM

Это вообще прекрасно! Тут уже без CSP не обойтись!

Пришлось переключиться на новую версию Контейнера (v2). Её как раз Codex сделал. В моей ручной версии был небезопасный код (new Function)

Сделал тестовый стенд, поставил в bootstrap задержку на 5 сек. Класс тот же - Client1_Di_Logger, метод тот же - print. Пробуйте.

http://app1.habr.dev.wiredgeese.com/index2.html

Декларация (не)зависимостей для ESM

Неплохо! Это всё ещё окружение, но тем не менее - это реальная возможность переопределить поведение порождаемых объектов.

В любом случае, спасибо за аргумент, коллега :) Меня тут на Хабре как-то уже ногами месили за то, что я использую замыкания в конструкторе вместо того, чтобы как "все нормальные люди" использовать классы и прототипы. Теперь, благодаря вам, я могу наглядно показать, почему я не делаю, как "все нормальные люди".

Переписал имплементацию логгера на замыкание:

export default class Client1_Di_Logger {

    constructor() {
        /** @type {Console|undefined} */
        let consoleRef;

        this.setConsoleLogger = (console) => {
            consoleRef = console;
        };

        this.print = (msg) => {
            consoleRef.log('Client1 logger: ' + msg);
        };
    }

}

Теперь ваш трюк с Client1_Di_Logger не работает. Остальное в примере тоже можно через замыкания переписать (я пример специально делал в виде, наименее шокирующем нормальных людей). Принцип тот же. Но я думаю, вы уже и сами это поняли.

Декларация (не)зависимостей для ESM

Да, я действительно по-другому, нежели вы, понимаю, как работает JS runtime. Но вы лично, и любой другой, можете повторить то, что я написал выше. Это скриншоты, а не нейрогенерёнка. Это повторяемо.

Размещать что-либо прикладное в globals после 2015-го года - это не олдскульно, а архаично.

console.log=null

Вы, так-то изменили не объект, который мой контейнер генерирует, а окружение, в котором мой контейнер работает. Надеюсь, вы понимаете разницу :) К моим прикладным объектам (и самому контейнеру) из консоли у вас доступа нет.

Декларация (не)зависимостей для ESM

У нас с вами, коллега, очень сильно разное чувство прекрасного. Моё, например, страдает от такой картины:

И это только с $hyoo_, а ещё с $mol_ не меньше

Разработчики языка специально в ES6 сделали возможность ограничивать область видимости объектов (let vs var). Понимали, что чем менее доступен объект, тем меньше поверхность атаки на него.

А разработчик $mol всё выложил в globals - скучное техническое решение с весёлыми последствиями. Каждый-всякий-любой может на странице https://mol.hyoo.ru/ сделать вот такое (в консоли или скриптом):

window.$mol_view=null

и получить такое после клика на любой ссылке:

Любой скрипт на странице может "убить" $mol

А ведь, при желании, можно не просто тупо грохать приложение, а обернуть любой $mol-объект собственным кодом прямо с консоли браузера. Можно это представить как непревзойдённую расширяемость, а можно - как дыру для утечки конфиденциальных данных.

А попробуйте-ка с консоли получить доступ к моему контейнеру и его объектам хотя бы вот в этой демке (к этой статье). Ну как? О!

ES6-модули рулят с 2015-го года:

<script type="module">

но ваша архитектура до сих пор тупо лезет в глобалс и подставляется через него :(

А что касается бойлерплейта, то в наш век автоматизации разработки ПО этот аргумент звучит жалко.

Декларация (не)зависимостей для ESM

А вы, коллега, правда считаете, что придумать декоратор - это круто?

Я, вот, например, считаю, что круто - это обойтись без декоратора. Так, чтобы работало на уровне базы ;)

Декларация (не)зависимостей для ESM

Коллега, вы как жили в мире розовых пони (@mem), так там и живёте. Не выходите оттуда. Я с вами уже говорил на эту тему.

Что день грядущий нам готовит: Агентные системы, платформы, AgentOS или ничего не поменяется?

Скоростью. Он очень быстрый. Очень. И исполнительностью - будет максимально придерживаться заданных инструкций, несмотря на весь свой "предыдущий опыт".

Что день грядущий нам готовит: Агентные системы, платформы, AgentOS или ничего не поменяется?

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

Это так не работает. Особенно с "декомпозирует". Агента нужно "загонять в рамки", а иначе он с результатом-то придёт, но результат будет не совсем тот, что ожидался. Творческий будет результат, а не инженерный.

Теория Информационной Гравитации: Вселенная как вечный цикл развития зрелости сознания

Ну, вот, например, конструктивная критика. Вводная в самом начале:

Эта статья предлагает ... фундаментальную философскую гипотезу о природе реальности, утверждающую, что первичной является динамика отношений и напряжений, а материя, энергия, поля и сознание — эмерджентные формы её проявления. .

Отношения и напряжения не существуют вне чего-либо. Отношения и напряжения существуют между кем-то или чем-то. Вы вывели "материю, энергию, поле и сознание" за рамки того, что "относится и напрягается" - у вас это всё "эмерджентные формы проявления динамики отношений и напряжений". Я бы сказал, что это уже "вторая производная" от "нечто существующего". Что-то должно существовать, (само)относиться и (само)напрягаться, а уже динамика отношений и напряжений порождает всё остальное.

Так что же лежит в фундаменте вашей философской гипотезы о природе реальности?

Как оптимизация промптов превратилась из шаманства в инженерную дисциплину

Я уверен, что где-то примерно так ПО уже сейчас и разрабатывают. Одни агенты пишут код, а другие его тестируют и пишут тикеты, которые первые разбирают и фиксят.

Это уже реальность. Где-то краем глаза видел про такой подход. Не запомнил, где именно. Я пока что считаю, что участие человека в контуре принятия решений (оценки результата) обязательным. Хотя бы при постановке задачи. Но лучше - при оценке результата (обучение, самое, что ни на есть) и ещё лучше - не в одно лицо, а массово ("судом присяжных"), а ещё лучше - если "все эти люди" заинтересованы в результатах правильной работы кода, который они оценивают.

Да, в такой "карусели" программисты действительно становятся не очень сильно нужными.

Как оптимизация промптов превратилась из шаманства в инженерную дисциплину

Однако практика показывает, что 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.

Как оптимизация промптов превратилась из шаманства в инженерную дисциплину

Запустить тесты? Я угадал?

Как оптимизация промптов превратилась из шаманства в инженерную дисциплину

К такому?

"готовый код"

Как оптимизация промптов превратилась из шаманства в инженерную дисциплину

О назначении этого кода, бро. О задачах, которые он должен выполнять.

Нам не нужен одинаковый код, нам нужен одинаковый результат работы этого кода.

Вам же всё равно, как называются переменные в коде? Особенно, если вам его ни дебажить не надо, ни даже читать. Более того, вам всё равно какие алгоритмы используются внутри, если результат работы кода вас устраивает. Вам нужна повторяемость не на уровне кода, а на уровне результата.

Если промпт даёт повторяемость на уровне результата - то вот и вот.

А если нам результат работы кода нужен вообще один раз? Параметризированный промпт, который создаёт одноразовые программы. Возможно даже на разных ЯП.