Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 80
Сколько это стоит?
Меня не покидает ощущение, что нам обещают 10х производительности, только плати. А если не получилось, значит сам виноват и купи ещё токенов.
У меня подписка на Claude Code за 200$ в месяц. Не могу сказать сколько точно мой X к производительности, но он однозначно кратный. X3 наверное минимум к уровню годовой давности. Коррелирует с доходом примерно на том же уровне. Подписка за себя окупает, не жалуюсь)
Думаю что если бы мне это было невыгодно - я бы не пользовался
А я не против, сам с курсором пишу.
Я вот за это зацепился: Один Codex run может работать 6+ часов подряд.
Мне просто интересно, сколько это стоит
Ааа, ну по API это однозначно ни в какие ворота) Только подписка. Там как правила большие объемы токенов дают. Мои агенты столько пока не работали. Думаю как только это станет массовым явлением появится подписка условно за 500$. Ну это мое мнение. Посмотрим как будет. Пока скорее интересна архитектура всего этого.
Интересно количественно в токенах это сколько получается или машино-часах для модели. То есть сопоставить с удельной стоимостью скажем 5$ за мегатокен или 8$ в час. Какова выработка для проекта при активном использовании. Есть конечно фундаментальное ограничение - это вывод модели порядка 100-500 тоекнов в секунду, отсюда +- часовой тариф при непрерывном использовании.
По ценам если интересно: GPT-5.3 Codex по API это $1.75/$14 за мегатокен вход/выход, Claude Sonnet 4.6 $3/$15, Opus 4.6 $15/$75. На подписке ($200/мес Claude Max или ChatGPT Pro) выходит в разы дешевле чем по API, потому что эквивалент по токенам это $3000+ в месяц
6-часовой run если грубо прикинуть: ~200 токенов/сек на выход, за 6 часов набежит ~4M токенов в час × 6 = 24M. По публичным ценам Codex это ~$336 только на output. OpenAI внутри платят себестоимость инференса, так что для них это копейки.
Ну и агенты параллелятся, 3.5 PR в день на инженера это не один длинный run а несколько параллельных. Пока один думает ты следующего запускаешь
Вот тут какая-то загадка. Может быть подписка что-то не гарантирует, в этом вопросе как говорится чудес не бывает когда речь идёт о корпоративных клиентах например. Для физлиц это похоже какой-то демпинг. Наверняка там мегатокены гарантируют 100% загрузку и полное владение инстансом. Для остальных - сколько получится. Вроде как модель переинициализируется до нуля при каждом запросе тем более для разных пользователей шарящих 1 облачный GPU к примеру. Когда токенов много есть ещё пакетная оплата, а когда непрерывный обмен - тарифы с часовой арендой. Вообщем на Яндексе Квен вроде как порядка грубо говоря 1000 руб/ч с безлимом токенов но при этом отклик и "пинг" минимальные. Иными словами если уж полностью грузить то получается 8000 в день и 240 тыс в месяц - вполне себе средняя зарплата среди синьоров. Только вот синьёр не налопатит столько сколько джун, а вот электронному джуну вполне себе можно закинуть пул задач сформированный уже одушевлённым синьором. Вообщем всё верно, уже подошли к порогу окупаемости.
Правильно ли я понял мысль, что отдавая по $200 в месяц за Calude, вы стали зарабатывать в три раза больше?
в 3 раза больше строк кода
И в 3 раза больше седых волос, после разгребания этого кода :)
У LLM не могут поседеть волосы, ведь в основном мой код проходит AI Review. Но были кейсы когда в качестве подрядчика код смотрели люди - можете не волноваться, и там были лишь благодарности по поводу того насколько быстро это сделано)
AI ревью с комментариями? Просто иногда можно его просить сделать питон-скрипт который вырезает все комменты из кода, пробелы, табуляции (кроме самого питона), вообщем всё то что нужно человеку для экрана но не нужно ИИ, и скармливает чистую "базу", в этом случае эффективное контекстное окно существенно больше.
Интересная идея но на практике не работает. Комменты и форматирование это часть контекста который помогает модели понять намерение кода а не только синтаксис. Убрать их = убрать подсказки, модель начнет хуже понимать что происходит. Плюс современные модели используют кеширование промптов, повторный код в контексте стоит копейки. Экономия на спичках при потере качества
Маленько не так - синтаксические единицы просить прятать в пояснительные_имена_переменных_что_они_тут_делают = 0. Для человека это дичь, для компилятора - всё равно, для ИИ - это семантика. Какая разница пробел это или нижний штрих. Важна максимальная энтропия сообщения для модели с точки зрения количества информации на токен. Можете проверить - любая модель идеально понимает шлак из значков внутри переменной и даже может восстановить код по наименованию макроса (!) или модуля.
Плохая идея. Комментарии нужны нейронке даже больше, чем человеку
Опус написал прекрасный план, AI Reviewer оценил как ок. А кожанный мешок увидел, что нагрузка на базу положит бек.
Кода и правда стало больше, но кому от этого стало хуже? В моих кейсах - никому. Только польза
Все верно понимаете. И нет, я не работаю в Anthropic, мне нет смысла рекламировать Claude Code
Платит работодатель. По времени выигрыша, не особо заметно. GPT 5.3 Codex нравится больше чем Opus 4.6. Опус ленится и вообще неженка, скажешь исправить ошибку которую он сделал, он вместо исправления бросится доказывать, что ошибку сделал не он, а она уже была раньше, поэтому надо с ним ласково общаться.
Ах, да, выигрышь по времени есть и большой, когда полностью все даешь, чтоб агентское приложение все само задизайнило и заимплементило. Но тогда получаются огромные пул-реквесты на десятки файлов, которые нормально отревьюить самому не реально. И потом либо долго вникать в логику работы, походу исправляя если что-то не так, то есть уже нихера не быстро, либо забить и просто дальше продолжать вайбкодить, типа, говорить что добавить, когда замечаешь херню, говорить где и как отрефакторить и тд, но по-факту, проект уже не твой и сам в нем нифига толком не разбираешься.
В общем, либо это твой проект, где ты знаешь и понимаешь каждое решение, и не важно, кто именно кодил, или помогал дизайнить, и тогда нет выигрыша по времени, либо проект смутно знаешь, тогда разработка идет быстрее.
Каждый сам для себя решает, что ему важнее, я для работодателя делаю только по первому варианту, когда точно знаю, что где и зачем, когда другие ревьюят мои пул реквесты и я по каждой строчке знаю зачем она здесь. Для себя могу что-то по-быстрому навайбкодить.
Благодарю за конструктивное мнение, вам интересно ответить даже так как вы пробуете.
Что могу сказать по существу - ревьюить код написанный LLM и невозможно и не нужно в старом понимании. Ну конечно - с такой скоростью люди не могут успевать за ними. И статья ровно про это - про обвязки, которые помогают допускать меньше ошибок которые делает ваш клод и не допускать каких-либо объяснений что это сделал не он, о которых вы говорите.
Скажу по своему опыту - я с таким не сталкиваюсь и здесь решает работа с контекстом. Если я просто открываю репозиторий новый (уже с кодом) и даю ему задание по легаси коду - конечно он сделает миллион ошибок и создаст проблемы. Но если я создам AGENTS.md, docs/, обвяжу все AI-паттернами - он будет делать идеально. И я себе это доказал на разных проектах (легаси питон и Джанго на 100к+ строк кода; легаси реакт на 80к+ строк; микросервисы; монорепо — чего только не было). Молчу уже про новые проекты, которые я создаю сразу с ИИ обвязкой - там все просто идеально.
Работа с контекстом - решает и я вам искренне желаю научиться этому и я уверен — ваше мнение изменится)
Хомячки может и поверят, но слишком уж много вас стало, агитаторов за ии, и чет вы одни и те же лозунги кричите, чет падазрительна...А вообще если это выглядит как гумно, пахнет как гумно, дак наверно это и есть гумно? Сколько ему диферамбы ни пой.
вот кстати интересный вопрос - всегда прошу ИИ-шку сделать сплит всех без исключения модулей на файлы не больше 500 строк, в этом случае проект с точки зрения хранилища раздувается непомерно, но зато помогает всё это дело запихнуть в векторную базу данных, вплоть до того что туда монтировкой вкорячить имена файлов в качестве тегов. В этом случае качество существенно улучшается так как отсутствует эффект границы с потерей смысла. Исключения составляют файлы-данные и прочие текстовики, они не трогаются. Мало того там ставится тег "не пытайся это загрузить, здесь то что заставит долго думать"
Это ровно то о чем статья. Вы строите обвязку: мелкие модули, векторный индекс, теги, метки на тяжелых файлах. Это и есть harness engineering, просто вы это сами для себя изобрели на практике. Сплит на 500 строк + индексация это по сути то же что layered architecture у OpenAI, только другими руками. Подход рабочий
дальше больше - хранить псевдо-код с кучей ошибок компилятора, но из которого можно нагенерить уже готовые модули. Это уже более фундаментальный аспект в виде кода-ТЗ или скетч-кода (вполне возможно года через 2-3 появится), когда будет база данных из разряда
float CifrovoiFilter( *Filter_IIR){
float_or_double Accumulator = 0;
for (i=0;i<RazmerMassivaX;i++)
{
Accumulator += FilterIIR.Massiv[i];
}
}С точки зрения С - ставим двойку джуну за этот код. Однако с точки зрения смысловой сути и попросив сделать промпт "умножение с накоплением" этот код превращается... в полностью рабочий вариант. То есть количество информации для восстановления алгоритма обладает свойством достаточности. И если модель даёт на таком примере под 98% (в моём опыте так все 100 для таких случаев до единиц килотокен), то спрашивается зачем в 21м веке учить синтаксис.
Еще один контринтуитивный вывод. Агентам проще работать с технологиями, которые:
Стабильны и хорошо задокументированы
Широко представлены в обучающих данных моделей
В чем контринтуитивность ЛОЛ? Автор вообще знает, как работает машинное обучение XD или это "магия". Если бы всех этих технологий не было, ничего бы у машины не получилось, вы же понимаете что агенты не пишут код, они переписывают то, что писали люди годами и по своей глупости все это выкладывали в интернеты за так. Все это фуфло про "агентов" лишь маркетинг, чтобы обернуть факт того, что просто берется тьма чужого кода и ищется оптимальный, но локальный минимум, где нет ошибок линтера. Хорошо, вы можете купить compute и переписать какой-то программный продукт. Можно ли так создать реально нечто новое, то есть найти глобальный максимум или реальную иновацию? Вряд ли, но каждому свое. А вот когда люди поймут, что те, кто продвигал Open Source, тупо отдали благосостояние всей индустрии капиталистам, они все это проклянут, но будет уже поздно, потому что надо будет идти на завод работать, а не сидеть жопу греть в офисе попивая флет уайт и кидая гифки в рабочий чатик. Радоваться по сути-то нечему XD -- привет 2050м из 2026.
Давайте по порядку)
Контринтуитивность в том что люди (включая опытных инженеров) интуитивно пишут больше инструкций, думая что это поможет. А на практике это ухудшает результат. Это буквально определение слова контринтуитивный.
Про "агенты не пишут код, просто переписывают чужой". Ну это как сказать что калькулятор не считает, а просто переставляет цифры которые придумали люди. Да, модели обучены на открытом коде. Но когда агент берет задачу, анализирует кодовую базу, находит абстракции, пишет реализацию, прогоняет тесты и отвечает на ревью это не ctrl+c/ctrl+v. 1500 PR за 5 месяцев это измеримый результат, не маркетинг.
"Можно ли создать нечто новое". А что такое нечто новое в софте? 95% инженерной работы это интеграция, обвязка, CRUD, тесты, инфраструктура. Не изобретение алгоритмов. Агенты справляются именно с этим, освобождая людей для тех 5% где нужно проектирование. Статья ровно про это.
Про Open Source и капиталистов. Это валидная тема но она вообще не про то о чем статья. Можно переживать за этику и при этом продуктивно работать с тем что есть. Одно другому не мешает.
Про завод и флэт уайт. Прогнозы про массовую безработицу от автоматизации звучат с 1810 года. Каждый раз инструменты менялись, люди находили новые роли. Статья как раз описывает одну из таких ролей.
1500 PR за 5 месяцев это измеримый результат, не маркетинг
Они даже не намекают что это за внутренний продукт такой на лям строк кода. Так что это только маркетинг и самый шапкозакидательский.
Да, OpenAI действительно не раскрывают что за продукт. Но статья и не про продукт а про процесс. Как устроена архитектура, почему большой AGENTS.md не работает, как линтеры заменяют инструкции, зачем "скучный" стек. Это конкретные инженерные решения которые можно проверить на своём проекте. Маркетинг бы не описывал свои провалы. И да, статью я писал через призму своего опыта. И я проверил - работает. А точнее - я это в какой-то степени делал и до их статьи.
1500 PR за 5 месяцев это измеримый результат, не маркетинг.
Простенький баш скрипт на технологиях предков сделает вам 15000 ПР за 5 часов.
Баш-скрипт на 15000 пустых коммитов — а смысл?) Там описан цикл: агент воспроизводит баг, пишет фикс, прогоняет тесты, проходит ревью, обрабатывает комменты и мержит. Если есть баш-скрипт который это умеет — серьёзно, покажите, думаю это будет прорыв))
Буквально соседняя статья. Сетка генерит какой-то нейрослоп. Кто будет разбираться в нем непонятно.
"Можно ли создать нечто новое". А что такое нечто новое в софте? 95% инженерной работы это интеграция, обвязка, CRUD, тесты, инфраструктура. Не изобретение алгоритмов. Агенты справляются именно с этим, освобождая людей для тех 5% где нужно проектирование. Статья ровно про это.
Ну чувак, ты как тот патентовщик в начале века, который утверждал, что можно патентное бюро закрывать, так как все изобретено. Ваше ИИ это верх инженерии? По мне дак это мусорная технологии во всех смыслах. Твой посыл понятен: "делегируй все". Ты то сам зачем вообще нужен тогда? Ты посредственность, которой никогда не стать чем то большим, и ты даже понять этого не сможешь. ИИ это паразит, который паразитирует на всеобщем достижении человечества, давая непонятные крохи в замен, более того, забирая у нас будущее
А вот когда люди поймут, что те, кто продвигал Open Source, тупо отдали благосостояние всей индустрии капиталистам
Можно подумать, отсутствие открытого кода остановило бы ИИ-компании. Авторы 500 тысяч книжек кому что отдали? "Капиталистам" это просто стоило 1,5 миллиарда президентов США - дороговато, но никто даже за решётку не сел.
Не всё так просто. Реализован предельно эффективный Lossy алгоритм (потому как глюки)-сжатия данных практически с максимальной энтропией из всех возможных, сохраняя их смысл в человеческом понимании (вывод данных). То есть триллионы токенов использованы для формирования заданного количества весов, в частности несколько миллиардов. При этом, вбираются практически все знания и умения накопленные человечеством. Ведь ЯП - это искусственные образования, никто специально их для ИИ не разрабатывал, это отдельная история доработки ИИ под среду проектирования (даже не программирования) которая работает непосредственно с векторами представления минуя язык, вплоть до машинного кода на выходе. В этом смысле диалог уже не ведётся на уровне инструкций кода а на уровне фактически ТЗ, где прописываются все ограничения, которые ИИ с агентом и будет выполнять. Какая разница что там внутри если код удовлетворяет тестам, параметры соответствуют цифрам, имеется описание поведения модели на уровне конечных автоматов или блок-схем, имеются тесты проверяющие парадоксальное поведение а также теоретические сведения об используемых алгоритмах на уровне О(n). ИИ - это просто неминуемый инструмент который в принципе может работать без прокладки в виде того что сделано за крайние лет 50 в виде языков программирования в том смысле в котором мы их понимаем
Продуктом пользуются сотни людей внутри OpenAI ежедневно
А можно публичный репозиторий чтобы посмотреть?
Нет, это внутренний продукт OpenAI. Но статья описывает не код, а инженерные практики — их можно проверить на своём проекте, репо для этого не нужен. Суть статьи вообще не в продукте и его никто и не рекламирует. Суть в подходе и продублирую свою мысль из комментария выше — я так уже делаю и у меня это работает.
Так это может быть всего навсего реклама OpenAI (вспомните нерабочий компилятор который написал рой агентов) - запускайте больше агентов и жгите больше токенов. "У нас есть такой проект и он работает, но мы его вам не покажем" это просто вверх наедалова какой-то.
Отвечу по-другому: допустим, код бесплатен совсем.
Но откуда взять требования: функциональные, нефункциональные, ограничения, корнер-кейсы?
Вариант 1 ТЗ.
Стоимость корректного ТЗ сравнима со стоимостью кода. Иксов ускорения не получается.
Вариант 2 датамайнинг (выявление) требований самим LLM (например, рефакторинг старой рабочей системы-оракула, мы не знаем как должно быть, но у нас есть оракул)
Теоретически может работать, но успешных кейсов пока не слышал.
Если скажете профиль приложения, которое пишет рой агентов, будет более предметное обсуждение.
И ещё одно наблюдение.
Максимальный эффект от подхода когда разработчик совмещает роли доменного эксперта, архитектора, сеньора разработчика и тестировщика. То есть требования и код помещаются в одной голове.
Но классическое разделение "аналитик - разработчик - тестировщик" существовало не зря. Совмещать разработчика и тестера плохо: разный стиль мышления, разная мотивация. А теперь всё это должно быть в одной голове и это источник серьёзных рисков, о которых статья молчит.
Итого: могу поверить в небольшие проекты, но в большие не могу.
А у кого в этой конструкции в голове знания хранятся: у инженера будущего или у обвязанных агентов?
Ну что вы начинаете. Тут на кону уже несколько триллионов долларов, а вы все нудите про какую-то надежность, басфактор и поддержку.
/s
Вопрос "у кого знания" ключевой, и статья прямо на него отвечает: ни у кого в голове. Все в репозитории. Архитектура, решения, планы, техдолг. Версионировано, проверяется линтерами, обновляется агентами. Обсуждение в Slack или решение в чьей-то голове для агента не существует, поэтому команда вынуждена все фиксировать. Documentation as source of truth, доведенный до предела.
Про надёжность, басфактор и поддержку (сразу отвечу на комментарий ниже). Это ровно то, что такой подход решает лучше классического. Когда знания размазаны по головам пяти сеньоров, басфактор = 1. Когда все в репо и любой агент или новый инженер может подхватить контекст за минуты, басфактор стремится к нулю. Ирония в том что "нудеть про надежность" это аргумент за подход из статьи, а не против.
Но для этого нужно статью прочитать, а не только заголовок.
Спрошу по-другому.
Что знания самого проекта в проекте-же и хранятся, это хорошо и правильно.
А вот тот корпус инженерных знаний, на котором основан проект и принимаемые в проекте решения - они где хранятся, в голове у нейросети или в голове у инженера будущего?
За минуты разобраться хотя бы в сотне тысяч строк кода? Вы это серьезно?
А кто будет чинить баг на проде в три ночи? Релизов не катали, вообще ничего не делали. А прод упал. Планируется нейросетку уговаривать починить? И видимо дать сетке доступ к проду. Потом будут веселые кулстори как сетка весь прод снесла.
Извиняюсь за то что накину еще хейта, но сам заголовок слишком категоричный. А агентов кто будет писать - не другие инженеры будущего, такие же как сейчас?)
Заголовок намеренно категоричный, согласен. Но "не пишет код" не значит "не понимает код". Инженер который строит обвязку для агентов должен понимать архитектуру, границы модулей, принципы тестирования глубже чем тот кто просто пишет CRUD руками. Он не перестает быть инженером, меняется инструмент.
А агентов пишут такие же инженеры, да. Как и компиляторы, IDE, линтеры, CI. Кто-то строит инструменты, кто-то ими пользуется. Это не новая ситуация, просто новый слой абстракции)
Артема в том, что чем дальше, тем меньше и хуже "инженер" будет понимать код. И речь не только о том, что код разрастается и сложно становится его понимать, а в том, что место одного "инженера" придет другой, который понимает вообще проектирование хуже чем предыдущий, потому что у него нет опыта, зато агентами пользуется он постоянно. И с каждым новым "инженером" ситуация будет усугубляться.
We are no longer particularly in the business of writing software to perform specific tasks. We now teach the software how to learn, and in the primary bonding process it molds itself around the task to be performed.
(c) SMAC
А ведь ещё немного, и научат этих агентов "how to learn", уже сейчас - и что-то там вырастет? Интересно.
Частично уже происходит. В статье описан агент-садовник который сам находит устаревшую документацию и чинит ее. Это еще не "learning" в полном смысле, но уже self-improvement loop. Направление понятно.
Не знал кстати что такое SMAC, но загуглил. Очень мощная цитата. Удивлен какой ее возраст. Спасибо что открыли это для меня)
"Всегда лучше пытаться писать программы, которые пишут программы. Как говорит Дуг Макилрой, «все, что вам придется делать неоднократно, можно считать готовым к автоматизации»." - была книга Кернигана-Риччи бумажная не помню какая по С или какая-то другая, это более полная цитата. "Вместо того чтобы вручную писать код или выполнять последовательности операций, лучше создать нотацию или спецификацию того, что нужно сделать, а потом написать программу для интерпретации этой спецификации. Такая замена кода данными почти всегда дает выигрыш." И это ... 70е годы прошлого века!
Не верьте сене альтману, открытый гей может оказаться настоящим пид..р..сом
Не понял, ни одного скептического комментария что OpenAI тупо врать могут про 100% кода от ИИ? Или люди считают, что если Альтман соврет, то сотрудники опровергнут?) Стартапы врут и преувеличивают (не только они, но в первую очередь), это один из их способов ускорить и увеличить заработок. Я сам в стартапе работал, и когда наш СЕО... очень сильно преувеличивал скажем так, никто ничего не опровергал ибо успех = бабло для сотрудников
Когда на деньги всё завязано, все врут: OpenAI врёт ради продаж подписок, автор врёт ради продаж курсов.
Могут врать, конечно. Но статья не про то верить ли OpenAI на слово, а про конкретные инженерные практики которые описаны достаточно детально чтобы проверить самому. AGENTS.md как оглавление, линтеры вместо инструкций, документация в репо, слоеная архитектура — это все можно взять и попробовать на своем проекте за выходные. Если не работает, значит врут. У меня работает)
Тут как со статистикой. Не нужно даже врать - можно не договаривать. Нет ровным счётом ничего сложного в том, чтобы написать с нуля проект на сто миллионов строк кода ии агентом. Например если твоя задача типична и часто встречалась (например сделать 100500 мини игр в одной), или есть твоё ТЗ уже на сто миллионов строк кода, и главное, если каждый новый блок кода мало взаимодействует с остальным. Например можно нагенерировать какой нибудь декодер кучи форматов, где связанная часть - чисто один файл с выбором in/out, а остальное - раздельные атомарные декодеры.
Проблемы у llm начинаются когда тебе надо не написать проект с нуля а внести правку в существующую многоступенчатую систему. У меня codex на бесплатном api со скоростью инференса 50 токенов в секунду - 6 часов варил одну очевидную строку кода (я решил просто проверить, а не сделал сам)
Инженеры будущего, почему приходя на любой проект мы видим говнокод, смешь шизы с ии слопом, где обещанный прогресс?
До чего же знатно в комментах пердаки полыхают!
Отрицание
Гнев <--- вы где-то здесь
Торг
Депрессия
Принятие
Так полыхают не потому, что не принимают новый инструмент, а потому, что им пытаются ссать в уши, что он работает намного лучше, чем оно есть по факту.
Я вот всеми руками за, чтобы я решал одну задачу в агент другую или 10, но что codex, что Клод, что chatgpt + kilo code - ну ни одну задачу продуктовую пока не смогли решить, ни с каким промптом. Ни декомпозированную, ни описанную, ни "как есть". Варят килотонны токенов, перечитывают десятки файлов проекта, и в конце составляют план из чуши или вносят изменения в файлы, которые вообще к делу отношения не имеют.
Да вот прямо час назад - я попросил deepseek в чате отцентровать элемент, и все что он сделал - описал какой он молодец и добавил в код комментарии. Комментарии Карл, без единой правки меняющий результат работы программы. Нет, конечно если по пытать его пол часика, он выдаст кривое решение, но я в коде это центрование напишу за три, просто я хотел за 10 секунд.
Ну не годятся пока инструменты, чтобы реально отказаться от знания кода, даже близко не похоже.
Если это и есть причина того, почему фронт chatgpt стал так безбожно лагать уже после 5 промтов с кодом и жрать по 500мб на вкладку, предлагаю сотрудникам OpenAI войти с разбегу в стену, потому что это полный ад, в то время как deepseek спокойно отрабатывает сотни огромных запросов и даже ни на секунду не подлагивает.
У меня двоякое ощущение. С одной стороны, автор описал вполне здравый и практичный путь развития AI‑кодинга. Он ничего явно не продаёт: кроме ссылки на свой ТГ - никаких офферов и курсов. Статья в плюсе, тезисы выглядят разумно.
Но при этом почти все комментарии автора под собственной статьёй заминусованы. Такой диссонанс вижу нечасто. Обычно, если подход действительно ошибочный, это видно и в тексте.
Я новичок в теме и пытаюсь разобраться, где здесь подводные камни. В комментариях звучала мысль, что при такой модели разработки экономика может не сходиться: стоимость токенов становится сопоставимой с зарплатами разработчиков. При этом внутренняя экономика OpenAI закрыта, а автор утверждает, что у него расчёты положительные.
Вопрос скорее общий: какие ограничения или слабые места у подобного подхода вы видите на практике? Где он перестаёт работать - по деньгам, по качеству кода, по масштабированию?
Скриньте - сейчас мне опять понизят карму за этот коммент, но мое мнение мне дороже)
Подводные камни определенно есть. В статье описывается долгая непрерывная работа агентов (по ночам в том числе). Это дорого, для OpenAI это намного дешевле, у меня пока так не получалось.
Как выглядит моя работа сейчас - это скорее AI-Assisted кодинг но в плане организации файловой архитектуры (markdown, планы, документация) - все почти то же самое (чуть адаптированное под мои нужды).
Экономит время? Да. Кратно? Да. Сколько стоит? 200$ в месяц. Работают ли за меня агенты по ночам? Нет. Менее ли полезная от этого статья? Нет. Если применять паттерны из статьи и даже без работы агентов в бесконечном цикле - ускорится работа? Да.
А горит у людей потому что сложно перестроится. И я их понимаю. Представляю, ты кодишь 5,10,15,20 лет, а кто-то и больше - а тут приходит какой-то чел и говорит тебе что вот теперь делают по-другому) Но я же в статье без осуждения подошел, а люди в комментариях - с осуждениям. Мне на самом деле больше грустно что так процессы перестраиваются, но это неизбежно.
Зашёл посмотреть, насколько заминусят автора за такой заголовок — и, не ошибся)
В статье всё красиво и складно изложено, но у меня возникает практический вопрос: какие проекты реально можно писать таким образом?
Я из тех людей, кто работает в ИТ давно — с 2002 года. Я начинал с Delphi, сейчас основной стек — Go и Kotlin. За свою карьеру я изучил сотни подходов и технологий. И причина в том, что опытный инженер учится каждый день, независимо от возраста или стажа. Поэтому неясно, почему предполагается, что я не способен освоить использование LLM в разработке — это не вопрос неспособности учиться, а вопрос ответственности за результат.
Проблема, на мой взгляд, в том, что вся ответственность за качество и корректность кода всё ещё на разработчике. Я не могу дать гарантию за код объёмом 20 000, 30 000 или миллион строк, который написан группой агентов, пусть даже они якобы проверяют друг друга.
Весь код, который я отправляю в продакшн, должен быть лично проверен мной. И я не представляю, как можно сесть и весь день читать десятки тысяч строк кода, сгенерированного LLM — это сложно, скучно и неэффективно. Даже если прочитать — это не гарантирует, что бизнес-логика и критические вычисления реализованы правильно, потому что без запуска и глубокого тестирования такие вещи не проверишь.
И это не только мои опасения: например, проект на бирже Bitget потерял около 1,78 млн долларов, когда ошибка в сгенерированном коде привела к неверному расчёту цены актива (cbETH) и позволила злоумышленникам извлечь выгоду.
Так что мой вопрос остаётся практическим: где, по вашему мнению, такой код можно безопасно применять: в банках; медицине; промышленности?
И если да — в каких именно частях проектов и с какими гарантиями качества?
В том кейсе с биржей Клоду активно помогал человек. Там была ошибка в новых конфигах, причём если посмотреть pr, рядом с новым конфигами оставили старые правильные но закомментированые - очень похоже на человеческий подчерк.
какими гарантиями качества?
Какие гарантии качества появляются от того что код написал человек?
Весь код, который я отправляю в продакшн, должен быть лично проверен мной
Ну это где-то в идеальном мире, а в реальности это может быть и новый проект со старой кодовой базой и open source, а прод сайноф надо.
потому что без запуска и глубокого тестирования такие вещи не проверишь.
Ну вот сами же говорите: дело то получается не в том, кто как писал, а в том как проверяли.
Какие гарантии качества появляются от того что код написал человек?
Личная ответственность исполнителя.
дело то получается не в том, кто как писал, а в том как проверяли
Вся суть моего комментария в этом и была - кто и как проверяет миллион строк кода написанных агентами?
Личная ответственность исполнителя.
А бизнесу то что с того? Ему нужны нормальные метрики, типа failure rate или availability.
как проверяет миллион строк кода написанных агентами
Точно так же как и милоионы кода написанного людьми: секурити сканы, автотесты, сайнофы перед выкадкой в прод - всё то же самое, агенты тут ни при чём.
Если вы намекаете на то, что кодревью усложняется или даже становится невозможным (особенно в ручном режиме) с появлением агентов, то это не проблема, потому что кодревью никогда не было достаточным критерием качества для прода.
А бизнесу то что с того? Ему нужны нормальные метрики, типа failure rate или availability.
Действительно. Ну и что, что Bitget потерял 1.8 млн, главное, что метрики есть.
Точно так же как и милоионы кода написанного людьми: секурити сканы, автотесты
В ядре Линукс за 35 лет, написано 40 млн. строк кода и каждый мр прошел ревью и обсуждение, а агенты за ночь генерируют миллионы строк кода.
Статические анализаторы не проверяют бизнес логику.
Кто пишет автотесты?
Кто пишет тесты на тесты (с)
Люди, теперь ещё и агенты будут помогать, всё то же самое, ничего нового никаких принципиально новых проблем с появлением агентов не возникает. Если только вы не фанат ручного труда потому что это не масштабируется никак.
Ну и что, что Bitget потерял 1.8 млн
Личная ответственность тут как бизнесу помогает?
агенты будут помогать
Помогать - это писать за разработчика тесты? Я сомневаюсь, что разработчик, который поленился написать код, сядет за самое скучное - написание тестов.
Правильно ли я понимаю, что LLM пишет код, а потом пишет на свой код тесты.
Выходит:
Ревью нет.
Тестирования нет.
Как вы гарантируете правильность выполнения своей работы?
Личная ответственность тут как бизнесу помогает?
Рынок труда устроен просто: есть наниматель и есть работник. Наниматель берет на себя обязательство оплачивать результаты труда или время, затраченное на их получение. Работник, в свою очередь, берет на себя обязательство выполнять порученную ему работу.
Работник получает задание, выполняет необходимые действия и получает результат своего труда. После этого происходит ключевой этап: он обязан проверить этот результат. Если обнаружены ошибки — исправить их. И только после этого передать результат нанимателю.
Личная ответственность работника — проверять результаты своей работы.
Проблема в истории с Bitget не в том, что LLM «ошиблась». LLM — это инструмент. Инструменты сами по себе не совершают ошибок. Ошибаются люди, которые ими пользуются.
Проблема в том, что работник, использовавший этот инструмент, не проверил результат своей работы перед тем, как передать его дальше.
Я каждую волну llm кодинга пытаюсь завалить мир сгенерированными приложениями (пока вообще не выходит). Расскажу свои выводы.
По плюсам
Llm почти всегда круто реализовывают локализованные задачи. Написать утилиту, скрипт, поправить вёрстку, обновить компонент, написать тест - очень круто. В этих задачах экономия времени прямо реально до 10 раз и больше.
Llm неплохо объясняют код. Если где-то непонятное поведение или надо исправить - есть шанс в половину, что llm даст хорошую наводку на причину проблемы.
Можно быстро раскатать mvp.
А теперь о проблемах
Агенты - чудовищные пожиратели токенов. Когда я использовал бесплатное api со скоростью инференса 50 токенов, на задачу которая решается за 1.5 часа ручного кодинга ушло ~48 часов непрерывной работы агента. Причем задача решена не была, только частичные наработки, которые надо допиливать напильником. И у меня есть ощущение, что на проверки - не помер ли агент в процессе и что он так долго делает - я потратил половину времени от ручного написания кода)
Llm ужасны в нелокализованных задачах. Дайте агенту обширную задачу требующую внести изменения в несколько файлов - и он перечитает их по 10 раз, и перепишет в 5 раз больше чем нужно, зачастую сломав что-то другое, что до этого работало. Я уже видел задачи, когда проблема решалась точечным изменением одного флага, а llm переписывала 800 строк кода.
Llm вообще не знает что такое производительность. Там, где агент писал мне решение, которое почти работало (и правкой импортов, мелочей и пары условий - завелось), я получил 6 кадров на сцене, которая не нёсет никакой нагрузки. Я попросил оптимизировать, и он оптимизировал, но вообще не то, что на самом деле жрало ресурсы. Пол часа напильника, и 6 фпс превратились в 120, но для этого надо понимать код. Оптимизировать написанный код - может быть значительно сложнее, чем написать оптимальный сразу, особенно когда проблемы ты находишь не сразу, а когда сверху ещё 20 зависимостей и сотни строк кода.
Ну и главная проблема - в один прекрасный момент агенты даже, блин, на микроскопической кодовой базе - впадают в тупняк. Они начинают ходить по файлам кругами, переживая контекст и повторяя круг, переписывают одни и те же параметры также обратно, ломают по очереди две фичи туда обратно, чиня одну и ломая вторую, или пишут семиступечантые вундервафли там, где нужно сделать что-то очень простое. И вот когда у тебя один - два новых класса и ты сталкиваешься с проблемой - можно спасти бедолагу руками. Но когда у тебя 100к строк кода, с архитектурой от llm (у меня в одном проекте например агент использовал 3 разных подхода к di в разных классах и 2 к построению интерфейса, и смешал несколько архитектур), то исправить одну протекающую проблему - может занять недели или месяцы.
Пока - по ощущениям, llm в качестве кодера - это как болиды формулы 1. Они очень быстрые, очень красивые, громко звучат, но на треке. И чем дальше ты от идеального трека к суровой реальности, тем больше экспоненциально растут в тебя проблемы.
Осталось понять где лучше этих агентов делать и выстраивать цепочки) а то каждый чтото свое хвалит
Успешность проекта теперь измеряется количеством строк кода и МРов? Какой-то индусский подход получается. Может, агенты там калькулятор написали на миллион строк
сам написал вайп кодом с полного нуля py torch для rtx5080 это 2 млн строк кода. Мета вырускает релиз за пол года. Командой из 100 человек. Я справился за неделю. Параметры получились выше чем у Меты.
Из статья я так и не понял что же такого полезного получилось в результате деятельности 7ми инженеров... Однако из коментариев под статьёй понял что для запуска этого чуда на 1000000 строк нужно платить $ и чем больше тем лучше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инженер будущего не пишет код. Он строит обвязку для агентов