В наше время известное изречение Линуса Торвальдса "Talk is cheap. Show me the code." можно переиначить в виде "Code is cheap. Show me the spec." Меня зовут Алекс Гусев и в этой публикации я постараюсь показать, почему я так считаю.
У меня есть несколько статей на Хабре, объединённых общей темой: ADSM (Agent Driven Software Management). По сути, это моя попытка формализовать свой личный опыт в Spec-Driven Development (SDD) в какое-то подобие методологии. Под катом я поделюсь результатами применения SDD-подхода (в его ADSM виде) к разработке простого приложения - помощника в создании плейлистов в Spotify. И покажу, что будет, если на базе одного и того же контекста (спецификации) сгенерировать код одним и тем же агентом (Codex, GPT-5.4) с разным уровнем reasoning'а (high, medium, low).
Предыстория
Нам для одного из семейных мероприятий понадобился плейлист на 4-5 часов на определённую тему. ChatGPT хорошо справился с задачей и выдал список из 100 музыкальных произведений с названиями и авторами. Оставалось сформировать плейлист для Spotify. Раньше мы делали это вручную и времени уходило порядком, но сейчас такие вещи легко поддаются автоматизации через ИИ-агентов.
Я уверен, что кто-то может навайбкодить подобное приложение за полчаса, а то и за десять минут. Но во-первых, я не умею вайбкодить, во-вторых, я умею SDDевелопить. Поэтому, на создание первой версии приложения у меня ушло 2 часа чистого времени.
История
До того, как я занялся реализацией этого проекта, я вообще был не в курсе о каких-либо возможностях интеграции Spotify с внешними приложениями. ChatGPT подсказал мне адрес https://developer.spotify.com/ и объяснил, что и где нужно прописать, чтобы зарегистрировать своё приложение.
Оказалось, что аутентифицироваться в Spotify нужно по протоколу OAuth. А для этого нужно иметь свой домен и TLS-сертификат. Домен у меня был, сертификат делается через Let's Encrypt. Я уже давно пишу только на JavaScript, поэтому выбор ЯП был безальтернативен. Как и выбор платформы - только TeqFW, только хардкор!
Создал приватный репозиторий на GitHub'е, склонировал на локалку. Добавил в контекст (./ctx/spec/) типовой код для nodejs-приложений на базе моей библиотеки @teqfw/di. Где-то около часа с небольшим я в VSCode обсуждал в диалоге с Codex-агентом детали будущей реализации - как запускать, как конфигурировать, какие зависимости тянуть. Агент всё это аккуратно фиксировал в контексте проекта (каталог ./ctx/docs/). Затем я попросил агента создать ./package.json, bootstrap-файл ./bin/cli.mjs и головной скрипт приложения ./src/Main.mjs. После чего попросил создать в две итерации: 1) интеграционные тесты и код для получения и сохранения токена аутентификации через веб-сервер; 2) загрузку и парсинг текстового файла с музыкальными композициями, поиск произведений в Spotify и формирование плейлиста (тоже интеграционные тесты и исходники). Соответствие формата es6-модулей требованиям своей платформы я верифицировал по скиллу teq-esm-validator.
Я проверял работу приложения по частям (каркас - просто запуск; получение токена аутентификации; разбор файла и поиск композиций; создание плейлиста и добавление в него найденных композиций). Итого, чуть больше, чем через два часа чистого времени в моём Spotify этим приложением был создан новый плейлист из 80+ композиций. Остальные композиции из списка не были обнаружены в Spotify.
Последствия
Я время от времени вижу в комментах на Хабре, что коллеги высказывают мысль, что LLM-агенты неприменимы в разработке, потому что от них нельзя получить детерминированный результат. Но для меня до сих пор программирование - это всё ещё отчасти искусство. Если бы Леонардо да Винчи рисовал свою Джоконду десять раз, то он бы нарисовал десять разных картин, на которых была бы изображена одна и та же женщина. Если любой программист десять раз реализует достаточно сложное приложение, то это будет десять разных приложений с одним и тем же, заданным, функционалом.
"детерминированность результата" != "детерминированность кода"
Для демонстрации этой идеи я опубликовал оригинальный код, созданный Codex-агентом (GPT-5.4, high reasoning) под версией 1.0.0. Только код, контекст я специально вырезал. Затем я попросил Codex-агента (GPT-5.4, medium reasoning) удалить папки ./src/ & ./test/ и на основе того же самого, неизменённого контекста из папки ./ctx/ создать с нуля тесты и исходники (для экономии я оставил прежние package.json и boostrap-файл). Получилась версия 2.0.0. Затем то же самое проделал на GPT-5.4, low reasoning - версия 3.0.0.
Промпт для перегенерации исходников
Удали все файлы из каталогов src, test. Подними в package.json версию до 3.0.0. Ознакомься с документами контекста (./ctx/). Посмотри, как запускается приложение. Создай интеграционные тесты для продукта (ctx/spec/code/platform/teqfw/quality/testing/overview.md). После этого создай полнофункциональный код продукта (согласно правилам платформы TeqFW), проверь по интеграционным тестам. Проверь код в src/ через скилл teq-esm-validator. Исправь найденные ошибки и снова проверь по интеграционным тестам. Собери юнит-тесты для проверки исходников (ctx/spec/code/platform/teqfw/quality/testing/unit.md). Обнови README.md с учётом, что это третья версия приложения, созданная агентом Codex GPT-5.4 на reasoning-уровне Low. Не надо поднимать прошлую реализацию из git-истории. Проектируй с нуля. В этом смысл этой итерации.
Вот сводка по созданным исходникам, сделанная агентом:
Версия |
Файлы в src |
Каталоги в src |
Строк всего |
Код |
Комментарии |
Пустые |
|---|---|---|---|---|---|---|
1.0.0 |
23 |
9 |
1546 |
983 |
404 |
159 |
2.0.0 |
18 |
10 |
1436 |
844 |
462 |
130 |
3.0.0 |
20 |
10 |
993 |
665 |
274 |
54 |
Можно зайти по ссылкам и посмотреть на получившийся код - он не идентичен. Можно установить любую из версий, получить токен аутентификации со Spotify и создать плейлисты - работает одинаково.
Замечания
У меня ушло довольно много времени (месяцы) на создание спецификаций для моего стиля разработки (./ctx/spec/code/platform/teqfw/) и я всё ещё продолжаю развитие этой документации. Но это часть контекста, переиспользуемая между всеми моими проектами. И мне потребовалось пару часов на описание продукта (создание документов в пространстве ./ctx/docs/). Но на генерацию тестов и кода каждой из версий у агента ушло в районе 10 минут. И что интересно, вне зависимости от reasoning-уровня у меня ушло порядка 4% недельной квоты от plus-подписки на ChatGPT на генерацию каждой из версий.
Все три версии затупили с созданием плейлиста в Spotify. Dry-запуск они проходили и треки искались, но при попытке добавления треков в плейлист все три раза агент использовал устаревший API и приходилось ему каждый раз указывать на эту ошибку. Если бы я не старался делать более-менее чистый эксперимент, я бы внёс в когнитивный контекст требование использовать новый API от Spotify, но я специально выполнял генерацию кода на одном и том же контексте. Так что помимо детерминированности результирующего функционала также проявилась и детерминированность ошибок прочтения контекста агентом.
Третья версия, которая делалась low-reasoning агентом, не справилась с запуском веб-сервера. Вернее, справилась - веб-сервер стартовал, но приложение сразу же его глушило, не дожидаясь получения токена аутентификации от Spotify. На уровнях high & medium такой проблемы не возникло.
Для понимания соотношения объёма документов контекста (ctx) к результирующему коду (см. таблицу выше):
Файлы в ctx |
Каталоги в ctx |
Строк всего |
Пустых |
|---|---|---|---|
53 |
27 |
5378 |
1869 |
Что касается объёма в байтах, то сводка такая:
Файлы в ctx |
src v1 (high) |
src v2 (medium) |
src v3 (low) |
|---|---|---|---|
152Kb |
48Kb |
42Kb |
36Kb |
Да, это моя осознанная позиция: документы контекста по объёму должны быть в разы больше результирующего кода.
Скиллы
Отдельно нужно выделить скиллы. Моя платформа использует позднее связывание исходников в момент выполнения. Все зависимости внедряются через конструктор. А это значит, что во всех файлах из каталога ./src/ нет статических импортов. Ни одного. Это довольно нетрадиционный подход к JS-кодированию и агенты очень плохо в него умеют.
Когда я столкнулся с упорным желанием агентов создавать классический исходный код (с ранним связыванием кода при помощи статических импортов), мне пришлось сделать свой скилл - teq-esm-validator. Его, кстати, тоже делал Codex-агент по той же методологии ADSM. После этого было достаточно в промпте указать, что нужно использовать этот скилл для проверки исходников, и проблема со связыванием очень сильно уменьшилась. По крайней мере, в этом проекте с плейлистом в Spotify она не возникла ни разу.
Заключение
Я сравниваю поведение LLM-агентов при генерации кода с поведением дождевой воды, которая следуя изгибам рельефа, собирается в струйки, в ручьи, в реки и стремится к океану. Так же и агент генерирует код - следует по пути наименьшего сопротивления. Документы контекста в этой аналогии играют роль плотин и каналов, а скиллы и тесты я бы сравнил с насосами, забрасывающими воду на другой уровень (шлюзование). Оттуда вода опять может течь вниз, но уже по другому пути.
Основные затраты в таком подходе - это инфраструктура (те самые плотины, каналы, шлюзы). Но зато потом, после создания этой инфраструктуры, вода в большинстве случаев попадёт туда, куда было задумано строителями. Код в моём представлении - это не конечный артефакт, а производный. Результат взаимодействия когнитивного контекста и агента.
Именно исходя из этих соображений я и считаю, что контекст проекта (те самые 53 файла в ./ctx/), важнее самого кода (18-23 файла в ./src/). Ведь когда у тебя есть контекст, агент тебе сделает нужный код в течение минут. Даже такой экзотический, как TeqFW.
Вы можете свободно изучать код всех трёх версий - он дешёвый. Но если вы хотите увидеть контекст проекта - стучите в личку. Я дам контекст бесплатно, в обмен на обратную связь о возможности применимости данного подхода в ваших проектах.
P.S.
И немножко прекрасного. ИИ-агенты спокойно вытягивают "бойлерплейт" и делают ненужными множественные зависимости в ./node_modules/:
Им ничего не стоит захардкодить Web API и перехардкодить его в случае изменений. В моём приложении всего две зависимости для режима runtime (мои собственные библиотеки) и ещё две зависимости для dev-режима (разрешение типов Node.js).
Комментарии (34)
Aggle
15.04.2026 16:09"Talk is cheap. Show me the code."
Напомнило: "И не надо рассказывать, как всё было на самом деле. Просто дайте документы." (c) Better Call Saul.
werevolff
15.04.2026 16:09Проблема ИИ не только в детерминизме.
Детерминизм требуется от таких сущностей как модели, схемы, репозитории, АПИ спецификации. В них мы не допускаем творческого подхода.
Далее, отношение к кодингу как к творческому процессу - наивное. Это не творческий процесс, а научный. Код можно писать, применяя математический подход (например, DP), либо, научный подход (SOLID, GRASP). Художникам на рынке IT нет места.
Далее, нужно различать кодинг и программирование. ИИ неплохо справляется с кодингом, но совершенно не справляется с программированием. Собственно, в этом и есть основная претензия к вайб-кодерам и прочим ИИ-покемонам: они не могут отличить разработку ПО от кодинга. Даже вашу статью читаешь, и не понимаешь: нет ни алгоритма, ни описания используемых паттернов, ни дизайна приложения. Есть компоновка, и на том спасибо. Есть позднее связывание как паттерн интеграции - уже хорошо - это прям выгодно отличает вашу статью от прочих подобных. Но всё опять сводится к тому, что человек навайбкодил много кода и впал от этого в экстаз. И это уже надоело, если честно.
Когда я был совсем молодым разработчиком и пилил какие-то статьи для Хабра, моего опыта тоже не хватало, чтобы расписать дизайн и архитектуру, сделать упор на паттерны проектирования. Но я, хотя бы, писал код руками. То есть, я самостоятельно сталкивался с такими вещами как «приёмка работ», «code-review», «приёмочное тестирование», «сопровождаемость», «изменяемость». А сегодняшний вайб-кодер будто не знает этих вещей. Будто он никогда не работал. Словно над ним никогда не было ведущего разработчика, который принимал на себя ответственность за приёмку работ. А ведь процессы почти везде одинаковые.
Вот, например, вы говорите о детерминизме. А что насчёт сопровождаемости? Изменяемости? Вот у вас есть приложение. Допустим, вы хотите сделать его коммерческим. Вы проводите масштабирование, и получаете:
Приложение может теперь работать не только со Spotify, но и с другими агрегаторами музыки (YouTube, Яндекс, Apple).
Пользователь имеет интерфейс, через который он настраивает около 15 параметров: размер плейлиста, возрастные ограничения, популярность треков и их рейтинг на разных участках плейлиста, блэклист песен и исполнителей, ограничения каверов и т.д..
Приложение имеет несколько форматов выгрузки плейлиста.
И вот, вы сделали масштабирование системы, чтобы она смогла охватить больше задач, и чтобы ею могли пользоваться разные люди, а не только ваша семья. И вы использовали ИИ для полной кодогенерации решения. Итак, вам необходимо добавить ещё три параметра фильтрации:
Настроение трека
Темп треков (от и до)
Сингл или альбомная версия трека
При этом, допустим, настроение трека есть в Яндексе и Apple, но нет в Spotify. Темп трека можно реализовать за счёт анализа трека внутри приложения. Сингл или альбомную версию можно определить через поиск.
Итак, как вы думаете, при каких условиях эта задача не вызовет переписывание большого объёма кода?
Evgenii-Lopatin
15.04.2026 16:09А есть ли существенная разница, если переписывание займет еще 10 минут х n (задач) работы нейронки? Взять Claude opus - нормально поставить ему задачу и он справится, не сломав.
Добавить в начале работы немного мороки с авто-документированием и нормальным ТЗ. Выполнять работы итеративно (что можно прописать одной строчкой при обсуждении плана на старте). Ключевые решения, которые придется отдавать на откуп нейронке - вынести на консилиум для перекрестного обсуждения несколькими агентами (желательно разные семейства, но и ролевые модели подойдут) для сбора консолидированного мнения.
И готово, проблема если не решена полностью, то купирована. Вполне рабочий продукт на выходе.
werevolff
15.04.2026 16:09Здесь проблема в том, что «он справится, не сломав» - это вопрос веры. Статистика багов в ИИ коде говорит об обратном: он ломает. А ещё попозже должна подъехать статистика по инцидентам.
Почему он ломает? Потому, что так устроен. Как правило, в коммерческом продукте очень много функциональных и не функциональных требований, а также, множество компромиссов. Код с высокой связанностью, написанный без учётов компромиссов, невозможно не сломать даже если он писался человеком. А ИИ, в принципе, не заморачивается соблюдением всех требований и поиском компромиссов. Он - машинка. У него диодики.
flancer Автор
15.04.2026 16:09Хороший коммент. В суть. Но, наверное, я плохо её изложил, раз у вас возник такой вопрос. Вот скриншот из публикации, чтобы быть предметнее:
Я выложил (опубличил) в npm только код - результат генерации. Но я не выложил "инфраструктуру" - документы (спецификации) которые и позволяют генерировать этот код, разный по содержанию, но одинаковый по функционалу. "Инфраструктура" лежит в приватном репо.
На все ваши вопросы про сопровождаемость, изменяемость, масштабирование, по большому счёту, ответ один - документы контекста. Просто заменив часть спецификаций вы можете получить этот же функционал на другом ЯП (python, php, java, ...) или в другом фреймворке.
Документы контекста очень хорошо удерживают процесс эволюции приложения. Именно об этом и публикация. Моя мысль - главная ценность в ИИ-разработке не код, а спецификации. Проектная документация. У кого она есть, тот и код задёшево сгенерировать сможет. Впрочем, у человеков так же: код без документации - "тяжёлое наследие прошлого"
А вайбкодинг - это ваншот. Вот что сгенерировалось агентом в пределах его контекста, то и вот.
Далее, отношение к кодингу как к творческому процессу - наивное.
Пусть так. Я просто иногда вижу красоту в коде. А создание красоты - процесс творчества.
Итак, как вы думаете, при каких условиях эта задача не вызовет переписывание большого объёма кода?
А вот это не проблема. Код дешёвый, можно переписать хоть весь. В примере к этой публикации я всё снёс и переписал дважды. Вернее, это сделал Codex-агент - за 4% от недельной квоты 20-евровой подписки на ChatGPT Plus. В деньгах это обошлось примерно где-то в 20 центов. И это вместе с тестами.
werevolff
15.04.2026 16:09Можно переписать весь код. Но, как вы говорили выше, есть проблема детерминизма. Чем больше вы перепишете, тем дольше тестирование, тем дольше доставка в прод. Тем выше риски потери данных или требований.
flancer Автор
15.04.2026 16:09Всё верно. Но только чем это отличается от ситуации с "кожаными разработчиками"? Там тоже есть те же самые проблемы, которые решаются обычными, знакомыми всем методами - соглашения, архитектура, ревью, тесты.
В данном примере я специально попросил агента переписать весь код и все тесты. То есть, по факту, всё приложение. Но это крайне необычный случай. Обычно собирают требования, пишут спецификации, определяют критерии соответствия этим спецификациям, автоматизируют проверку соответствия, потом пишут код, удовлетворяющий критериям соответствия спецификациям этих требований. А затем повторяют все эти шаги итерационно - наращивают функционал, опираясь на существующую базу, по спирали. По ходу получая обратную связь от пользователей прода.
Вопрос в том, где и на каких позициях в этой производственной цепочке находятся люди, а где - агенты. По большому счёту - вопрос баланса тех и этих. А риски потери данных и требований существуют и в полностью "кожаных" производственных цепочках. Яркий пример - Schiaparelli, марсианский зонд, который разбился из-за ошибки ПО.
Где-то риски допускают большее присутствие "силиконовых", где-то меньшее.
werevolff
15.04.2026 16:09Не скажите: разница есть.
Сроки доставки в прод. Переписывание с нуля, во-первых, увеличивает сроки тестирования, во-вторых, создаёт дополнительные расходы на тестирование и ревью. Здесь надо смотреть: можно ли уменьшать T2M и автоматизировать все этапы проверки? Пока что, ответы не в пользу ИИ.
Сопутствующие расходы. Пока проект маленький, переписать его с нуля - дёшево. А что если это большой проект, и нам на каждое изменение надо его переписывать с нуля? Это же и токены тратятся, и время QA, и время проверяющего инженера. Если декомпозировать проект на относительно независимые микросервисы, станет дороже размещение (MSA чаще требует больших расходов). Плюс, сейчас ИИ работает в убыток: финансовая аналитика компаний-владельцев ИИ показывает отрицательный рост доходов. То есть, токены продаются сильно дешевле себестоимости.
Ответственность и страховка. Если некая компания предоставила некачественное ПО, из-за которого произошла трагедия, она оплатит ущерб. Человек, допустивший критическую ошибку, также, возместит ущерб. Кто ответит за код, написанный ИИ?
В настоящий момент времени, ИИ предлагает более быстрое написание больших объёмов кода. Но кодинг - это только небольшая часть процесса. Есть ещё проектирование и анализ, приём работ, разные варианты тестирования, доставка и интеграция кода (Delivery and Integration). И эти процессы не всегда автоматизируются из-за критичности узких мест. Большой объём кода может замедлять последующие процессы и влиять на T2M. Я повторюсь: вы в вашей статье поднимаете важный вопрос проектирования системы, но, учитывая область её использования, у вас нет последующих этапов, и вы не можете оценить их. И эта проблема характерна, наверное, для 99% статей об использовании ИИ на Хабре. Они сводятся к тому, что человек видит объём работающего кода, и ему кажется, что ИИ может заменить целую команду разработки. Но нет реальных метрик T2M, ошибок и инцидентов, сопровождаемости.
flancer Автор
15.04.2026 16:09Вы во многом правы. Я уверен, что нельзя, на данный момент, сделать всю эту производственную цепочку полностью, на 100%, автоматической. Весь вопрос в том, какие из участков этой цепочки и в каких случаях насколько можно автоматизировать. Для каждого программного продукта это будет своё собственное значение.
Мой опыт показывает, что в веб-приложениях процент автоматизации может быть достаточно высокий. Вплоть до автоматической обработки баг-репортов от конечных пользователей с автоматической выкаткой фиксов на прод (с учётом возможности промпт-инъекций и всего сопутствующего веселья). Этого пока нет, но я к этому стремлюсь. Получится или нет - посмотрим.
difhel
15.04.2026 16:09Спасибо за статью. У меня возникло два вопроса:
Зачем использовать позднее связывание, если, как вы говорите, нейронки в это не умеют без дополнительных настроек? Понимаю, что хочется иметь свой личный стиль во всех проектах, но в эпоху ИИ как минимум имеет смысл ревьюить свой стиль кода на наличие паттернов, которые на ровном месте ухудшают эффективность ИИ (больший шанс, что нейронка налажает в этом коде, так как такого кода нет/мало в данных обучения модели; больше токенов на то, чтобы прочитать скилл и держать его в контексте, что тоже влияет на дороговизну разработки и на качество, если контекст у вас забит не реально нужными знаниями о проекте, а формальностями, которые можно опустить).
Вы пишите, что размер спецификаций у вас превышает размер кода в несколько раз, и это ожидаемое поведение. Почему вы так считаете? Как будто весь смысл в том, что снижается сложность реализации проектов с нуля, что достаточно написать относительно короткую спеку, а нейронка ее заимплементит, вместо того, чтобы самому писать десятки тысяч строк кода. Возможно, проблема в том, что спека у вас тоже сгенерирована ИИ и поэтому она размытая и такая большая.
flancer Автор
15.04.2026 16:09Спасибо за вопросы.
1) Нейронки умеют в позднее связывание, только не в JS и не в том виде, как это у меня сделано. Я в таком виде программировал долгое время на Java & PHP - там это норм (в том числе и для ИИ). Естественно, что я не хочу терять свои "инвестиции времени" и применяю привычный мне стиль кодирования и при смене ЯП :) У позднего связывания есть свои плюсы. Самый явный - прямое внедрение моков при юнит-тестировании (это уже явный плюс и для ИИ).
Я считаю, что код в том виде, что у меня получается, в конечном счёте удобен для ИИ. Ведь, в конце-концов, я отказался от своего стиля и принял предложенный ChatGPT формат. Ну а проектные соглашения всё равно нужны в разработке и агенты всё равно "жрут токены" при проверке соответствия результата генерации этим соглашениям.
2) Я осознанно сравнил поведение агента при генерации кода с дождевой водой - она стекает в океан с учётом рельефа (общими знаниями, что в модель заложили при обучении). Если вам всё равно, куда будет течь вода (как Карпаты, когда он впервые повайбкодил), то вы точно достигнете своей цели ("нас невозможно сбить с пути - нам всё равно, куда идти!"). Если ваши цели незначительно отличаются от обычно принятых (заложенных при обучении), то вам нужно лишь слегка скорректировать своими спецификациями поведение модели при генерации кода. Ну а если вы хотите, чтобы получился результат, который будет значительно отличаться от того, к чему модель привыкла (заложено при обучении) - вам придётся очень сильно "изменить рельеф" дополнительными спецификациями.
Я не хочу, чтобы "вода текла вниз к океану", я хочу, чтобы она "текла" туда, куда мне надо.
Triton5
В смысле, "код ничего не стоит"?! Вы видели цены на OpenAI: o1-pro ? :)
flancer Автор
На эту тему даже анекдот есть :)
У меня подписка GPT Plus за 20 евро. Мне норм.
akod67
Её хватает менее, чем на час активной работы =)
flancer Автор
Вы не могли бы показать код, который вы получаете за "час активной работы"?
Sobakaa
Судя по минусам в приличном обществе показывать код не принято. Джентльменам верят на слово.
akod67
Вы не согласны с приведённым фактом по реальным лимитам? Или вам надо мне доказать, что получаемый результат - Г? Со вторым можете не утруждаться, мне виднее, устраивает меня результат или нет.
flancer Автор
Смотрите, я беру по минимуму. При генерации кода (с правками и публикацией) у меня уходило примерно по 4% от недельного лимита. Это точно больше 10 минут чистого времени работы Codex-агента в режиме плагина для VSCode. Я визуально фиксировал 9 минут с чем-то при генерации кода, а это только один из шагов, пусть и самый длинный, на что ушли эти 4%. За это время агент нагенерировал 1-1.5К строк кода (с комментариями и пропусками). Тесты и спеки я не учитываю.
100% / 4% = 25 раз по 10 минут. Это 250 минут. Чистого времени работы агента за одну неделю. За месяц (4 недели) получается 1000 минут это 16 с лишним часов.
Допустим, вы запускаете своего агента в 16 потоков (раз вам не хватает этого объёма на час работы). Он должен нагенерировать за это время огромную кучу кода. Пусть и говнокода, но работающего хоть как-то и хоть как-то соответствующего поставленной задаче.
Просто любопытно взглянуть на эту кучу.
akod67
Я сижу на Клоде на подписке 100 евро (5x). Но последние несколько недель субъективно - лимиты стали раза в 2-3 меньше, наверное они из-за крабов стали подрезать всех. Купил кодекс за 20ку. Мне его хватило ровно на 40 минут. Вот как раз сегодня проапгрейдил его до 5x. И теперь могу сравнивать на одном и том же проекте их обоих. Кодекса реально хватает в разы дольше. При этом, опять же субъективно, как минимум он не “глупее”. Порой вообще искрит творчеством, Клод в этом плане поскромнее =)
А сожрать лимиты совсем несложно - я сейчас перегоняю старый легаси на современное, а это флоу - ресёрч конкретной фичи, написание спеки, имплементация, сравнение и так несколько итераций до получения 1:1. И это в 2-3 окна, бОльше я не тяну по когнитивной нагрузке =)
flancer Автор
Трансформировать легаси в современный код - это боль. Там можно токены сжигать в галлактических масштабах и с минимальным участием человека. Особенно на большой кодовой базе.
Но у меня генерация и развитие кода с чистого листа. Тут и участие человека поболе будет, и токены используются в более контролируемом режиме. Так что 16 часов работы Codex'а в месяц - этого мне вполне хватает на разработку 4-5 npm-пакетов.
akod67
Я с нуля вайбю кой что под себя, там да, опять же, по ощущениям, лимитов хватает раза в 2-3 дольше, чем конверсия существующего. Просто потому, что дольше думаешь. Но там другая беда - быстро входишь во вкус и начинаешь плодить фичи опять же в несколько окон, не шибко следя за контекстом и наступаешь на те же грабли с лимитами. В общем придерживаюсь начального утверждения - 20 баксов - это ни о чём, для ознакомления =)
flancer Автор
Это не 20 баксов - это 16 часов работы агента :)
Я, например, неделю обсуждал с ChatGPT спецификации для моей библиотеки в md-формате. Отвечал на вопросы, задавал ограничения, добивался согласованности и компактности контекста. За те же "20 баксов", но не агентом, а в чате. Да, пришлось вручную формировать документацию в проекте, перенося md-код между чатом и репозиторием. Зато потом, по готовому контексту, агент мне в течение менее получаса создал работающий код в ./src2/. А это значит, что он может порядка 32 таких библиотек за месяц нагенерить. Правда сам я не успеваю согласовывать более 4 контекстов (по одному в неделю). Сейчас уже чуть быстрее стало, но всё равно торможу.
Так что я пока даже свои лимиты не выбрал ни разу. А у меня ещё у жены, сестры и сына по GPT Plus учётке с неиспользуемыми лимитами для Codex'а. Есть куда расти :)
akod67
Да, спеки конечно лучше изначально как можно детальне прорабатывать. Потом дольше рефакторить ЛЛМом. Но подсаживаешься на быстрый дофамин от быстрого получения результатов и промпты становятся всё короче, а контекст - всё жирнее =) Но своя польза от этого тоже есть. Чем быстрее результат - тем быстрее понимание, куда на самом деле надо двигаться. А переписать нынче всё с нуля не так долго, когда вот такая “легаси” основа есть. Подноси бабло на токены только…
codecity
Так для кода - это не обязательно, можно за $10 взять Copilot и там запаса хватит как минимум на генерацию 10 тыс. + строк кода средней паршивости.
Сгенерить код можно, не вопрос. Будет даже решать какую-то задачи. Только нафиг это кому-то нужно то? Попробуйте найти задачу, которую еще не решили и которую действительно нужно решать, за которую люди будут готовы платить (а не просто юзать на халяву - так не честно - вы тратите время, деньги, силы - а другие просто юзают бесплатно). И даже если найдете задачу, создадите решение - как монетизировать? Как защитить от того, что Вася сгенерит что-то подобное по вашему образцу?
BlackSCORPION
Брать пример с китайцев. Конкуренция в Китае таких масштабов, что придумать что то и почивать на лаврах не вариант.
Я как то купил квадрокоптер с камерой за 7$. И он даже летает. И камера работает. Конечно тут нет магии, это одноразовая игрушка для детей. Но интересное тут в том что разобрав такой дрон, понимаешь что при цене 7$ на нем зарабатывает цепочка людей, от производителя до реселлеров, включая доставку, растаможку итд.
Это не подвальное производство, это качественный пластик но тонкий как бумага, это продуманный дизайн чтобы этот тонкий пластик сохранял форму, какое то серьёзное оборудование которое обеспечивает высокую точность штамповки чтобы это все без проблем собирать и иметь приятный внешний вид (похож на мавик мини, складывается). Это кастомные чипы все в одном чтобы экономить на обвязке электроники.
Победить такого производителя думаю невозможно, потому что его бизнес модель не в идее, она в оптимизации производства. Ты можешь скопировать его игрушку, но удачи производить ее хотя бы так же дёшево))
codecity
Такой подход - делает всех несчастными. Поясняю.
Работодатель играет на жадности - как бы психология - человек ищет чем дешевле, но лишь бы выполняло функцию. И для этого человека они работают. Значит и работникам нужно платить чем меньше денег, чтобы итоговая сумма была ниже. И качество нужно как можно ниже, но чтобы летало.
Все основано на грехе жадности.
Покупатель купил - насладился что дешево, что как бы сэкономил. Но на этом наслаждения заканчиваются. Он не купил вещь - а купил почти мусор. Оно быстро сломается. Оно не принесет длительного удовлетворения как надежный инструмент.
Так же и работники - они несчастны, т.к. их использовали на полную катушку - но заплатили самый минимум.
Получается такой подход всех делает несчастными и единственное наслаждение - за счет греха жадности.
PereslavlFoto
Единственное наслаждение — за счёт того, что вы можете купить такую вещь. Можете позволить себе.
Конечно, хорошо бы оно не быстро ломалось. Хорошо бы оно работало долго. Хорошо бы оно было надёжным. Хорошо бы качество повыше.
Но тогда — не хватит денег на покупку.
codecity
Но оно знаете как. Вы то хотите не просто купить вещь для галочки - а решать задачу жизненную. И по итогу оно сломалось очень быстро и задачу вы решать не можете. Фактически это был обман, т.е. думая что купили и смогли себе позволить - на самом деле выкинули деньги в мусорный бак. И более того - еще и нанесли вред Природе (больше мусора), заставили других людей страдать (чтобы они вложили все силы и работали за копейки от безвыходности).
PereslavlFoto
С одной стороны, сломалось и задачу не решили.
С другой стороны, на другие решения нет денег.
codecity
Ну деньги то можно накопить, вопрос времени. Если не размениваться на мусор, не работать за копейки.
PereslavlFoto
Вы уже сорок лет работаете в сельской библиотеке. Вы решили не размениваться на мусор. Куда вы перейдёте работать с вашим дипломом библиотекаря?
AlekseyPraskovin
Варианта, где нужна одноразка, а не надежный инструмент вы не представляете?
TimsTims
Поздравляю, вы открыли капитализм и механику невидимой руки рынка. Только вы ушли немного в другую историю, будто у такой формы нет будущего.
На самом деле пользователь может и купит мусор за $7, но если ему нужно нормальное качество и чтобы не ломалось, то это будет стоить все $500.
И у работодателей тоже также: пока есть те, кто готов за $1 работать целый день - от будет нанимать тех, кто будет работать за $1. И дело здесь не в том, что работодатель такая гнида, а в том, что у его есть конкуренты, у которых работают китайцы с зарплатой $1. Если ты будешь платить своим по $1,5 значит твои дроны будут дороже чем у конкурентов, и на большой партии выберут не тебя. У тебя перестанут поступать заказы, придется со временем закрывать фабрику.