Лучший код занял второе место: разбираем финал Dev-to-Dev хакатона и ищем границы агентной инженерии

В финале хакатона Dev-to-Dev: Agentic Engineering Challenge на втором месте оказался самый качественно написанный проект соревнования. 65 тестов, типы, защита от path traversal, Docker с non-root user, архитектура, в которой видно инженера, а не участника хакатона. И именно поэтому он не победил.

Победителем стал не самый чистый код и не самая смелая архитектура. Это решение точнее всех попало в то, что мы пытались измерить — agentic engineering. Термин, которому едва пара лет, и в который каждая команда пока вкладывает что-то своё.

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

ХАКАТОН В ЦИФРАХ

▸ 151 регистрация, 20 загруженных решений, 10 финалистов.

▸ 4 дня на разработку (26 февраля — 1 марта 2026).

▸ Docker-контракт стал главным инженерным фильтром — критерий запуска, который не зависит от стека.

▸ Топ-3 финалистов набрали 88 / 84 / 84 балла — плотная борьба наверху.

▸ Самый компактный образ — 96 МБ (Clojure/JVM), самый тяжёлый — 574 МБ (Python).

▸ В peer review каждый финалист потратил 2–3 часа на проверку четырёх работ коллег.

Откуда возникла идея

В конце 2025 года мы переписали Codenrock — платформу для проведения хакатонов, ML-челленджей, CTF и соревнований по алгоритмическому программированию. За два месяца команда из четырёх разработчиков и Claude Code полностью переделала продукт с реальными пользователями и реальной нагрузкой на современный стек. Подробнее можно прочитать здесь. 

Опыт оказался настолько показательным, что мы решили превратить этот формат работы в публичное соревнование. У индустрии как раз появилось подходящее слово.

Андрей Карпатый

Сооснователь OpenAI, февраль 2026

«Agentic — потому что теперь по умолчанию ты 99% времени не пишешь код напрямую. Ты оркестрируешь агентов, которые пишут его, а сам осуществляешь контроль. Engineering — чтобы подчеркнуть, что в этом есть и искусство, и наука, и профессиональная экспертиза. Этому можно учиться и со временем становиться лучше — у этой практики своя, особая глубина».

Эта концепция и легла в основу хакатона. Мы предложили участникам разработать сервер на базе MCP — открытого стандарта от Anthropic. Протокол позволяет ИИ вызывать внешние инструменты через единый JSON-RPC интерфейс. По сути это «USB-порт» для модели: подключаешь сервер — ассистент получает новые возможности (например, может сканировать зависимости, генерировать changelog, проверять Docker-конфигурации).

Формат: контракт, который никто не обошёл

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

• DEMO.md — описание сценария проверки решения.

• AGENTIC.md — описание процессов, ролей агентов и организации работы.

• CLAUDE.md — правила и контекст для агента.

Отдельная история — Docker-контракт. Каждое решение должно было собираться в образ, запускаться командой docker run IMAGE serve на порту 8000, отвечать на /health, поднимать endpoint /mcp, а по команде docker run IMAGE smoke проходить самодиагностику.

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

Кто пришёл и что принёс

На хакатон зарегистрировался 151 участник. Формат был индивидуальным — если так можно назвать соревнование, где один разработчик окружён множеством ИИ-агентов. За четыре дня (26 февраля — 1 марта 2026) участники успели загрузить 20 решений, из которых в финал прошли 10 самых сильных.

Распределение по стекам у финалистов:

• Python + FastMCP — 7 из 10. Самый прагматичный выбор для короткого хакатона: FastMCP берёт на себя MCP-протокол, и это просто работает.

• TypeScript — 1. Один проект с 11 Docker-контейнерами.

• Go — 1. MCP Devkit с release-readiness как «светофором» перед релизом.

• Clojure — 1. Самое необычное решение хакатона на фреймворке хореографического программирования. Хоть проект не попал в зачёт по формальным причинам, мы решили разобрать его отдельно.

Все работы финалистов разделились на два лагеря:

• Утилитарный лагерь. Инструменты с детерминированным поведением: TODO-сканеры, анализаторы техдолга, генераторы release notes. Сильная сторона — предсказуемость, прозрачность и практическая польза в ежедневной работе.

