Да, это красиво звучит, но кейс "бабушка слушает умершего мужа со старого телефона в метро" выглядит очень нежизнеспособно. Но поживем, увидим. Может и правда взлетит.
Почти все решения вы реализуете два раза: сначала неправильно, а потом как надо. Неужели у вас в команде нет ни одного человека, который до реализации не видит, что решение нерабочее?
С точки зрения бизнеса, сама идея делать решение как сервис - провальная. Идея с клонированием голоса рабочая, но пользователю здесь не нужен риалтайм и не нужна платформа. Ему нужен менеджер (прямо человек), которому он отдает имеющиеся материалы. Потом вы спокойно работаете, делаете клона и отдаете человеку ссылку. Вот эта вся спешка, реакты, лоадеры, собственная модель - не нужны.
Я использую облачный Codex - нет проблем с доверием к агенту, не нужно держать запущенный Codex CLI. На выходе сразу готовый пулл реквест. Правда в последнем обновлении включили Codex Max, который работает намного хуже предыдущей версии. Поэтому для серьёзных задач пока кодексом почти не пользуюсь.
Альтернатива - Github Copilot агент. Работает прямо из гитхаба, без всяких воркспейсов. Результат выдает прекрасный. Сразу прогоняет тесты, запускает playwright если нужно тестировать интерфейс, пишет саммари, делает ревью...
Во-первых, понимание безопасности к всех разное. Во-вторых, если бы я знал точный рецепт, то пулл реквест уже лежал бы в репозитории раста.
В целом, выглядит так, что если на уровне модуля сделать какое-то скрытое хранилище данных (чтобы скоуп выглядел модульным, но работал как скоуп функции), то это уже решило бы проблему. Тогда мы могли бы на уровне модуля создать стейт, как это мы делаем внутри функции. И далее можно использовать стейт из других частей модуля на своё усмотрение.
Глобальный стейт конечно можно сделать в расте, но это сложнее делается, чем в JS например. Вместо того, чтобы тупо инициализировать стейт, нужно делать дополнительные методы, нужно определять, кто его будет хранить. Без всего этого можно было бы обойтись.
А я не говорил про константный стейт. Сможете просто создать и инициализировать стейт для модуля без использования функций? Так, чтобы это была одна структура типа State.
Например у JS или Питон кодеров - это стандартный подход, объявить на самом высоком уровне константы, стейт. Они видят, что это удобно и понятно, но по неясным причинам этот подход в Расте не работает. В константах даже строку нельзя собрать, типа const APP = APP_NAME + APP_VERSION. По факту разработчики сделали столько ограничений на константы, что весь сопутствующий функционал сделан на макросах, либо не сделан вообще и от привычных вещей приходится отказываться.
Аргументный аргумент. Метод keys() в растовском HashMap почему-то присутствует, хотя это в вашем понимании антипаттерн. И в документации приведен обходной путь как засунуть мапу в константы. Видимо очень популярный антипаттерн, да?
Речь не о том, что в Typescript нет константных выражений, а о том, что в расте их нельзя задать таким образом. Это удобный способ для хранения настроек например.
К сожалению top level паттерн матчинг ни один язык кроме эрланга не умеет. Я бы его очень хотел, но тащить ради этого эрланг - явный перебор.
Если еще указывать недостатки Rust, то явно стоит упомянуть ограничения константных выражений. Например, нельзя как в Typescript написать внутри модуля:
Codex и Copilot облачные агенты уже решают описанные автором проблемы. Они запускаются в docker контейнере, поэтому точно ничего не сломают. Вместо сотен тысяч токенов они тратят фиксированное количество кредитов. У копилота - один премиум кредит на запрос или код ревью. У кодекса система посложнее: счетчик запросов сбрасывается каждые 5 часов и раз в неделю.
Это все хорошо, но реализация времени жизни переменных и наследование через трейты, кривая реализация константных данных и недоделанная шаблонизация - убивают язык. Если в соло писать, то все эти проблемы можно обойти и язык становится идеален. Если в команде кто-то неудачно воткнул трейты, то использование Rust становится кошмаром.
Наконец-то хоть кто-то написал о том, как правильно пользоваться агентской разработкой. А то сплошняком идут статьи, где пишут на Курсоре или через ЧатГПТ.
Codex после обновления стал чуть похуже работать. Я попеременно делаю через Codex и Github Copilot агента. У них схожие принципы работы, но копилот более "разговорчивый": сразу пишет план работ, добавляет сам тесты и рассуждения более детальные.
Выбрана слабая модель. Выбор хорошей модели - самое главное.
Заказчик хочет странное. Просишь его нарисовать кнопку в консольном приложении и он сразу сходит с ума. Короче, надо внимательно читать, что ты у него просишь.
Нет контекста. Если нужны данные из сторонних апи, подключаемые библиотеки, дополнительные ассеты, то он сдохнет. Надо аккуратно его всем этим обеспечить, например через MCP сервисы.
Большой контекст. Если хочешь много и сразу, то он сдохнет.
Узкая предметная область или если нужны точные данные. Делаешь торгового бота - ИИ что-то неправильно округлит и все упадет.
Это правда, ИИ именно в описанных местах любит косячить. Еще физику примерно так же плохо решает. Но это, в общем, специфика инструмента. Надо знать эти слабые места и в этих местах применять другой инструментарий.
Да и в целом, без TDD ИИ применять нет смысла. Надо сразу все покрывать тестами и за содержимым тестов следить именно глазами и мозгом. Это хороший способ держать агента в узде и не давать лениться.
Ну так инструментами пользоваться нужно уметь:
https://chatgpt.com/s/t_6953937f54448191ad3085751243fb86
Да, это красиво звучит, но кейс "бабушка слушает умершего мужа со старого телефона в метро" выглядит очень нежизнеспособно. Но поживем, увидим. Может и правда взлетит.
Почти все решения вы реализуете два раза: сначала неправильно, а потом как надо. Неужели у вас в команде нет ни одного человека, который до реализации не видит, что решение нерабочее?
С точки зрения бизнеса, сама идея делать решение как сервис - провальная. Идея с клонированием голоса рабочая, но пользователю здесь не нужен риалтайм и не нужна платформа. Ему нужен менеджер (прямо человек), которому он отдает имеющиеся материалы. Потом вы спокойно работаете, делаете клона и отдаете человеку ссылку. Вот эта вся спешка, реакты, лоадеры, собственная модель - не нужны.
Я использую облачный Codex - нет проблем с доверием к агенту, не нужно держать запущенный Codex CLI. На выходе сразу готовый пулл реквест. Правда в последнем обновлении включили Codex Max, который работает намного хуже предыдущей версии. Поэтому для серьёзных задач пока кодексом почти не пользуюсь.
Альтернатива - Github Copilot агент. Работает прямо из гитхаба, без всяких воркспейсов. Результат выдает прекрасный. Сразу прогоняет тесты, запускает playwright если нужно тестировать интерфейс, пишет саммари, делает ревью...
Во-первых, понимание безопасности к всех разное. Во-вторых, если бы я знал точный рецепт, то пулл реквест уже лежал бы в репозитории раста.
В целом, выглядит так, что если на уровне модуля сделать какое-то скрытое хранилище данных (чтобы скоуп выглядел модульным, но работал как скоуп функции), то это уже решило бы проблему. Тогда мы могли бы на уровне модуля создать стейт, как это мы делаем внутри функции. И далее можно использовать стейт из других частей модуля на своё усмотрение.
Глобальный стейт конечно можно сделать в расте, но это сложнее делается, чем в JS например. Вместо того, чтобы тупо инициализировать стейт, нужно делать дополнительные методы, нужно определять, кто его будет хранить. Без всего этого можно было бы обойтись.
А я не говорил про константный стейт. Сможете просто создать и инициализировать стейт для модуля без использования функций? Так, чтобы это была одна структура типа State.
Например у JS или Питон кодеров - это стандартный подход, объявить на самом высоком уровне константы, стейт. Они видят, что это удобно и понятно, но по неясным причинам этот подход в Расте не работает. В константах даже строку нельзя собрать, типа const APP = APP_NAME + APP_VERSION. По факту разработчики сделали столько ограничений на константы, что весь сопутствующий функционал сделан на макросах, либо не сделан вообще и от привычных вещей приходится отказываться.
Аргументный аргумент. Метод
keys()в растовском HashMap почему-то присутствует, хотя это в вашем понимании антипаттерн. И в документации приведен обходной путь как засунуть мапу в константы. Видимо очень популярный антипаттерн, да?Пруф, что это антипаттерн в студию.
Если принципиально, то это разные структуры данных. Если с точки зрения разработчика, то как сделать обход всех ключей при реализации через модуль?
Словарь в коде вы принципиально не хотите видеть?
Речь не о том, что в Typescript нет константных выражений, а о том, что в расте их нельзя задать таким образом. Это удобный способ для хранения настроек например.
К сожалению top level паттерн матчинг ни один язык кроме эрланга не умеет. Я бы его очень хотел, но тащить ради этого эрланг - явный перебор.
Если еще указывать недостатки Rust, то явно стоит упомянуть ограничения константных выражений. Например, нельзя как в Typescript написать внутри модуля:
const params = {key: 123, key2: "133"}
Codex и Copilot облачные агенты уже решают описанные автором проблемы. Они запускаются в docker контейнере, поэтому точно ничего не сломают. Вместо сотен тысяч токенов они тратят фиксированное количество кредитов. У копилота - один премиум кредит на запрос или код ревью. У кодекса система посложнее: счетчик запросов сбрасывается каждые 5 часов и раз в неделю.
Это все хорошо, но реализация времени жизни переменных и наследование через трейты, кривая реализация константных данных и недоделанная шаблонизация - убивают язык. Если в соло писать, то все эти проблемы можно обойти и язык становится идеален. Если в команде кто-то неудачно воткнул трейты, то использование Rust становится кошмаром.
Наконец-то хоть кто-то написал о том, как правильно пользоваться агентской разработкой. А то сплошняком идут статьи, где пишут на Курсоре или через ЧатГПТ.
Codex после обновления стал чуть похуже работать. Я попеременно делаю через Codex и Github Copilot агента. У них схожие принципы работы, но копилот более "разговорчивый": сразу пишет план работ, добавляет сам тесты и рассуждения более детальные.
У меня он стабильно лажает если:
Выбрана слабая модель. Выбор хорошей модели - самое главное.
Заказчик хочет странное. Просишь его нарисовать кнопку в консольном приложении и он сразу сходит с ума. Короче, надо внимательно читать, что ты у него просишь.
Нет контекста. Если нужны данные из сторонних апи, подключаемые библиотеки, дополнительные ассеты, то он сдохнет. Надо аккуратно его всем этим обеспечить, например через MCP сервисы.
Большой контекст. Если хочешь много и сразу, то он сдохнет.
Узкая предметная область или если нужны точные данные. Делаешь торгового бота - ИИ что-то неправильно округлит и все упадет.
Это правда, ИИ именно в описанных местах любит косячить. Еще физику примерно так же плохо решает. Но это, в общем, специфика инструмента. Надо знать эти слабые места и в этих местах применять другой инструментарий.
Да и в целом, без TDD ИИ применять нет смысла. Надо сразу все покрывать тестами и за содержимым тестов следить именно глазами и мозгом. Это хороший способ держать агента в узде и не давать лениться.
Пока не знаю. Я щас всю эту работу делегирую агенту и что-то хардкорное, с чем бы он не справился, пока не попадалось.