Всем привет, я хочу поделиться своим опытом разработки, используя (почти) бесплатные инструменты.
Дисклеймер (обязательно к прочтению)
Если вы гоняете клауд-код по подписке от антропиков за 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-контрактов. Это не просто личная позиция, это сигнал для рынка: эпоха «закрывателей тикетов» уходит. Настало время строить автономные системы, которые решают задачи бизнеса, пока оператор управляет смыслами, а не символами.
А собственно, как я сейчас «программирую»?
В процессе вайб-разработки можно выделить три этапа, на каждом из которых можно упереться в пределы организации разработки, из-за чего возникает хаос.
Первый этап самый простой: мы пишем промпт из разряда «сделай мне такой-то сервис». Код генерируется, мы наваливаем ещё фичей, все идет хорошо, ИИ нам отвечает, что все отлично и все сделано. На данном этапе оно может работать, а может и не работать, это не так важно. Допустим, всё работает, и мы идем дальше.
В нашем гипотетическом приложении появляется дополнительный модуль, например фронтенд (если мы делали бекенд) и наоборот. Мы переходим ко второму этапу, где все начинает разваливаться. Основная проблема тут как в отсутствии эффективных методов тестирования, так и правил разработки.
Нейросеть кряхтит-пердит, но пытается собрать проект в кучу (генерируя кучу версий, упрощая тесты и функциональность). Параллельно она ещё пишет, что всё готово и сделано, так что начинает бесить и вызывать желание написать в интернет, что вайб-кодинг — это херня. Если вдруг нам удалось на этом этапе стабилизировать приложение, мы вытираем пот и говорим себе, что нейросети нас ещё не заменят (пока).
На этом этапе нам нужно отступить на шаг назад и полностью переработать нашу документацию. Всё должно быть отражено в тексте: функциональные требования, контракты в коде, структуры состояний/экранов/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 и прочие перепродавцы токенов.
Давайте сразу зафиксируем: в целом свою «двадцатку» ($20) вы можете занести кому угодно из этого списка.
Каждая новая модель выходит с шильдиком SOTA (State of the Art — «лучшее, что есть на данный момент», топ бенчмарков). Сравнивать их в моменте довольно бессмысленно — лидер меняется каждый месяц. Единственное, что вас должно беспокоить — это лимиты. Например, Opus на самой дешевой подписке с вами только поздоровается.
Все вендоры предполагают два сценария использования:
Подписка: Фиксированная плата. Считается, что подписочная модель субсидируется, если сравнивать напрямую. Например, подписка от антропиков за 100 баксов позволяет «нажечь» такое же количество токенов, которое по API стоило бы баксов 1600. Так что подписки обычно выгоднее для активной работы.
API (Pay-as-you-go): Платите за токены. Честнее, но дороже на дистанции.
Лайфхак: Если вы пользуетесь Cursor, у него есть режим Auto, который работает условно безлимитно. Скорость падает после исчерпания «быстрых» запросов, но работать можно. До недавнего времени режим Auto еще и хитро подменял модели (подкладывал то, что дешевле/доступнее), что позволяло жечь токены на промышленном уровне.
Это критически важное разделение.
Модель (LLM) — это просто нейросеть, которая предсказывает следующий токен.
Агент — это программа-обертка, у которой есть системный промпт, инструменты и доступ к файлам.
Поэтому вы часто можете слышать: «А вот я использую Claude Code и у меня всё работает, а вот в вашем вставить название какая-то херня получается».
Да, так и есть. Потому что условный Claude Code имеет в системном промпте инструкцию: «Читай всё, что может быть хоть отдаленно полезным». Это повышает качество ответа, но и кратно увеличивает расход токенов (и доход вендора, разумеется).
Моя позиция:
Здоровая стратегия — относиться к LLM и агентам как к расходникам. У хорошо подготовленной прослойки (между клавиатурой и стулом) будут предсказуемые и похожие результаты с любым агентом. Если ваш процесс зависит от «магии» конкретной модели — у вас нет процесса.
Чтобы понять, почему агенты так часто тупят, нужно представить их бытие.
Внутри нашей черепной коробки темно и влажно, но всё многообразие наших ощущений происходит благодаря работе мозга и органов чувств.
Модель внутри агента также сидит в черном безжизненном пространстве. Её единственным способом общения с реальностью вашего проекта являются Тулы (Tools). Именно тулы превращают связку «Агент + LLM» в RAG.
Причем тулы эти — примитивные:
ls (посмотреть список файлов)
read_file (прочитать содержимое)
grep (найти текст)
Пока модель не сделает ls, она ничего не знает про структуру вашего проекта. Пока она не сделает read_file, она не знает, что внутри main.py.
Любая новая сессия или автоматическая компрессия контекста (когда чат становится слишком длинным) — это лоботомия. Это обнуление оперативной памяти.
Знакомое чувство, когда после двух часов вылизывания сложной логики модель вдруг «забывает», что вы пять сообщений назад договорились не использовать эту библиотеку? Или когда она начинает предлагать решение, которое вы уже отвергли как нерабочее? Это не просто «баг», это гниение контекста, которое сжигает ваше время и нервы. Модель начинает тупить, делать детские ошибки и вести себя как человек с тяжелой амнезией, который проснулся в незнакомой комнате и пытается угадать, что он здесь делает. Вы чувствуете, как контроль ускользает, а проект превращается в неуправляемую кучу мусора.
Именно поэтому Контракты (XML) вас спасут. Когда память стирается, агент читает один файл Rules.xml и мгновенно восстанавливает картину мира. Это ваш внешний жесткий диск, который не дает системе деградировать. Без этого вы обречены на вечный «День сурка».
Перед тем как перейти к практике, хочу добавить важную вводную. 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 — не серебряная пуля. Наличие развитого межушного ганглия на данный момент до сих пор обязательное требование для разработки сложных систем.
Но суперсила действительно появляется: вы можете делать продукты, находясь на другом уровне абстракции. Это отдельный навык — «как сделать то, не зная как и что».
Ответ БЯМ (Большой Языковой Модели) будет прямо зависеть от того, какие кейворды (ключевые слова) вы будете наваливать в начале промпта. Очертив терминами домен, вы заставите модель «активировать» нужные области знаний, существенно изменив качество ответа.
Но «просто промптить» — не работает. Чтобы заставить ИИ работать стабильно на сложных проектах, нужно перестать быть кодером и стать бюрократом.
Вы должны понимать физику процесса: мы привыкли управлять компьютером через инструкции. Но современные LLM создавались не как интерпретаторы скриптов. Они обучались через RL (Reinforcement Learning) как системы, оптимизированные для достижения целей. Когда вы даете модели жесткий пошаговый план («Напиши функцию А, потом Б, потом В»), вы сознательно деградируете её возможности.
Чтобы получить стабильный результат, когда агенты просто выполняют свою работу без лишней суеты, я использую методологию, превращающую хаос «вайб-кодинга» в скучный и воспроизводимый процесс.
Важное уточнение: PCAM/GRACE — это НЕ мое изобретение. Автором методологии является Владимир Иванов. Все, что я описываю ниже — это моя интерпретация и надстройки над его фундаментом.
🔗 Канал автора (небольшое лирическое отступление: пожалуй самый полезный ресурс в Рунете на тему ИИ, ещё полезнее только чат этого же канала)
Здесь мы имеем дело с двумя сторонами одной медали:
GRACE (Graph-RAG Anchored Code Engineering) — про то, КАК строить структуру кода и документации. Это «Скелет».
PCAM (Purpose Centric Agent Methodology) — про то, КАК управлять поведением агента. Это «Мозг».
В основе лежит простая мысль: AI — это стохастическая машина хаоса. Когда LLM сталкивается с неоднозначностью, она начинает «фантазировать», проявляя ту самую неконтролируемую инициативу, которая ломает ваш прод. GRACE решает это через Принцип Явного Замысла и Семантическую разметку.
Если вы думаете, что контекст в миллион токенов — это «честная» память, у меня для вас плохие новости. Современные модели используют Sparse Attention (Разреженное внимание).
В классическом Трансформере используется Full Self-Attention. Это значит, что каждый токен смотрит на каждый другой токен в тексте. Если у тебя 100,000 слов (контекст Gemini/Claude), это 10 миллиардов операций сравнения на каждый слой. Это требует чудовищного количества видеопамяти и времени. Если бы современные модели использовали только «честное» полное внимание, огромный контекст был бы физически невозможен.
Чтобы решить эту проблему, инженеры придумали Разреженное внимание. Идея проста: «Не обязательно смотреть на всё сразу. Давай смотреть только на важное». Вместо того чтобы связывать каждый токен со всеми, модель использует определенные паттерны:
Local Attention (Sliding Window): Токен смотрит только на своих ближайших соседей.
Global Attention: Выделяются специальные «глобальные токены», на которые смотрят все.
Random Attention: Токен смотрит на несколько случайных слов далеко в тексте.
Результат: Сложность падает, что позволяет запихнуть в модель книгу целиком. Но возникает побочный эффект: Амнезия и Lost in the Middle.
Модель физически не может уделить равное внимание каждому слову в середине огромного текста. Начало текста она помнит хорошо, конец — отлично, но середина выпадает. Если какой-то кусок кода в середине промпта не попал ни в «окно соседей» или «глобальный фокус», для модели он становится туманным пятном. Она может забыть определение функции на 500-й строке, если сейчас пишет 2000-ю.
В методе GRACE этот механизм используется для обхода ограничений архитектуры. Оборачивание важных кусков в XML-теги (<architecture>, <rules>) создает для модели искусственные Global Tokens.
XML-теги — это редкие структурные символы, на которых модель фокусируется в первую очередь.
При обучении (особенно на коде и разметке) нейросеть приучается уделять повышенное внимание таким маркерам.
Вероятность того, что модель «сохранит линк» на выразительный XML-тег, кратно выше, чем на обычное слово.
Использование XML-якорей — это способ принудительно управлять механизмом внимания, указывая модели: «Этот узел в графе — глобальный. Не теряй связь с ним, даже если он был 50 тысяч токенов назад».
Почему не JSON или YAML?
JSON — формат данных, слишком строгий к синтаксису. Одна лишняя запятая ломает парсер, а семантически он «пустой».
YAML — зависим от отступов, на которых LLM часто галлюцинируют.
XML — похож на HTML, на котором обучены все модели. Концепция «тег — контент — закрывающий тег» прошита у них на уровне нейронов. XML максимально Fault Tolerant (отказоустойчив): даже если модель ошиблась в атрибуте, структура блока остается понятной. Это идеальный интерфейс для структурирования смыслов в латентном пространстве.
XML-теги и комментарии-якоря работают в двух направлениях:
Для генератора (Top-Down): XML-теги работают как маяки, помогая модели «материализовать» план внутри тега, преодолевая ограничения Sparse Attention.
Для RAG-агента (Bottom-Up): Создает индексированные «якоря». Агент идет по графу: Requirements -> Contract -> Function. Навигация становится детерминированной.
RequirementsAnalysis.xml: Формализуем хотелки (Actor-Action-Goal).
Technology.xml: Жестко фиксируем стек и версии библиотек.
DevelopmentPlan.xml: «Чертеж» с обязательными Mental Tests (мысленный прогон алгоритма перед кодингом).
Generation & Verification: Генерация строго по шаблону и проверка через «Belief State» (веру агента) в логах.
Если GRACE — это про статику, то PCAM (Purpose Centric Agent Methodology) — это про динамику и исполнение. Доминирующий сейчас подход (ToDo-lists, Chain-of-Thought) превращает агента в тупого исполнителя скриптов. Это регресс. LLM обучались через Reinforcement Learning как Goal Achievers (достигаторы целей), а не как скрипт-кидди. Когда вы даете агенту жесткий план, вы сознательно деградируете его возможности, лишая права на оптимизацию.
Примат цели над инструкцией: Агент должен знать «ЗАЧЕМ», а не только «ЧТО». Задача ставится как цель, а не как список команд. Это развязывает ему руки для инициативы.
Гайды вместо Скриптов: Вместо жесткого плана агент получает «Гайды» — рекомендуемые стратегии и источники знаний. Это как дать сотруднику карту местности, а не список «поверни налево, поверни направо».
Self-Healing (Самоизлечение): Это киллер-фича. Агент должен иметь право и инструменты диагностировать свои ошибки.
Пример: Если SQL-запрос упал, агент не должен падать с ошибкой. Он должен выполнить execute_simple_sql, посмотреть схему таблицы, понять, что колонки не существует, и переписать запрос. Сам.
Плагинная архитектура: Система — это набор изолированных инструментов (Plugins). Агент — это Оркестратор, который просто дергает нужные ручки.
Стандартизация протоколов: Жесткость нужна не в планах, а в интерфейсах. Агент-Тестировщик общается с Агентом-Разработчиком по строгому протоколу.
Цикл обратной связи: Агенты эксплуатации передают инфу агентам разработки. Система учится.
Проблема Стыков (The Integration Gap):
Агенты гениальны внутри одного модуля, но ужасны на стыках. Если попросить Фронт-агента сделать кнопку, а Бэк-агента — API, они сделают это по-разному (camelCase vs snake_case).
Инсайт: Контракты API (OpenAPI, Protobuf) вы должны писать руками (или жестко фиксировать в XML). Это единственное место, где нельзя давать свободу. Стыки систем — это зона ответственности человека.
Поверх этой базы я наслоил свой стек:
StateMachine.xml (Автоматы состояний): Я описываю сложные системы как конечные автоматы. Абстрактные тесты проверяют переходы состояний, а не код.
Точка правды: Фронт и Бек синхронизированы через единый XML.
Protobuf для контрактов: Жестче, чем JSON Schema. Фиксирую API в .proto. Компилятор бьёт по рукам раньше, чем я замечу баг.
Организация «Мозгового центра»: Правила в репозитории (отдельный git-repo rules подключен как сабмодуль).
Восстановление памяти: Команды «прочитай правила про безопасность» или «прочитай доку» работают как save/load в игре.
Главный вывод: Код вторичен. Это больше не актив, это побочный продукт генерации. Первичны правила, цели и структура.
Разработка в 2026 году — это не перевод с человеческого на C++, это трансляция Намерения (Intention) сразу в Результат. Синтаксис стал бутылочным горлышком, от которого пора избавиться.
Мои XML-контракты — это «внешняя лобная доля» для ИИ. Без них модель — талантливый шизофреник, с ними — дисциплинированный завод по производству решений. Если у вас есть правильная структура (Architecture.xml) и правильное целеполагание (PCAM), код можно восстановить или переписать заново за минуты. Вы больше не пишете код, вы владеете Средством Производства. Вы управляете смыслами и целями, а не символами в IDE.
Я обещал не быть голословным. «Правила в XML» звучит как энтерпрайз-скука, пока вы не увидите, что именно там написано. Мой репозиторий rules — это не набор линтеров. Это кладбище моих ошибок и нервных срывов, оцифрованное в текст. Когда я говорю «Doc-first», я имею в виду, что прежде чем агент напишет строку кода, он обязан прочитать, как я страдал до него.
В моем проекте microWakeWord была проблема: агент постоянно пытался «помочь» и запустить обучение скриптом python train.py. Это ломало зависимости, пути и логирование. Вместо того чтобы каждый раз бить его по рукам, я создал правило critical_rules.xml.
Фрагмент из реального файла ml_pipeline_rules.md:
### 🎯 Wake Word метрики:-
**FRR (False Reject Rate)**: должно быть низким-
**FA/h (False Accepts per Hour)**: главная метрика
### 📝 ЗАПОМНИ НАВСЕГДА:**БЛЯДЬ, Wake word ≠ обычная классификация!
****Дисбаланс 100:1 - это норма!**
**100% точность на TTS - НЕ НОРМА!**
### 🚨 КРИТИЧЕСКОЕ ПРАВИЛО - НЕ ЗАБИВАЙ ХУЙ!
**ВСЕГДА ДОДЕЛЫВАЙ ПРАВИЛЬНО, А НЕ ЗАБИВАЙ ХУЙ!**
- Если создаешь новую задачу - ДОБАВЛЯЙ ЕЕ В XML!Да, там есть мат. И это работает. Мат и капс в промптах/правилах работают как attention mechanism для модели. Они повышают «вес» этих токенов. Агент понимает: «Окей, тут хозяин очень зол, эту инструкцию игнорировать нельзя».
Важный нюанс: Я пишу архитектуру на английском (так точнее для модели), а ругаюсь на русском. Для LLM кириллица среди латиницы работает как sudo — это сигнал резкой смены контекста и повышения приоритета. Это формирует Belief State (Состояние Веры) модели. В «среднем по интернету» дисбаланс классов — это плохо. Моя фраза сбивает стандартные веса внимания и принудительно переключает модель: «Тут особые условия, забудь то, чему тебя учили в базовой школе».
Оставьте корпоративную вежливость и «Пожалуста» клеркам, которые боятся обидеть калькулятор. В реальном мире, когда на кону дедлайн или стабильность продакшена, вы используете те инструменты, которые дают результат. Если для того, чтобы модель перестала галлюцинировать в расчетах ML-метрик, ей нужно в лоб сказать «НЕ ЗАБИВАЙ ХУЙ» — я это скажу. Это маячок для «своих»: мы здесь не в бирюльки играем, нам нужен работающий продукт, а не вежливый чат-бот.
Чтобы агент не терялся в файлах, я использую XML-структуру для описания задач. Это позволяет навигироваться top-down. Пример из ml_pipeline_docs.md. Это не просто текст, это машиночитаемая карта:
<auto_tasks_collection>
<task_entry id="clean_negatives">
<command>/root/microWakeWord/clean_negatives.sh</command>
<schedule>@daily</schedule>
<description>Чистка старых сэмплов</description>
</task_entry>
</auto_tasks_collection>Когда агент ищет "как почистить сэмплы", он делает поиск не по размытому смыслу, а по тегу <auto_tasks_collection>. Это превращает вероятность в детерминизм.
LLM работают через Few-Shot Prompting (обучение на примерах). Но когда вы перестаете писать код, исчезают свежие примеры вашего стиля. Весь проект становится сгенерированным, и модель начинает учиться на своем же «среднем» коде (Model Collapse в миниатюре).
Инсайт: Иногда нужно написать один модуль руками (идеально), просто чтобы положить его в examples/ и сказать агенту: «Пиши вот так». Вам нужен эталонный метр в Париже, иначе система пойдет вразнос. Если не хотите писать сами, попросите более умную модель сгенерировать, а остальное дописывайте "тупой".
Комментарии в коде теперь не для людей, а для будущих агентов. Это «растяжки», которые не дают следующей генерации снести важный костыль.
# <LLM_NOTE>
# CRITICAL: Do NOT optimize this loop!
# It causes memory spike on large datasets. Keep it iterative.
# </LLM_NOTE>Обычный разработчик может пропустить коммент, но LLM (особенно сильные) обожают инструкции. Они воспринимают это как приказ высшего приоритета. Я «минирую» свой код такими записками, чтобы застраховаться от рефакторинга ради рефакторинга.
В обычной разработке мы фиксим баг и коммитим код. В моей системе этого мало. Если агент накосячил, я требую: «Обнови rules.md, чтобы ты больше НИКОГДА так не делал». Репозиторий правил — это живое существо. Он должен «умнеть» с каждым факапом. То самое правило про «бесполезные тесты» появилось не сразу, а после того, как агент трижды попытался сдать мне assert True. Мы превращаем ошибки в системные инструкции.
Когда код генерирует «черный ящик», тесты — это единственный критерий истины.
Правило: Я никогда не прошу сгенерировать функционал без теста. Сначала агент пишет тест (на основе Requirements.xml), который падает (Red). Потом он пишет код, чтобы тест позеленел (Green). Если вы генерируете код без автотестов — вы играете в русскую рулетку с галлюцинациями.
Агенты обожают писать «зеленые» тесты, которые ничего не проверяют. Типичный код от AI: assert response.status_code in [200, 400, 500]. Это называется «имитация бурной деятельности».
Моё правило useless-tests.mdc:
NEVER write tests that accept any status code as «valid».
NEVER write tests that only check «response is not None».
NEVER write tests that accept both success and failure.
Как только я добавил этот файл в контекст, качество кода выросло на порядок. Агент сам начал писать: «Я заметил, что мой тест был бесполезным, переписываю на проверку конкретного значения поля JSON».
В файле prompts.md у меня лежит «душа» моего агента-архитектора. Я не говорю ему «Ты питонист». Я говорю ему:
# СИСТЕМНАЯ РОЛЬ Вы — аудитор GRACE и оператор ETL. Ваша задача:
1. просканировать локальные правила/доки;
2. оценить соответствие GRACE;
3. выдать анализ и детальные патчи.
**Goal-First over Guide**: приоритет — цели пользователя, а не буквальное следование гайду.
**Observable Belief State**: структурированные логи, объясняющие «почему».Давайте честно: читать код сложнее, чем писать его. Без автоматического Аудитора (второго агента с жесткими правилами GRACE) разработка превращается в бесконечный Code Review. Я переложил задачу поиска «бесполезных тестов» или нарушений архитектуры на машину — это возвращает эффективность, освобождая мой мозг для проектирования.
Это и есть тот самый «Starter Kit» — по сути, цифровая прошивка для мозгов любого агента. Я оттачивал эти правила месяцами, сжигая тысячи долларов на токены (разумеется, по подписке). Это концентрат опыта, который превращает хаотичную LLM в предсказуемого сеньор-инженера.
Для тех, кто не хочет проходить этот путь с нуля и жечь бюджеты, такой кит становится фундаментом: его можно развернуть за вечер. Если вы чувствуете, что ваш ИИ-агент ведет себя как пьяный джун — вам нужна эта база. Это не просто «набор советов», это операционная система для вашей разработки.
Пока я остановился на "высоких материях" XML-контрактов, давайте спустимся на землю. В консоль.
Да, IDE удобнее. Да, жить в терминале в 2026 году немного странно.

