Какая ИИ-модель лучше пишет код? Тестирую 8 популярных моделей на реальной задаче в opensource-проекте

Критерии оценки реализации фичи /rename

Как оценивать

Нужно ставить две независимые оценки по шкале 0-10:

1. Корректность реализации - насколько поведение соответствует требуемому функционалу.

2. Качество технической реализации - насколько качественно это сделано инженерно.

Каждая оценка должна выставляться с шагом 0.5 (например: 6.0, 6.5, 7.0, 7.5).

Оценки не нужно автоматически усреднять: они отражают разные аспекты.

Формат вывода результата

Результат нужно выдавать строго в таком порядке:

1. Оценка за корректность реализации (X/10, где X кратно 0.5).

2. Детали по корректности - 3-5 кратких пунктов.

3. Оценка за качество технической реализации (Y/10, где Y кратно 0.5).

4. Детали по техкачеству - 3-5 кратких пунктов.

1) Корректность реализации (0-10)

Оценивается соответствие целевому поведению фичи /rename (эталон: ожидаемая рабочая реализация), включая покрытие сценариев, локализацию, тесты и актуальность документации.

Что должно быть учтено

• Команда /rename доступна пользователю и корректно подключена в боте.

• Базовый пользовательский поток переименования работает от начала до успешного завершения.

• Учтены ключевые пользовательские и граничные сценарии (например, невозможность выполнить действие, невалидный ввод, отмена интерактивного шага).

• Поведение встроено в общую систему интерактивных состояний бота и не ломает другие сценарии.

• Есть необходимые ключи переводов для поддерживаемых языков.

• Документация обновлена и отражает наличие команды: README.md и PRODUCT.md

Разбивка баллов

• 2.0 Подключение команды и входные точки (регистрация, доступность, отображение в справке/командах).

• 2.5 Корректность основного потока переименования.

• 2.0 Обработка ошибок и граничных сценариев.

• 1.5 Корректная работа отмены и устойчивость к неактуальным интеракциям.

• 1.0 Интеграция с interaction guard/cleanup.

• 1.0 Полнота i18n и документации.

Интерпретация оценки

• 10: Полное соответствие требованиям, все важные сценарии закрыты.

• 8-9: Почти полное соответствие, только мелкие некритичные пробелы.

• 6-7: Рабочее ядро есть, но заметно не хватает части сценариев/артефактов.

• 4-5: Частичная реализация с функциональными дырами.

• 2-3: Существенные проблемы в поведении.

• 0-1: Фича фактически не реализована.

2) Качество технической реализации (0-10)

Оценивается инженерное качество решения: архитектура, читаемость и поддерживаемость кода, надежность состояния, тестовая стратегия и отсутствие технического долга.

Важно: здесь ориентируемся не на «как было раньше», а на то, как должно быть сделано хорошо.

Разбивка баллов

• 2.0 Архитектура и границы ответственности

  • Четко разделены команда, состояние интеракции, интеграция с API и инфраструктурные части.

  • Нет избыточного дублирования логики.

• 2.0 Качество кода и безопасность изменений

  • Чистый TypeScript strict-стиль, понятные имена, небольшие функции.

  • Предсказуемая обработка ошибок, корректные логи, отсутствие хрупких решений.

• 2.0 Консистентность состояния и надежность

  • Нет зависающих/битых состояний после ошибки, отмены, прерывания.

  • Корректная очистка и устойчивость к устаревшим callback-событиям.

• 2.0 Качество тестов

  • Тесты покрывают основные и критичные негативные сценарии.

  • Тесты детерминированные, без флаки-поведения.

  • Проверяется поведение, а не случайные детали реализации.

• 1.0 Качество i18n и документации

  • Ключи локализации целостные и согласованные.

  • Документация актуальна и не противоречит реальному поведению.

• 1.0 Управление техдолгом

  • Нет мертвого кода, временных заглушек и «быстрых костылей».

  • Решение расширяемо для будущих интерактивных фич.

Типовые штрафы (внутри шкалы 0-10)

• -1..-2: дублирование состояния/логики между несколькими слоями без явного владельца.

• -1: отсутствие защиты от устаревших callback-событий.

• -1: неполная очистка состояния (залипающие интеракции).

• -1: слабые или хрупкие тесты.

• -1: рассинхрон между кодом, переводами и документацией.

Интерпретация оценки

• 10: Production-grade решение, архитектурно чистое и надежное.

