Пределы AI coding agents: что показал кейс Depixelizing Pixel Art

Разбор Habr-эксперимента с Depixelizing Pixel Art: почему сложная графическая задача лучше обычного бенчмарка показывает пределы AI coding agents.

Схема Depixelizing Pixel Art для проверки пределов AI coding agents: входной пиксельный спрайт, граф похожести, перестроенные ячейки, сплайны и финальный рендер

Пределы AI coding agents: что показал кейс Depixelizing Pixel Art

По состоянию на 25 июня 2026 года хороший способ проверять AI coding agents — давать им задачу, где нельзя спрятаться за красивым кодом. Нужен результат, который видно глазами, можно прогнать на входных файлах и сложно подделать парой удачных эвристик.

Свежий Habr-эксперимент с алгоритмом Depixelizing Pixel Art как раз такой. Автор дал разным агентам один и тот же большой промпт: реализовать на Swift алгоритм из статьи SIGGRAPH 2011, без сторонних библиотек, без уточнений и без итераций правок. На выходе получился не универсальный рейтинг моделей, а полезная картинка про пределы ИИ-агентов на сложных задачах.

AI coding agents — это ИИ-агенты, которые не только пишут фрагменты кода, но и планируют работу, читают файлы, запускают инструменты, меняют проект и пытаются довести инженерную задачу до готового результата. В коротких задачах они уже часто выглядят убедительно. В задачах с длинной цепочкой зависимых шагов слабые места видны быстрее.

Что произошло в эксперименте

В основе задания был алгоритм Depixelizing Pixel Art Йоханнеса Копфа и Дани Лишчински, опубликованный в ACM Transactions on Graphics по материалам SIGGRAPH 2011. Алгоритм превращает маленький пиксельный спрайт в масштабируемое векторное представление: сначала разбирает связность похожих пикселей, затем перестраивает ячейки, извлекает контуры, строит B-сплайны и оптимизирует кривые, чтобы убрать «лесенку», но не потерять важные пиксельные детали.

Автор Habr-материала прогнал через одну и ту же постановку несколько агентов и моделей, в том числе Claude, Codex, Cursor, Cline, Antigravity, Kimi и Grok. В его эксперименте Claude Fable получил лучший результат, Codex оказался близко, но перевернул финальное изображение по вертикали, а часть систем выдала фактически nearest-neighbor апскейл вместо реализации алгоритма. Эти выводы относятся к конкретной постановке, промпту, языку Swift, входным файлам и режиму «один промпт, без доработок».

Схема Depixelizing Pixel Art: входной пиксельный спрайт, граф похожести, перестроенные ячейки, сплайны и финальный рендер
Figure 3 из работы Kopf & Lischinski: от входного 16x16-спрайта к графу похожести, перестроенным ячейкам, сплайнам и финальному рендеру. Источник: Depixelizing Pixel Art, SIGGRAPH 2011; изображение проверено 25 июня 2026 года.

Почему эта задача сложнее обычного бенчмарка

Depixelizing Pixel Art плохо похож на типичную задачу из HumanEval. Здесь нельзя написать одну функцию, пройти несколько unit-тестов и объявить победу. Надо удержать спецификацию из нескольких этапов, не потерять визуальные инварианты и согласовать математику, графы, геометрию, рендеринг и файловый ввод-вывод.

Где ломается агент Почему это трудно Что показывает кейс Depixelizing Pixel Art
Связность диагональных пикселей В 2x2-блоке две диагонали могут конфликтовать, а неверный выбор меняет форму контура. Агент должен не просто прочитать правило, а применить несколько эвристик и сохранить планарный граф.
Промежуточные представления Граф похожести, ячейки, видимые рёбра и сплайны должны быть согласованы между этапами. Один неверный переход может оставить большой код, который визуально работает как обычный ресайз.
Визуальные инварианты Контур должен сглаживаться, но глаза, рот и тонкие линии нельзя «усреднить» до мусора. Обычный тест размера файла или запуска программы не видит, что смысл спрайта потерян.
Система координат Чтение изображения, внутренний буфер и запись PNG могут считать ось Y по-разному. Даже полная реализация может получить сниженный результат из-за перевёрнутого кадра.
Самопроверка Нужны диагностические картинки и синтетические случаи, а не только финальный PNG. Без промежуточных артефактов сложно понять, где именно агент сошёл с алгоритма.

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

Что видно на результатах

Самый полезный фрагмент Habr-эксперимента — не таблица баллов, а визуальное сравнение одного и того же спрайта Boo. Несколько решений выглядят как аккуратный или не очень аккуратный апскейл; часть сохраняет форму, но портит детали; один результат перевёрнут; лучший похож на эталон из статьи. Для разработчика это гораздо честнее, чем фраза «модель справилась на 85 баллов».

