Как я перестал относиться к ИИ как к человеку: опыт соло-разработки двух пет-проектов

Всем привет! Меня зовут Андрей. Я продакт с опытом запуска продуктов с нуля: в банке сначала занимался цифровыми финансовыми активами, а теперь — цифровым рублём. Но здесь я не буду рассказывать про корпорации. Расскажу про моё хобби — соло-разработку с ИИ, как в свободное время пытался сделать несколько своих собственных продуктов с помощью LLM, и что из этого вышло.

Если вы тоже пробовали «вайб-кодить», сжигали тонны денег на подписки, получали много вроде бы почти готового кода, который потом не могли довести до прода, — эта статья для вас. Я не буду говорить, что ИИ — это плохо, так как считаю, что ИИ — это очень сильный инструмент. Но топором махать умеючи надо: а то вместо того, чтоб дом срубить, да дров нарубить, оттяпаешь себе палец.

Я давно в теме и уже писал на Хабре про то, как мы делали техдокументацию для ЦФА с нейронкой. Но тогда это была командная работа, а сейчас я хочу рассказать про то, что происходит, когда ты один, у тебя есть LLM, и ты пытаешься сделать продукт. Есть ненулевая вероятность, что корпоративная разработка перестроится, и то, что сейчас десятки или сотни специалистов делают долго и дорого, с ИИ можно делать иначе. Может быть эффективнее. Может быть нет. Вот про это и расскажу.

Эйфория

Когда про вайбкодинг кричали с каждого утюга и умного чайника, для погружения в соло-разработку я решил попробовать Codex. Но бесплатный пробный тариф закончился раньше, чем я успел что-либо понять. Попытка купить подписку не увенчалась успехом: санкции, блокировки, сомнительные способы оплаты и прочее.

Но не в наших правилах сдаваться, так что аналог, доступный в РФ, был найден. Выглядело похоже. Поигрался с пробником и купил подписку Pro на год. Решил сделать сайт с аналитикой по цифровым финансовым активам, так как был в теме, а об удобном едином источнике развёрнутых данных по всему рынку не знал. Парсинг открытых источников, удобная инфографика, актуальная информация по всему рынку в одном месте — казалось бы, ресурс будет полезен для потенциальных инвесторов.

Это была первая попытка решить с ИИ более или менее большую задачу и я вёл себя как с командой людей: иногда обсуждал с ИИ абстрактные темы, шутил, приводил неочевидные примеры, — создавал «атмосферу». Выстраивал производственные процессы, определял DOR и DOD, придавал виртуальной команде не только профессиональные черты, но и персональные характеры и, конечно, имена. Устраивал мозговые штурмы, груминги с рассмотрением с разных точек зрения и спорами как внутри, так и с привлечением внешних экспертов в виде других LLM.

Мне казалось, что это помогает — как с людьми. Казалось, что это создаёт инновационный фон, в котором работа идёт лучше и в спорах рождается истина. Со стороны, видимо, это смотрелось странно, очень напоминало игру в стратегию с элементами РПГ. А может и шизофрению, когда тихо сам с собой ведёшь беседу и радуешься завязавшемуся спору, как ребёнок новой игрушке.

Это была эйфория. Виртуальная команда почти сама что-то уверенно делала, искала информацию, проверяла гипотезы, сама уточняла цели, нарезала задачи, проектировала, грумила и, конечно, меняла файлы проекта, наращивая код и инфраструктуру. Проект быстро обрастал «мясом» и казалось, что доделать остаётся совсем немного — ну, пара итераций, и всё будет готово. Чутьё подсказывало: скоро будет прорыв. Знакомая картина?

Но прорыва не было. Я промучался пару месяцев и забросил. А если быть честнее — еле-еле заставил себя дотолкать хоть что-то до прода уже чисто из принципа.

Через несколько месяцев я с трудом опубликовал хоть как-то работающий сайт, убрав оттуда все наполеоновские планы и грандиозные перспективы развития. Динамический парсинг, регулярное обновление данных, дриллинг по данным, по собранной наполовину вручную базе — всё это исчезло. Сайт стал статичным, который просто открывается и не вызывает у пользователя истерику.

Я тогда пока не осознал проблему. Я просто настолько устал добиваться простого полезного инкремента в почти готовый продукт, что больше попыток повторить такой опыт ещё пока не делал.

Осознание пришло позже.

ИИ — не команда людей

Когда я начал работать с ИИ, то делал это так, как привык с людьми: обсуждал с ним идеи, шутил, приводил примеры из жизни, строил «команду». Мне казалось, что это создаёт контекст, в котором работа идёт лучше. Как с командой: если людям комфортно, они работают продуктивнее.