• Амбициозный лагерь. Системы, в которых MCP-сервер участвует в многоэтапной логике, дополняет результаты с помощью ИИ, координирует цепочки действий. Сюда относятся, например, обогащённые ИИ логи изменений, автоисправление SonarQube-issues через цепочку агентов, сканирование уязвимостей через OSV API.

Большинство финальных проектов оказались не агентами, а хорошими инструментами. Для четырёхдневного хакатона это естественный выбор: сделать надёжный MCP-сервер проще и практичнее, чем строить полноценную агентную систему. Тем заметнее стали те немногие проекты, где участники попытались реализовать систему с состоянием, планированием и способностью к самокоррекции.

Docker-контракт стал главным инженерным фильтром хакатона.

Топ-3 решений: парадокс хакатона

В этом разделе мы пойдём не по убыванию баллов, а по логике сюжета. Сначала — два проекта, которые разделили второе место. Это самые любопытные решения хакатона: они оказались на одной строчке лидерборда, набрав ровно по 84 балла, и при этом представляют почти противоположные подходы к разработке. Один — образец инженерного качества без ИИ в архитектуре. Другой — настоящая мультиагентная архитектура с компромиссами в инженерии. Чтобы понять, почему оба остались на втором, а не на первом месте, нужно увидеть их рядом.

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

Лучший код хакатона — RepoHealth, Алексей Кошкидко (2 место, 84 балла)

MCP-сервер для анализа технического состояния репозитория: диагностика техдолга, разбор CI-логов, проверка зависимостей и сборка агрегированного health report по проекту.

Это самое инженерно зрелое решение хакатона. Чистая модульная архитектура с разделением analyzers/transport/core, 65 тестов, модели на Pydantic v2, typed errors, защита от path traversal, подробная документация. Docker настроен с non-root user и HEALTHCHECK. Репозиторий производит впечатление инженерного продукта, а не конкурсного прототипа за 4 дня.

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

Репозиторий: github.com/akoshkidko/mcp-server

Лучшая агентная архитектура — SonarGatekeeper, Станислав Винокур (2 место, 84 балла)

MCP-сервер для работы с issues из SonarQube, построенный как полноценная мультиагентная система. Архитектура из пяти агентов с чётким распределением ролей: Collector забирает issues из SonarQube, Triage ранжирует их по важности, Fix предлагает исправления, Verifier проверяет результат, Reporter собирает итоговый отчёт. Каждый агент отвечает за свой этап, вместе они образуют связанный процесс.

Решение работает с локальной LLM через Ollama, разворачивается через Docker Compose и включает 11 контейнеров. Для наблюдаемости и анализа поведения агентов используется Langfuse. Если в современном понимании «агентная инженерия» — это система, в которой ИИ принимает решения, а не подсказывает строки кода, то этот проект подошёл к определению ближе всех.

Цена за амбицию — сложность развёртывания и более высокий порог входа. Проект зависит от работающего SonarQube, опирается на тяжёлую инфраструктуру и сопровождается сравнительно короткой историей разработки. На фоне универсального проекта-победителя это и стало решающим фактором.

Репозиторий: github.com/stasvinokur/dev_to_dev_agentic_engineering_challenge

Михаил Трофимов

исполнительный директор Codenrock, член жюри хакатона

«Когда RepoHealth и SonarGatekeeper набрали одинаковые баллы, это был самый показательный момент хакатона. Один проект — образец того, как должна выглядеть инженерная работа: тесты, типы, безопасность, документация. Второй — менее идеальный по коду, но с настоящей мультиагентной архитектурой. Сейчас индустрия будет ценить именно второе. Не потому что качество кода неважно — а потому что писать чистый код через год научится любая модель, а проектировать агентные системы пока умеют единицы.»

Победитель — Dependency & License Inspector, Эдуард Курганов (1 место, 88 баллов)

MCP-сервер для анализа зависимостей проекта. Он проверяет лицензии, ищет известные уязвимости через OSV API и умеет генерировать SBOM в форматах SPDX и CycloneDX. Архитектура из шести специализированных инструментов: scan_dependencies, check_licenses, scan_vulnerabilities, generate_sbom, check_policy, analyze_project. Каждый решает отдельную задачу, вместе они закрывают стандартные проверки зависимостей в проекте.

