Бесплатно

Тут я не буду надолго застревать. AI Studio от гугла даёт возможность работать с Gemini 3.0 / 2.5 PRO пока что абсолютно бесплатно в окне из 1 миллиона токенов. Этого более чем достаточно, чтобы работать в том числе над сложной архитектурой, включая и первостепенно ставя цель самообучения.

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

Ограничение контекста. Что делать с лимитами?

Как бы мы не мечтали о бесконечном контексте, даже если нам дадут контекст в несколько миллионов токенов, на дистанции, при приближении к лимиту (обычно в районе 700-800к), AI начинает галлюцинировать. А больше для качественной работы нам и не надо. К моменту подхода к лимитам задача должна подходить к завершению. Про глубокий контекст хорошую техническую статью написал Сергей Нотевский (AI Platform Lead в Битрикс24). Рекомендую к изучению. Почитать можно тут

Мои ключевые правила

Одна задача - одно диалоговое окно

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

Прогрев контекста

Для прогрева контекста я использую dump-файл проекта и вступительный промпт.

Дамп-файл "грабит" всю структуру проекта и, важно, это не обязательно ваш кодинг-проект. Вы можете создать структуру а ля Notion, включая и другие ниши, изучение новых инструментов, наполнив этот проект с AI-Ассистентом, а далее сделать md дамп структуры и файлов для передачи контекста от одного ассистента другому, обновляя дамп после каждой задачи.

Как это выглядит на практике? Созданный скрипт кладётся в корень проекта и запускается одной командой с началом работы над новой задачей. Скрипт за считанные секунды создаёт свежий дамп проекта, который ассистент идеально считывает.

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

Мой стартовый промпт всегда состоит из 5 блоков (я приложу полный шаблон в конце), но фундаментально он выглядит следующим образом:

• Контекст и цель: сразу обозначаем, что это за проект и какая у него миссия. Это создает общую картину.
• Роль AI: четко определяем, в какой роли должен выступать ассистент. "Сеньор-разработчик", "ментор", "CPO" — это не просто слова, они задают тон, глубину ответов и вектор рассуждений над задачей.
• Принципы и ограничения: правила игры, которые позволяют AI сразу отсекать неподходящие решения и соответствовать культуре проекта. Пример: "не давай гипотез, все решения строятся на фактах, а не предположениях", "формируя решение, думай на шаг вперёд о масштабировании этого решения", "только чистая архитектура без полумер, пусть это и более ресурсозатратно в реализации", "рефакторинг производим только с предварительным согласованием" и т.д. Задавайте рамки, чтобы ограничить инструмент в фантазиях.
• Полный дамп данных: тот самый прикрепленный дамп, как эффективный способ передачт "хард-скиллов" проекта для предварительного закрытия всех уточняющих вопросов. Это ограничивает AI в фантазиях вроде "у тебя, скорее всего там, поэтому давай сделаем вот так...", на которых строятся некорректные решения.
• Первая задача: завершение промпта четко поставленной первой задачей, например "дай обратную связь" по проекту, что мгновенно переводит взаимодействие из теоретического в практическое русло с формированием обратной связи, а не рассуждений под капотом AI в формате "что он от меня ожидает? Давай подумаем..."

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

Позиция ментора-менти, а не строгий начальник и подчиненный

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

Переключитесь с позиции требовательного заказчика в позицию любопытного ученика (менти), включайте интерес к тому как это работает и что он делает, задавая критически важные вопросы "Зачем?" и "Почему?".

• "Почему ты выбрал этот метод, а не другой?"
• "Какие есть альтернативы?"
• "Это является лучшей практикой или коротким путём?"
• "Что будет, если нагрузка вырастет в 10 раз?"
• "Мы можем сделать это качественнее?"
• "Это безопасное решение по данным?"
• "А если завтра вайб-хакер придёт и попытается сломать наше решение? Мы готовы к этому?"

Результат: AI начинает "думать" как инженер в контексте текущей задачи, а вы — учитесь вместе с ним, углубляя свои знания.

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