Кажется естественным, что я антропоморфизировал LLM. В конце концов, она все-таки разговаривает. К тому же научная фантастика научила меня ожидать, что говорящие компьютеры будут разговаривать как люди и с ними можно даже шутить (конечно, если это не HAL 9000).

На LLM этот принцип работает с точностью до наоборот.

Каждое слово, которое я писал в чат, — притча или шутка, любое абстрактное рассуждение, пример «из жизни» — всё это оседало в контекстном окне. Но модель не «понимала» юмор и не «вдохновлялась бирюзой», как бы мне ни хотелось, а просто учитывала всё как данные. А когда я потом просил поправить одну функцию, как-то неожиданно выстреливала не та информация и модель начинала переписывать архитектуру — потому что в контексте было полно «второстепенных» сигналов, которые она считала такими же важными, как задачи, ведущие к основной цели.

Шутка стреляла. Но не там, где я хотел.

В остальном общение так похоже на человеческое, что невольно всплывают в голове проверенные подходы и ловишь себя на мысли, что пишешь в ИИ «пожалуйста».

Это называется забивание контекста. Это не баг, а фича архитектуры LLM.

Мы, люди, умеем фильтровать: на совещании можем пошутить, обсудить посторонние темы, отпуск и хорошую погоду, а потом вернуться к делу — и в голове у нас останется суть, а не весь шум. А LLM так не умеет: для неё всё, что попало в контекст, одинаково значимо, пока не доказано обратное. Когда контекст переполняется, модель начинает «плыть»: путаться, противоречить себе, забывать, зачем мы вообще начали.

Я потом посмотрел статистику в личном кабинете. У одного из запросов на вход было 39 650 токенов, а на выход — 103 токена. Вдумайтесь: 99,7% входных токенов — это то, что модель перечитывала, чтобы сгенерировать 103 токена ответа. И это только один запрос. А если таких запросов 20–30 до первого полезного инкремента? Контекст растёт лавинообразно, и каждый следующий запрос стоит дороже, а качество падает.

Есть исследования, которые это подтверждают. В работе «Structured Session Management for LLM-Augmented Software Development» (Zenodo, 2026, DOI: 10.5281/zenodo.19410828) вводится понятие «session entropy» — накопление противоречий и потерь контекста в длинных сессиях. Исследование, «Output-Maximizing Long-Context Programming» (Zenodo, 2026), прямо критикует итеративные воркфлоу и предлагает генерировать большие артефакты за один проход, вместо того чтобы дробить работу на мелкие шаги.

Сейчас будет важная мысль: Agile и MVP — это костыли под человеческие ограничения. Человек не может долго держать фокус, ему нужны короткие итерации и обратная связь. LLM этих ограничений не имеет — но имеет своё: контекстное окно. И когда мы применяем к ИИ человеческие практики, мы не помогаем ему, а забиваем ему голову мусором.

К примеру, ИИ по умолчанию склонен делать заглушки. «Вот тут пока заглушку, потом доделаем, вот тут заготовку на будущее». В разработке с людьми это признак того, что команда понимает, что делает, и легко возвращается к задаче, когда приходит время. Съесть слона по кускам — это так понятно и привычно. С ИИ это уводит в дебри и в итоге ломает всё.

Почему так? Потому что LLM обучали на «лучших практиках». А для разработки цифровых продуктов сейчас — это Agile, Scrum, итеративная разработка, MVP — всё то, что создано для людей. Есть, конечно, и ортодоксы, но это больше связано с бюджетами и годовыми планами, и количество таких практик в датасетах для обучения сильно меньше. В обучающих данных большинство примеров и практик, подходящих для команд людей, и они находятся ближе к центру распределения вероятностей. Модель выдаёт то, что наиболее одобряемо, — типовое, безопасное, «среднее». Она не «понимает», что работает с другим исполнителем. Она делает то, что делали бы люди, и так, как они бы обычно делали.

Но модель — не человек, и через несколько итераций она легко забывает, зачем была заглушка. Или путается. Или решает «улучшить» заглушку, ломая то, что уже работало.

Теперь я почти не даю делать заглушки, с ИИ это только усложняет достижение цели. Сразу делаем достаточный для использования продукт, тем более ИИ не осторожничает и может сразу выдавать крутейшие решения, к которым команда людей пришла бы далеко не сразу. Да, это дольше на старте. Но количество итераций сокращается, и контекст не забивается мусором.

