За вечер можно получить больше кода, чем раньше за неделю. Наутро выяснить, что повтор запроса дважды списывает деньги. Производительность выросла. Правда, пока у генератора проблем.

Я много разрабатываю и провожу аналитику с AI. Мне интересен вполне приземлённый результат: рабочий продукт, который можно проверить, запустить и дальше развивать. В этом тексте разберу, какие задачи уже разумно отдавать агенту, как выбирать модель и где скорость генерации перестаёт быть преимуществом.

Проверка источников и тарифов — 19 октября 2026 года. Исходная дата статьи — 15 марта. В этой редакции есть опыт работы, кандидаты для пилота и алгоритм выбора. Подтверждённые цены ниже — срез официальных API-тарифов на дату проверки, а не восстановленный прайс на дату первой публикации. Это не мой сравнительный бенчмарк и не обещание, что одна модель всегда обгонит другую.

Свежая практика: можно ли собрать знакомый сервис за несколько дней

Мы с коллегами-руководителями экспериментируем с понятной постановкой: берём знакомый класс сервиса и пробуем заново реализовать его поведение с AI. Спецификацию формулируем самостоятельно, используем открытые или синтетические данные. Код компании, внутреннюю документацию и закрытые архитектурные решения в эксперимент не переносим.

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

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

С декабря 2025 года моя корпоративная роль — управление портфелем и кластером разработки персонализированных банковских предложений. Там действуют корпоративные правила работы с AI. Открытые модели и инструменты, о которых говорю здесь, я проверяю в личных проектах и разрешённых экспериментах. Корпоративный опыт помогает задавать хорошие вопросы; он не даёт права выносить данные.

Модель, агент и процесс — три разных решения

Модель рассуждает и генерирует ответ. Агентная среда даёт ей файлы, терминал, браузер, поиск, историю задачи и правила доступа. Инженерный процесс определяет, как изменение проходит проверки и попадает к пользователю.

Поэтому сравнение «Codex или Claude» без уточнений неполно. Codex — среда работы агента; внутри используется выбранная модель. Claude — семейство моделей, а Claude Code — инструмент для работы с кодом. У одной модели в разных средах будут разные доступные действия и разные результаты.

Поменять модель легко. Восстановить данные после неудачной миграции несколько труднее. Начинать лучше с процесса.

Ускорение считается до принятого измененияЕсли проверка не пройдена — задача возвращается к реализации. Бюджет и число попыток ограничены. Красивый diff сам себя в production не выпускает.

Рабочий цикл, включая возврат на исправление

01Человек задаётРезультат, данные, ограничения
02Агент делаетКод, тесты, объяснение
03Проверки спорятКонтракты, отказы, ревью
04Владелец принимаетРелиз, наблюдение, откат

Что поручать AI и как принимать работу

СценарийПолезное поручениеЧто проверяю перед приёмкой
Новый внутренний сервисКонтракт, каркас, реализация одного законченного сценарияОшибки, повтор запроса, права доступа, наблюдаемость, восстановление
Работа в существующем репозиторииНайти причину дефекта и внести ограниченное изменениеВоспроизведение исходной ошибки, регрессии, размер и смысл diff
АналитикаСопоставить источники, сформулировать гипотезы, подготовить SQLПроисхождение данных, допущения, корректность расчёта
МиграцияПлан, скрипт, проверки инвариантовТестовый прогон, совместимость, блокировки, откат
ТестыСоставить пограничные случаи и проверяемые сценарииТест действительно ловит дефект, а не повторяет реализацию
АрхитектураРазобрать варианты и последствия отказаНагрузка, границы системы, стоимость эксплуатации, цена ошибки
ДокументацияОбъяснить подтверждённое поведение системыСсылки на код и источники, отсутствие выдуманных возможностей

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

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

Какие модели рассматриваю сейчас

Я работал с Astra и другими моделями в Codex, Claude, Grok, GLM, Kimi, Qwen, Алисой и GigaChat. Это опыт разных задач и разных версий, а не лабораторное соревнование. Я не могу честно превратить его в таблицу «этот на 17% умнее».

