Покажи, что ты делаешь, когда код перестал быть ценностью

У Остина Клеона есть короткая книга «Покажи свою работу!» с одной большой идеей: не ждать, пока всё будет готово, а показывать процесс. Маленькие шаги, то, чему учишься, что вдохновляет, как ты идёшь к результату. Делиться понемногу каждый день, учить тому, что знаешь, и не превращать это в спам. Клеон считает, что люди находят тебя через то, чем ты делишься, и некоторые из них начинают тебе помогать.

Если применить эту философию к разработчикам, чем стоит делиться сейчас в 2026 году? Советы в сети сводятся к нескольким вариантам: выкладывать код в open-source, вести публичный журнал сделанного за день или описывать, как ты думал над задачей. Даже те, кто советует код, признают: это выглядит скучно.

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

Так что же показывать?

Твой репозиторий теперь показывает, что умеет твой агент

С этой частью, думаю, кто-то не согласится. Когда агент пишет большую часть кода за минуты (архитектура и трудные решения по-прежнему на тебе, но о них ниже), чистый репозиторий говорит больше об агенте, чем о тебе. Любой человек с тем же агентом напишет похожий код. Чего он не повторит — это всё вокруг кода: что ты решил, что проверил, где агент уверенно ошибался и как ты это заметил.

Вот это теперь и есть твоя работа. И в отличие от кода компании, большую её часть можно показать, если убрать названия.

Шесть вещей, которые может показать разработчик в команде

Все примеры из моих последних недель. Я работаю в основном с Claude Code над небольшим продуктом, и в командной работе повторяется то же самое.

1. Решение и варианты, от которых ты отказался. Оно показывает суждение — то, чего у агента о твоём проекте нет. Мой пример: каталог, который ранжирует MCP-серверы, поставил моему 98 из 100 и снял два балла за то, что имена инструментов без точек, вроде stories.search. Я оставила их без точек намеренно: правила имён функций у крупных провайдеров моделей точки не пропускают, и «правильные» по мнению каталога имена сломали бы клиентов, ради которых сервер и существует. Чтобы это объяснить, код не нужен.

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

3. Как ты проверил работу агента. Это самый важный навык сейчас, и его никто не видит. Три примера за одну неделю. 

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

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

• Третий я поймала на днях: Search Console показала страницы моего сайта, которых не существует, все с окончанием .mdread-only. На каждой странице истории ссылка на исходный текст стояла вплотную к пометке «read-only». На экране между ними был отступ, в тексте страницы — нет, и Google склеил их в один адрес и пошёл его обходить. Исправила один пробел, а мой тест этого не поймал бы никогда, потому что выглядело всё правильно. Все три раза работа агента была «готова». Заметить, что это не так, было моей работой.

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

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

6. Что ты сделал бы иначе. Короткий честный разбор полётов. Ему верят больше, чем истории успеха, и чаще всего это полезнее для тех, кто делает что-то похожее.

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

Учи тому, что знаешь, чужого агента

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

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

Как показывать работу изнутри компании

• Оставь механизм, убери названия. «Внутренний сервис», «шаг оплаты», «наш CDN». Урок почти никогда не зависит от бренда.

• Показывай рассуждение, а не артефакт. Почему выбрал так, как проверил, что изменил бы.

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

• Маленькое — это нормально. Одна проблема, одно исправление, 300 слов. Клеон прав: людям интереснее всего именно маленькие шаги. Удобная схема для такой заметки: контекст → в чём агент был уверен и ошибся → как ты нашёл причину → что изменил, чтобы это не повторилось.

А что показали бы вы?

Если бы нельзя было показать ни строчки кода, что бы вы показали о своей работе? Мне правда интересно, чем делятся разработчики в командах — и что им делиться запретили.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку