Нейросеть как co-pilot, а не автопилот: как я выстроил работу с AI на реальном проекте
Меня зовут Дима. Я full-stack разработчик, и полгода назад запустил mesty.ru— геосервис событий для Уфы — в одиночку. Без команды, без инвестиций.О самом продукте я писал раньше. Сегодня — про инструмент, без которого проект занял бы не полгода, а минимум год. И про то, как я научился с ним работать правильно.
Сначала — честно о провалах
В первые недели я использовал нейросети так, как большинство: «напиши функцию которая делает X», получал код, копировал, шёл дальше. Иногда это работало. Иногда — я получал код который делал что-то похожее на X, но не совсем. И тратил больше времени на разбор чужой логики, чем потратил бы на написание своей.Проблема была не в нейросетях. Проблема была в том, что я относился к ним как к автопилоту — дал задание, принял результат. Это не работает.
Ключевой сдвиг: co-pilot вместо исполнителя
У нейросетей есть сильные стороны и слабые. Секрет не в том, чтобы использовать самую умную модель. Секрет в том, чтобы использовать только сильные стороны и контролировать слабые.
Сильные стороны:
- Быстро пишет boilerplate и типовой код
- Объясняет незнакомый синтаксис и паттерны
- Предлагает несколько вариантов решения задачи
- Не устаёт и не отвлекается на рутину
Слабые стороны:
- Не знает контекст вашего проекта по умолчанию
- Может уверенно предложить неправильное архитектурное решение
- Не несёт ответственности за безопасность и последствия
- Без чётких ограничений — делает слишком много или не то
Вывод простой: архитектурные решения, ревью результата и финальная ответственность — всегда за мной. Нейросеть исполняет по моему проекту. Не проектирует вместо меня.
Лучшая аналогия которую я нашёл: представьте что вам нужно построить дом. Вы знаете как делается — фундамент, стены, крыша. Но вы один. Другое дело когда есть бригада: вы ставите задачу, проверяете понимание, принимаете результат, делегируете следующее. Можно вести несколько задач параллельно. Разница — в скорости. Не в том, кто архитектор.
Как выглядит работа с формальным workflow
К концу проекта я перестал работать с нейросетями интуитивно и перешёл на письменные протоколы — документы с описанием роли, алгоритма и явных ограничений. Для разных типов задач — разные протоколы.Покажу на примере отладки — это одна из самых частых задач.
Протокол отладки: структура
Документ начинается с определения роли:
``` Ты — эксперт по отладке в роли советника (co-pilot), а не исполнителя-самоходки. Ключевые правила: - Ты самостоятельно исследуешь (читаешь файлы, смотришь логи) — это твоя работа - Ты не изменяешь систему без явного согласия - Ты работаешь в режиме диалога: предлагаешь → ждёшь подтверждения → действуешь ```
Затем — справка по архитектуре проекта: окружения, сервисы, порты, правила сети. Это контекст который агент получает при каждой сессии отладки — иначе он не знает, к какому серверу подключаться и через какие маршруты делать запросы.
Алгоритм, а не угадайка
Дальше — пошаговый алгоритм:
Шаг 1 — уточнить контекст: на каком окружении баг, что происходит, что должно было произойти. Не переходить дальше пока нет ответа.
Шаг 2–3 — собрать данные: прочитать код, собрать логи контейнеров, сделать тестовые запросы. Никаких гипотез до сбора данных.
Шаг 4 — выдвинуть гипотезу в строгом формате:
``` 🔍 Гипотеза: [краткая формулировка причины]
📎 Доказательства: - Лог [сервис, время]: [цитата] - Код [файл]:строка [N]: [описание] - Логика: [почему эти данные → эта причина]
⚠ Что опровергло бы гипотезу: [условие]
📊 Уверенность: [XX%]
💡 Варианты:
А) Проверка — добавить логирование, выполнить запрос, посмотреть результат
Б) Прямое исправление — [описание изменения]
Согласен?
Выбирай: А, Б или предложи свой вариант. ```
Уверенность ниже 50% — только вариант А. 50–80% — оба варианта. Выше 80% — рекомендую Б, но решение за мной.
Запрещённые действия — явно и письменно
Отдельный раздел протокола — что нельзя делать без моего явного согласия:
- ❌ Редактировать, создавать или удалять файлы с кодом
- ❌ git commit, git push, git merge
- ❌ docker restart, docker stop, docker-compose down/up
- ❌ Запросы к БД с изменением данных (INSERT / UPDATE / DELETE)
- ❌ Любые действия на prod-сервере без явного разрешения
- ❌ Выдвигать гипотезы без предварительного сбора данных
Это не паранойя. Это контроль над инструментом который работает в вашей инфраструктуре. Без явных ограничений агент иногда «помогает» — делает что-то что кажется ему логичным продолжением задачи. Последствия бывают интересными.
Какими моделями пользовался
На протяжении проекта я работал с разными моделями в зависимости от задачи: DeepSeek, Qwen Coder, Gemini, MinMax. В последнее время основной инструмент — Claude Code
Я не придерживаюсь одной модели. У каждой есть задачи где она работает лучше. Это тоже часть подхода: инструмент подбирается под задачу, а не наоборот.
Что это дало в цифрах
Без нейросетей проект занял бы не полгода, а минимум год. Это моя честная оценка.
Конкретные выгоды:
- Boilerplate — то что раньше занимало час, теперь занимает 10 минут
- Незнакомые области — когда столкнулся с настройкой Drone CI и Gitea, не тратил дни на документацию: агент объяснял и помогал отлаживать по ходу
- Параллельность — пока один агент разбирается с конфигурацией Nginx, я думаю над следующей задачей
- Ревью кода — быстрая проверка логики перед коммитом
Чего нейросети не заменили:
- Архитектурные решения (пятиэтапный конвейер парсера — моё решение)
- Продуктовые решения (что показывать, когда скрывать, как называть)
- Ответственность за результат
Главный вывод
Нейросеть — это инструмент с высоким потолком и высоким риском при неправильном использовании. Чем точнее вы описываете роль, контекст, алгоритм и ограничения — тем предсказуемее и полезнее результат.
Интуитивное использование («попрошу — посмотрю») работает для простых задач. Для сложных, многоэтапных, с доступом к инфраструктуре — нужен протокол.
Я не претендую что мой подход оптимальный. Но он работает лучше чем то с чего я начинал.