Решение упаковано в многоэтапный Docker-образ, поддерживает DEMO_MODE без внешних зависимостей и сопровождается аккуратной документацией. По репозиторию видно, что разработка шла не хаотично: история коммитов остаётся читаемой, структура проекта понятна для внешнего проверяющего.

Этот проект не был самым сложным архитектурно — у SonarGatekeeper мультиагентная система выглядит ярче. И не самым чистым по коду — у RepoHealth инженерная дисциплина выше. Но автор лучше остальных соединил универсальность задачи (анализ зависимостей нужен почти в любом проекте), точную реализацию, воспроизводимость и осмысленную работу с агентами в самом процессе разработки. CLAUDE.md зафиксирован, AGENTIC.md описывает процесс, ИИ использован как полноценный инструмент.

Иными словами, победил не самый смелый и не самый аккуратный — победил самый сбалансированный. Это и есть ответ на парадокс двух вторых мест: agentic engineering в 2026 году — это про умение находить рабочую точку между амбицией и инженерной дисциплиной, а не про достижение максимума по одной из осей.

Репозиторий: github.com/edwovld/mcp-dependency-and-license-inspector

Третьи места — практический срез

Два проекта поделили третью позицию с 80 баллами. Оба — крепкие, рабочие, полезные. И оба показывают, где проходит граница между «полезным MCP-инструментом» и «агентной системой».

Dev Tools MCP Server (Денис Зайцев)

Локальный MCP-сервер с тремя инструментами для повседневной работы. scan_tech_debt ищет маркеры вроде TODO, FIXME, HACK и BUG и раскладывает их по приоритетам. generate_release_notes строит release notes по git-логу и Conventional Commits. audit_dockerfile проверяет Dockerfile на проблемы с безопасностью и базовыми практиками. Сервер не пытается делать всё сразу — решает несколько конкретных задач понятным и проверяемым способом.

Репозиторий: github.com/denis-42ds/dev-tools-mcp

MCP Devkit (Вячеслав Дедов)

Локальный MCP-сервер на Go для предрелизной проверки кода. В центре идеи — release_readiness как «светофор» перед релизом: инструмент собирает результаты других проверок и быстро показывает общий статус. Поверх него работают code_check, gen_release_notes, test_coverage_analyzer, audit_docker, todo_debt_scan, dependency_guard. Вместо одного перегруженного инструмента — несколько отдельных проверок с общим итоговым статусом.

Репозиторий: github.com/FlynntDev/mcp-devkit

Оба третьих места имеют общую черту: ИИ помогал авторам в процессе разработки, но не играет ключевой роли в самой архитектуре решения. Сами серверы остаются наборами детерминированных инструментов. Это полезные продукты, но если возвращаться к парадоксу из начала раздела — они ближе к RepoHealth, чем к SonarGatekeeper. И именно эта близость определила третье место, а не второе.

4–8 места: где теряли баллы

Дальше — пять проектов, которые попали в финал, но не дотянули до призовой тройки. У каждого была своя слабость — и в этих слабостях видно общую картину того, что отделяет хороший MCP-сервер от выраженной агентной системы.

4 место — Алексей Юдин, 79 баллов. Codebase Audit MCP

Локальный MCP-сервер для статического анализа кодовой базы: scan_todos, find_code_smells, generate_report. Поиск технического долга, секретов и опасных вызовов через regex и Python AST. Полностью автономная работа без внешних API. Высокие баллы по продуктовой ценности, надёжности и инженерной дисциплине.

Чего не хватило: выраженного агентного компонента. ИИ активно использовался в процессе разработки, но не стал центральным звеном системы.

Репозиторий: github.com/AlekseyYudin-161/codebase-audit-mcp

5 место — Vadim V., 75 баллов. Dev-to-Dev MCP

MCP-сервер для генерации changelog и описаний релизов на основе git-истории. Поддержка Conventional Commits, два чётко разделённых инструмента, smoke-тесты для самодиагностики, несколько форматов вывода.

Чего не хватило: глубины. Получился крепкий инструментальный сервер, но AI-компонент здесь полезный, а не центральный — логика остаётся прямолинейной.