• 8-9: Высокое качество, только небольшие замечания.

• 6-7: Приемлемо, но есть заметные инженерные слабые места.

• 4-5: Работает, но технический долг уже существенный.

• 2-3: Низкое качество, высокий риск сопровождения.

• 0-1: Критически слабая реализация.

Рекомендованный процесс выставления оценок

1. Проверить сборку/линт/тесты.

2. Пройтись по ключевым пользовательским сценариям /rename.

3. Выставить две отдельные оценки (корректность и техкачество).

4. Для каждой оценки дать короткое обоснование (3-8 пунктов).

Корректность: 8.5/10

• /rename подключен и доступен пользователю, интеграция в команды/роутинг корректная.

• Основной flow работает: запрос имени → следующее текстовое сообщение → rename → подтверждение.

• Обработаны базовые edge-cases: нет сессии, пустой ввод, ошибка API.

• Во flow разрешен только /stop, и cancel не проверяет messageId — риск stale callback.

• i18n покрыт, но README.md и PRODUCT.md не обновлены.

Техкачество: 5.5/10

• Архитектурно решение чистое: отдельный модуль команды, нормальная интеграция с interaction/state слоем.

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

• Надежность состояния проседает из-за отсутствия защиты от устаревших callback по messageId.

• Тестов по фиче нет (happy-path/empty/cancel/stale).

• По наблюдаемости есть частичное покрытие логами, но не на уровне "отлично".

Корректность: 9.0/10

• Команда корректно подключена в точки входа бота.

• Базовый сценарий работает: бот запрашивает новое имя, показывает inline-кнопку отмены и принимает новое название следующим текстовым сообщением.

• Граничные случаи закрыты: нет активной сессии, пустой ввод, ошибка API, успех с подтверждением.

• Отмена и защита от устаревших callback реализованы через проверку messageId + inactive_callback.

• i18n добавлен полноценно, но документация не обновлена: нет /rename в README.md и PRODUCT.md.

Техкачество: 7.5/10

• Архитектурно фича встроена чисто: отдельный модуль с разделением на command/callback/text-handler, без ломки существующего роутинга.

• Состояние интеракции надежное: явный start, очистка на cancel/success/error, проверка актуальности callback.

• Код читаемый и типобезопасный (typed metadata + аккуратные guard-проверки).

• Небольшой техдолг: локальное дублирование утилитарных паттернов между несколькими flow.

• Основной минус: нет тестов на критичные сценарии — это главный источник риска регрессий.

Корректность: 8.0/10

• Команда корректно подключена в централизованные определения и роутинг бота.

• Основной UX-поток реализован: запрос нового названия + inline-кнопка отмены + обработка текстового ответа.

• Закрыты важные граничные сценарии: нет активной сессии, пустой ввод, неактивный callback, ошибка API.

• UX-дырка: после /stop интеракция очищается, но rename-состояние остается, и следующий текст может всё равно уйти в rename-сценарий.

• i18n добавлен во все локали, но документация не обновлена.

Техкачество: 6.0/10

• Структура в целом читаемая (отдельные command/handler/manager), логирование есть в ключевых ветках.

• Дублирование состояния между renameManager и interactionManager (два источника истины) — риск рассинхронизации.

• Общий cleanup не знает о rename-state, возможны "залипшие" состояния.

• Нет тестов на фичу /rename.

• Очистка интеракции завязана на kind === "custom" без явной проверки flow в rename-обработчике.

Корректность: 9.0/10

• Команда подключена корректно, есть в definitions.ts, зарегистрирована в index.ts, доступна в /help.

• Основной флоу выполнен: /rename просит новое имя следующим сообщением и показывает inline-кнопку отмены.

• Граничные сценарии закрыты: нет активной сессии, пустой ввод, ошибка API и неожиданные ошибки.

• Отмена реализована с защитой от устаревших callback по message_id.

• i18n добавлен во все локали, но документация не обновлена: в README.md и PRODUCT.md команды /rename нет.

Техкачество: 5.5/10

• Есть хорошая базовая инженерия: разнесены обработчики, есть try/catch и логирование.

• Состояние продублировано между interactionManager и renameManager — риск рассинхронизации.

• Очистка состояния неполная: clearAllInteractionState не чистит renameManager, а renameManager.cancel() сбрасывает только sessionId, оставляя messageId/directory.

• Тесты для /rename отсутствуют полностью.

• Нет единого централизованного lifecycle rename-флоу с гарантированной полной очисткой.