Пример. Когда я делал торгового бота, после получения рабочего продукта я захотел улучшить интерфейс: сделать фон контрастнее, выровнять иконки, поправить текст. Простая задача, правда? Я в системном промпте попросил сделать именно это, а модель, не сделав простые изменения там, где надо, по-тихому внесла много изменений совсем в других местах, и я обнаружил это далеко не сразу, а потом, чтобы восстановить работоспособность, пришлось откатывать и терять в том числе множество полезных изменений. На основе недоделанных предложений и второстепенных, по моему мнению, обсуждений из прошлых итераций она переписала архитектуру и ключевую логику — и всё развалилось.

Если бы я сразу продумал интерфейс и зафиксировал в ТЗ, не пришлось бы итеративно доводить его до ума с риском порушить ранее выстраданное. И косметика не привела бы к переделкам там, где уже всё работало и меня устраивало.

Кстати, в Китае это, кажется, понимают лучше. Пока на Западе два лагеря спорят, что делать — хоронить Agile или адаптировать, — китайские команды просто делают и перестраивают процесс под инструмент. Подход называется AI-native процесс разработки, если что. Прагматично.

Метод тыка

После наступившего разочарования я забросил разработку. Подписка осталась, но я перестал туда заходить. Казалось, что это не для меня: слишком сложно, слишком дорого, слишком непредсказуемо.

А потом совершенно случайно нащупал другой подход, когда просто проверял, как работает API. Открыл чат с LLM, попросил вывести команды для диагностики через терминал. Сам понимал их с трудом, но по инструкции копировал и выполнял. Ответы, включая множество неудачных, я возвращал обратно в чат и получал новые инструкции. Так как многие данные у ИИ или не совсем актуальны для разработки в РФ, особенно в части блокировок ранее обычно просто доступных библиотек и сервисов, то итераций с терминалом было очень много, но зато не нужно собирать исходный код и получать ошибку только после сборки.

С терминалом мне понравилось куда больше, и получалось выяснять важные детали куда быстрее. Например, бот в мессенджере — как обычно принято и как ИИ рекомендовал для продвижения — я решил всё же не делать, хотя и нашёл рабочий вариант. Шаг за шагом что-то заработало.

Потом скопировал код в блокнот, сохранил файлы, установил окружение, нужные библиотеки, и в итоге собрал продукт. По факту перешёл на разработку с чатом LLM, блокнотом и командной строкой. UAT проходил сам в браузере, иногда собирая данные из режима разработчика. И так постепенно получилось вполне рабочее расширение для браузера.

В процессе я начал замечать закономерности. Одна из них — контекст.

Неочевидное решение проблемы контекста

Когда я понял, что контекст — это главная проблема, я начал думать, как её решить. И тут мне помогла теория решения изобретательских задач. Один из её принципов: если система упирается в противоречие, ищи решение не в очевидном месте, а на периферии. Не там, где все ходят.

Очевидное решение было: «писать промпты короче». Но это не работало — контекст всё равно забивался, потому что в одном чате смешивались разные темы.

Неочевидное решение: разделить чаты. Не «один чат — одна задача», а «один чат — одна тема». Белая книга — отдельно. ТЗ — отдельно. Разработка — отдельно. Маркетинг — отдельно. И не смешивать.

Это выглядело нелогично: зачем мне три-четыре чата, если можно всё в одном? Раньше я так и делал — как с командой, где все обсуждают всё вместе. Но с ИИ это не работает. И разделение чатов оказалось тем самым неочевидным решением, которое сработало.

Дополнительный эффект: я стал точнее формулировать. Потому что перед тем, как перейти в следующий чат, я должен был вычитать результат предыдущего и понять, что именно передать. Это дисциплинирует.

Артефакты собираю в Obsidian — в Markdown-формате, чтобы всё было под рукой. Понравилось, что чат со всей историей доступен с разных устройств. Вполне можно продвигаться и со смартфона: ясно, что исходный код пересобрать неудобно, но подумать над ролями или сегментами пользователей и поискать информацию для маркетинга — вполне.

Технологическая спираль провернулась

Я не сразу понял, что мой подход — это, по сути, возврат к классической модели: сначала требования, потом проектирование, потом код, потом тестирование. Без итераций или с их минимальным количеством. Даже состав участников на этих этапах был разный, и они могли между собой особо не пересекаться. Без «давайте сделаем MVP и посмотрим, и допилим».

Вернулся обратно в чат с LLM и блокнотом не потому, что «старое — правильное». Я пришёл к этому потому, что итераций должно быть меньше — иначе контекст забивается. Контроля должно быть достаточно, чтобы принимать решения. Развитие идёт по спирали: мы возвращаемся к старым методам, но на новом уровне.

