В 2026 году показывать работу разработчика всё чаще означает не выкладывать очередной репозиторий, а объяснять, где ИИ-агент ошибся и как человек это заметил. Для специалистов, работающих с корпоративным кодом и генеративными инструментами, это меняет и портфолио, и публичный профессиональный образ: ценностью становится не объём сгенерированных строк, а инженерное суждение.
Такую версию идеи «показывай процесс, а не только результат» предлагает автор публикации на Habr / Карьера. Отправная точка проста: открытый код доступен не всем из-за NDA и прав компании, а собственный код при массовом использовании агентов уже не всегда отвечает на главный вопрос о специалисте — какие решения он принял сам и как проверил правдоподобный, но ошибочный результат.
Речь не о том, что агентная разработка отменяет инженера. Архитектура, компромиссы и выбор ограничений по-прежнему остаются на человеке. Но чистый репозиторий действительно стал менее информативным: при одинаковых инструментах два агента могут быстро собрать похожую реализацию. Гораздо сложнее воспроизвести контекст проекта, увидеть скрытую проблему и понять, какой тест не проверяет реальное поведение системы.
Автор предлагает делиться шестью типами материалов: принятым решением и отброшенными вариантами, разбором сбоя, способом проверки результата агента, новой инструкцией или защитой после ошибки, метриками до и после исправления, а также честным ответом на вопрос «что бы я сделал иначе». Это формат заметок по 200–300 слов, а не обязательство вести публичный дневник каждого рабочего часа.
В качестве примера приводится MCP-сервер, которому каталог поставил 98 баллов из 100: два балла сняли за отсутствие точек в именах инструментов. Автор сознательно не использовал формат вроде stories.search, потому что правила именования функций у крупных провайдеров моделей не принимают точки. Код здесь вторичен; полезнее зафиксировать конфликт между формальным рейтингом и совместимостью с клиентами.
Ещё показательнее истории о проверках. Google помечал страницы как soft 404, хотя они открывались в браузере: правило в robots.txt закрыло API, из которого страницы получали содержимое. В другом случае тесты не заметили, что политика безопасности CDN блокирует встроенные скрипты в продакшене. Ещё одна ошибка возникла из-за склейки ссылки на исходный текст с пометкой read-only: поисковый робот увидел несуществующие адреса с окончанием .mdread-only. Во всех трёх эпизодах работа агента выглядела законченной, пока её не столкнули с реальной средой.
Именно такие кейсы позволяют показывать работу разработчика, не раскрывая внутренности компании. Достаточно обезличить систему: вместо названия продукта написать «внутренний сервис», вместо конкретного провайдера — «CDN». Затем оставить механизм: какое предположение оказалось неверным, как нашли причину, какую защиту добавили. После истории с CSP, например, в деплое появилась проверка, не допускающая публикацию страницы со встроенным скриптом; после расхождения публичного описания сервера с его поведением — контроль изменения версии.
Для работодателя и команды это полезнее витрины из коммитов. Такой материал показывает, умеет ли кандидат работать с неопределённостью, строить обратную связь и превращать разовый инцидент в повторяемое правило. Для самого разработчика это ещё и внешняя память: через несколько месяцев детали расследования стираются, а записанный сценарий можно воспроизвести — в том числе с помощью собственного агента.
Публичные разборы могут приводить и к практическому обмену опытом. Автор пишет, что обсуждения MCP-сервера на dev.to дали две функции продукта: проверку соответствия версии изменениям и тесты через настоящего клиента. Один из участников дискуссии, Сидни Биссоли, применил идею к 142 опубликованным версиям своих MCP-серверов, нашёл две не запускавшиеся версии и описал результат отдельно. В этой модели полезный контент — не демонстрация безошибочности, а приглашение проверить ход мысли.
Главный вопрос для российского IT-рынка звучит вполне прикладно: что останется в профессиональном профиле, если нельзя показать ни строчки рабочего кода? Вероятно, всё более важным ответом будут решения, границы применимости ИИ и следы качественной проверки. Код всё ещё нужен, но в агентной разработке он всё реже оказывается единственным доказательством квалификации.