Сжигать агентом миллиарды токенов по простому запросу “А ну-ка переведи мне этот 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 потоков (раз вам не хватает этого объёма на час работы). Он должен нагенерировать за это время огромную кучу кода. Пусть и говнокода, но работающего хоть как-то и хоть как-то соответствующего поставленной задаче.
Вы во многом правы. Я уверен, что нельзя, на данный момент, сделать всю эту производственную цепочку полностью, на 100%, автоматической. Весь вопрос в том, какие из участков этой цепочки и в каких случаях насколько можно автоматизировать. Для каждого программного продукта это будет своё собственное значение.
Мой опыт показывает, что в веб-приложениях процент автоматизации может быть достаточно высокий. Вплоть до автоматической обработки баг-репортов от конечных пользователей с автоматической выкаткой фиксов на прод (с учётом возможности промпт-инъекций и всего сопутствующего веселья). Этого пока нет, но я к этому стремлюсь. Получится или нет - посмотрим.
1) Нейронки умеют в позднее связывание, только не в JS и не в том виде, как это у меня сделано. Я в таком виде программировал долгое время на Java & PHP - там это норм (в том числе и для ИИ). Естественно, что я не хочу терять свои "инвестиции времени" и применяю привычный мне стиль кодирования и при смене ЯП :) У позднего связывания есть свои плюсы. Самый явный - прямое внедрение моков при юнит-тестировании (это уже явный плюс и для ИИ).
Я считаю, что код в том виде, что у меня получается, в конечном счёте удобен для ИИ. Ведь, в конце-концов, я отказался от своего стиля и принял предложенный ChatGPT формат. Ну а проектные соглашения всё равно нужны в разработке и агенты всё равно "жрут токены" при проверке соответствия результата генерации этим соглашениям.
2) Я осознанно сравнил поведение агента при генерации кода с дождевой водой - она стекает в океан с учётом рельефа (общими знаниями, что в модель заложили при обучении). Если вам всё равно, куда будет течь вода (как Карпаты, когда он впервые повайбкодил), то вы точно достигнете своей цели ("нас невозможно сбить с пути - нам всё равно, куда идти!"). Если ваши цели незначительно отличаются от обычно принятых (заложенных при обучении), то вам нужно лишь слегка скорректировать своими спецификациями поведение модели при генерации кода. Ну а если вы хотите, чтобы получился результат, который будет значительно отличаться от того, к чему модель привыкла (заложено при обучении) - вам придётся очень сильно "изменить рельеф" дополнительными спецификациями.
Я не хочу, чтобы "вода текла вниз к океану", я хочу, чтобы она "текла" туда, куда мне надо.
Всё верно. Но только чем это отличается от ситуации с "кожаными разработчиками"? Там тоже есть те же самые проблемы, которые решаются обычными, знакомыми всем методами - соглашения, архитектура, ревью, тесты.
В данном примере я специально попросил агента переписать весь код и все тесты. То есть, по факту, всё приложение. Но это крайне необычный случай. Обычно собирают требования, пишут спецификации, определяют критерии соответствия этим спецификациям, автоматизируют проверку соответствия, потом пишут код, удовлетворяющий критериям соответствия спецификациям этих требований. А затем повторяют все эти шаги итерационно - наращивают функционал, опираясь на существующую базу, по спирали. По ходу получая обратную связь от пользователей прода.
Вопрос в том, где и на каких позициях в этой производственной цепочке находятся люди, а где - агенты. По большому счёту - вопрос баланса тех и этих. А риски потери данных и требований существуют и в полностью "кожаных" производственных цепочках. Яркий пример - Schiaparelli, марсианский зонд, который разбился из-за ошибки ПО.
Хороший коммент. В суть. Но, наверное, я плохо её изложил, раз у вас возник такой вопрос. Вот скриншот из публикации, чтобы быть предметнее:
Я выложил (опубличил) в npm только код - результат генерации. Но я не выложил "инфраструктуру" - документы (спецификации) которые и позволяют генерировать этот код, разный по содержанию, но одинаковый по функционалу. "Инфраструктура" лежит в приватном репо.
На все ваши вопросы про сопровождаемость, изменяемость, масштабирование, по большому счёту, ответ один - документы контекста. Просто заменив часть спецификаций вы можете получить этот же функционал на другом ЯП (python, php, java, ...) или в другом фреймворке.
Документы контекста очень хорошо удерживают процесс эволюции приложения. Именно об этом и публикация. Моя мысль - главная ценность в ИИ-разработке не код, а спецификации. Проектная документация. У кого она есть, тот и код задёшево сгенерировать сможет. Впрочем, у человеков так же: код без документации - "тяжёлое наследие прошлого"
А вайбкодинг - это ваншот. Вот что сгенерировалось агентом в пределах его контекста, то и вот.
Далее, отношение к кодингу как к творческому процессу - наивное.
Пусть так. Я просто иногда вижу красоту в коде. А создание красоты - процесс творчества.
Итак, как вы думаете, при каких условиях эта задача не вызовет переписывание большого объёма кода?
А вот это не проблема. Код дешёвый, можно переписать хоть весь. В примере к этой публикации я всё снёс и переписал дважды. Вернее, это сделал Codex-агент - за 4% от недельной квоты 20-евровой подписки на ChatGPT Plus. В деньгах это обошлось примерно где-то в 20 центов. И это вместе с тестами.
Я когда вижу, что агенты генерят, у меня глаз дёргается. Ну а когда не вижу - норм. Что-то делают, как-то работает - уже ОК. Но я под Magento больше 5 лет интегратором различных расширений был. До сих пор удивляюсь, как тот зоопарк работал. Всё-таки у сложных программных систем в определённой конфигурации есть достаточный уровень самостоятельной живучести.
Я как раз только что выложил свою публикацию на похожую тему (Spec-Driven Dev). У меня в коде тоже используется мой "самописный фреймворк" без "накатанных рельсов". Проблему решал "самописным скиллом" (teq-esm-validator). Если у агентов есть спецификация по условиям применения фреймворка и скилл-валидатор, который загоняет агента в рамки - вполне себе приемлемо (для человека). Но расход токенов, думаю, должен быть побольше. Особенно на старте, пока шаблонного кода мало.
Перед светофором останавливаются два авто - Рено Логан и Ламборгини. Водитель Логана, крутя ручку, опускает стекло и спрашивает водителя Ламборгини:
- Ну как тачка вообще? Не ломается?
- Да вроде нормальная тачка, а почему спрашиваешь?
- Да смотрю, что-то не очень народ их покупает.
IMHO, ревьюить каждую строчку нейрокода человеками - безумие не меньшее.
Я это к тому, что смотреть сгенерённый код людям нужно. Но это не ревью - это анализ. Поиск типовых "ляпов", что делает агент, и исключение их как класса через документы контекста, промпты, скиллы, тесты и перекрёстные проверки другими агентами. Человек не вывезет эту гонку, на мой взгляд.
Лично я сравниваю навык ревьюинга нейрокода с навыком ревьюинга машкодов после компиляции исходников. Неплохо, конечно, разбираться в таком коде, но корректность его работы нужно обеспечивать на другом уровне (компилятор, тесты). У европейского финтеха может быть другое мнение на этот счёт.
IMHO, нет смысла человеку ревьюить нейрокод. На край, можно поручить это другой нейронке, но тоже такое - могут вступить в сговор. А вот делать приёмочные тесты (интеграционные) - смысл, наоборот, есть. Но это и с людьми так.
Человек может изучать сгенерённый код, чтобы понимать, как "думает" нейронка, но ревьюить "каждую строчку"... перебор, на мой взгляд.
Статья получила +10 на данный момент и 35 читателей добавили в закладки. Она кому-то оказалась полезной. Просто подумайте об этом.
А если у вас есть способ, чтобы читатели получали доступ только к полезным для них публикациям - поделитесь с редакцией Хабра. Ныть про то, что "этот мир под вас плохо подстроили" - инфантильно.
К каждой статье есть вот такой блок с контролами. Нажми на "шестерёнку", а потом скрой публикации автора. Прекрати ныть и сделай себя счастливым сам! Ты - сильный, ты - сможешь!!
Сжигать агентом миллиарды токенов по простому запросу “А ну-ка переведи мне этот 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 потоков (раз вам не хватает этого объёма на час работы). Он должен нагенерировать за это время огромную кучу кода. Пусть и говнокода, но работающего хоть как-то и хоть как-то соответствующего поставленной задаче.
Просто любопытно взглянуть на эту кучу.
Вы во многом правы. Я уверен, что нельзя, на данный момент, сделать всю эту производственную цепочку полностью, на 100%, автоматической. Весь вопрос в том, какие из участков этой цепочки и в каких случаях насколько можно автоматизировать. Для каждого программного продукта это будет своё собственное значение.
Мой опыт показывает, что в веб-приложениях процент автоматизации может быть достаточно высокий. Вплоть до автоматической обработки баг-репортов от конечных пользователей с автоматической выкаткой фиксов на прод (с учётом возможности промпт-инъекций и всего сопутствующего веселья). Этого пока нет, но я к этому стремлюсь. Получится или нет - посмотрим.
Спасибо за вопросы.
1) Нейронки умеют в позднее связывание, только не в JS и не в том виде, как это у меня сделано. Я в таком виде программировал долгое время на Java & PHP - там это норм (в том числе и для ИИ). Естественно, что я не хочу терять свои "инвестиции времени" и применяю привычный мне стиль кодирования и при смене ЯП :) У позднего связывания есть свои плюсы. Самый явный - прямое внедрение моков при юнит-тестировании (это уже явный плюс и для ИИ).
Я считаю, что код в том виде, что у меня получается, в конечном счёте удобен для ИИ. Ведь, в конце-концов, я отказался от своего стиля и принял предложенный ChatGPT формат. Ну а проектные соглашения всё равно нужны в разработке и агенты всё равно "жрут токены" при проверке соответствия результата генерации этим соглашениям.
2) Я осознанно сравнил поведение агента при генерации кода с дождевой водой - она стекает в океан с учётом рельефа (общими знаниями, что в модель заложили при обучении). Если вам всё равно, куда будет течь вода (как Карпаты, когда он впервые повайбкодил), то вы точно достигнете своей цели ("нас невозможно сбить с пути - нам всё равно, куда идти!"). Если ваши цели незначительно отличаются от обычно принятых (заложенных при обучении), то вам нужно лишь слегка скорректировать своими спецификациями поведение модели при генерации кода. Ну а если вы хотите, чтобы получился результат, который будет значительно отличаться от того, к чему модель привыкла (заложено при обучении) - вам придётся очень сильно "изменить рельеф" дополнительными спецификациями.
Я не хочу, чтобы "вода текла вниз к океану", я хочу, чтобы она "текла" туда, куда мне надо.
Всё верно. Но только чем это отличается от ситуации с "кожаными разработчиками"? Там тоже есть те же самые проблемы, которые решаются обычными, знакомыми всем методами - соглашения, архитектура, ревью, тесты.
В данном примере я специально попросил агента переписать весь код и все тесты. То есть, по факту, всё приложение. Но это крайне необычный случай. Обычно собирают требования, пишут спецификации, определяют критерии соответствия этим спецификациям, автоматизируют проверку соответствия, потом пишут код, удовлетворяющий критериям соответствия спецификациям этих требований. А затем повторяют все эти шаги итерационно - наращивают функционал, опираясь на существующую базу, по спирали. По ходу получая обратную связь от пользователей прода.
Вопрос в том, где и на каких позициях в этой производственной цепочке находятся люди, а где - агенты. По большому счёту - вопрос баланса тех и этих. А риски потери данных и требований существуют и в полностью "кожаных" производственных цепочках. Яркий пример - Schiaparelli, марсианский зонд, который разбился из-за ошибки ПО.
Где-то риски допускают большее присутствие "силиконовых", где-то меньшее.
Хороший коммент. В суть. Но, наверное, я плохо её изложил, раз у вас возник такой вопрос. Вот скриншот из публикации, чтобы быть предметнее:
Я выложил (опубличил) в npm только код - результат генерации. Но я не выложил "инфраструктуру" - документы (спецификации) которые и позволяют генерировать этот код, разный по содержанию, но одинаковый по функционалу. "Инфраструктура" лежит в приватном репо.
На все ваши вопросы про сопровождаемость, изменяемость, масштабирование, по большому счёту, ответ один - документы контекста. Просто заменив часть спецификаций вы можете получить этот же функционал на другом ЯП (python, php, java, ...) или в другом фреймворке.
Документы контекста очень хорошо удерживают процесс эволюции приложения. Именно об этом и публикация. Моя мысль - главная ценность в ИИ-разработке не код, а спецификации. Проектная документация. У кого она есть, тот и код задёшево сгенерировать сможет. Впрочем, у человеков так же: код без документации - "тяжёлое наследие прошлого"
А вайбкодинг - это ваншот. Вот что сгенерировалось агентом в пределах его контекста, то и вот.
Пусть так. Я просто иногда вижу красоту в коде. А создание красоты - процесс творчества.
А вот это не проблема. Код дешёвый, можно переписать хоть весь. В примере к этой публикации я всё снёс и переписал дважды. Вернее, это сделал Codex-агент - за 4% от недельной квоты 20-евровой подписки на ChatGPT Plus. В деньгах это обошлось примерно где-то в 20 центов. И это вместе с тестами.
Вы не могли бы показать код, который вы получаете за "час активной работы"?
Я когда вижу, что агенты генерят, у меня глаз дёргается. Ну а когда не вижу - норм. Что-то делают, как-то работает - уже ОК. Но я под Magento больше 5 лет интегратором различных расширений был. До сих пор удивляюсь, как тот зоопарк работал. Всё-таки у сложных программных систем в определённой конфигурации есть достаточный уровень самостоятельной живучести.
Я как раз только что выложил свою публикацию на похожую тему (Spec-Driven Dev). У меня в коде тоже используется мой "самописный фреймворк" без "накатанных рельсов". Проблему решал "самописным скиллом" (teq-esm-validator). Если у агентов есть спецификация по условиям применения фреймворка и скилл-валидатор, который загоняет агента в рамки - вполне себе приемлемо (для человека). Но расход токенов, думаю, должен быть побольше. Особенно на старте, пока шаблонного кода мало.
На эту тему даже анекдот есть :)
У меня подписка GPT Plus за 20 евро. Мне норм.
IMHO, ревьюить каждую строчку нейрокода человеками - безумие не меньшее.
Я это к тому, что смотреть сгенерённый код людям нужно. Но это не ревью - это анализ. Поиск типовых "ляпов", что делает агент, и исключение их как класса через документы контекста, промпты, скиллы, тесты и перекрёстные проверки другими агентами. Человек не вывезет эту гонку, на мой взгляд.
Лично я сравниваю навык ревьюинга нейрокода с навыком ревьюинга машкодов после компиляции исходников. Неплохо, конечно, разбираться в таком коде, но корректность его работы нужно обеспечивать на другом уровне (компилятор, тесты). У европейского финтеха может быть другое мнение на этот счёт.
Вот здесь: "Задолбали уже со своим вайб-говнокодом. Что, писать на хабре больше неочем?"
Мне показалось, что ваш коммент в какой-то мере поддерживает это инфантильное нытьё. Извините, если был не прав.
IMHO, нет смысла человеку ревьюить нейрокод. На край, можно поручить это другой нейронке, но тоже такое - могут вступить в сговор. А вот делать приёмочные тесты (интеграционные) - смысл, наоборот, есть. Но это и с людьми так.
Человек может изучать сгенерённый код, чтобы понимать, как "думает" нейронка, но ревьюить "каждую строчку"... перебор, на мой взгляд.
Статья получила +10 на данный момент и 35 читателей добавили в закладки. Она кому-то оказалась полезной. Просто подумайте об этом.
А если у вас есть способ, чтобы читатели получали доступ только к полезным для них публикациям - поделитесь с редакцией Хабра. Ныть про то, что "этот мир под вас плохо подстроили" - инфантильно.
Есть выход! Можно читать только главную ленту!! Главное - не поддаваться унынию.
К каждой статье есть вот такой блок с контролами. Нажми на "шестерёнку", а потом скрой публикации автора. Прекрати ныть и сделай себя счастливым сам! Ты - сильный, ты - сможешь!!