Репозиторий: github.com/aabdiv/dev-to-dev-MCP

6 место — Илья Пушкарёв, 71 балл. MCP Todo-Scanner

Компактный TODO-сканер для поиска и вывода маркеров в коде. Узкий, понятный сценарий, аккуратная реализация без избыточных слоёв логики.

Чего не хватило: масштаба. Для финала хакатона по агентной инженерии решение оказалось слишком базовым.

Репозиторий: github.com/Trepetet/mcp-todo-scanner

7 место — Дмитрий Грибанов, 66 баллов. FastAPI MCP Server

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

Чего не хватило: технической готовности и точного попадания в задачу конкурса. Проект не прошёл базовый порог работоспособности.

Репозиторий: github.com/medmancifra/fastAPI-MCP-server

8 место — Вадим Лютов, 58 баллов. Agentic Dependency Updater

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

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

Репозиторий: github.com/Podtverzhdeno/Agentic-dependency-updater-Hackathon

Два паттерна повторяются в этой пятёрке:

• Чем дальше от агентности и чем ближе к утилитарности — тем больше шансов на работающее решение, но меньше шансов на победу. 

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

Проект вне зачёта: NixOS Colmena Deploy MCP на Clojure

Самое необычное решение хакатона. Алексей Алдебогданов собрал MCP-сервер для тестирования NixOS-деплойментов в эфемерных Docker-контейнерах. Стек: Clojure + Klor — фреймворк для хореографического программирования, в котором взаимодействие компонентов описывается как единый сценарий. Клор позволяет отлавливать deadlock-сценарии ещё на этапе компиляции.

Архитектура из трёх контейнеров. Wrapper flake-подход: исходные конфигурации пользователя не модифицируются, а оборачиваются через lib.mkForce overrides. Двухуровневый анализ ошибок: базовый regex работает всегда, LLM-анализ подключается опционально. Образ — 96 МБ. Это самый компактный среди всех решений хакатона: в шесть раз меньше типичного Python-образа на 574 МБ. Что особенно интересно при том, что JVM считается «тяжёлым» стеком.

Отдельно впечатляет AGENTIC.md. Это эталон инженерной рефлексии — с зафиксированными развилками, отвергнутыми архитектурными вариантами, найденными багами и выводами о том, что сработало, а что нет. Например: «Klor provided compile-time guarantees» рядом с «Klor’s error messages are cryptic».

Если бы проект участвовал в общем зачёте, он, вероятно, оказался бы в числе лидеров. Но правила оказались важнее: участник не оценивал проекты других конкурсантов в peer review и не полностью соответствовал Docker-контракту.

Даже сильное решение должно соответствовать техническим требованиям и формату запуска.

Репозиторий: github.com/aldebogdanov/nixos-colmena-deploy-mcp

Как мы отбирали финалистов: peer review

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

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

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

Критерии оценки (шкала 0–5):

• Полезность и применимость. Решает ли проект реальную задачу разработчика.

• Качество работы. Проходит ли демо-сценарий, насколько решение стабильно.

• Простота запуска. Полезность документации, лёгкость настройки.

Плюс один вопрос «да/нет» — пользовались бы вы этим решением сами после хакатона? И свободное поле для мини-рецензии.

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

Что показал этап в цифрах:

• В среднем участники тратили на проверку четырёх проектов 2–3 часа.

• 100% опрошенных назвали процесс «скорее интересным» или «очень интересным».

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

• Все выразили желание участвовать в подобном формате снова.

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

ИИ как ассистент жюри: где помог и где промахнулся

Финальную десятку проектов оценивали в две руки: Михаил Трофимов, исполнительный директор Codenrock, и Claude Code от Anthropic как технический ассистент. Чтобы не было путаницы со схемой принятия решений, проговорим её сразу:

• Peer review отбирал десятку финалистов из 20 загрузок — на основании оценок других участников хакатона.

• Claude Code анализировал код финалистов: читал репозитории, искал технические ошибки, проверял корректность сборок, помогал понять, как именно устроены отдельные инструменты внутри проектов.

• Михаил принимал все окончательные решения по баллам и местам. ИИ был инструментом проверки, а не заменой жюри.

