Процесс разработки с LLM: как организовать чаты и контекст, чтобы избежать хаоса в коде

Разработка с LLM: от хаоса к системе

Ты открываешь ChatGPT или Claude, начинаешь кодить. Первые 20 сообщений — восторг. Код пишется сам, идеи льются рекой. К 50-му сообщению уже забыл, какие классы ты создал, какой был интерфейс у того сервиса, и почему функция validateUser() теперь возвращает не boolean, а объект с тремя полями.

К 100-му сообщению — полный бардак. LLM начинает противоречить самому себе, контекст деградировал, а код выглядит как собранный из кусков пяти разных проектов. Знакомо? Это не проблема модели. Это проблема процесса.

Архитектура чатов: почему один мега-чат убивает проект

Самый частый антипаттерн — один чат на весь проект. Начинаешь с «создай мне REST API на FastAPI», заканчиваешь обсуждением CSS-анимаций и конфигурации Docker. Контекстная память LLM (даже у Claude 3.7 Sonnet или GPT-5, которые актуальны на 2026 год) имеет ограничения. Но дело не только в технических лимитах токенов.

Психологически ты начинаешь относиться к чату как к коллеге, который «помнит всё». Но LLM — не коллега. Это инструмент с амнезией, которую нужно компенсировать структурой.

1 Декомпозиция по ответственности: паттерн «Один чат — одна задача»

Забудь про универсальных ассистентов. Создавай специалистов:

• Архитектор — отдельный чат. Обсуждаешь только высокоуровневую структуру: модули, интерфейсы, выбор технологий. Сюда же загружаешь документацию к фреймворкам.
• Бэкенд-разработчик — свой чат. Только бизнес-логика, API-эндпоинты, работа с БД. Контекст чистый, без отвлечений на фронтенд.
• Фронтенд-разработчик — свой чат. Компоненты, стили, состояние. Никаких обсуждений миграций базы данных.
• DevOps/Инфраструктура — отдельный чат для Docker, CI/CD, развёртывания. Особенно актуально, если используешь self-hosted LLM в своём стеке.
• Тестировщик/ревьюер — чат для code review и создания тестов. Идеально подходит для автоматизации с помощью подходов из статьи «Код-ревью умерло? Да здравствует код-ревью с LLM».

Переключаешься между чатами как между вкладками IDE. Сложно? Первые два дня — да. Потом скорость и качество вырастают в разы.

Контекст-менеджмент: что загружать, а что выбрасывать

Ты загружаешь в промпт весь файл на 500 строк, чтобы попросить изменить одну функцию. LLM тратит 90% контекста на анализ кода, который не меняется. Результат — поверхностные правки и пропущенные edge cases.

2 Принцип минимального необходимого контекста

Перед тем как вставить код в чат, спроси себя: «Что именно нужно знать модели, чтобы выполнить эту задачу?»

Как НЕ делать:

# Всё содержимое файла database.py (200 строк)
import psycopg2
import logging
from typing import Dict, List, Optional
from datetime import datetime
from contextlib import contextmanager

class DatabaseConnection:
    def __init__(self, dsn: str):
        self.dsn = dsn
        self.connection = None
    # ... ещё 190 строк ...

# Промпт: "Добавь в метод get_user обработку случая, когда user_id = None"

Как делать правильно:

# Только релевантные части
class DatabaseConnection:
    # ...
    def get_user(self, user_id: Optional[int]) -> Optional[Dict]:
        """Возвращает пользователя по ID. Текущая реализация:"""
        if not user_id:
            return None  # TODO: нужно вернуть специальный объект ошибки
        with self._get_cursor() as cur:
            cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))
            return cur.fetchone()

# Промпт: "Метод get_user должен возвращать не None, а объект {'error': 'Invalid ID', 'code': 400} если user_id = None. Не меняй остальную логику."

Разница в 10x по эффективности использования контекста. Модель фокусируется на задаче, а не парсит весь файл.

Жизненный цикл чата: когда убивать и создавать заново

Чат — как рабочая ветка в Git. Есть момент, когда её проще пересоздать, чем мержить.

Признаки того, что чат пора убить:

• LLM начинает путаться в собственных предыдущих решениях
• Ты тратишь больше времени на напоминание контекста («помни, мы договорились, что интерфейс будет таким...»), чем на новую работу
• В истории больше 50-70 сообщений (эмпирическое правило, зависит от модели)
• Ты сменил задачу внутри одного чата (перешёл с разработки API на настройку CI/CD)

3 Процедура миграции контекста

Не просто начинаешь новый чат с нуля. Экспортируешь критически важную информацию:

1. Создаёшь файл `chat_context_export.md`
2. Копируешь туда: ключевые архитектурные решения, сигнатуры важных интерфейсов, принятые конвенции именования
3. Указываешь ссылки на актуальные файлы в репозитории (модели 2026 года умеют работать с относительными путями)
4. В новом чате загружаешь этот файл как «базовый контекст»

Это занимает 5 минут. Экономит часы на исправление противоречий.

Инструменты и автоматизация: без этого никак

Ручное управление десятком чатов — ад. Нужна автоматизация.

Мой стек на 2026: Cursor для написания кода + Claude Desktop для архитектурных обсуждений + локальная модель (через LMStudio-Ollama связку) для работы с приватными данными.

Контроль качества: как не скатиться в «вайб-кодинг»

Самая опасная вещь в разработке с LLM — эйфория скорости. Код пишется так быстро, что забываешь про тесты, документирование, ревью. Через месяц получаешь legacy-монстр, который понимаешь только ты (и то не факт).

Обязательные правила:

• Каждый значимый кусок кода от LLM проходит человеческое ревью. Да, даже если «он и так работает».
• Используешь LLM для создания тестов, но не доверяешь им слепо. Запускаешь, проверяешь покрытие.
• Ведишь changelog решений. «Почему выбрали именно эту библиотеку? LLM предложил три варианта, мы взяли X потому что...»
• Раз в неделю — ревизия архитектуры. Не превратился ли проект в «вайб-кодинг» кошмар?

FAQ: частые вопросы и ошибки

Вопрос: Не слишком ли сложно вести 5 чатов вместо одного?

Ответ: Первые дни — да. Потом привыкаешь. Выигрыш в качестве и скорости окупает сложность. Это как перейти с одного монитора на два — обратно не захочется.

Вопрос: Как быть с моделями, у которых маленький контекст?

Ответ: Жёстче фильтровать что загружаешь. Используешь RLM-подходы: заставляешь модель сама решать, что важно сохранить. И чаще убиваешь чаты.

Ошибка: Доверять LLM архитектурные решения без проверки.

Решение: LLM — генератор идей, а не архитектор. Он предлагает 3 варианта, ты выбираешь один, исходя из знаний проекта, команды, бизнес-контекста.

Ошибка: Не документировать решения, принятые в чате.

Решение:

Что будет дальше? Прогноз на 2027