Потеря глубокого понимания деталей в программировании вызывает эмоциональный кризис у низкоуровневых разработчиков, но выявляет ниши, где этот навык остаётся критически важным — кибербезопасность и оптимизация производительности, где LLM пока не могут заменить человеческое понимание архитектуры. Многие испытывают горе не из-за потери продуктивности, а из-за смерти идентичности, построенной на глубоком понимании машинных деталей — это не адаптация, а прощание с ушедшей эпохой. LLM не способны автоматически находить горячие участки кода или оптимизировать низкоуровневый код без чёткого понимания архитектуры и целей — они беспомощны без человеческого контекста. Работы в кибербезопасности — исследование уязвимостей, реверс-инжиниринг, анализ инцидентов — остаются областями, где детали определяют успех, и LLM не могут полностью заменить экспертов. Современные системы стали слишком сложны для удержания в голове — это не новость, но LLM усугубляют проблему, убирая стимул к глубокому пониманию, заменяя его поверхностным доверием к автоматизированным решениям. Спор: LLM генерируют ужасно неоптимизированный низкоуровневый код — например, снижение first paint с 4500ms до 1000ms в Claude, как заявлено, невозможно без ручной оптимизации, и это не достижение LLM. Спор: Один разработчик утверждает, что его коллега, почти не использующий LLM, остаётся самым ценным членом команды — он лучше всех понимает код, отвечает на вопросы и ловит баги в ревью, что опровергает тезис о неизбежной замене людей. Совет: Специализируйтесь на тех частях системы, где агентные потоки слишком рискованны — там, где ошибка может стоить миллионы, а не просто замедлить API — именно там глубокое понимание остаётся незаменимым. Совет: Используйте LLM как новый 'процессор' для логики — сосредоточьтесь на создании языков и систем для их контроля, что возвращает интерес к фундаментальным принципам информатики, а не к написанию кода. Совет: Ищите ниши, где ручная работа ценится — например, создание 'hand-made' ПО, где пользователи готовы платить за безупречный опыт, а не за быструю, но шаблонную автоматизацию. Совет: Переключитесь с написания кода на управление и поддержку — как один инженер, перешедший в менеджмент, заметил: люди, выполняющие агентную работу, требуют больше эмоциональной поддержки, и это новая возможность. Инженеры, которым важно понимание, а не построение, чувствуют себя потерянными — но это не слабость, а естественная реакция на уничтожение той культуры, где глубина ценилась выше скорости. Исторически, как и при промышленной революции, автоматизация уничтожает ремесло, но не устраняет потребность в мастерстве — она просто смещает его в более узкие, менее массовые ниши. Понимание компиляторов, кэширования CPU, TCP-стеков и пайплайнов остаётся ценным — даже если вы не пишете ассемблер, это знание позволяет находить скрытые узкие места, которые LLM не видят. Совет: Примите, что вы больше не сможете держать в голове всю систему — но это не значит, что вы перестали быть инженером; это значит, что ваша роль теперь — быть тем, кто понимает, что нельзя доверять автоматизации. LLM — это машина для интерполяции, а не для творчества; они не способны на открытия, как специальная теория относительности, если их обучали на данных до 1904 года — они не понимают, а пересобирают.