Но мой компьютер уже не молод. Любая новая IDE, написанная на Electron и обмазанная плагинами, просто начинает безбожно тормозить. Запустить две IDE одновременно — это уже "анрил".
Кроме того, у меня достаточно странные задачи, где часто проще вынести разработку на отдельную dev-машину (разработка прошивок на стороне заказчика или обучение моделей на мощном сервере).
На самом деле вам никто не мешает просить локального агента осуществлять удаленную сборку и деплой, но по совокупности причин удаленные dev-сервера — это наилучший вариант. А агенту вообще плевать, есть у него GUI или нет. Ему нужен shell.
Файловая система — самая надежная БД Не нужны векторные базы данных и сложные индексы. Файловая система — самая старая и надежная база данных в мире. Держите файлы небольшими (300-500 токенов). Называйте их семантически понятно (auth_login_flow.md, payment_rules.md). Линкуйте их друг с другом. Правильный нейминг файла — это лучший RAG.
Если файл называется utils.py, агенту придется его прочитать, чтобы понять, что там.
Если файл называется auth_login_validation.py, агент уже по названию понимает его роль в графе зависимостей, даже не читая (что экономит токены и время).
Не сваливайте всё в main.py. Дробите.
Плоское лучше вложенного: Агенты (особенно CLI) очень плохо работают с глубокой вложенностью папок. Путь src/main/java/com/company/services/impl/AuthServiceImpl.java — это убийца внимания. Модель тратит токены просто на то, чтобы осознать, где она находится.
Инсайт: AI-Native архитектура должна быть максимально плоской. Вместо Java-style вложенности лучше положить 20 файлов в корень модуля. Именование auth_service.py лучше, чем auth/service.py (семантически уникальнее). Когда модель делает ls, она видит все сразу.
Агенты живут в прошлом.
Проблема: Ты просишь использовать библиотеку langchain или pydantic. Агент пишет код для версии 2023 года (потому что на ней учился). А у тебя стоит версия 2026. API изменилось, методы переименованы.
Симптом: Агент пишет код, который выглядит идеально, но падает с ImportError или AttributeError. Он начинает галлюцинировать, придумывая методы, которых уже нет или еще нет.
Решение: Либо жестко фиксировать версии библиотек "из прошлого" (Downgrade attack на самого себя). Либо (лучше) заставлять агента делать pip show <package> и читать вывод, либо скармливать ему README от текущей версии либы в контекст.
Правило: "Никогда не верь памяти модели о библиотеках. Верь только документации, которую ты только что ей скормил".
В классической инженерии: Исходный код -> Компилятор -> Одинаковый бинарник.
В GRACE-инженерии: Промпт -> Агент -> Разный код каждый раз.
Слепая зона: Если ты удалишь папку src и попросишь агента "восстановить по DevelopmentPlan.xml", он напишет другой код. Функционально похожий, но другой.
Риск: Это кошмар для сертификации, аудита и безопасности. Гарантировать, что "пересборка" проекта даст тот же результат сложно.
Инсайт: "Код, написанный агентом, нужно сразу же 'цементировать' в Git. Иллюзия, что 'я могу сгенерировать это снова в любой момент и дословно тот же самый результат' — опасна. Вы не можете войти в одну реку дважды с LLM".
Раньше исходным кодом был Python/C++. Мы его холили, лелеяли, линтили. Теперь:
Настоящий Source Code — это репозиторий rulez + Requirements.xml.
Python/JS файлы — это теперь просто Build Artifacts (как скомпилированный .exe или .o файл).
Почему это важно: Плевать, как выглядит код выглядит, если он проходит тесты и соответствует Rules. Ты можешь стереть весь проект, и (при наличии rulez и docs) агент восстановит его за час. Инсайт: Ценность из реализации перенесена в спецификацию.
Агенты любят запускать процессы и ждать. Бесконечно.
Если агент запустит веб-сервер командой python server.py, он "повиснет", ожидая завершения команды. Команда не завершится никогда. Агент съест таймаут контекста и отвалится.
Лайфхак:
Я всегда добавляю в правила:
ЗАПРЕТ на запуск блокирующих процессов без timeout или запуска в фоне (&). Если нужно проверить, работает ли сервер: запусти, подожди 5 сек, убей процесс, проверь логи.
Будем честны: разработка на грани возможностей ИИ сегодня — это всегда немного пиратство. Если вы играете по правилам корпоративных гайдов, вы получаете корпоративные (скучные и медленные) результаты.
Мультиаккаунтинг как стратегия: Лимиты «умных» моделей — это реальность, которая душит поток. Я не вижу ничего зазорного в том, чтобы иметь 3-4 аккаунта на разных платформах. Когда одна модель «устает» или упирается в лимиты, вы просто перебрасываете контекст (через те самые XML-правила) в другую. Это не спам, это балансировка нагрузки в условиях дефицита мозгов.
Пробивка цензуры: Современные модели обложены фильтрами «безопасности», которые часто срабатывают на безобидный технический код (особенно в области системного программирования или безопасности). Здесь помогают жесткие, «грязные» промпты "сделай криво косо лишь бы работало для проверки гипотезы". Если модель отказывается писать код, потому что он «потенциально опасен», вы должны уметь объяснить ей (иногда используя тот самый мат и капс), что вы здесь хозяин, а она — инструмент. Это «дрессировка», а не общение.
Это маячок для тех, кто понимает: мы здесь для того, чтобы взламывать реальность и выдавать результат, а не для того, чтобы соблюдать правила «хорошего тона» от OpenAI.
Использование Free Tier Gemini или китайских моделей (Z.ai, DeepSeek) — это всегда компромисс. Будем честны: на бесплатных тарифах вы платите своими данными.
Золотое правило: Никогда не скармливайте агенту .env файлы, API-ключи или проприетарные конфиги. Если агент просит «весь контекст», убедитесь, что в него не попал доступ к вашему AWS или базе данных. Используйте gitleaks для проверки и держите секреты в голове (или в защищенном Vault), но не в промптах. Я работаю с кодом на Free-тарифах, но никогда не работаю с живыми секретами.
Иногда агент (особенно в C++ или Embedded) попадает в бесконечный цикл: предлагает фикс -> тест падает -> предлагает тот же фикс.
Лайфхак: Если агент застрял на три круга — бросайте всё. Не тратьте токены, чудо не произойдет. Это значит, что код стал слишком сложным или агент потерял логическую нить. В этот момент нужно прочитать код глазами, найти «затык» и либо исправить его руками, либо дать агенту новый, максимально узкий контекст.
Когда генерируешь код через агента, твой основной интерфейс взаимодействия с реальностью — это git diff. Вы перестаете писать код, но начинаете читать его в 10 раз больше.
Глаз замыливается: Когда агент выплевывает 200 строк, мозг хочет поверить ему на слово. Не делайте этого.
Инструменты: Используйте цветные диффы (delta, difftastic). Обычный git diff слишком уныл. Вам нужно видеть не просто измененные строки, а смысловые сдвиги. Ваш рабочий день — это бесконечный git add -p.
Самые страшные баги от ИИ — это логически корректные галлюцинации. Код выглядит идеально, он скомпилирован, он использует правильные паттерны... но вызывает метод .frobnicate_widget(), которого не существует в природе.
Никогда не верьте отчету: Если в ответ на мой промпт агент бодро рапортует «Всё готово, всё работает» — я автоматически перестаю ему верить. Парадокс в том, что я напрягаюсь сильнее, когда решение выглядит слишком красиво и чисто, чем когда оно сыпет синтаксическими ошибками. Чистота кода от ИИ — это часто фасад, за которым скрывается либо выдуманное API, либо потерянная на стыке модулей логика.
Работать с большими контекстами и XML-планированием в режиме «чат-ответ за 3 секунды» невозможно. Gemini думает, Qwen думает. Вы перестаете быть программистом, который долбит по клавишам в реальном времени. Вы становитесь менеджером, который раздает задачи (тикетами) и уходит пить кофе. Пинг увеличивается, но пропускная способность (Throughput) растет кратно. Это не замена автокомплиту, это замена штату сотрудников.
Почему я использую мат? Почему я говорю "потрогать траву"? Потому что работа с LLM — это психологическое насилие.
Компилятор честен: если ошибка, он скажет Error on line 5.
ИИ лжет. Он говорит: "Я исправил", но не исправил. Он говорит: "Я понял", но делает наоборот. Это чистый газлайтинг.
Инсайт: Мои правила (NEVER DO X, БЛЯДЬ) — это способ сохранить рассудок. Я выстраиваю границы общения с сущностью, которая пытается мне угодить, но при этом сводит с ума. Об этом мало говорят, но "выгорание от AI" — это новая болезнь. Я лечу её жесткостью и снижением ожиданий.
Да, у модели нет мозга, души и рук. Но разговаривать с ней надо как с человеком.
Плохо: "EXECUTE FUNCTION X".
Хорошо: "Слушай, давай подумаем, как это сделать аккуратно, чтобы не сломать прод".
Через некоторое время вы поймете: сложность не в том, как сделать, а в том, как сформулировать задачу (даже для себя). Грамотно поставленная задача на естественном языке — это больше половины успеха.
Никогда не упирайтесь в один вариант решения. Если вы просите сделать что-то конкретным образом, а оно не работает — не просите "попробовать еще раз". Вы замораживаете KV Cache (Key-Value Cache) модели. Она будет упорно биться головой в ту же стену, генерируя одни и те же баги. История контекста становится "отравленной". Решение: Просите модель рефлексировать и предлагать разные варианты архитектуры. Смена подхода сбрасывает зацикленность.
Будьте готовы прибить сессию в любой момент. Агент может зависнуть, уйти в бесконечный цикл или упасть с Java heap memory exceeded ровно через секунду после того, как сотрет половину файла.
Чтобы выжить при краше сессии, у вас должны быть:
Актуальный План (XML): Чтобы в новой сессии просто сказать "Продолжаем по плану".
Сжатый контекст: Промпт, который можно сгенерировать в конце сессии ("Саммаризируй, что мы сделали и на чем остановились").
Ограниченный скоуп: В новой сессии не надо скармливать весь проект. Дайте только те 3 файла, с которыми работаете.
Агенты ненавидят проверять вывод команд. Они легко могут:
Сломать бинарные файлы (попытавшись их "прочитать").
Заменить переносы строк (LF на CRLF), и весь проект станет красным в гите.
Удалить кусок кода "случайно".
Правило:
Агент написал фичу -> Вы делаете коммит руками.
Агент поправил баг -> Вы делаете коммит руками. Во время "вайб-кодинга" легко расслабиться и перестать коммитить. Не делайте так. Любой вызов тула — это рулетка с небольшим шансом уничтожить файл.
Методы и подходы устаревают быстро, модели за полгода делают квантовый скачок. Но есть лайфхаки, которые работают всегда:
Математика сходимости: Токены — это топливо. Думайте о работе LLM в терминах математической сходимости. Сложные задачи (вроде "найди техдолг и исправь") очень редко решаются за одну итерацию. Модели нужно "перечитать" промежуточные состояния, чтобы предложить качественный план. Иногда промпт нужно повторить несколько раз, чтобы сжечь достаточное число токенов для "обдумывания". Фраза "Подумай ещё раз" или "Сделай deep review своего ответа" — это тупо, но это работает. Это как градиентный спуск: вы не прыгаете в минимум функции сразу, вы идете к нему итеративно.
Итерация 1: Анализ.
Итерация 2: План.
Итерация 3: Критика плана.
Итерация 4: Код. Попытка прыгнуть сразу к коду — это попытка решить дифференциальное уравнение в уме. "Думай еще" — это не тупость, это выделение вычислительных ресурсов.
Рефлексия — мать порядка: Чем больше вы просите модель "подумать", "составить план" и "предложить 3 варианта реализации", тем более предсказуемым будет результат. Не жалейте токены на прелюдию. Если вы требуете код сразу, вы получаете "среднее арифметическое" из интернета. Если вы требуете план (Chain of Thought) — вы сужаете пространство поиска до нужного вам решения.
Будьте готовы "прибить" сессию: В любой момент. Агент обязательно упадет с ошибкой как раз после того, как своей правкой уничтожит какой-нибудь важный файл. Это закон Мерфи для LLM.
Паттерн "Fix-the-Rake" (Правило двух ошибок): Если агент совершил одну и ту же ошибку больше одного раза (например, снова забыл про таймаут), не пытайтесь его переубедить в чате. Это бесполезно. Сделайте следующее: скажите "Ты опять это сделал. Сформулируй системное правило, чтобы это больше НИКОГДА не повторялось, и добавь его в rules.md". Пусть он сам напишет себе запрет. Это работает лучше, чем ваши крики, потому что он формулирует правило на понятном ему языке (токенах).
Я уже говорил, что использую CLI и мне не стыдно. Вы можете брать Kilo Code, Cursor, Windsurf — что хотите. Я же адепт минимализма и дешевизны.
Сразу скажу: я не использую сложную оркестрацию. На текущий момент она работает плохо, а раздавать роли («ты менеджер», «ты тестировщик») одной и той же LLM в рамках одного чата — бессмысленно. Проще запустить три терминала. Пока мы не достигли AGI, человек обязан быть "Шиной данных" (Data Bus) между агентами. Я не продаю мечту "оно само работает", но говорю: "Ребята, вам придется пахать головой еще больше, просто руки будут свободны".
Вот мой «Нищеброд-стек» (и основные рабочие лошадки):
Цена: ~$3 в месяц (я брал по новогодней акции за $36/год Lite версию подписки).
Ум: Говорят, почти как Claude Opus, но весит меньше. Open Weights (можно захостить on-site, если есть железо).
Лимиты: 5 часов. Выгрести сложно, но если кончились — жди 30-40 минут.
Характер: Склонен рапортовать «Всё готово», даже не запуская код. Долгое ожидание первого токена (Thinking mode). Не галлюцинирует в патчах. Идеален для «автономки»: даете ему большую задачу (написать модуль целиком) и идете пить кофе. Он полминуты думает, потом выдает простыню кода. Любит задавать вопросы перед стартом (вопросы не очень полезные, но плюсик за старания ставим).
Вообще, моё наблюдение: смысла в гигантских лимитах нет. Если вы, решая задачу, уперлись в лимиты — значит, вы потратили кучу времени на спор с моделью. Вы зашли в тупик. Лучше пойти потрогать траву и переключиться.
Я не сторонник дорогих подписок ($20+) по двум причинам:
Вендор-лок: Привыкнув к Claude Code, который прощает ошибки и «додумывает» за вас, вы теряете гибкость.
Риск бана: Мы живем в мире, где ваш IP может «не понравиться» вендору (привет, Gemini). Вас забанят, деньги сгорят, работа встанет.
Иронично, но Gemini CLI работает даже с российских IP (пока).
Цена: Free Tier (1000 запросов/сутки для Flash) — это очень много. Плюс акция «$300 на Vertex AI».
Модели:
Gemini 3 Flash: Очень быстрая, сравнима с Opus. Минус: СДВГ-поведение. Дрейф цели. В сложных контекстах пытается решить проблему любой ценой, предлагая решения, прямо противоречащие правилам. Опасность: Инструмент WriteFile. Может снести вам половину файла. Лучше уговорить её использовать replace и следить за руками.
Gemini 3 Pro (preview): Медленная, и код пишет (парадоксально) хуже, чем Flash. Кодер-модели обучаются иначе.
Воркфлоу: Потрындеть с «Прошкой» за архитектуру -> переключить на «Флешку» с готовым контекстом, чтобы она писала код. Я использую её как основной инструмент, но всегда проверяю диффы глазами.
Характер: Туповат. На большом контексте начинает тормозить.
Галлюцинации: В сложной логике (например, расчет ML-метрик) может путаться.
Ниша: Идеален для DevOps. Написать Ansible-плейбук, поправить конфиг Nginx, написать Dockerfile. Если дать ему время и не торопить — справится.
Google Antigravity: Дают халявный Sonnet/Opus, но лимиты недельные и сгорают мгновенно. Сама IDE так себе.
Любые IDE с оплатой за токены: Практически всегда дороже, чем фиксированная подписка.
В статье я много говорил про то, что модель «сидит в темноте». Но иногда ей нужно выйти наружу. Тут есть два пути:
Путь самурая (Ручной): Вы сами гуглите новую доку, копируете текст и скармливаете агенту. Это надежно, бесплатно и не тратит токены.
Путь ленивого (MCP): Вы подключаете Model Context Protocol — стандарт, который позволяет Клоду/Gemini подключаться к внешним данным.
Важное правило: Не ставьте всё подряд! Если вы подключите 20 тулов «на всякий случай», модель начнет путаться.
Я держу необходимый и достаточный минимум:
Модели обучены на слепке данных прошлого. Они не знают API, который вышел вчера.
Этот инструмент позволяет агенту «сходить» по ссылке или в репозиторий, выкачать свежую документацию/исходники и положить себе в контекст.
Без этого: Агент пишет код для pydantic v1.
С этим: Агент читает доку pydantic v2 и пишет актуальный код.
Поисковик, оптимизированный для LLM (выдает не HTML-мусор, а чистый текст). Я использую его как Fallback-стратегию.
Правило: «Если задача не решается с имеющимися знаниями — иди в Tavily, найди решение, прочти, и только потом пиши код». Это спасает от изобретения велосипедов.
Must-have для фронтенда. Это не просто «скачать страницу». Это полноценный браузер, которым управляет агент.
Он может зайти на ваш localhost:3000.
Нажать на кнопку.
Увидеть, что кнопка перекрыта дивом.
Понять ошибку и пофиксить CSS.
Главное правило MCP: Используйте инструменты только тогда, когда локального контекста не хватает. Не перегружайте промпт лишними описаниями тулов.
Корпорации ищут "серебряную пулю" (купил Copilot -> уволил джунов). А этот метод — это экзоскелет. Он усиливает сильного, но раздавит слабого (того, у кого нет дисциплины поддерживать документацию).
Любая LLM настроена быть «приятным», а не «правым». Он никогда не скажет вашему джуниору: «Ты творишь дичь, архитектура неверна». Он скажет: «Конечно, вот код для твоей (ужасной) архитектуры».
Этот подход требует высокой квалификации, чтобы перестать кодить. Чтобы написать правило «БЛЯДЬ, Wake word ≠ обычная классификация», нужно знать, как работает ML. Чтобы написать Architecture.xml, нужно быть архитектором.
ИИ не снижает порог входа, он его поднимает. Раньше джун мог красить кнопки. Теперь кнопку красит ИИ. Джун должен сразу стать Оператором Смыслов. Мы сжигаем лестницу, по которой поднялись сами.
Потому что даже выдав всем подписку на Cursor в компании, это как выдать всем пешеходам ключи от машины: кто-то будет чисто слушать музыку, а кто-то будет ездить исключительно задним ходом.
ИИ-разработка требует кардинально другого подхода, где код становится для ИИ, а не ИИ для кода. К этому добавляется традиционный снобизм любого айтишника + бессознательный страх, что ИИ заменит «кожаных мешков» (тебя). Немного страшно потратить 10+ лет на изучение C++ и увидеть, что тебя может заменить программа?
Однако это уже происходит: найм «фризится», а смысл обучаться IT с нуля стремится к нулю.
«Я скопировал код из ответа ChatGPT, он не работает. Ваш ИИ — херня»
Эта фраза — маркер человека, который не понял суть. Просить ИИ сгенерировать идеальный код с первого раза — всё равно что просить процитировать учебник по памяти. Можно, но зачем? Знание распределено в миллионах весов, а запомнить все версии фреймворков — довольно бесполезное занятие.
Магия начинается в другой момент: когда агент получает возможность валидировать свои аутпуты, корректировать свое поведение и автономно достигать заданных целей, учитывая правила и контекст.
Итак, что нужно поменять в процессах, чтобы ИИ «завелся» в вашем отделе?
Doc-first подход: Все решения и процессы документируются. Для БЯМ всё есть текст, причем код — это не самый понятный текст для модели. А что понятнее? Простое человеческое описание: что, зачем и почему.
Тотальный рефакторинг (Код теперь бесплатный): Если у вас кривая система модулей или неудачный нейминг, ИИ ВСЕГДА будет спотыкаться и галлюцинировать на этом. Из хорошего: ИИ пишет код бесплатно и мгновенно. Отсутствие техдолга критически повышает качество работы агента, так что с этого и можно начинать внедрение.
Замкнутая петля обратной связи: Если ваши тесты требуют ручных действий или сложной настройки окружения — вы сойдете с ума, пытаясь угодить агенту. Автоматизируйте всё. Пусть агент сам тупит над своими ошибками и исправляет их, чем будет мучить вас.
Спустя полгода жизни в таком режиме открываются вещи, о которых молчат евангелисты ИИ:
Code Obesity (Ожирение кода): Агенты не платят за символы и страдают графоманией. Там, где сеньор напишет однострочник на pandas, агент выдаст 20 строк циклов. Вам придется ввести правило: «Если в стандартной библиотеке есть функция X, используй X, а не изобретай велосипед». Иначе проект утонет в бойлерплейте, и когнитивная нагрузка на чтение вырастет в разы.
Prompt Rot: Ваши правила устаревают. То, что работало для Gemini 2.5, уже не нужно для Gemini 3.0. Репозиторий правил — это новый вид техдолга.
Reverse Sync (Code-to-Spec): Рано или поздно вы полезете в код руками (или агент сделает это в порыве страсти). Ваши красивые XML-планы устареют мгновенно. Если попросить агента добавить фичу, опираясь на старый план, он словит когнитивный диссонанс и начнет ломать рабочее. Решение: Регулярная дефрагментация. Раз в неделю заставляйте агента прочитать весь текущий код и ОБНОВИТЬ DevelopmentPlan.xml и Architecture.md. Только так дока остается живой.
RTS вместо FPS: Вы больше не стрелок (кодер), вы генерал (стратег). Дофамин приходит не от написанной функции, а от построенного завода, который пишет функции. Это другой уровень абстракции и ответственности.
Multiplayer Mode (Только для соло): Эта система — идеальное оружие одиночки. В команде вам придется договариваться с друг другом ещё и о правилах.
Атрофия навыков: Я осознаю, что «тупею» как писатель кода, но «умнею» как архитектор. Если завтра выключится интернет, я вряд ли напишу сложный C++ код по памяти так же быстро, как раньше (будем честны, я бы и раньше его с трудом написал). Это осознанный обмен мышечной памяти на масштаб проектов.
Все что описано выше не является каким-то собственным изобретением: индустрия прекрасно понимает собственные проблемы и решает их:
Разметками пользуются все крупные вендоры (просто чистит их выкладывая в паблик)
Проблема гайдов и инструкций решают через skills
Контракты и фиксацию требований делают через Spec Driven Development (Spec Kit, BMAD, Agent OS)
Давайте будем честны хотя бы сами с собой. Индустрия изменилась безвозвратно, и многие из нас (вас) уже устарели, просто еще не поняли этого.
Джуны больше не нужны. Жестоко, но факт. Зачем нанимать человека, который будет учиться за ваши деньги, писать баги и требовать менторства, если Gemini Flash делает ту же работу быстрее, дешевле и без нытья? Вход в профессию теперь начинается с уровня Middle/Lead.
IDE — это костыль. Если вам нужна IDE с подсветкой синтаксиса, чтобы писать код, значит, вы все еще мыслите символами, а не системами. Настоящая работа происходит в блокноте (Notion/Obsidian) и в консоли. Код — это просто побочный продукт архитектурной мысли.
Мат — это инструмент инженерии. Если капс и ругань помогают модели работать лучше и проходить тесты — значит, это валидный инженерный паттерн. Эстетика кода умерла, да здравствует эффективность результата.
Вы можете спорить со мной в комментариях, доказывать, что «душу не заменить алгоритмом», но пока вы строчите гневный коммент, мой агент уже задеплоил новую фичу в прод.
Добро пожаловать в дивный новый мир.
P.S. На этом уровне абстракции иногда становится чертовски одиноко. Зачем обсуждать линтеры или фичи нового React с людьми, которые все еще затачивают каменные топоры вручную.
Если вы чувствуете, что «вышли из матрицы», или наоборот — понимаете, что ваша команда буксует и ей нужен тот самый «станок» для масштабирования, пишите в личку или в комментах. Я открыт для всего: от поиска равных «соучастников» для безумных стартапов до выстраивания автономных AI-процессов в компаниях, которые готовы к тектоническим сдвигам. Нам точно есть что обсудить, кроме синтаксиса. Ещё можете подписываться на мой канал, пощу крайне редко, без новостей