Что показывать, когда агент пишет код за пять минут

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

Этот вопрос подхватил принцип из книги Остина Клеона «Покажи свою работу!» — не ждать завершения проекта, а демонстрировать процесс маленькими шагами, обучая других тому, что знаешь. Но в 2026 году это требует переосмысления: нужно показывать не артефакты, а суждения.

Шесть вещей вместо кода

Что раскрывает вашу работу, если код уже написан агентом:

• Решения и отклоненные варианты. Показывают суждение, которого у агента о вашем проекте нет. Когда каталог MCP-серверов снял два балла за имена функций без точек (вроде `stories.search`), это было намеренным решением: крупные провайдеры моделей точки в именах не пропускают, а правильные по каталогу имена сломали бы клиентов, ради которых сервер существует.

• Провалы и способ диагностики. Google начал называть страницы «soft 404», хотя они открывались в браузере. Причина — одна строка в robots.txt блокировала API для получения содержимого. Google рендерит как браузер, не смог получить данные и увидел экран ошибки.

• Как вы верифицировали работу агента. Самый важный навык сейчас, невидимый в коде. Три примера за неделю: тест сервера проверял неправильный код ошибки и проходил несколько дней, пока реальный клиент через сторонний инструмент не упал с исключением; блок статистики был пустой в продакшене из-за политики безопасности CDN, которую тестовый браузер не применял; Google нашёл несуществующие страницы с окончанием `.mdread-only` — ссылка на исходный текст стояла вплотную к пометке, браузер видел отступ, в исходном коде его не было, Google склеил их в один адрес.

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

• Цифры до и после. Результат легко показать, даже когда систему показать нельзя. «Через два дня после исправления Google перестал называть страницы soft 404» или «проверка теперь ловит это до релиза» говорит больше, чем дифф.

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

Как это работает: сценариус вместо одиночки

Когда демонстрируете решения и ошибки вместо кода, отвечают люди с другим опытом. Две переписки в комментариях на dev.to о MCP-сервере превратились в функции продукта: проверку версии и набор тестов через настоящего клиента. Одна из них дошла до Сидни Биссоли, автора семи MCP-серверов для бразильских открытых данных. Он создал из неё отдельный инструмент, прогнал через него все 142 версии своих серверов, нашёл две, которые вообще не запускались, и написал статью с выводом: «одна ветка комментариев изменила то, как выпускаются восемь серверов». Остин Клеон называет это «сцениусом» — хорошая работа рождается в группе, которая показывает друг другу, что делает, а не у одиночки.

Внутри компании: механизм без названий

На worklore.dev публикуют короткие истории: что пробовали, что сломалось, что сработало. Когда чей-то агент воспроизводит историю, это учитывается на странице. Контент, который нельзя обобщить для публики, всё равно стоит записать для себя — ваш собственный агент повторит через пару месяцев, когда детали забудутся.

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