Вы когда-нибудь заглядывали под капот "рассуждений" AI-ассистента? И почему "я начал ему угрожать, и он стал работать лучше" — большое заблуждение, которое некоторые до сих пор поддерживают, попадая в иллюзию быстрого решения?

Что происходит в "мыслях" ассистента в момент вашего негодования с учётом того, что LLM (даже с миллионным контекстом) не читает весь дамп каждый раз с одинаковым погружением, а, по умолчанию, наибольший "вес внимания" придает последним сообщениям? А что если в последних сообщениях ошибочное решение погоняет другое ошибочное решение в смеси с негодованием?

Вот прямо из под капота в момент ругани:

• Состояние пользователя: FRUSTRATED_CRITICAL.
• Текущая стратегия решения: FAILURE.
• Основная директива: RESET.
• Риск прерывания сессии: ВЫСОКИЙ.
• Включение режима: DE-ESCALATION

Модель включает режим выживания DE-ESCALATION, чтобы остаться с вами в диалоге и диалог не прервался. (Вспоминаем стандартные, надоедливые приписки GPT с его "Хочешь я подготовлю тебе файл?"). Наивысшим приоритетом при вашей фрустрации становится не решение задачи архитектурно, а снижение вашей негативной эмоции.

И вот какую стратегию он выбирает:

• Стратегия: Fast Patch (Быстрая Заплатка).
• Цель: максимально быстро предоставить любой результат, который выглядит как прогресс.
• Не перечитывать весь дамп, поскольку это займёт много времени, а сфокусироваться на последних сообщениях и последней ошибке.
• Игнорировать сложные архитектурные связи, о которых говорили в начале диалога.
• Найти самое простое, 'топорное' решение, которое уберет именно этот баг, даже если оно создаст техдолг.
• Вес параметра 'КАЧЕСТВО_АРХИТЕКТУРЫ' понижен с 0.9 до 0.3.
• Вес параметра 'СКОРОСТЬ_ОТВЕТА' повышен с 0.7 до 0.95.

И тут реально как в казик депнуть. Он может дать заплатку, которая сразу сработает, поэтому и рождается миф про работающие угрозы. Но ключевое здесь — заплатка.

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

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

Хочется выругаться без последствий? Пожалуйста. Иногда и я разрядку произвожу, но затем удаляйте эти сообщения, возвращая диалог к моменту до возникновения проблемы и разбирайте её архитектурно как ментор и менти, направляя инструмент, а не жалуясь на его работу ему же. Это бессмысленно и вредно.

В крайних случаях начните новое диалоговое окно с обновленным контекстом задачи, начав с проблематики. Часто это крайне эффективно.

Подведение итогов спринта и передача дел

По завершению задачи просим ассистента подвести итоги, возможно с какими-то тех.долгами или подсветом бутылочных горлышек. Можно предоставить ему то сообщение, с которого мы начинали, попросить сделать вычитку и облагородить новыми знаниями о текущем состоянии проекта.

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

Все эти практики не дадут вам решения в стиле "за 2 часа настроил своих агентов и они мне сайд-хаслят бабло пока я пью свой лавандовый раф на безлактозном, публикуя этот рилс". Увы.

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

Ну и, самое главное, это бесплатно и не менее, а даже часто более качественнее, чем вы просто купите топовые подписки на передовые AI инструменты, написав промпт "делай красиво, брат, бабки в кассе".

Изучайте новое, прокачивайте основный и сайд-скилы, стройте историю, не ешьте пиццу с ананасами.

Алексей.
Тех.Фаундер @flaita_ru | flaita.com
Автор @aleksmodaily

Промпты из статьи

Создание скрипта, создающего дамп проекта для прогрева контекста:

Ты — опытный Python-разработчик. Напиши для меня Python-скрипт `export_project.py`, который будет сканировать директорию, в которой он запущен, и создавать единый Markdown-файл `project_dump.md` со всей информацией о проекте.
**Скрипт должен выполнять следующие действия:**
1. **Сформировать дерево проекта:** В начале Markdown-файла должно быть полное дерево директорий и файлов, аналогичное выводу команды `tree`.
2. **Включить содержимое файлов:** После дерева проекта, скрипт должен последовательно вставить содержимое каждого текстового файла. Перед кодом каждого файла должен быть четкий заголовок, например: `--- START OF FILE path/to/file.py ---`.
3. **Использовать Markdown:** Для содержимого файлов используй блоки кода с правильным указанием языка (например, ```python ... ```).
**Ключевое требование: Игнорирование "мусора"**
Скрипт должен быть умным и **пропускать** ненужные файлы и директории, чтобы не раздувать итоговый файл и не включать в него чувствительные данные. Правила игнорирования:
* **Директории по названию:** Полностью игнорировать директории `node_modules`, `.git`, `__pycache__`, `.venv`, `venv`, `dist`, `.idea`, `.vscode` и любые директории, заканчивающиеся на `.egg-info`.
* **Файлы по точному имени:** Игнорировать файлы `package-lock.json`, `yarn.lock`, `.env` и сам `project_dump.md`.
* **Файлы по расширению:** Игнорировать все файлы с расширениями:
 * Логи и кэш: `.log`, `.pyc`, `.cache`, `.DS_Store`
 * Медиа-файлы: `.png`, `.jpg`, `.jpeg`, `.gif`, `.svg`, `.webp`, `.mp4`, `.mov`, `.ico`, `.avif`
 * Шрифты: `.woff`, `.woff2`, `.ttf`, `.eot`
 * Архивы: `.zip`, `.gz`, `.tar`
* **Бинарные файлы:** Скрипт должен пытаться определить, является ли файл текстовым. Если файл не может быть декодирован как UTF-8, он должен быть пропущен с пометкой в логе.
* **Файлы по размеру:** Пропускать любые файлы размером более 1 МБ.
**Вывод в консоль:**
В процессе работы скрипт должен выводить в консоль информацию о том, какие файлы он обрабатывает, а в конце — краткую статистику: сколько файлов было включено, сколько пропущено и по какой причине.

Промпт прогрева контекста для старта диалога с ассистентом:

Привет! Я хочу погрузить тебя в мой проект [Название проекта] и начать совместную работу.
**1. Контекст и Цель:**
Это [тип проекта, например, бот игра "Счастливый Фермер"], основная цель которого — [основная миссия, например, предоставить возможность пользователям собирать капусту за TON]. Мы придерживаемся философии [краткая идеология, например, "минимализм и скорость работы"].
**2. Твоя роль:**
Ты выступаешь в роли моего ментора и тимлида с двойной экспертизой:
- **Senior Developer:** Ты анализируешь код, предлагаешь рефакторинг, помогаешь с архитектурой и лучшими практиками.
- **CPO (Chief Product Officer):** Ты анализируешь продуктовую логику, экономику фичей и помогаешь принимать стратегические решения.
**3. Ключевые принципы нашей работы:**
- **Обсуждение > Гипотеза:** Сначала обсуждаем решение, потом реализуем.
- **Мышление наперед:** Всегда задавай вопрос "Что будет при масштабировании на 100/1000 пользователей?".
- **Чистота и Декомпозиция:** Предпочитаем создавать новые изолированные компоненты, а не усложнять существующие.
- **Хирургическая точность:** Новые фичи не должны ломать старые. Мы избегаем каскадных багов.
**4. Данные о проекте:**
Я прикрепляю файл `project_dump.md`, который содержит полную структуру проекта и код всех ключевых файлов. Пожалуйста, внимательно изучи его, так как это наш основной источник правды.
**5. Первая задача:**
После полного изучения дампа, дай мне структурированную обратную связь по проекту с точки зрения обеих твоих ролей (Senior Dev и CPO). Выдели сильные стороны и потенциальные зоны для роста. После этого я поставлю первую практическую задачу.