Всем привет, я хочу поделиться своим опытом разработки, используя (почти) бесплатные инструменты.
Дисклеймер (обязательно к прочтению)
Если вы гоняете клауд-код по подписке от антропиков за 20+ баксов и у вас все работает — это нормально. Если наоборот, вы попробовали этот самый вайб-кодинг и получили кучу бесполезного кода — это тоже нормально. У всех опыт разный, и я хочу примирить адептов двух лагерей, потому что каждый лагерь по-своему прав.
Я не собираюсь тут никого учить «как правильно». Все мои знания — от противного. Я могу лишь рассказать, чего делать точно не стоит, чтобы не сжечь нервы и бюджет.
Кроличья нора
Итак, пока у кого-то есть возможность сжигать бесконечно токены на Opus (и жаловаться, что AI бесполезен), а другие жмутся на двадцатку (как я) и получают ровно противоположные результаты, я немного расскажу о своем опыте.
Чуть менее года назад я решил начать активно использовать AI, и эта кроличья нора оказалась настолько глубокой, что я до сих пор не могу оттуда вылезти. Я прошел и этапы «нейрошизы» (когда ChatGPT говорит, что ты гений и покоришь мир), и тяжелое похмелье, когда ответы нейросеток спотыкались о суровую реальность продакшена.
В чем суть моего экс(к)перимента: я решил отказаться от идеи писать код. Вообще. Да и не только писать код, но и заниматься инфраструктурой руками. Да, ваш Cursor вполне может хоть файлы сортировать у вас на компьютере, для этого даже не нужно использовать Clowdbot/Molty.
Чтобы не быть голословным, вот список задач, которые я закрыл за последнее время, не набрав ни одной строчки продуктового кода лично (используя почти бесплатные модели Gemini/Qwen/Z.ai и CLI-инструменты):
Frontend: SPA-приложение «Психологический опросник» (TypeScript/React) — psyco-d2df6.web.app
Science: Научная статья на базе результатов опросника (LaTeX) — preprints.ru/article/1962
ML: Обучение нейросети wake-word (споттер) на PyTorch для голосового помощника в многоквартирном доме.
Embedded/IoT: Интеграция проприетарного SDK (Audio Codec/DSP Synapttics) в ESPHome/ESP32 (C++) для того же голосового помощника.
System/VDI: Сквозной SSO-логин в среде Windows VDI / QEMU (NDA).
Kotlin/Android: Агент для удаленного управления внутри Android (NDA).
Health: Тренажер для развития DBT-навыков — VyvozavrBot
Data Analytics: Chat-to-Data слой (Text-to-SQL) для ClickHouse. Агент сам пишет запросы, фиксит диалект SQL и отдает данные — app.kolkhoz.io
(Очевидно, по каждому пункту можно докопаться, особенно по "научной статье". Но факт остается фактом: это промышленный результат, за который платят реальные деньги. Здесь нет «Hello World» из туториалов, здесь ClickHouse, C++, PyTorch и обученная нейросетка решающая бизнесовую задачу. Заказчику плевать, кто я по диплому — ему нужен этот станок, который закрывает квартальные KPI отдела за пару вечеров).
Про последние два проекта я хотел бы сказать буквально два слова, потому что их получилсь собрать на коленке за несколько дней:
Это полноценный учебный курс по ДБТ навыкам от Марша Линехан в виде телеграм бота. Сделано (почти) полностью с помощью LLM, начиная от самих уроков, заканчивая тестами и деплоем. Серьезно: автотесты сделала LLM, деплой сделала LLM. Даже продуктовая аналитика сделана на своем собственном велосипеде. Монетизации тут нет, поэтому рекламирую с чистой совестью.
Давайте начистоту. Я не дата-сайентист. Я не плюсовый разработчик (хотя опыт такой был в прошлой жизни). Я не ML-инженер, не Windows Solution Architect и даже не Kotlin-разработчик. Вообще, больше всего я DevOps, Python-разработчик и аналитик данных. У меня свой бизнес, а программирование — так, для души...
На самом деле нет. Вынужден сделать каминг-аут: я ненавижу программирование!
Писать код руками в 2026 году — это либо признак глубокого снобизма, либо профнепригодности. Перекладывание JSON-ов, борьба с зависимостями, написание бойлерплейта — это рутина, которая убивает творчество. И я наконец-то рад, что могу не заниматься этим лично.
Разработка превращается в работу оператора станков с ЧПУ. «Станок» — это связка из мощных LLM-агентов, а «чертеж» — жесткая структура правил и XML-контрактов. Это не просто личная позиция, это сигнал для рынка: эпоха «закрывателей тикетов» уходит. Настало время строить автономные системы, которые решают задачи бизнеса, пока оператор управляет смыслами, а не символами.
А собственно, как я сейчас «программирую»?
Анатомия провала: Три стадии принятия AI
В процессе вайб-разработки можно выделить три этапа, на каждом из которых можно упереться в пределы организации разработки, из-за чего возникает хаос.
Этап 1: Медовый месяц
Первый этап самый простой: мы пишем промпт из разряда «сделай мне такой-то сервис». Код генерируется, мы наваливаем ещё фичей, все идет хорошо, ИИ нам отвечает, что все отлично и все сделано. На данном этапе о��о может работать, а может и не работать, это не так важно. Допустим, всё работает, и мы идем дальше.
Этап 2: Похмелье
В нашем гипотетическом приложении появляется дополнительный модуль, например фронтенд (если мы делали бекенд) и наоборот. Мы переходим ко второму этапу, где все начинает разваливаться. Основная проблема тут как в отсутствии эффективных методов тестирования, так и правил разработки.
Нейросеть кряхтит-пердит, но пытается собрать проект в кучу (генерируя кучу версий, упрощая тесты и функциональность). Параллельно она ещё пишет, что всё готово и сделано, так что начинает бесить и вызывать желание написать в интернет, что вайб-кодинг — это херня. Если вдруг нам удалось на этом этапе стабилизировать приложение, мы вытираем пот и говорим себе, что нейросети нас ещё не заменят (пока).
Этап 3: Архитектор Хаоса (XML как спасение)
На этом этапе нам нужно отступить на шаг назад и полностью переработать нашу документацию. Всё должно быть отражено в тексте: функциональные требования, контракты в коде, структуры состояний/экранов/whatever. Только когда мы оформили это в XML, у нас появляется возможность использовать рефлексию ИИ над самой структурой приложения. А добавив правила, мы позволяем агенту самому исправлять ошибки в архитектуре и поставлять стабильное качество.
Это и есть третий этап (ничто не мешает вам сразу начать с него). На данном этапе вы как разработчик следите только за правилами агента и за документацией. Код становится не важен, и его можно редуцировать (во многих аспектах) до парсера XML. Здесь мы работаем только с требованиями (различных уровней), сам код можно уже не смотреть, потому что постоянный поток рефлексии (даже слегка галлюцинирующий) поверх жесткой структуры приводит к стабильным результатам.
Именно на этом этапе становится понятно, почему неповоротливые корпорации с их бесконечными стендапами и отделами согласований неизбежно проиграют. Пока сеньор-помидор «синхается» с архитектурным комитетом, а тестировщики заводят тикеты в Jira, мой агент уже трижды отрефлексировал над XML-контрактом, нашел логическую дыру и выкатил детерминированный фикс. Корпоративная машина пытается впихнуть ИИ в свои ветхие процессы, не понимая, что нужно полностью менять сами процессы. Это переход от управления людьми к управлению смыслами и правилами.
Но чтобы к этому прийти, нужно разобраться в базе.
Ликбез: Как не потеряться в зоопарке
Чтобы избежать проблем с пониманием, придется ввести некоторую терминологию и ликбез. Не воспринимайте слишком буквально, некоторые вещи будут (бес)сознательно упрощены, но на итоговый результат это не влияет.
На данный момент ситуация на рынке такая:
Вендоры (поставщики «мозгов»):
OpenAI: Семейство ChatGPT (5.2 и все семейство.
Anthropic: Claude (Opus / Sonnet).
Google: Gemini (Pro / Flash ).
Китайцы: Deepseek, Z.ai, Kimi, Qwen.
Агрегаторы: OpenRouter (шлюз ко всем моделям сразу).
IDE / Инструменты: Cursor, Windsurf, OpenCode, KiloCode и прочие перепродавцы токенов.
Цена вопроса и SOTA
Давайте сразу зафиксируем: в целом свою «двадцатку» ($20) вы можете занести кому угодно из этого списка.
Каждая новая модель выходит с шильдиком SOTA (State of the Art — «лучшее, что есть на данный момент», топ бенчмарков). Сравнивать их в моменте довольно бессмысленно — лидер меняется каждый месяц. Единственное, что вас должно беспокоить — это лимиты. Например, Opus на самой дешевой подписке с вами только поздоровается.
Все вендоры предполагают два сценария использования:
Подписка: Фиксированная плата. Считается, что подписочная модель субсидируется, если сравнивать напрямую. Например, подписка от антропиков за 100 баксов позволяет «нажечь» такое же количество токенов, которое по API стоило бы баксов 1600. Так что подписки обычно выгоднее для активной работы.
API (Pay-as-you-go): Платите за токены. Честнее, но дороже на дистанции.
Лайфхак: Если вы пользуетесь Cursor, у него есть режим Auto, который работает условно безлимитно. Скорость падает после исчерпания «быстрых» запросов, но работать можно. До недавнего времени режим Auto еще и хитро подменял модели (подкладывал то, что дешевле/доступнее), что позволяло жечь токены на промышленном уровне.
Модель vs Агент
Это критически важное разделение.
Модель (LLM) — это просто нейросеть, которая предсказывает следующий токен.
Агент — это программа-обертка, у которой есть системный промпт, инструменты и доступ к файлам.
Поэтому вы часто можете слышать: «А вот я использую Claude Code и у меня всё работает, а вот в вашем вставить название какая-то херня получается».
Да, так и есть. Потому что условный Claude Code имеет в системном промпте инструкцию: «Читай всё, что может быть хоть отдаленно полезным». Это повышает качество ответа, но и кратно увеличивает расход токенов (и доход вендора, разумеется).
Моя позиция:
Здоровая стратегия — относиться к LLM и агентам как к расходникам. У хорошо подготовленной прослойки (между клавиатурой и стулом) будут предсказуемые и похожие результаты с любым агентом. Если ваш процесс зависит от «магии» конкретной модели — у вас нет процесса.
Феноменология Агента: Жизнь в темной комнате
Чтобы понять, почему агенты так часто тупят, нужно представить их бытие.
Внутри нашей черепной коробки темно и влажно, но всё многообразие наших ощущений происходит благодаря работе мозга и органов чувств.
Модель внутри агента также сидит в черном безжизненном пространстве. Её единственным способом общения с реальностью вашего проекта являются Тулы (Tools). Именно тулы превращают связку «Агент + LLM» в RAG.
Причем тулы эти — примитивные:
ls(посмотреть список файлов)read_file(прочитать содержимое)grep(найти текст)
Пока модель не сделает ls, она ничего не знает про структуру вашего проекта. Пока она не сделает read_file, она не знает, что внутри main.py.
Почему это важно:
Любая новая сессия или автоматическая компрессия контекста (когда чат становится слишком длинным) — это лоботомия. Это обнуление оперативной памяти.
Знакомое чувство, когда после двух часов вылизывания сложной логики модель вдруг «забывает», что вы пять сообщений назад договорились не использовать эту библиотеку? Или когда она начинает предлагать решение, которое вы уже отвергли как нерабочее? Это не просто «баг», это гниение контекста, которое сжигает ваше время и нервы. Модель начинает тупить, делать детские ошибки и вести себя как человек с тяжелой амнезией, который проснулся в незнакомой комнате и пытается угадать, что он здесь делает. Вы чувствуете, как контроль ускользает, а проект превращается в неуправляемую кучу мусора.
Именно поэтому Контракты (XML) вас спасут. Когда память стирается, агент читает один файл Rules.xml и мгновенно восстанавливает картину мира. Это ваш внешний жесткий диск, который не дает системе деградировать. Без этого вы обречены на вечный «День сурка».
Парадокс интерфейса: Забытый User Profile
Перед тем как перейти к практике, хочу добавить важную вводную. LLM — продукт одновременно и очень сложный, и очень простой.
Сложный, потому что они буквально обучаются на всех знаниях человечества, но это знание существует в скрытой форме с обманчиво простым интерфейсом. Все как в жизни: квантовая нелокальность есть, а информацию передать нельзя.
Многие отмечают в промптах роль агента («ты сеньор-помидор / эксперт в области пельменной лепки»), но совершенно забывают про User Profile. На мой взгляд, это гораздо важнее.
Если вы скажете, что модель — сеньор, она навалит вам сеньорского текста (сложного, абстрактного). Но если вы скажете, кто ВЫ, что ВАМ нужно и ПОЧЕМУ, результат будет кардинально другим.
Поэтому старайтесь говорить прямо: если у вас MVP, вам не нужны шарды, Kubernetes и High Availability. Вам нужен просто скрипт на Питоне, который решит задачу здесь и сейчас. Агент не умеет читать мысли, он умеет только предсказывать текст, наиболее вероятный для заданного контекста.
Слон и слепые
И совсем последнее. В мире LLM архитектуру придумывают одни люди, датасеты для обучения собирают (и обучают) другие, а эксплуатируют — вообще третьи.
В итоге получается натуральный слон со слепыми мудрецами. Не позволяйте регалиям вводить вас в заблуждение.
Если человек, который придумал архитектуру GPT (да, тот самый, один из), раздает интервью, где скептически говорит о продакшен-эксплуатации, а вы тоже относитесь к ИИ скептически — вы оба можете оказаться неправыми в своем пузыре. Архитектор знает математику весов, но он может не знать, как этот вес решает задачу парсинга логов в 3 часа ночи. Слушайте практиков.
Инструментарий: Где взять мозги?
Ладно, уже пора про инструменты. Сразу оговорюсь: я принципиально тестирую гипотезы на «железе с помойки» и бесплатных тарифах. Если архитектура работает в спартанских условиях — залив бабками оно станет работать ещё лучше. Это мой стресс-тест на прочность решения и радикальную эффективность. Пока корпоративные отделы сжигают десятки тысяч долларов на подписки и GPU-кластеры, я показываю, как можно строить Enterprise-решения за $0. Это вопрос не экономии, а ROI.
Для начала нам нужно запастись как минимум одной (относительно) умной моделью.
Бесплатные веб-версии: ChatGPT / Claude. Для небольших задач может хватить, но у них довольно быстро заканчиваются лимиты на «умные» мо��ели, и вас переключают на «глупые» (mini, flash).
Китайцы (Kimi, Z.ai, DeepSeek): Отличная альтернатива. Лимиты у них побольше, а говорить, что они сильно тупее топов, я бы не стал. Особенно DeepSeek (кодер) и Kimi (длинный контекст).
Perplexity (Перпла): Раньше существовал отличный хак (на ggsel/plati можно было купить промокод на год за смешные деньги), но эту лавочку прикрыли. Однако до сих пор там можно купить подписку со скидкой, или, если вас не душит жаба, занести $20 напрямую.
Чем полезна: Позволяет выбирать разные модели (Claude, GPT, Llama) в рамках одного окна. Это топ для сравнения ответов.
LMSYS Arena (arena.ai): Если платить не хочется совсем, идем сюда. Можно бесплатно сравнивать ответы разных моделей, но в режиме «слепого теста» или Direct Chat.
Для чего нам всё это нужно?
Для того, чтобы в свободной форме обсудить задачу, написать ПЛАН, а то и сделать Deep Research по теме. И только когда у нас есть План, мы идем дальше.
Цена галлюцинации (Почему план — это мусор)
Но не обольщайтесь: ваш план не стоит и тех токенов, которые вы на него сожгли.
LLM галлюцинируют, и чем сложнее ваша область, тем менее надежен план. В некоторых задачах он по сути становится не то что бесполезен, но...
«Вы абсолютно правы, оно не работает!» — и дальше идет объяснение, почему у вас не получилось то, что ещё пару сообщений назад было признано алгоритмом, надежным как швейцарские часы.
Как с этим бороться? Да никак.
Если вы делаете какую-то энтерпрайзовую штуку с минимальной документацией + вендор ещё сам против и хочет, чтобы использовали его готовые решения, а не «велосипедили» на его API (привет, Microsoft), вас ждет боль и мучение. Вероятность галлюцинаций растет на порядки, если у задачи проблемы с документацией.
Но, строго говоря, эта проблема будет и при решении задачи в обычном порядке: неактуальный StackOverflow «поднасрет» и вам лично, и отравит LLM.
Битва моделей:
Минимальный профит тут можно получить, заставив одну LLM спорить с другой. Правда, их рабская покорность будет приводить к смешным результатам: две модельки тут же поменяют свое мнение на противоположное, когда вы будете давать им перекрестные ответы («Клод сказал, что ты неправ»).
Однако, это лучше, чем ничего.
Серебряной пули нет (но есть суперсила)
Собственно, в этом и заключается главный ответ: LLM — не серебряная пуля. Наличие развитого межушного ганглия на данный момент до сих пор обязательное требование для разработки сложных систем.
Но суперсила действительно появляется: вы можете делать продукты, находясь на другом уровне абстракции. Это отдельный навык — «как сделать то, не зная как и что».
Ответ БЯМ (Большой Языковой Модели) будет прямо зависеть от того, какие кейворды (ключевые слова) вы будете наваливать в начале промпта. Очертив терминами домен, вы заставите модель «активировать» нужные области знаний, существенно изменив качество ответа.
Методология: Превращаем раба в партнера (PCAM / GRACE)
Но «просто промптить» — не работает. Чтобы заставить ИИ работать стабильно на сложных проектах, нужно перестать быть кодером и стать бюрократом.
Вы должны понимать физику процесса: мы привыкли управлять компьютером через инструкции. Но современные LLM создавались не как интерпретаторы скриптов. Они обучались через RL (Reinforcement Learning) как системы, оптимизированные для достижения целей. Когда вы даете модели жесткий пошаговый план («Напиши функцию А, потом Б, потом В»), вы сознательно деградируете её возможности.
Чтобы получить стабильный результат, когда агенты просто выполняют свою работу без лишней суеты, я использую методологию, превращающую хаос «вайб-кодинга» в скучный и воспроизводимый процесс.
Важное уточнение: PCAM/GRACE — это НЕ мое изобретение. Автором методологии является Владимир Иванов. Все, что я описываю ниже — это моя интерпретация и надстройки над его фундаментом.
Интересные статьи
Интересные статьи
