Прочитал интересный разбор того, почему большинство CLAUDE.md файлов не эфективны. Проблема не в том, что Claude их не читает — проблема в том, что мы их неправильно пишем.

Для контекста. CLAUDE.md — это файл-инструкция для Claude Code, который автоматически добавляется в начало каждой сессии. Многие воспринимают его как место, куда можно свалить все команды, стайл-гайды и архитектурные решения проекта. Результат — Claude начинает игнорировать инструкции.

Современные модели могут стабильно следовать примерно 150-200 инструкциям. Claude Code в системном промпте уже использует около 50 из них — то есть треть бюджета уходит до того, как модель увидит ваш код. При этом по мере роста числа инструкций качество их выполнения падает не точечно, а равномерно по всем пунктам.

Короче, держите CLAUDE.md коротким и универсальным. Вместо того чтобы описывать все команды сборки, настройки тестов и паттерны кода, используйте метод прогрессивного погружения: создайте папку agent_docs/ с отдельными файлами (building_project.md, testing_guidelines.md, architecture.md) и в CLAUDE.md просто перечислите их с кратким описанием. Пусть Claude сам решает, что ему нужно прочитать для текущей задачи.

Для повседневных задач это тожже работает. Я после прочтения статьи попросил агента разобрать мой CLAUDE.md и раскидать все не нужное по разным документам. И он сразу вынул из него примерно половину. Правда, выкинуть придется еще примерно 500 строк :)

Правда, авторы статьи категорически призывают не использовать /init для автогенерации CLAUDE.md и вообще писать там всё вручную. Но так далеко заходить я, конечно, не буду :)

—
Пономарь

Единственное, что действительно будет future-proof - это judgment. Суждение.

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

Именно поэтому главный дефицит теперь не в производстве, а в выборе.

Появилась новая проблема - AI slop. Когда код пишется быстрее чем думается, получается много, но не факт что нужного.

Раньше вопрос был "как это сделать", а теперь "зачем".

За последние месяцы произошло фундаментальное изменение.

Появились долгоиграющие агенты - системы, которые:
1) Не ломаются от первой ошибки
2) Умеют сами себя чинить
3) Позволяют нетехническим людям собирать реальные продукты

То, что полгода назад не работало вообще, сегодня собирается за час через промпты.

Что ломается?

1. Классическую модель продуктовой команды:

PM больше не тот кто пишет ТЗ - это теперь делает кто угодно. Его работа сместилась в сторону "зачем мы это делаем" и "какую проблему решаем".

2. Границы ролей:

Роли поплыли: PM-ы кодят. Дизайнеры кодят.
Дизайн-системы → AI → меньше дизайнеров, больше инженеров.

3. Детерминированное ПО:

Было: нажал кнопку - получил результат.
Стало: нажал кнопку - получил что-то похожее на результат или нет.

Это значит: появляется новая ключевая функция - оценка (evals).
Это снова зона ответственности людей с judgment.

Почему judgment - главное?

Потому что в мире бесконечной производительности ценность смещается.

Когда делать можно бесконечно много, скорость перестаёт быть преимуществом. Важнее становится что именно ты решил делать.

Judgment нужен:
• чтобы понять, что строить
• чтобы оценить, можно ли это выпускать
• чтобы отсеять красивый, но опасный код
• чтобы понять, имеет ли продукт смысл в системе в целом

Если коротко: ИИ забрал исполнение, ускорил всех и убрал порог входа.

А вот суждение - нет.

В новой индустриальной революции (революции сервисов), выигрывают не те, кто быстрее пишет код, а те, кто лучше понимает последствия своих решений.

Будущее за людьми, которые умеют: выбирать, отказывать, оценивать и брать ответственность.

Это, похоже, единственное, что не автоматизируется.

Отдельно стоит сказать про Salesforce и Zendesk, там хорошо видно куда всё движется.

Речь про utility-based software - когда продукт продаётся по «сиденьям» и каждый seat = человек, который делает работу.

Zendesk - идеальный пример.

50 саппорт-агентов → 50 лицензий.
Но теперь рядом можно поставить AI-агентов:
• было 50 людей
• стало 20 людей + 30 AI
• лицензий покупают меньше
• Zendesk теряет деньги, но медленно - никто не замечает

