Comments 37
В смысле, "код ничего не стоит"?! Вы видели цены на OpenAI: o1-pro ? :)
На эту тему даже анекдот есть :)
Перед светофором останавливаются два авто - Рено Логан и Ламборгини. Водитель Логана, крутя ручку, опускает стекло и спрашивает водителя Ламборгини: - Ну как тачка вообще? Не ломается? - Да вроде нормальная тачка, а почему спрашиваешь? - Да смотрю, что-то не очень народ их покупает.
У меня подписка GPT Plus за 20 евро. Мне норм.
Её хватает менее, чем на час активной работы =)
Вы не могли бы показать код, который вы получаете за "час активной работы"?
Судя по минусам в приличном обществе показывать код не принято. Джентльменам верят на слово.
Вы не согласны с приведённым фактом по реальным лимитам? Или вам надо мне доказать, что получаемый результат - Г? Со вторым можете не утруждаться, мне виднее, устраивает меня результат или нет.
Смотрите, я беру по минимуму. При генерации кода (с правками и публикацией) у меня уходило примерно по 4% от недельного лимита. Это точно больше 10 минут чистого времени работы Codex-агента в режиме плагина для VSCode. Я визуально фиксировал 9 минут с чем-то при генерации кода, а это только один из шагов, пусть и самый длинный, на что ушли эти 4%. За это время агент нагенерировал 1-1.5К строк кода (с комментариями и пропусками). Тесты и спеки я не учитываю.
100% / 4% = 25 раз по 10 минут. Это 250 минут. Чистого времени работы агента за одну неделю. За месяц (4 недели) получается 1000 минут это 16 с лишним часов.
Допустим, вы запускаете своего агента в 16 потоков (раз вам не хватает этого объёма на час работы). Он должен нагенерировать за это время огромную кучу кода. Пусть и говнокода, но работающего хоть как-то и хоть как-то соответствующего поставленной задаче.
Просто любопытно взглянуть на эту кучу.
Я сижу на Клоде на подписке 100 евро (5x). Но последние несколько недель субъективно - лимиты стали раза в 2-3 меньше, наверное они из-за крабов стали подрезать всех. Купил кодекс за 20ку. Мне его хватило ровно на 40 минут. Вот как раз сегодня проапгрейдил его до 5x. И теперь могу сравнивать на одном и том же проекте их обоих. Кодекса реально хватает в разы дольше. При этом, опять же субъективно, как минимум он не “глупее”. Порой вообще искрит творчеством, Клод в этом плане поскромнее =)
А сожрать лимиты совсем несложно - я сейчас перегоняю старый легаси на современное, а это флоу - ресёрч конкретной фичи, написание спеки, имплементация, сравнение и так несколько итераций до получения 1:1. И это в 2-3 окна, бОльше я не тяну по когнитивной нагрузке =)
Трансформировать легаси в современный код - это боль. Там можно токены сжигать в галлактических масштабах и с минимальным участием человека. Особенно на большой кодовой базе.
Но у меня генерация и развитие кода с чистого листа. Тут и участие человека поболе будет, и токены используются в более контролируемом режиме. Так что 16 часов работы Codex'а в месяц - этого мне вполне хватает на разработку 4-5 npm-пакетов.
Я с нуля вайбю кой что под себя, там да, опять же, по ощущениям, лимитов хватает раза в 2-3 дольше, чем конверсия существующего. Просто потому, что дольше думаешь. Но там другая беда - быстро входишь во вкус и начинаешь плодить фичи опять же в несколько окон, не шибко следя за контекстом и наступаешь на те же грабли с лимитами. В общем придерживаюсь начального утверждения - 20 баксов - это ни о чём, для ознакомления =)
Это не 20 баксов - это 16 часов работы агента :)
Я, например, неделю обсуждал с ChatGPT спецификации для моей библиотеки в md-формате. Отвечал на вопросы, задавал ограничения, добивался согласованности и компактности контекста. За те же "20 баксов", но не агентом, а в чате. Да, пришлось вручную формировать документацию в проекте, перенося md-код между чатом и репозиторием. Зато потом, по готовому контексту, агент мне в течение менее получаса создал работающий код в ./src2/. А это значит, что он может порядка 32 таких библиотек за месяц нагенерить. Правда сам я не успеваю согласовывать более 4 контекстов (по одному в неделю). Сейчас уже чуть быстрее стало, но всё равно торможу.
Так что я пока даже свои лимиты не выбрал ни разу. А у меня ещё у жены, сестры и сына по GPT Plus учётке с неиспользуемыми лимитами для Codex'а. Есть куда расти :)
Да, спеки конечно лучше изначально как можно детальне прорабатывать. Потом дольше рефакторить ЛЛМом. Но подсаживаешься на быстрый дофамин от быстрого получения результатов и промпты становятся всё короче, а контекст - всё жирнее =) Но своя польза от этого тоже есть. Чем быстрее результат - тем быстрее понимание, куда на самом деле надо двигаться. А переписать нынче всё с нуля не так долго, когда вот такая “легаси” основа есть. Подноси бабло на токены только…
Так для кода - это не обязательно, можно за $10 взять Copilot и там запаса хватит как минимум на генерацию 10 тыс. + строк кода средней паршивости.
Сгенерить код можно, не вопрос. Будет даже решать какую-то задачи. Только нафиг это кому-то нужно то? Попробуйте найти задачу, которую еще не решили и которую действительно нужно решать, за которую люди будут готовы платить (а не просто юзать на халяву - так не честно - вы тратите время, деньги, силы - а другие просто юзают бесплатно). И даже если найдете задачу, создадите решение - как монетизировать? Как защитить от того, что Вася сгенерит что-то подобное по вашему образцу?
Брать пример с китайцев. Конкуренция в Китае таких масштабов, что придумать что то и почивать на лаврах не вариант.
Я как то купил квадрокоптер с камерой за 7$. И он даже летает. И камера работает. Конечно тут нет магии, это одноразовая игрушка для детей. Но интересное тут в том что разобрав такой дрон, понимаешь что при цене 7$ на нем зарабатывает цепочка людей, от производителя до реселлеров, включая доставку, растаможку итд.
Это не подвальное производство, это качественный пластик но тонкий как бумага, это продуманный дизайн чтобы этот тонкий пластик сохранял форму, какое то серьёзное оборудование которое обеспечивает высокую точность штамповки чтобы это все без проблем собирать и иметь приятный внешний вид (похож на мавик мини, складывается). Это кастомные чипы все в одном чтобы экономить на обвязке электроники.
Победить такого производителя думаю невозможно, потому что его бизнес модель не в идее, она в оптимизации производства. Ты можешь скопировать его игрушку, но удачи производить ее хотя бы так же дёшево))
на нем зарабатывает цепочка людей, от производителя до реселлеров, включая доставку, растаможку итд.
Такой подход - делает всех несчастными. Поясняю.
Работодатель играет на жадности - как бы психология - человек ищет чем дешевле, но лишь бы выполняло функцию. И для этого человека они работают. Значит и работникам нужно платить чем меньше денег, чтобы итоговая сумма была ниже. И качество нужно как можно ниже, но чтобы летало.
Все основано на грехе жадности.
Покупатель купил - насладился что дешево, что как бы сэкономил. Но на этом наслаждения заканчиваются. Он не купил вещь - а купил почти мусор. Оно быстро сломается. Оно не принесет длительного удовлетворения как надежный инструмент.
Так же и работники - они несчастны, т.к. их использовали на полную катушку - но заплатили самый минимум.
Получается такой подход всех делает несчастными и единственное наслаждение - за счет греха жадности.
Единственное наслаждение — за счёт того, что вы можете купить такую вещь. Можете позволить себе.
Конечно, хорошо бы оно не быстро ломалось. Хорошо бы оно работало долго. Хорошо бы оно было надёжным. Хорошо бы качество повыше.
Но тогда — не хватит денег на покупку.
Единственное наслаждение — за счёт того, что вы можете купить такую вещь. Можете позволить себе.
Но оно знаете как. Вы то хотите не просто купить вещь для галочки - а решать задачу жизненную. И по итогу оно сломалось очень быстро и задачу вы решать не можете. Фактически это был обман, т.е. думая что купили и смогли себе позволить - на самом деле выкинули деньги в мусорный бак. И более того - еще и нанесли вред Природе (больше мусора), заставили других людей страдать (чтобы они вложили все силы и работали за копейки от безвыходности).
Он не купил вещь - а купил почти мусор. Оно быстро сломается. Оно не принесет длительного удовлетворения как надежный инструмент
Варианта, где нужна одноразка, а не надежный инструмент вы не представляете?
Такой подход - делает всех несчастными. Поясняю.
Поздравляю, вы открыли капитализм и механику невидимой руки рынка. Только вы ушли немного в другую историю, будто у такой формы нет будущего.
На самом деле пользователь может и купит мусор за $7, но если ему нужно нормальное качество и чтобы не ломалось, то это будет стоить все $500.
И у работодателей тоже также: пока есть те, кто готов за $1 работать целый день - от будет нанимать тех, кто будет работать за $1. И дело здесь не в том, что работодатель такая гнида, а в том, что у его есть конкуренты, у которых работают китайцы с зарплатой $1. Если ты будешь платить своим по $1,5 значит твои дроны будут дороже чем у конкурентов, и на большой партии выберут не тебя. У тебя перестанут поступать заказы, придется со временем закрывать фабрику.
"Talk is cheap. Show me the code."
Напомнило: "И не надо рассказывать, как всё было на самом деле. Просто дайте документы." (c) Better Call Saul.
Проблема ИИ не только в детерминизме.
Детерминизм требуется от таких сущностей как модели, схемы, репозитории, АПИ спецификации. В них мы не допускаем творческого подхода.
Далее, отношение к кодингу как к творческому процессу - наивное. Это не творческий процесс, а научный. Код можно писать, применяя математический подход (например, DP), либо, научный подход (SOLID, GRASP). Художникам на рынке IT нет места.
Далее, нужно различать кодинг и программирование. ИИ неплохо справляется с кодингом, но совершенно не справляется с программированием. Собственно, в этом и есть основная претензия к вайб-кодерам и прочим ИИ-покемонам: они не могут отличить разработку ПО от кодинга. Даже вашу статью читаешь, и не понимаешь: нет ни алгоритма, ни описания используемых паттернов, ни дизайна приложения. Есть компоновка, и на том спасибо. Есть позднее связывание как паттерн интеграции - уже хорошо - это прям выгодно отличает вашу статью от прочих подобных. Но всё опять сводится к тому, что человек навайбкодил много кода и впал от этого в экстаз. И это уже надоело, если честно.
Когда я был совсем молодым разработчиком и пилил какие-то статьи для Хабра, моего опыта тоже не хватало, чтобы расписать дизайн и архитектуру, сделать упор на паттерны проектирования. Но я, хотя бы, писал код руками. То есть, я самостоятельно сталкивался с такими вещами как «приёмка работ», «code-review», «приёмочное тестирование», «сопровождаемость», «изменяемость». А сегодняшний вайб-кодер будто не знает этих вещей. Будто он никогда не работал. Словно над ним никогда не было ведущего разработчика, который принимал на себя ответственность за приёмку работ. А ведь процессы почти везде одинаковые.
Вот, например, вы говорите о детерминизме. А что насчёт сопровождаемости? Изменяемости? Вот у вас есть приложение. Допустим, вы хотите сделать его коммерческим. Вы проводите масштабирование, и получаете:
Приложение может теперь работать не только со Spotify, но и с другими агрегаторами музыки (YouTube, Яндекс, Apple).
Пользователь имеет интерфейс, через который он настраивает около 15 параметров: размер плейлиста, возрастные ограничения, популярность треков и их рейтинг на разных участках плейлиста, блэклист песен и исполнителей, ограничения каверов и т.д..
Приложение имеет несколько форматов выгрузки плейлиста.
И вот, вы сделали масштабирование системы, чтобы она смогла охватить больше задач, и чтобы ею могли пользоваться разные люди, а не только ваша семья. И вы использовали ИИ для полной кодогенерации решения. Итак, вам необходимо добавить ещё три параметра фильтрации:
Настроение трека
Темп треков (от и до)
Сингл или альбомная версия трека
При этом, допустим, настроение трека есть в Яндексе и Apple, но нет в Spotify. Темп трека можно реализовать за счёт анализа трека внутри приложения. Сингл или альбомную версию можно определить через поиск.
Итак, как вы думаете, при каких условиях эта задача не вызовет переписывание большого объёма кода?
А есть ли существенная разница, если переписывание займет еще 10 минут х n (задач) работы нейронки? Взять Claude opus - нормально поставить ему задачу и он справится, не сломав.
Добавить в начале работы немного мороки с авто-документированием и нормальным ТЗ. Выполнять работы итеративно (что можно прописать одной строчкой при обсуждении плана на старте). Ключевые решения, которые придется отдавать на откуп нейронке - вынести на консилиум для перекрестного обсуждения несколькими агентами (желательно разные семейства, но и ролевые модели подойдут) для сбора консолидированного мнения.
И готово, проблема если не решена полностью, то купирована. Вполне рабочий продукт на выходе.
Здесь проблема в том, что «он справится, не сломав» - это вопрос веры. Статистика багов в ИИ коде говорит об обратном: он ломает. А ещё попозже должна подъехать статистика по инцидентам.
Почему он ломает? Потому, что так устроен. Как правило, в коммерческом продукте очень много функциональных и не функциональных требований, а также, множество компромиссов. Код с высокой связанностью, написанный без учётов компромиссов, невозможно не сломать даже если он писался человеком. А ИИ, в принципе, не заморачивается соблюдением всех требований и поиском компромиссов. Он - машинка. У него диодики.
Хороший коммент. В суть. Но, наверное, я плохо её изложил, раз у вас возник такой вопрос. Вот скриншот из публикации, чтобы быть предметнее:
Я выложил (опубличил) в npm только код - результат генерации. Но я не выложил "инфраструктуру" - документы (спецификации) которые и позволяют генерировать этот код, разный по содержанию, но одинаковый по функционалу. "Инфраструктура" лежит в приватном репо.
На все ваши вопросы про сопровождаемость, изменяемость, масштабирование, по большому счёту, ответ один - документы контекста. Просто заменив часть спецификаций вы можете получить этот же функционал на другом ЯП (python, php, java, ...) или в другом фреймворке.
Документы контекста очень хорошо удерживают процесс эволюции приложения. Именно об этом и публикация. Моя мысль - главная ценность в ИИ-разработке не код, а спецификации. Проектная документация. У кого она есть, тот и код задёшево сгенерировать сможет. Впрочем, у человеков так же: код без документации - "тяжёлое наследие прошлого"
А вайбкодинг - это ваншот. Вот что сгенерировалось агентом в пределах его контекста, то и вот.
Далее, отношение к кодингу как к творческому процессу - наивное.
Пусть так. Я просто иногда вижу красоту в коде. А создание красоты - процесс творчества.
Итак, как вы думаете, при каких условиях эта задача не вызовет переписывание большого объёма кода?
А вот это не проблема. Код дешёвый, можно переписать хоть весь. В примере к этой публикации я всё снёс и переписал дважды. Вернее, это сделал Codex-агент - за 4% от недельной квоты 20-евровой подписки на ChatGPT Plus. В деньгах это обошлось примерно где-то в 20 центов. И это вместе с тестами.
Можно переписать весь код. Но, как вы говорили выше, есть проблема детерминизма. Чем больше вы перепишете, тем дольше тестирование, тем дольше доставка в прод. Тем выше риски потери данных или требований.
Всё верно. Но только чем это отличается от ситуации с "кожаными разработчиками"? Там тоже есть те же самые проблемы, которые решаются обычными, знакомыми всем методами - соглашения, архитектура, ревью, тесты.
В данном примере я специально попросил агента переписать весь код и все тесты. То есть, по факту, всё приложение. Но это крайне необычный случай. Обычно собирают требования, пишут спецификации, определяют критерии соответствия этим спецификациям, автоматизируют проверку соответствия, потом пишут код, удовлетворяющий критериям соответствия спецификациям этих требований. А затем повторяют все эти шаги итерационно - наращивают функционал, опираясь на существующую базу, по спирали. По ходу получая обратную связь от пользователей прода.
Вопрос в том, где и на каких позициях в этой производственной цепочке находятся люди, а где - агенты. По большому счёту - вопрос баланса тех и этих. А риски потери данных и требований существуют и в полностью "кожаных" производственных цепочках. Яркий пример - Schiaparelli, марсианский зонд, который разбился из-за ошибки ПО.
Где-то риски допускают большее присутствие "силиконовых", где-то меньшее.
Не скажите: разница есть.
Сроки доставки в прод. Переписывание с нуля, во-первых, увеличивает сроки тестирования, во-вторых, создаёт дополнительные расходы на тестирование и ревью. Здесь надо смотреть: можно ли уменьшать T2M и автоматизировать все этапы проверки? Пока что, ответы не в пользу ИИ.
Сопутствующие расходы. Пока проект маленький, переписать его с нуля - дёшево. А что если это большой проект, и нам на каждое изменение надо его переписывать с нуля? Это же и токены тратятся, и время QA, и время проверяющего инженера. Если декомпозировать проект на относительно независимые микросервисы, станет дороже размещение (MSA чаще требует больших расходов). Плюс, сейчас ИИ работает в убыток: финансовая аналитика компаний-владельцев ИИ показывает отрицательный рост доходов. То есть, токены продаются сильно дешевле себестоимости.
Ответственность и страховка. Если некая компания предоставила некачественное ПО, из-за которого произошла трагедия, она оплатит ущерб. Человек, допустивший критическую ошибку, также, возместит ущерб. Кто ответит за код, написанный ИИ?
В настоящий момент времени, ИИ предлагает более быстрое написание больших объёмов кода. Но кодинг - это только небольшая часть процесса. Есть ещё проектирование и анализ, приём работ, разные варианты тестирования, доставка и интеграция кода (Delivery and Integration). И эти процессы не всегда автоматизируются из-за критичности узких мест. Большой объём кода может замедлять последующие процессы и влиять на T2M. Я повторюсь: вы в вашей статье поднимаете важный вопрос проектирования системы, но, учитывая область её использования, у вас нет последующих этапов, и вы не можете оценить их. И эта проблема характерна, наверное, для 99% статей об использовании ИИ на Хабре. Они сводятся к тому, что человек видит объём работающего кода, и ему кажется, что ИИ может заменить целую команду разработки. Но нет реальных метрик T2M, ошибок и инцидентов, сопровождаемости.
Вы во многом правы. Я уверен, что нельзя, на данный момент, сделать всю эту производственную цепочку полностью, на 100%, автоматической. Весь вопрос в том, какие из участков этой цепочки и в каких случаях насколько можно автоматизировать. Для каждого программного продукта это будет своё собственное значение.
Мой опыт показывает, что в веб-приложениях процент автоматизации может быть достаточно высокий. Вплоть до автоматической обработки баг-репортов от конечных пользователей с автоматической выкаткой фиксов на прод (с учётом возможности промпт-инъекций и всего сопутствующего веселья). Этого пока нет, но я к этому стремлюсь. Получится или нет - посмотрим.
Спасибо за статью. У меня возникло два вопроса:
Зачем использовать позднее связывание, если, как вы говорите, нейронки в это не умеют без дополнительных настроек? Понимаю, что хочется иметь свой личный стиль во всех проектах, но в эпоху ИИ как минимум имеет смысл ревьюить свой стиль кода на наличие паттернов, которые на ровном месте ухудшают эффективность ИИ (больший шанс, что нейронка налажает в этом коде, так как такого кода нет/мало в данных обучения модели; больше токенов на то, чтобы прочитать скилл и держать его в контексте, что тоже влияет на дороговизну разработки и на качество, если контекст у вас забит не реально нужными знаниями о проекте, а формальностями, которые можно опустить).
Вы пишите, что размер спецификаций у вас превышает размер кода в несколько раз, и это ожидаемое поведение. Почему вы так считаете? Как будто весь смысл в том, что снижается сложность реализации проектов с нуля, что достаточно написать относительно короткую спеку, а нейронка ее заимплементит, вместо того, чтобы самому писать десятки тысяч строк кода. Возможно, проблема в том, что спека у вас тоже сгенерирована ИИ и поэтому она размытая и такая большая.
Спасибо за вопросы.
1) Нейронки умеют в позднее связывание, только не в JS и не в том виде, как это у меня сделано. Я в таком виде программировал долгое время на Java & PHP - там это норм (в том числе и для ИИ). Естественно, что я не хочу терять свои "инвестиции времени" и применяю привычный мне стиль кодирования и при смене ЯП :) У позднего связывания есть свои плюсы. Самый явный - прямое внедрение моков при юнит-тестировании (это уже явный плюс и для ИИ).
Я считаю, что код в том виде, что у меня получается, в конечном счёте удобен для ИИ. Ведь, в конце-концов, я отказался от своего стиля и принял предложенный ChatGPT формат. Ну а проектные соглашения всё равно нужны в разработке и агенты всё равно "жрут токены" при проверке соответствия результата генерации этим соглашениям.
2) Я осознанно сравнил поведение агента при генерации кода с дождевой водой - она стекает в океан с учётом рельефа (общими знаниями, что в модель заложили при обучении). Если вам всё равно, куда будет течь вода (как Карпаты, когда он впервые повайбкодил), то вы точно достигнете своей цели ("нас невозможно сбить с пути - нам всё равно, куда идти!"). Если ваши цели незначительно отличаются от обычно принятых (заложенных при обучении), то вам нужно лишь слегка скорректировать своими спецификациями поведение модели при генерации кода. Ну а если вы хотите, чтобы получился результат, который будет значительно отличаться от того, к чему модель привыкла (заложено при обучении) - вам придётся очень сильно "изменить рельеф" дополнительными спецификациями.
Я не хочу, чтобы "вода текла вниз к океану", я хочу, чтобы она "текла" туда, куда мне надо.
Сейчас, с новой игрушкой, парадигма сдвигается к раздутым спекам и пере~генерации исходников агентами с такой же раздутой вычислительной мощностью.
Интересно, в какой момент все вернется к компактным исходникам и зависимостям, по которым проект соберётся без испарения литров воды в иидатацентрах 😂
Ваш эксперимент хорошо показывает одну важную вещь:
да, интересно -- конечно же главный крючок статьи -- спека в 3 раза больше кода. хотя б частями тогда показали, хоть 5% спеки -- просто чтобы оценить деятельность ну и вообще -- каким языком пишете, как называете сущности и взаимодействие между ними.
и конечно прям интересно провести тест на другие языки - сгенерировать это же по спецам на питоне и пхп, насколько будет работоспособно и единообразно.
Разговоры ничего не стоят. Код тоже