Я имею опыт взаимодействия именно с кодексом. С Copilot'ом как-то не сложилось. Плюс, я могу агента менять, на того же Клода, например. А вместо гитхаб взять гитлаб. Ну, могу думать в эту сторону. А решение от Майкрософта - это вендор-лок.
А где здесь критика? В том, что "ресурс можно превратить в тыкву"? Я согласен, что можно. Это не так просто сделать, но можно. Абсолютной защиты не бывает, но хороша та защита, затраты на преодоление которой не оправдываются "призом". Мне, например, не сложно откатить мой сайт на несколько коммитов назад, если что-то пойдёт не так.
А так-то я тоже не во все свои проекты всех подряд запускаю.
У вас же не вижу ответа в статье
А ответ простой: "серебряной пули не существует". Каждая задача требует своих решений. У вас - свои задачи, у меня - свои. Применять мои ответы к вашим задачам... ну как-то неправильно, что ли. Сами ищите.
Супермодели не существует. А если бы она существовала, она бы далеко не с каждым человеком диалог вела б. Поэтому наши рассуждения напомнили мне об одной байке про философа, раввина, двух трубочистов и Талмуд.
Вот, а потом Эллочка такая говорит Супермодели: "Фу, получилось точно так же, как у этой шмары с патриков! Это полный зашквар!! Не хочу такую же, сделай другую!" И всё, Супермодель пошла жечь токены мириадами, потому что Эллочка не может толком рассказать, чего же она хочет, но твёрдо знает, что хочет чего-то такого, чего ни у кого другого нет, а Супермодель тупая и не понимает.
Для супермоделей, не будет разницы кто ей пишет "хотелку", суслик-агроном или профессиональный промпт-"инженер" (он не инженер, если что).
Будет. Возьмите супермодель, себя и Эллочку-людоедку из "Двенадцати стульев". Придумайте любое персональное приложение, а потом сравните результаты работы по созданию этого приложения пары "супермодель - вы" с парой "супермодель - Эллочка".
Супермодель сделает вам любое приложение, но она должна понимать, что ей делать. Если мысли в вашей голове скачут и противоречат друг-другу, как, допустим, у суслика-агронома, то супермодель сожрёт токены и сделает ерунду.
Раньше люди копали ямы лопатами, а потом появился экскаватор. Но экскаватор не даёт возможности любому "суслику-агроному" копать ямы настолько же успешно, как это делает профессиональный экскаваторщик (промпт-инженер - это не профессиональный экскаваторщик, если что, да и вообще - профессиональных водителей супермоделей пока ещё нет, как и самих супермоделей).
Вы сейчас смешали типы методов внедрения зависимостей (через конструктор и через setter'ы) и типы построения дерева зависимостей (ручное или автоматическое).
Есть еще похожая беда с dependency injection фреймворками. По коду невозможна навигация, так как зависимости модулей/объектов прописаны в каком-то другом месте, а не при инициализации.
Не во всех. Вот, например, JS-код, который использует DI и вполне себе парсится VSCode через JSDocs.
Переход по Ctrl+Click на исходник соответствующего метода зависимости `pipelineEngine`.
Код писал Codex-агент под моим, не сильно чутким руководством. Поэтому он вот такой. Но я специально не правлю его руками. Работает - и славно.
Тем не менее, JSDoc + types.d.ts позволяют вполне себе сносно навигировать по коду и людям, и агентам (этим ещё и проще) даже с таким экзотическим подходом, как TeqFW DI. Можете открыть пакет flancer32/teq-web в VSCode и убедиться сами. Кстати, в правом верхнем углу видно, что валидация IDE работает. Красным выделены ошибки в коде с точки зрения VSCode.
Признаком LLM-текста для меня зачастую являются слова, которые редко употребляются в обычном русском языке, а их аналоги часто употребляются в английском: нарратив, рамка, поверхность (API), удерживает (назначение), оптика... Но частое общение с LLM делает эти обороты более привычными. Это как "дорожная карта" (roadmap) - резало слух поначалу, затем попривык. Раньше всегда говорили "план" в таких случаях: "Есть ли у вас дорожная карта, мистер Фикс?"
Как англоязычный стиль разговора проникает в другие языки, так и стиль "разговора" Моделей проникает в наше человеческое мышление. Я уверен, что для эффективного использования Моделей нужно применять в общении эффективные "штапмы". Те из "кожанных", кто не сможет подавить в себе неприятие "нового стиля", просто будут менее эффективны (суть - менее полезны в человеческо-компьютерном обществе). Это не про выживаемость, если что, а про благосостояние (вот и штампик "Не А, а Б"!).
Сжигать агентом миллиарды токенов по простому запросу “А ну-ка переведи мне этот legacy код на современные рельсы” немудрено. И это нормально, что за такую работу Компании будут драть деньги. Но им самим выгодно стимулировать тех, кто сможет выжимать максимум из “лёгких” моделей.
Так что, нам всем лучше уже прямо сейчас начать привыкать запускать своих агентов в мини-режиме и искать пути их оптимального использования на малых рабочих контекстах.
Я, например, неделю обсуждал с ChatGPT спецификации для моей библиотеки в md-формате. Отвечал на вопросы, задавал ограничения, добивался согласованности и компактности контекста. За те же "20 баксов", но не агентом, а в чате. Да, пришлось вручную формировать документацию в проекте, перенося md-код между чатом и репозиторием. Зато потом, по готовому контексту, агент мне в течение менее получаса создал работающий код в ./src2/. А это значит, что он может порядка 32 таких библиотек за месяц нагенерить. Правда сам я не успеваю согласовывать более 4 контекстов (по одному в неделю). Сейчас уже чуть быстрее стало, но всё равно торможу.
Так что я пока даже свои лимиты не выбрал ни разу. А у меня ещё у жены, сестры и сына по GPT Plus учётке с неиспользуемыми лимитами для Codex'а. Есть куда расти :)
Трансформировать легаси в современный код - это боль. Там можно токены сжигать в галлактических масштабах и с минимальным участием человека. Особенно на большой кодовой базе.
Но у меня генерация и развитие кода с чистого листа. Тут и участие человека поболе будет, и токены используются в более контролируемом режиме. Так что 16 часов работы Codex'а в месяц - этого мне вполне хватает на разработку 4-5 npm-пакетов.
Смотрите, я беру по минимуму. При генерации кода (с правками и публикацией) у меня уходило примерно по 4% от недельного лимита. Это точно больше 10 минут чистого времени работы Codex-агента в режиме плагина для VSCode. Я визуально фиксировал 9 минут с чем-то при генерации кода, а это только один из шагов, пусть и самый длинный, на что ушли эти 4%. За это время агент нагенерировал 1-1.5К строк кода (с комментариями и пропусками). Тесты и спеки я не учитываю.
100% / 4% = 25 раз по 10 минут. Это 250 минут. Чистого времени работы агента за одну неделю. За месяц (4 недели) получается 1000 минут это 16 с лишним часов.
Допустим, вы запускаете своего агента в 16 потоков (раз вам не хватает этого объёма на час работы). Он должен нагенерировать за это время огромную кучу кода. Пусть и говнокода, но работающего хоть как-то и хоть как-то соответствующего поставленной задаче.
Можно и посерьезнее, но, конечно, не через доступ всем, кому ни попадая.
Никогда. Теперь уже никогда. Привыкайте.
Я имею опыт взаимодействия именно с кодексом. С Copilot'ом как-то не сложилось. Плюс, я могу агента менять, на того же Клода, например. А вместо гитхаб взять гитлаб. Ну, могу думать в эту сторону. А решение от Майкрософта - это вендор-лок.
Это делается путём изменения промптов к агентам. В других репо у меня другой workflow.
Уже сделали :)
А где здесь критика? В том, что "ресурс можно превратить в тыкву"? Я согласен, что можно. Это не так просто сделать, но можно. Абсолютной защиты не бывает, но хороша та защита, затраты на преодоление которой не оправдываются "призом". Мне, например, не сложно откатить мой сайт на несколько коммитов назад, если что-то пойдёт не так.
А так-то я тоже не во все свои проекты всех подряд запускаю.
А ответ простой: "серебряной пули не существует". Каждая задача требует своих решений. У вас - свои задачи, у меня - свои. Применять мои ответы к вашим задачам... ну как-то неправильно, что ли. Сами ищите.
Попробуйте, не голословьте.
Не понял вопроса. Что вас смутило в "github-репо"?
Супермодели не существует. А если бы она существовала, она бы далеко не с каждым человеком диалог вела б. Поэтому наши рассуждения напомнили мне об одной байке про философа, раввина, двух трубочистов и Талмуд.
Вот, а потом Эллочка такая говорит Супермодели: "Фу, получилось точно так же, как у этой шмары с патриков! Это полный зашквар!! Не хочу такую же, сделай другую!" И всё, Супермодель пошла жечь токены мириадами, потому что Эллочка не может толком рассказать, чего же она хочет, но твёрдо знает, что хочет чего-то такого, чего ни у кого другого нет, а Супермодель тупая и не понимает.
Будет. Возьмите супермодель, себя и Эллочку-людоедку из "Двенадцати стульев". Придумайте любое персональное приложение, а потом сравните результаты работы по созданию этого приложения пары "супермодель - вы" с парой "супермодель - Эллочка".
Супермодель сделает вам любое приложение, но она должна понимать, что ей делать. Если мысли в вашей голове скачут и противоречат друг-другу, как, допустим, у суслика-агронома, то супермодель сожрёт токены и сделает ерунду.
Раньше люди копали ямы лопатами, а потом появился экскаватор. Но экскаватор не даёт возможности любому "суслику-агроному" копать ямы настолько же успешно, как это делает профессиональный экскаваторщик (промпт-инженер - это не профессиональный экскаваторщик, если что, да и вообще - профессиональных водителей супермоделей пока ещё нет, как и самих супермоделей).
Вы сейчас смешали типы методов внедрения зависимостей (через конструктор и через setter'ы) и типы построения дерева зависимостей (ручное или автоматическое).
Не во всех. Вот, например, JS-код, который использует DI и вполне себе парсится VSCode через JSDocs.
Код писал Codex-агент под моим, не сильно чутким руководством. Поэтому он вот такой. Но я специально не правлю его руками. Работает - и славно.
Тем не менее, JSDoc + types.d.ts позволяют вполне себе сносно навигировать по коду и людям, и агентам (этим ещё и проще) даже с таким экзотическим подходом, как TeqFW DI. Можете открыть пакет
flancer32/teq-webв VSCode и убедиться сами. Кстати, в правом верхнем углу видно, что валидация IDE работает. Красным выделены ошибки в коде с точки зрения VSCode."Про" - это моё, "кожаное" :) Когда-то, давным давно, я, скорее всего, написал бы "о". В школе - так точно. Но... вот такие паттерны у меня сложились.
Признаком LLM-текста для меня зачастую являются слова, которые редко употребляются в обычном русском языке, а их аналоги часто употребляются в английском: нарратив, рамка, поверхность (API), удерживает (назначение), оптика... Но частое общение с LLM делает эти обороты более привычными. Это как "дорожная карта" (roadmap) - резало слух поначалу, затем попривык. Раньше всегда говорили "план" в таких случаях: "Есть ли у вас дорожная карта, мистер Фикс?"
Как англоязычный стиль разговора проникает в другие языки, так и стиль "разговора" Моделей проникает в наше человеческое мышление. Я уверен, что для эффективного использования Моделей нужно применять в общении эффективные "штапмы". Те из "кожанных", кто не сможет подавить в себе неприятие "нового стиля", просто будут менее эффективны (суть - менее полезны в человеческо-компьютерном обществе). Это не про выживаемость, если что, а про благосостояние (вот и штампик "Не А, а Б"!).
Сжигать агентом миллиарды токенов по простому запросу “А ну-ка переведи мне этот legacy код на современные рельсы” немудрено. И это нормально, что за такую работу Компании будут драть деньги. Но им самим выгодно стимулировать тех, кто сможет выжимать максимум из “лёгких” моделей.
Так что, нам всем лучше уже прямо сейчас начать привыкать запускать своих агентов в мини-режиме и искать пути их оптимального использования на малых рабочих контекстах.
Это не 20 баксов - это 16 часов работы агента :)
Я, например, неделю обсуждал с ChatGPT спецификации для моей библиотеки в md-формате. Отвечал на вопросы, задавал ограничения, добивался согласованности и компактности контекста. За те же "20 баксов", но не агентом, а в чате. Да, пришлось вручную формировать документацию в проекте, перенося md-код между чатом и репозиторием. Зато потом, по готовому контексту, агент мне в течение менее получаса создал работающий код в ./src2/. А это значит, что он может порядка 32 таких библиотек за месяц нагенерить. Правда сам я не успеваю согласовывать более 4 контекстов (по одному в неделю). Сейчас уже чуть быстрее стало, но всё равно торможу.
Так что я пока даже свои лимиты не выбрал ни разу. А у меня ещё у жены, сестры и сына по GPT Plus учётке с неиспользуемыми лимитами для Codex'а. Есть куда расти :)
Трансформировать легаси в современный код - это боль. Там можно токены сжигать в галлактических масштабах и с минимальным участием человека. Особенно на большой кодовой базе.
Но у меня генерация и развитие кода с чистого листа. Тут и участие человека поболе будет, и токены используются в более контролируемом режиме. Так что 16 часов работы Codex'а в месяц - этого мне вполне хватает на разработку 4-5 npm-пакетов.
Смотрите, я беру по минимуму. При генерации кода (с правками и публикацией) у меня уходило примерно по 4% от недельного лимита. Это точно больше 10 минут чистого времени работы Codex-агента в режиме плагина для VSCode. Я визуально фиксировал 9 минут с чем-то при генерации кода, а это только один из шагов, пусть и самый длинный, на что ушли эти 4%. За это время агент нагенерировал 1-1.5К строк кода (с комментариями и пропусками). Тесты и спеки я не учитываю.
100% / 4% = 25 раз по 10 минут. Это 250 минут. Чистого времени работы агента за одну неделю. За месяц (4 недели) получается 1000 минут это 16 с лишним часов.
Допустим, вы запускаете своего агента в 16 потоков (раз вам не хватает этого объёма на час работы). Он должен нагенерировать за это время огромную кучу кода. Пусть и говнокода, но работающего хоть как-то и хоть как-то соответствующего поставленной задаче.
Просто любопытно взглянуть на эту кучу.