Разработчики ищут, что показывать, если код за 5 минут пишет агент

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

Идея Клеона и три совета

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

К разработчикам эту философию обычно применяют тремя способами:

• публиковать код в open-source;
• вести публичный журнал того, что сделано за день;
• описывать, как думал над задачей.

Автор отмечает, что даже сторонники первого варианта признают: выглядит это скучно.

Где ломается каждый вариант

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

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

Журнал дня и описание рассуждений ближе к тому, что предлагает Клеон, но и они не решают проблему целиком. Без конкретного результата такие записи легко становятся самоописанием, а не демонстрацией ценности.

Что из этого следует для практики

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

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

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

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