Исследования это подтверждают.

К примеру, работа «Evaluating Classical Software Process Models as Coordination Mechanisms for LLM-Based Software Generation» (arXiv:2509.13942v1, 2025) сравнила Agile, Waterfall и V-модель как способы координации для LLM. Результат: Waterfall оказался наиболее эффективным. Agile дал лучшее качество кода, но ценой более высокой вычислительной стоимости — а для соло-разработчика это твои токены и твоё время.

Другая работа, «SDAD: Spec-Driven Agentic Development for the AI-Native SDLC» (arXiv:2608.20341v1, 2026), прямо говорит о «Waterfall Resurgence» и «BDUF 2.0» (Big Design Up Front). Смысл в том, что скорость агентов не отменяет инженерную дисциплину — она перемещает её вверх по потоку, в точность спецификаций, явные gates и проверяемую provenance.

То есть я не «изобрел велосипед». Я интуитивно пришёл к тому, что другие формулируют как методологию. Просто сформулировал это как «не давать контексту забиваться».

Отдельно про ИИ-агентов.

Про них сейчас много говорят: мол, агенты всё сделают сами, надо только правильно настроить. У меня опыт в этой теме небольшой, и я не буду делать громких заявлений. Но поделюсь ощущением.

Мне кажется, что пока не разобрался с ИИ в обычном чате — лезть в агентов не только бесполезно, но даже опасно. Это как, не научившись медленно ездить с инструктором по учебной площадке, сразу влезть за руль гоночного болида или даже просто слишком резвой спортивной машины. В целом если очень хочется, то можно, и скучно не будет, но скорее выгоришь и разобьёшься, чем доберёшься до пункта назначения.

У меня был опыт с агентами, который закончился пока неудачно. В той среде, где я пробовал, всё выглядело солидно: файлы создаются, структура растёт, работы вроде бы много. Но довести до прода не получилось. И самое неприятное — было трудно понять, где именно всё пошло не так. В разработке с людьми, когда команда делает много файлов и уверенно двигается, это признак того, что процесс идёт правильно. С ИИ это может означать совсем другое: он уходит в такие дебри, что проще стереть и начать заново, чем разбираться, как так получилось.

Поэтому я для себя решил: сначала нужно научиться работать с ИИ в чате. Понять его ограничения, научиться управлять контекстом, выстроить процесс. А агенты — это следующий уровень. Доверять чьи-то жизни или даже критическую информацию, пока не разберёшься как следует, явно не стоит. Может быть, когда-нибудь, когда правила Айзека Азимова будут вшиты в корневой промпт. Но не сейчас.

Некоторые мои правила

Обычно прошу нумеровать вопросы, так, чтобы удобнее комментировать выдачу и не путаться. В системном промпте я запретил одновременно существенно продвигать разные варианты без выбора основного. Бывает, что ИИ выдаёт несколько вариантов действий. Я отвечаю по одному, не фокусируюсь на другом, и мы идём дальше. Потом дочитываю вариант два — там интересные мысли. Пишу промпт. Но вторая итерация сместила контекст.

Переделка архитектуры или корневой логики — только по прямому указанию или после предварительного согласования. Большие переделки оценивать и предварительно согласовывать. Часто после начала разработки новые идеи или серьёзные изменения требований лучше начать заново в новом контексте, чем переделывать в старом.

Сбор контекста чата для передачи в другой теперь делаю регулярно, это похоже на точки отката или передачу задачи другой команде. Иногда такой контекст закидываю в другие LLM с заданием дать конструктивную критику. Собираю разные мнения и устраиваю спор, тут главное не увлекаться слишком. Однажды даже была мысль собрать разные модели в роли советников и устраивать показательные придворные словесные дуэли, а я в роли верховного арбитра, но кажется, это уже слишком. Тема для фантазёров тут обширная, кажется, скоро продуктивные системные промпты будут вполне себе ходовым товаром.

ИИ — это очень сильный инструмент. Но не волшебная палочка. Любым мощным инструментом необходимо сначала научиться правильно пользоваться. Мы все в опасности, если проверенные рабочие подходы для людей из середины нормального распределения будут основой для датасетов для общения ИИ, и промпты не будут это учитывать.

Пока писал эту статью, случилась забавная вещь. Я работал с LLM в одном длинном чате: загружал примеры статей, правила, обсуждал структуру, правил формулировки. Мы прошли вместе несколько версий текста — сначала черновик, потом редактуру, потом ещё раз редактуру. И вот на каком-то этапе я присылаю свою финальную правку: убрал в начале упоминание конкретной модели, хотел плавно подвести к этому дальше по тексту.

А в ответ получаю текст, где эта правка откатилась. Модель вернула мою старую формулировку почти в самое начало. Как будто моих правок и не было.

Я спрашиваю: «Как ты оцениваешь запылённость текущего контекста? Ты явно поменял текст, который я правил, и вернул то, что я убрал». Я это называю запылённостью контекста: когда в диалоге накапливается много второстепенного и модель перестаёт различать, что важно, а что нет. Это не совсем полная аналогия загруженности, ближе к термину «забивание».

И получаю честный ответ. Модель сказала: да, контекст запылён. У неё в памяти лежат несколько версий текста — первая, вторая, третья, моя правка. И когда она собирала «цельный текст», она «схватила ту, которая первая попалась» или «наиболее полную по её ощущению». Не ту, что я только что прислал.

Я сидел и думал: это же ровно то, о чём я пишу статью. Модель не умеет чётко разделять «вот это самая свежая версия, работай только с ней». Ей нужно явно сказать: «вот финальная версия, всё остальное забудь». Она не понимает, что мои правки — это не просто «ещё один текст в контексте». Это новый источник истины, который отменяет предыдущие.

И главное — это не баг. Это та же самая природа LLM, о которой я писал выше. Для модели всё, что в контексте, одинаково значимо, пока не доказано обратное. Четыре версии статьи для неё — это четыре равноправных набора данных. И она берёт тот, который «вероятнее» — то есть ближе к центру распределения, к тому, что чаще встречалось в обучающих данных. А не тот, что я только что прислал.

Я потом пересобрал текст у себя: сам склеил все правки в один файл, отправил заново одним куском и сказал: «Работаем только с этим. Всё, что было раньше, — не существует». И это сработало.

С тех пор я всегда так делаю с большими текстами. Не «вот тебе правка, примени к предыдущей версии», а «вот тебе финальная версия целиком, остальное забудь». Иначе получается как у нас с этой статьёй: пишешь про перегрузку контекста — и сам в неё попадаешь.

Мета-ирония, конечно. Но зато на своём опыте убедился, что это работает именно так, как я описываю.

Что я вынес из этого опыта

Главное, что я вынес из этого опыта: не надо впрямую переносить на ИИ человеческие практики. Agile, MVP, короткие итерации, «атмосфера в команде», настроение, поручения в стиле «додумай сам» — всё это создано для людей. У ИИ другие ограничения, и с ними надо работать иначе.

Я знаю, что многие выстраивают производственный процесс вайб-разработки на основе лучших работающих корпоративных практик. Пытаются нащупать привычные точки контроля. Но при большом потоке информации, который генерирует ИИ, это, на мой взгляд, бесполезно. В моём случае я понял, что не успеваю отслеживать все изменения, которые вносит модель. А модель этими изменениями может кардинально поменять вектор развития. И доверять ей по привычке, как человеку — «раз исполнитель уверенно говорит по теме и результаты показывает, значит всё нормально», и смотреть можно только в привычных ключевых точках — не работает.

Конкретно для меня это значит:

Меньше итераций. Чем меньше итераций, тем меньше мусора в контексте. Тем точнее промпты. Тем лучше результат.

Точнее и полнее промпты. Прежде чем идти в следующий чат, надо вычитать результат предыдущего и понять, что именно передать. Это дисциплинирует.

Отдельные чаты под каждую тему или цель. Белая книга, ТЗ, разработка, маркетинг — всё отдельно. Не смешивать.

Не давать делать заглушки. Сразу рабочий продукт. Да, дольше на старте, но меньше переделок потом.

Контролировать изменения архитектуры и ключевой логики. Переделка — только по прямому указанию, а лучше в отдельном новом контексте. Иначе модель перепишет половину приложения, когда ты просил поправить кнопку.

У меня два доведённых до результата пет-проекта. Первый — торговый бот для одного из брокеров: расширение для браузера, сигналы, лимитные заявки, управление позициями. Сделал за две-три недели. Второй — аналитика цифровых финансовых активов: агрегатор данных, парсинг открытых источников, инфографика. Занял полтора-два месяца, дался тяжело. Разница между проектами для меня показательна: бот я делал после того, как нащупал подход. Аналитику — до, когда ещё пытался работать с ИИ как с командой людей. Отсюда и результат.

Это не «правильная методология». Это то, что сработало у меня. У кого-то может быть иначе. Но если вы тоже пробовали вайб-кодить, сжигали токены и не могли довести проект до прода, — может быть, дело не в инструменте. Может быть, дело в том, что мы относимся к ИИ как к человеку. А он — не человек.