Я начал с простой идеи: сделать шахматный сервис, где можно играть против ИИ, который объясняет свои ходы. Не Stockfish, который просто вычисляет, а что-то более человечное, с комментариями. И сделать это быстро, используя AI-кодинг. Через три месяца у меня был работающий продакшен с 100 тысячами строк кода, сгенерированных по 3300 промптам. Вот что между ними произошло.
Идея: шахматы, но с учителем внутри
Мне надоели бездушные шахматные движки. Хотелось получить соперника, который после хода мог бы сказать: "Я пошел сюда, потому что видел угрозу на ферзевом фланге". Это превращало игру в обучение. Проблема была в том, что писать такой движок с нуля — дело на год. Писать интерфейс, бэкенд, систему анализа — еще на полгода. Я решил проверить, насколько далеко зашел AI-кодинг в 2026 году.
Первая ошибка: я думал, что можно просто описать проект в одном большом промпте и получить готовое приложение. Реальность оказалась жестче.
1 Инструменты 2026: что выбрал и почему
В апреле 2026 года выбор AI-помощников для кода уже не сводился к "ChatGPT или Claude". Я использовал связку:
- DeepSeek Coder 33B (локально) — для быстрого, контекстного рефакторинга и генерации шаблонного кода. Его последняя версия на тот момент идеально работала с Python и JavaScript без лагов.
- Claude Opus 3.5 (через API) — для сложных архитектурных решений и написания документации. Он лучше всех понимал контекст большой кодовой базы.
- Cursor IDE — как основную среду. К 2026 году она научилась почти предугадывать, какой файл я хочу изменить дальше.
- Ревью-бот на базе GPT-5.2 — кастомный скрипт, который проверял каждый пулл-реквест на уязвимости и стиль.
Это не было случайным выбором. После статей про вайбкодинг на практике я понял: один инструмент не справится. Нужен "комитет" моделей.
2 Первые 500 промптов: восторг и первая стена
Первая неделя была магией. Промпты вроде "Создай React-компонент шахматной доски с drag-and-drop" давали готовый, работающий код за минуты. Я собрал прототип интерфейса за два дня. Казалось, что неосознанный вайб-кодинг — это суперсила.
Потом начались проблемы. AI генерировал код, который работал в изоляции, но ломался при интеграции. Шахматный движок на Python не хотел общаться с WebSocket-сервером на Node.js. Логика ходов ИИ была в трех разных местах, каждый файл думал, что он главный.
# Типичная ошибка ранних промптов - AI не видит картину целиком
Напиши функцию для проверки шаха.
Напиши функцию для генерации ходов конем.
Напиши функцию оценки позиции.
# Результат: три функции, которые не знают друг о друге и конфликтуют.Когда AI тупит: как заставить его думать как инженер
Ключевой поворотный момент наступил, когда я попросил реализовать систему объяснений ходов ИИ. AI генерировал красивые, общие фразы вроде "я улучшаю контроль центра", которые не были привязаны к конкретной позиции. Код был синтаксически правильным, но семантически бессмысленным.
Тут помог прием из статьи про SDD для 1С: я начал писать промпты как технические задания. Вместо "Сделай объяснение ходов" я писал:
Задача: Функция generate_explanation(current_fen, move, engine_evaluation)
Входные данные:
- FEN строку позиции ДО хода
- ход в нотации UCI (e2e4)
- оценку движка от -10 до +10
Логика:
1. Определить тип хода: атака, защита, развитие, захват центра и т.д.
2. Если оценка резко улучшилась (>+2), найти причину: открытая линия, слабость пешки и пр.
3. Вернуть структуру { "type": "attack", "target": "weak_pawn", "phrase": "Я атакую изолированную пешку на d5, чтобы создать долгосрочную слабость." }
Ограничения: Не использовать общие фразы. Привязываться к конкретным фигурам и полям.После такого ТЗ Claude Opus сгенерировал на 80% готовую, логичную функцию. Остальное — докрутка.
3 От прототипа к архитектуре: рефакторинг кошмара
К 2000 промпту у меня был "работающий" монолит. База данных SQLite, внутри логика игры, движок, юзер-сервис — все в одном репозитории. Первые тестовые пользователи начали жаловаться на лаги. Пришлось резать.
Я выделил микросервисы:
- Game Service (Python) — управление игровой сессией, правилами.
- AI Engine Service (Rust) — сам шахматный движок на основе Stockfish 18, но с оберткой для генерации объяснений.
- User & Analytics Service (Node.js) — аутентификация, сбор статистики.
- API Gateway (Go) — для маршрутизации.
Рефакторинг с помощью AI — это особый вид боли. Нужно было не просто перемещать код, а менять парадигму. DeepSeek Coder локально справлялся с переписыванием функций под новый API, но постоянно "забывал", какие модули от чего зависят. В итоге я нарисовал полную схему взаимодействий в Excalidraw и загружал ее скриншот в Claude с промптом: "Вот архитектура. Перепиши game_logic.py для работы с AI Engine через gRPC, а не через прямой вызов". Сработало.
Вторая большая ошибка: я не настроил CI/CD с самого начала. Вручную деплоить три сервиса после каждого изменения — это ад. Потратил неделю, чтобы автоматизировать с помощью GitHub Actions, и это окупилось за два дня.
Цифры, которые имеют значение
К концу третьего месяца я сел и посчитал.
| Метрика | Значение | Комментарий |
|---|---|---|
| Всего промптов | ~3300 | Из них 40% — рефакторинг и исправление багов |
| Сгенерированный код | ~100k строк | Python, JavaScript, Rust, Go. После минификации и чистки осталось ~65k |
| Время до первого MVP | 3 недели | Против оцененных 3 месяцев вручную |
| Стоимость API | ~$420 | В основном Claude Opus и GPT для сложных задач |
| Багов в продакшене | 17 критических | Большинство — из-за неявных допущений AI в краевых случаях |
Самое интересное: 100k строк кода — не значит 100k уникальной логики. AI любит добавлять многословие, лишние проверки, шаблонные комментарии. После агрессивного рефакторинга объем упал на треть.
Ошибки, которые я бы не повторил
Если бы я начинал сейчас, я бы сделал иначе.
- Не писать юнит-тесты параллельно с кодом. AI генерировал функции, а я откладывал тесты "на потом". В итоге рефакторинг превращался в игру "что сломалось на этот раз?". Сейчас я бы использовал подход, как в кейсе Bitrix24: сразу промпт "Напиши функцию и 5 юнит-тестов для нее, включая краевые случаи".
- Доверять AI с конфигурацией инфраструктуры. Dockerfile от Claude работал, но содержал неоптимальные слои и security-дыры. Потратил день на аудит. Теперь инфраструктурный код проверяю только вручную.
- Игнорировать производительность на раннем этапе. AI сгенерировал "чистый" OOP-код для проверки шахов, который был в 10 раз медленнее bitboard-реализации. Переписывание на Rust заняло две недели. Нужно было сразу закладывать требования по скорости в промпты.
Как сейчас работает LanChess
Сервис жив. В день играют около 500 партий. ИИ-соперник имеет 10 уровней сложности, на каждом объясняет ходы своим языком (новичкам — проще, экспертам — с терминологией). Самое сложное было не генерация кода, а создание понятного слоя данных для анализа игр пользователей. Эту часть делал вручную.
Что дальше? Я экспериментирую с автономным AI-агентом, который сам пишет промпты на основе метрик продакшена (например, "пользователи уходят на шаге регистрации — улучши UX"). Пока что он делает глупости, но через пару лет, возможно, я смогу просто сказать: "Сделай клон LanChess, но для го", и через месяц получить готовый продукт. А пока — 3300 промптов, 100k строк и один работающий сервис, который доказывает, что путь от вайбкодинга к продакшену существует. Главное — не заблудиться в нем.