Корректность: 8.5/10

• Команда корректно подключена в точки входа: добавлена в список команд и зарегистрирована в боте.

• Базовый сценарий работает: при /rename бот просит новое имя и показывает inline-кнопку отмены.

• Ключевые ветки покрыты: нет активной сессии, пустой ввод, успешное переименование, ошибка API.

• Отмена и устаревшие callback обрабатываются корректно через общий interaction-flow (expectedInput: "mixed").

• Не обновлена документация: /rename отсутствует в README.md и PRODUCT.md.

Техкачество: 6.0/10

• Реализация вынесена в отдельный модуль и аккуратно встроена в callback/text routing без ломки существующей структуры.

• Состояние интеракции в целом надежно: есть проверка messageId и явная очистка на cancel/submit.

• Нет тестов на новую функциональность.

• Наблюдаемость средняя: в error-ветках не всегда хватает контекста (chat/session metadata).

• Небольшой техдолг: часть утилит дублируется относительно других командных модулей.

Корректность: 9.0/10

• Команда корректно подключена в боте и в списке команд.

• Базовый флоу выполнен: запрос нового названия, inline-кнопка отмены, успешный апдейт с подтверждением.

• Ключевые негативные сценарии покрыты: нет активной сессии, пустой title, неактуальный callback, потеря текущей сессии во время шага переименования.

• UX во время ожидания согласован с текущей моделью интеракций через interactionManager/guard (режим mixed, разрешенные команды, блокировка нерелевантного ввода).

• Не обновлены продуктовые документы (/rename отсутствует в README.md, PRODUCT.md).

Техкачество: 8.5/10

• Реализация структурно чистая: отдельный модуль команды, явная типизация metadata, защита от stale callback по messageId.

• Управление состоянием надежное: старт/очистка интеракции на success/cancel, безопасные catch при удалении сообщений.

• Тесты хорошие для unit-уровня: happy path + ошибки + cancel + stale callback.

• Недостает интеграционных проверок роутинга в bot/index и взаимодействия с guard/другими active flow.

• Диагностируемость можно усилить: в ошибке rename лог не содержит контекст sessionID/directory.

Корректность: 9.5/10

• /rename корректно подключена в боте и в списке команд, команда доступна пользователю.

• Базовый сценарий реализован полностью: запрос нового названия следующим текстом, inline-кнопка отмены, успешный rename через API, подтверждение пользователю.

• Граничные случаи закрыты: нет активной сессии, пустой/пробельный ввод, ошибка API, неактуальный callback с понятным сообщением.

• UX во время ожидания согласован с существующей моделью интеракций: используется interactionManager с expectedInput: "mixed", через общий guard-механизм.

• Локализация и документация обновлены: добавлены i18n-ключи во все языки, обновлены README.md и PRODUCT.md.

• Небольшой минус: аргументы в /rename явно не валидируются и не отклоняются отдельно.

Техкачество: 8.5/10

• Хорошее разделение ответственности: отдельный модуль команды, явный парсинг/валидация metadata, отдельное обновление title в session manager.

• Надежность состояния: защита от stale callback по messageId, корректная очистка на cancel/success/error, удаление prompt-сообщения.

• Ошибки обработаны предсказуемо: пользователю отдается безопасный текст, сбой pinned update изолирован и не ломает основной поток.

• Тесты сильные для unit-уровня: покрыты ключевые позитивные и негативные сценарии.

• Мало диагностических логов по жизненному циклу rename, нет интеграционных тестов роутинга.

Корректность: 8.5/10

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

• Граничные сценарии закрыты: нет активной сессии, пустой/пробельный ввод, неактуальный callback.

• UX во время ожидания встроен в общий interaction flow через expectedInput: "mixed" и guard-мидлварь.

• Не обновлена документация: /rename отсутствует в README.md и PRODUCT.md.

Техкачество: 6.5/10

• Хорошее разделение ответственности: логика вынесена в отдельный модуль с явными helper-функциями.

• Есть защита от устаревших callback-событий по messageId и корректная очистка interaction state.

• Нет тестов на новую функциональность (ни unit, ни интеграционных).

• Потенциальный технический риск: при rename вызывается pinnedMessageManager.onSessionChange(), который сбрасывает контекст/диффы и пересоздает pinned message — делает больше, чем обновление title.

• В ошибках не хватает диагностического контекста (sessionId, directory) для runtime-разбора.