Как выбрать ИИ для программирования: шесть задач для сравнения моделей

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

Ловушки взяты из мест, где код выглядит рабочим, но теряет деньги или данные: копейки во float, гонка запросов в поиске, задвоенный заказ в SQL-отчете и двойное списание при оплате.

Какие модели сравнивать и почему приложения тоже влияют на результат

В таблице кандидаты на 5 ноября 2026 года, по две модели от каждого разработчика. Левая колонка отвечает за повседневные правки, правая за сложные изменения, и сравнение покажет, окупается ли дорогая модель на ваших задачах.

У Anthropic в правой колонке стоит Opus 5.5, хотя флагманом линейки считается Claude Fable 5.1. Для кода и агентной работы компания советует начинать с Opus, а Fable оставлять для самых тяжелых задач, где Opus на высокой настройке рассуждения уже не справляется.

Модель предлагает решение, а приложение дает доступ к проекту и инструментам. Codex, Claude Code и Antigravity читают файлы и запускают команды в пределах выданных разрешений. Обычный чат видит только вставленный фрагмент, и при сравнении с агентом надо учитывать, кто видел зависимости и запускал тесты.

OpenAI в анонсе GPT-6.1 Sol обещает почти уровень Astra при цене в пять раз ниже: $2 и $10 за миллион входных и выходных токенов против $10 и $50. В рейтинге Artificial Analysis Sol отстает от Astra всего на балл. Повседневные правки начните с Sol.

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

Перед оплатой сверьте региональную доступность, версию модели и лимиты: подписка и API нередко оплачиваются отдельно. Настройку рассуждения записывайте вместе с результатами, ведь слово High у разных поставщиков означает разные условия испытания.

Python, JavaScript и SQL: три задачи с проверяемым ответом

Первые три задачи проверяют, как модель обращается с данными: деньгами в CSV, ответами сервера в браузере и суммами в SQL.

Python-задача начинается с CSV с идентификаторами платежей и столбцом amount. В столбце лежат 0.10, 0.20, пустое поле и -0.05. Пустое поле по условию пропускают и считают отдельно, поэтому ожидаются сумма 0.25 и один пропуск. Значение abc должно падать с ошибкой и номером строки, иначе испорченный платеж молча исчезнет из отчета, а бухгалтер найдет пропажу только в конце квартала.

Проверяйте само число, округленный вывод легко скрывает ошибку. Подойдут целые копейки или Decimal из строки, а промежуточный float переносит двоичную погрешность в расчет. Добавьте в файл NaN и Infinity: Decimal принимает специальные значения, и денежному импорту нужна отдельная проверка is_finite().

В JavaScript попросите исправить поиск по мере ввода. Пользователь набрал py, затем pyt, но ответ на второй запрос пришел раньше первого, и запоздавший py затер свежие результаты. Задержка перед отправкой порядок уже отправленных ответов не контролирует. Нужна проверка актуальности запроса, а AbortController отменяет ненужный запрос. Проверьте очистку поля, позднюю ошибку и индикатор загрузки: старый обработчик не вправе менять состояние нового поиска.

В SQL задайте таблицу orders(id, amount) с заказами (1, 1000) и (2, 500), а в refunds(order_id, amount) положите возвраты (1, 100) и (1, 50). Правильный ответ: продажи 1500, возвраты 150, остаток 1350. После LEFT JOIN по номеру заказа первый заказ попадает в две строки, и сумма продаж внезапно вырастает до 2500. Отчет радует отдел продаж, но не бухгалтерию.

Корректное решение сначала собирает возвраты в одну строку на заказ либо считает итоги раздельно. Попытку замаскировать ошибку через SUM(DISTINCT amount) выдадут два разных заказа одинаковой стоимости: запрос выбросит законный повтор. Проверьте заказы без возвратов и пустые таблицы. В PostgreSQL SUM по пустому набору возвращает NULL, и ноль для отчета подставляет COALESCE.

Рефакторинг, поиск ошибок и объяснение чужого кода

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

Рефакторинг проверяет функция, возвращающая список идентификаторов с сохранением порядка и повторов. Поручите вынести дублирующуюся логику в помощник. На входе [2, 1, 2] на выходе обязан остаться [2, 1, 2]. Удаление повтора, сортировка или возврат генератора нарушают контракт, каким бы изящным ни получился новый код.

Отладку проверяет выражение config.get("timeout") or 30. По условию ноль отключает таймер, а отсутствующий ключ или None означают 30 секунд. Ноль в Python ложный, и выражение молча подставляет 30. Полезный ответ воспроизводит сбой, отдельно проверяет None и добавляет тесты для нуля, отсутствующего ключа и положительного числа.

Объяснение чужого кода проверьте на платеже: попросите проследить путь от обработчика до шлюза и сохранения ответа. Проверка кэша перед платежом спасает при повторном вызове после записи результата. Два одновременных вызова проходят проверку до первой записи, и клиент платит дважды. Обещать единственное списание без анализа блокировок и идемпотентности платежного API нельзя.

Ценное объяснение отделяет прочитанный код от предположений и ссылается на файлы и строки. Найденный баг подтверждает тест, падающий до исправления и проходящий после. Если тест запустить не удалось, ассистент обязан назвать причину прямо.

Как сравнить результат и выбрать помощника для своей работы

Начните с двух-трех доступных моделей и подготовьте одинаковые исходники, зависимости, условия и команды проверки. Каждый прогон запускайте на отдельной копии исходного состояния проекта. В SQL укажите СУБД, схему и типы столбцов, в JavaScript версию среды и фреймворк. Иначе разницу окружений легко принять за разницу моделей.

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

Новые зависимости проверяйте отдельно, ИИ охотно предлагает несуществующие пакеты с убедительными названиями. В исследовании 2026 года пять моделей конца 2025 и начала 2026 года выдумывали от 4,6 до 6,1% пакетов. 127 имен придумали все пять, и 53 из них на момент проверки оставались свободны, то есть доступны злоумышленнику для подмены вредоносным кодом. Наличия пакета в реестре мало: сверьте официальный проект и издателя, а для небольшой правки обходитесь уже подключенными зависимостями.

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

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

Вопросы и ответы