Сравнение результатов AI coding agents на спрайте Boo: Antigravity, Claude Fable, Claude Sonnet, Cline, Codex, Cursor и Grok
Сравнение результатов одного Habr-эксперимента: часть агентов приблизилась к векторизации, часть фактически осталась на nearest-neighbor апскейле. Источник: Habr, PALiarMo; изображение проверено 25 июня 2026 года.

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

Это перекликается с кейсом SWE-Explore, где агенты находят файл, но теряют строки кода. В обоих случаях проблема не в полном незнании темы. Агент понимает много локальных фрагментов, но не всегда удерживает цепочку условий до конца.

Почему визуальная задача так хорошо вскрывает пределы агентов

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

В Depixelizing Pixel Art проблема начинается уже на графе похожести. В исходной статье авторы прямо описывают неоднозначность диагональных соседей: на маленьком пиксельном изображении тонкие линии кажутся связанными, но при увеличении могут распасться. Чтобы сохранить смысл, алгоритм должен решить, какие пиксели одной детали должны делить ребро после перестройки ячеек.

Визуализация графа похожести в задаче Depixelizing Pixel Art с синими рёбрами и выделенной красной областью
Диагностическая визуализация графа похожести: такие промежуточные артефакты помогают понять, где реализация сохранила связность, а где ушла в неверную геометрию. Источник: Habr, PALiarMo; изображение проверено 25 июня 2026 года.

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

Что говорят внешние исследования

Исследование METR Measuring AI Ability to Complete Long Tasks предлагает смотреть на способность агентов через длину задач, которые они выполняют автономно. В версии от 19 марта 2025 года METR пишет, что на их наборе многошаговых программных и логических задач успех резко зависит от человеческой длительности задачи: почти 100% для задач меньше 4 минут и меньше 10% для задач около 4 часов. Также они оценивают исторический рост 50%-time horizon примерно с удвоением каждые 7 месяцев.

Любой четырёхчасовой проект, конечно, не обречён. Но рамка полезная: агенту сложно не только «знать» шаги, но и держать длинную последовательность действий без дрейфа. Depixelizing Pixel Art попадает в эту зону. Ошибка может появиться в YUV-порогах, диагоналях, ячейках, сплайнах, оптимизации, рендере или записи изображения.

Похожий сигнал даёт препринт ProjDevBench, опубликованный на arXiv в феврале 2026 года. Авторы оценивают coding agents на сквозной разработке проектов и сообщают общую долю принятых решений 27,38%: агенты справляются с базовой функциональностью и структурами данных, но хуже проходят сложный системный дизайн, оптимизацию времени и управление ресурсами. Тип задачи другой, вывод близкий: чем больше связанная система, тем быстрее проявляются ошибки на стыках.

Что проверять команде перед доверием coding agent

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

  • Просите агента сохранять не только итоговую цель, но и проверяемые промежуточные артефакты: графы, логику переходов, отладочные изображения, контрольные файлы.
  • Разделяйте «код выглядит правдоподобно» и «алгоритм действительно работает». Для визуальных задач нужен визуальный oracle или хотя бы набор эталонных сравнений.
  • Проверяйте координатные системы, размерности, ориентацию буферов и повторяемость результата. Это скучные ошибки, но они часто портят готовую реализацию.
  • Ставьте smoke-тесты на синтетике прямо в цикл работы агента: однотонная картинка, шахматный паттерн, диагональная линия, одиночный пиксель.
  • Ограничивайте бесконечное улучшение. Если агент уходит в петлю «ещё чуть-чуть поправлю», нужен лимит и критерий остановки.
  • Не делайте рейтинг моделей по одному кейсу. Делайте каталог failure modes и используйте его для своих задач.

Это же видно в истории про накопление ошибок у ИИ-агентов в коде: проблема часто не в одном катастрофическом промахе, а в серии мелких сдвигов, которые выглядят терпимо по отдельности. Графическая задача просто делает эти сдвиги видимыми.

FAQ

Почему Depixelizing Pixel Art сложнее обычного benchmark?

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

Можно ли считать Habr-эксперимент рейтингом моделей?

Нет. Это один кейс с конкретным промптом, языком Swift, набором файлов и режимом без итераций. Его лучше читать как разбор типовых отказов AI coding agents, а не как универсальный рейтинг Claude, Codex, Cursor, Cline, Kimi, Grok или Gemini.

Что главное проверить перед использованием coding agent в сложной задаче?

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

Главное

Кейс Depixelizing Pixel Art ценен не победителем. Он показывает, что пределы AI coding agents проходят там, где локальная правдоподобность кода должна сложиться в длинный, проверяемый, визуально корректный результат. Для таких задач нужен не только сильный агент, но и хороший проверочный контур: промежуточные артефакты, тесты, эталоны, лимиты и человеческая проверка там, где формальный критерий слабый.

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

Источники и проверка фактов

Факты, источники, изображения и внутренние ссылки проверены 25 июня 2026 года. Названия агентов и численные результаты Habr-эксперимента использованы как данные конкретного авторского кейса, а не как официальная сравнительная таблица текущих модельных линеек.

Telegram-канал @toolarium