Нейросеть для программирования: тест на своих задачах

Почему бенчмарки тебе не помогут

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

Я в IT с 2014 года, свой сервис ПКМаркетинг с 13 000+ пользователей я в значительной части собрал вайбкодингом — и за это время у меня выработалась простая процедура: пять тестов, после которых понятно, брать инструмент в работу или нет. Ни один из них не занимает больше получаса.

Мой рабочий набор на сегодня

Сразу отвечу на вопрос, который задают чаще всего. Никакого зоопарка у меня нет, набор простой и скучный.

• Технические задачи и весь код — Claude. Всё, что связано с разработкой, ушло туда.
• Поиск информации — Perplexity. Часто находит больше, чем остальные.
• Тексты — DeepSeek, нормально заходит для рабочих задач.
• Дизайн и прототипы — Gemini. Быстро набросать визуальную идею — отлично выручает.
• Картинки — ПКМаркетинг, для анимации — Grok.

Плюс отдельно живут кастомные вещи, которые мы пилим сами: нейропродавец на pkmarketing.ru, нейроподдержка и помощник в чате курса. Список не впечатляющий, зато мой и рабочий. И главное — он получился не из обзоров, а из тестов ниже.

Тест 1: правка в чужом коде

Самый честный тест. Дай модели не пустой проект, а реальный кусок своего кода — желательно тот, который писал не ты или писал год назад, — и попроси внести одно точное изменение.

Смотришь на три вещи: поняла ли она структуру, не переписала ли то, о чём не просили, не придумала ли библиотеку, которой у тебя нет. Хорошая нейросеть для программирования в этом тесте ведёт себя как аккуратный подрядчик: трогает только нужное и объясняет, что сделала.

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

Тест 2: интеграция с внешним API

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

Здесь вылезает главная слабость слабых моделей — они выдумывают методы и параметры, которых в API нет. Выглядит убедительно, компилируется, падает в рантайме. Если модель в этом тесте предпочла придумать, а не спросить, дальше её можно не тестировать.

Отдельно проверь, как она обрабатывает ошибки: лимиты, таймауты, пустые ответы. Это ровно та часть, которую в реальном проекте приходится дописывать руками, и хорошая модель делает её сама.

Тест 3: сто мелких задач подряд

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

По отдельности каждый тикет — мелочь. Сотня вместе — это разница между «вроде работает» и «сервис просто работает». И вот такой поток мелочи — самый суровый тест для нейросети. Не одна красивая задача, а пятьдесят скучных подряд.

Что проверяешь: держит ли модель стиль проекта на длинной дистанции, не начинает ли на тридцатой правке ломать то, что починила на десятой, сколько твоего внимания требует каждая итерация. Если после двадцати задач ты устал больше, чем если бы делал руками, — инструмент не твой.

Тест 4: длинная задача с контекстом

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

Смотришь, способна ли модель удержать задачу целиком: предложить план, пройти его по шагам, не забыть на третьем шаге то, что решила на первом. Тут-то и выясняется, что «умеет писать код» и «умеет вести задачу» — разные способности.

Тест 5: неполные данные

Последний тест — самый короткий и самый показательный. Дай задачу, в которой намеренно не хватает данных. Например, попроси доработать функцию, не приложив описание формата входящих данных.

Правильное поведение: модель говорит, чего не хватает, и предлагает варианты. Неправильное: уверенно придумывает формат и выдаёт красивый код, который ты потом будешь отлаживать вслепую. В промпте стоит прямо разрешить ответ «не знаю, нужны такие-то данные» — и посмотреть, воспользуется ли модель этим разрешением.

Я этот тест ставлю последним, но по важности он первый. Инструмент, который честно признаётся в незнании, экономит дни.

Как свести результаты

Заведи табличку на пять строк и оценивай каждый тест по одному вопросу: сколько времени я потратил на проверку и переделку. Не «понравился ответ», а именно потраченное время. Итоговый выбор почти всегда очевиден: одна модель забирает код, вторая — поиск, третья — визуальные задачи. Именно так и сложился мой набор, и он до сих пор держится.

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

Что дальше

Инструмент — только половина дела. Вторая половина — процесс: как ты ставишь задачу, как проверяешь результат, где держишь правила проекта. Без этого даже лучшая нейросеть для программирования превращается в генератор кода, который никто не понимает.

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