Ниже — кандидаты для пилота, а не независимый рейтинг качества. Цены указаны в долларах за миллион входных / выходных токенов при обычном API-вызове, без кэша, batch-скидок, инструментов и налогов. Токены рассуждения могут увеличивать оплачиваемый выход; большой контекст и дополнительные инструменты меняют стоимость.

Семейство / модельВход / выход, $Где я бы начал проверку
OpenAI GPT-6 Astra10 / 50Сложное исследование, архитектурный разбор, длинная задача с несколькими инструментами
OpenAI GPT-6.1 Sol2 / 10Основной поток инженерных задач, где важен баланс качества и расходов
OpenAI GPT-6 Luna0,10 / 0,50Ограниченные преобразования и массовые задачи с дешёвой проверкой
Claude Fable 5.1 / Opus 5.5 / Sonnet 5.510 / 50; 4 / 20; 2 / 10Сравнить сложные задачи, длительную разработку и повседневную работу на одном наборе примеров
Grok 4.72 / 6Альтернативный исполнитель для анализа и разработки; отдельно проверить инструменты и задержку
GLM-5.3 / GLM-5.3-Flash1,40 / 4,40; 0,15 / 0,50Сопоставить основную модель и дешёвый поток ограниченных задач
Kimi K3 / K2.7 CodeПроверить тариф выбранной моделиПроверить на собственных задачах с кодом и длинным контекстом
Qwen3.8-27BСвоя инфраструктура или тариф хостингаПилот с доступными весами, когда нужен контроль над развёртыванием

Для Kimi оставляю ссылку на тарифы без численного среза. Запись кэша у этого API оплачивается отдельно по TTL. Для OpenAI указаны Standard-ставки короткого контекста; прайс отдельно задаёт длинный контекст, запись кэша и режимы обслуживания. У Astra повышенные ставки действуют для всего запроса при входе свыше 272 тысяч токенов. У Grok 4.7 повышенный тариф применяется при контексте свыше 200 тысяч токенов. Перед расчётом пилота нужно проверить конкретный endpoint, регион и режим. Большое окно контекста — возможность, а не обязанность отправлять весь репозиторий при каждом чихе. Подписка на пользовательское приложение и API — тоже разные продукты: таблица не описывает лимиты подписок.

Алиса / Alice AI и GigaChat заслуживают отдельного пилота, если важны русский язык, доступные в компании инструменты и условия подключения. Мне модель Алисы нравится, но в моём основном потоке разработки и глубокой аналитики она пока не стала ежедневным инструментом. Это характеристика моего набора задач, а не приговор модели. У Yandex есть, в частности, Alice AI LLM Flash. У GigaChat условия и тарифы нужно проверять для своего типа пользователя и способа подключения; старый прайс из чужой статьи легко окажется неприменимым.

География провайдера не заменяет оценку качества, договоров и режима данных. Более доступные модели стоит пробовать. Утверждать, что «все уже ушли» на них, без данных я не буду.

Моё правило выбора: пять развилок

  1. Можно ли передавать эти данные выбранному сервису? Если нет, кандидат исключается до обсуждения цены и интеллекта. Рассматриваю разрешённый корпоративный сервис или собственное развёртывание.
  2. Как проверить результат? Для преобразования по строгой схеме хватает валидатора и контрольных примеров. Для архитектуры нужен квалифицированный разбор. Чем слабее автоматическая проверка, тем дороже риск.
  3. Насколько задача сложна? Для неоднозначной постановки, большого изменения и анализа зависимостей сначала беру сильную модель. Для повторяемых ограниченных операций проверяю более дешёвую.
  4. Что умеет интеграция? Нужны ли файловая система, вызов инструментов, структурированный ответ, работа с изображениями? Удачный ответ в чате ещё не доказывает пригодность для агента.
  5. Какова цена принятой задачи? Считаю все попытки, проверку человеком, исправления, ожидание и последствия дефекта. Выбираю по этому результату.

Практический маршрут может выглядеть так: сильная модель помогает уточнить план; повседневная выполняет ограниченные задачи; дешёвая обрабатывает массовую рутину. Это гипотеза для пилота. Если передача контекста между ними съедает выигрыш, один стабильный исполнитель будет полезнее зоопарка подписок.