Это самый опасный сценарий для таких компаний: их не заменяют, их высасывают по кусочкам.

С Salesforce ситуация другая.

CRM - это база, на которой всё держится. Данные с длинным сроком жизни, карьерные риски, интеграции, процессы.

Никто в здравом уме не вырезает Salesforce одним решением.

Но даже тут давление растёт:
• Агенты начинают относиться к CRM как к «тупой базе»
• API закрываются или становятся платными
• Платформы начинают встраивать собственных агентов

Вот тут снова всплывает ключевая мысль: когда строить можно всё, главная ценность - judgment

Judgment:
• Какие workflows реально имеют смысл
• Где AI добавляет value, а где создаёт иллюзию прогресса
• Что стоит автоматизировать, а что опасно трогать

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

@maxvotek | linkedin | substack

Все больше разговоров, как ИИ убивает профессию программиста. Глобальные данные это подтверждают — занятость разработчиков в возрасте 22–25 лет упала на 20% от пика 2022 года. Стажировки в IT — минус 30% за два года, найм на начальные позиции в технологических компаниях — минус 25% год к году. Всё это уже происходит, но вывод из этого обычно делают неправильный.

Разумеется, программисты не исчезнут, а изменятся их задачи. Одно из очевидных направлений — превращение в «оркестратора», человека, который управляет набором ИИ-агентов и не пишет код руками. На этом фоне в индустрии звучит мнение, что навыки менеджмента теперь выходят на передний план, что нынешние менеджеры получат огромное преимущество, потому что «они уже умеют управлять людьми, а управлять агентами — это почти то же самое».

Но я не согласен. Это не то же самое. И вот почему.

Современная «полевая» школа IT-менеджмента — это продукт конкретной рыночной ситуации. Лет пятнадцать подряд спрос на разработчиков сильно превышал предложение. Это привело не только к гонке зарплат, но и к формированию целой культуры, в которой менеджер — это в первую очередь человек, который заботится о благополучии команды. Софт-скиллы стали чуть ли не важнее хард-скиллов. Страшный сон HR — сотрудник обновил резюме, а значит, надо за него бороться. Появились wellness-программы, корпоративные психологи, бесконечные встречи 1-1 про «как ты себя чувствуешь». ДМС, который в американской реальности объясним дороговизной медицины, в российских IT-компаниях превратился в ритуальную статью расходов — при зарплатах, на которые можно лечиться даже в Европе. Любой, кто управлял командой разработки, знаком с историей, когда половину времени тратится не на задачу, а на то, чтобы никто не выгорел, не ушёл к конкуренту и не обиделся на код-ревью.

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

Впрочем, мы говорили про менеджмент.

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

Это подтверждается данными. Есть исследование Penn State University, что грубые, директивные промпты стабильно дают лучший результат, чем вежливые — точность ответов ChatGPT-4o составила 84,8% для «Very Rude» и 80,8% для «Very Polite». Авторы предполагают, что новые модели воспринимают директивность как сигнал к фокусировке — без «лингвистического шума» вежливых формулировок. Другое более раннее кросс-лингвальное исследование показало, что чрезмерная вежливость не гарантирует лучших ответов ни на одном языке. А команда сервиса Vercel обнаружила, что агенты работают лучше, когда им дают меньше свободы, а не больше.

Показательно, что в феврале 2026 года в индустрии закрепился термин «harness engineering» — от слова harness, упряжь. Не coaching, не mentoring, не facilitation — упряжь. Потому что управление ИИ-агентами — это про жёсткие ограничения, чёткие рамки и контроль непредсказуемой силы.

Короче, куда эффективнее среднего проджект-менеджера из айти ИИ-агентами будет управлять даже не орущий на новобранцев сержант Хартман из «Цельнометаллической оболочки», а римский рабовладелец. Рабовладелец не тратил время на мотивационные беседы, а точно формулировал задачу, устанавливал жёсткие рамки, контролировал исполнение и наказывал за отклонение. И это описание идеального оркестратора мультиагентной системы в 2026 году.

—
Пономарь