Где Claude Code оказался полезен. За секунды прочитывал тысячи строк кода, находил сложные места в логике, выявлял технические ошибки, которые легко пропустить при ручном просмотре. Конкретный пример: в одном из проектов Claude обнаружил вызов tomllib.dump, которого нет в стандартном модуле tomllib (это distinct от tomli_w.dump). Без машинной проверки такая деталь бы прошла мимо при просмотре множества проектов.

Где не помог. Решение о месте — это вопрос ценностей, а не фактов. Когда RepoHealth с безупречной инженерной реализацией оказался ниже SonarGatekeeper с агентной архитектурой, но более тяжёлой инфраструктурой — это не вычитывается из кода. Это инженерное суждение про то, что такое именно «агентная инженерия» и где проходит её граница. ИИ может подсветить факты, но решение о приоритетах остаётся человеческим.

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

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

• Наличие CLAUDE.md / AGENTIC.md — бинарная проверка.

• Распределение ролей — кто проектировал архитектуру, писал код, оценивал его, и как этот процесс был зафиксирован.

• Рефлексия — описание итераций, тупиков, принятых решений и их обоснований.

• Метрики процесса — количество turns, найденных багов, отвергнутых подходов.

• Доказательства — логи чатов, скриншоты, конкретные примеры вклада ИИ в архитектуру.

Чёткий проверяемый Docker-контракт (serve, smoke, /health, /mcp) оказался отличным уравнителем. Он не зависит от стека, не требует субъективной оценки и моментально показывает, работает решение или нет.

Где легче всего потерять баллы

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

• Решение не работает. Самый обидный тип ошибки. Идея может быть гениальной, но если Docker-образ не собирается, endpoint не поднимается, а DEMO-сценарий не воспроизводится — оценить проект не получится. Агентная часть заявлена, но не доведена до рабочего состояния. Это специфичная для агентной инженерии ошибка. Мультиагентные сценарии и сложная оркестрация особенно чувствительны к мелким недоработкам: одна ошибка в цепочке агентов — и вся архитектура перестаёт производить впечатление.

• Слишком простое решение. От хакатона по агентной инженерии ожидались более смелые инструменты, чем обычный TODO-сканер. Чисто собранное, но базовое решение проигрывает в финале.

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

Что мы поняли по итогам

Первое: протокол MCP работает. FastMCP делает создание MCP-сервера тривиальной задачей — 7 из 7 Python-решений на этом стеке успешно собрались. Но экосистема ещё молода: нет общепринятых паттернов тестирования, нет линтеров для MCP-инструментов, нет стандартного способа измерить качество описаний. Участники хакатона столкнулись с этим напрямую: кто-то путал MCP с REST API, кто-то выставлял инструменты без JSON Schema для параметров.

Второе: размер образа — индикатор инженерной культуры. 96 МБ на Clojure/JVM против 574 МБ на Python. Шестикратная разница на одной задаче. JVM считается «тяжёлым» стеком, но в умелых руках даёт самый компактный результат. Если вы упаковываете MCP-сервер и образ весит больше 500 МБ — это повод пересмотреть Dockerfile.

Третье: агентная инженерия и качество кода — разные оси. Лучшее с инженерной точки зрения решение (RepoHealth) поделило второе место с проектом, который местами написан хуже, но имеет настоящую агентную архитектуру (SonarGatekeeper). Если ваша цель — попасть в ТОП хакатона по агентной инженерии, ИИ должен быть в архитектуре системы, а не только в процессе её разработки.

Четвёртое: разработка с ИИ может уйти от формулы «ChatGPT, напиши мне красивый код». В этом процессе становятся важны распределение ролей, рефлексия и итерации. CLAUDE.md — это контракт между человеком и ИИ. AGENTIC.md — честный отчёт о том, что получилось, а что нет. Если этих файлов в репозитории нет, проект, скорее всего, не агентный, как бы ни звучало его описание.

Сейчас «агентная инженерия» — это термин, в котором каждая команда вкладывает своё. К следующему году станет понятнее, какие практики окажутся стабильными, а какие — модой одного сезона. Мы планируем повторить формат Dev-to-Dev и измерить, насколько изменится подход участников.