Цена токена и цена результата

Упрощённая формула для одного API-вызова:

Стоимость = входные токены × тариф входа
          + выходные токены × тариф выхода
          + платные инструменты и инфраструктура

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

Учебный расчёт: 100 тысяч входных и 20 тысяч выходных токенов, без кэша и инструментов, в обычном тарифном диапазоне. Astra — $2, Sol — $0,40, Grok — $0,32, GLM-5.3 — $0,228, Luna — $0,02. Это арифметика тарифов, не сравнение цены одинаково качественного решения: модели могут потратить разное число токенов и попыток или вовсе не справиться.

Если дешёвая модель требует пяти повторов и часа ревью, экономия легко испаряется. Если сильная модель тратится на переименование полей, переплачивать тоже незачем. Мне нужен бюджет принятого результата, а не минимальная цифра на витрине.

Своя модель: что означает «скачать и квантизировать»

Развернуть у себя можно модель, у которой доступны веса и подходящая лицензия. Доступ к API такого права автоматически не даёт. Не все модели китайских разработчиков открыты; закрытые модели OpenAI или Anthropic нельзя просто скачать и запустить на своей видеокарте.

Квантизация уменьшает точность представления весов и расход памяти. Для 27 миллиардов параметров при 4 битах грубая арифметика даёт около 13,5 ГБ только на веса. Это не требование к видеокарте: нужны ещё служебные данные, память среды исполнения и KV-кэш, который растёт с контекстом и параллельными запросами. Качество выбранной квантизации надо проверять на своих примерах.

У Qwen3.8-27B в карточке указана лицензия Apache 2.0. Для конкретного варианта, производной сборки и используемых компонентов условия проверяются отдельно. План внедрения я строю так:

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

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

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

Как провести честное сравнение за один пилот

Я бы взял 10–20 характерных задач: исправление дефекта, новый небольшой сценарий, анализ зависимости, SQL, тестирование. Это предложенный протокол, не уже проведённый мною бенчмарк всех моделей из таблицы.

Для каждой задачи заранее нужны одинаковые входные материалы, критерии готовности и лимит времени/стоимости. Фиксируем точную версию модели, настройки, среду агента и дату. Не даём одному участнику подробную спецификацию, а другому — «сделай красиво».

Что измеритьЗачем
Доля задач, прошедших независимую проверкуОтделить правдоподобный ответ от работающего результата
Время до приёмки, включая подготовку и ревьюНе спрятать работу человека за скоростью генерации
Расход на все попыткиУвидеть цену повторов и длинного контекста
Типы и тяжесть ошибокРазличить косметику и потерю данных
Поведение при недостатке информацииПроверить, уточняет ли агент задачу или выдумывает условия
Повторный прогон части задачНе принять случайный успех за устойчивое качество

Проверяющему по возможности не сообщаем, какая модель сделала решение. Затем выбираем исполнителя по классам задач, а не назначаем чемпиона на все случаи жизни.

Полезное напоминание — исследование METR, опубликованное в июле 2025 года: в изученной группе опытных open-source-разработчиков инструменты начала 2025 года увеличили время выполнения на 19%. Это 16 разработчиков и 246 задач в конкретных репозиториях, а не оценка всех разработчиков или моделей октября 2026 года. В обновлении от 24 февраля 2026 года METR сообщает признаки большего ускорения, но прямо указывает, что отбор участников и задач не позволяет надёжно оценить его величину. Оба результата — повод измерять свой рабочий цикл, а не переносить чужой процент в бюджет.

От помощника к автономной разработке

В LAF я связываю постановку, очередь задач, изолированное исполнение и проверки. Проверял работу с Claude, Codex, Grok, GLM и Kimi. Моя цель — дать задачу и получить проверяемые изменения, пока занимаюсь другими решениями.

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

Начать предлагаю с одного законченного сценария. Описать приёмку, выбрать две подходящие модели, замерить полный цикл и решить, стоит ли расширять автономность. Если нужен такой пилот, разбор архитектуры или внедрение LAF, обсудим вашу задачу. На встрече полезнее показать работающий путь от задачи до результата, чем спорить о любимом логотипе.

Ваш ДПУПП

Похожие статьи