В публикации, открывающей цикл материалов об инженерной культуре, рассматривается понятие «спектра глубины» — шкалы, отражающей степень погружения специалиста в технологию. На одном полюсе находится Tool Operation (TO) — подход, при котором разработчик опирается на проверенные решения и наблюдаемое поведение программы, часто заимствуя готовые фрагменты кода из Stack Overflow или, в последнее время, у больших языковых моделей. На другом полюсе — Whitebox Engineering (WE), предполагающий исследование внутренних механизмов системы, понимание принципов её работы, исторических предпосылок, границ применимости и последствий использования. Автор подчёркивает, что это не бинарный флаг «хорошо/плохо», а качественная шкала, помогающая находить грамотные решения и избегать множества проблем.

Ключевая идея заключается в том, что Tool Operation, хотя и позволяет быстро получать работающий код, часто оставляет пробелы в объяснении причин инцидентов и обосновании принятых решений. Whitebox Engineering, напротив, требует построения и улучшения моделей системы, что даёт возможность точнее прогнозировать поведение, раньше обнаруживать уязвимые места и предвидеть последствия. Автор приводит аналогию с решением математической задачи: найти несколько корней уравнения недостаточно — нужно доказать, что других нет. Так и прохождение тестов не гарантирует правильность алгоритма; надёжность, масштабируемость и поддерживаемость требуют отдельной проработки. В качестве примера приводится исследование о влиянии мемоизации на производительность React-приложений, где глубокий анализ позволил определить, когда оптимизация действительно нужна, а когда от неё лучше отказаться.

Спектр глубины автор представляет как последовательность уровней: от работы с промптом (человекочитаемым описанием задачи) до понимания сгенерированного кода и среды его выполнения. Далее следуют спецификации языков, алгоритмы, структуры данных, принципы и паттерны, знание устройства компилятора и рантайма, операционных систем, управления памятью, архитектуры процессора и даже физических основ. Это не контрольный список для изучения, а одна из возможных плоскостей, смысл которой — формирование целостной картины мира, построение причинно-следственных связей и выявление ограничений. С помощью такой картины можно точнее прогнозировать, раньше обнаруживать уязвимые места и выбирать решения по их применимости и эффективности, а не по распространённости или новизне. Автор ссылается на работы датского учёного Питера Наура, который описывает программирование как построение внутренней модели системы, а не исключительно как производство кода.

В статье подчёркивается, что в чистом виде Tool Operation или Whitebox Engineering не существуют, и вряд ли это фиксированная характеристика человека, которую можно измерить в процентах. Нужно учитывать разные области, время и условия; скорее это вектор, направление, в котором можно двигаться. Где-то разумно использовать готовое решение, где-то — глубже погрузиться в реализацию. При этом не существует идеальных абстракций: все они протекают, а ресурсы и выгода ограничены. Универсальной ценности для любого бизнеса здесь тоже нет — это отдельная тема для обсуждения, и аргумент о преимуществе глубокого подхода часто неверно ставят в абсолют. Например, при оптимизации React-приложения можно ограничиться консольным логом, React Profiler и Dev Tools, уменьшив количество рендеров. Часто это разумно. Но если результаты пользователей нестабильны и противоречивы, можно опробовать другие методы или погрузиться в fiber, reconciliation, main thread, layout, влияние сторонних виджетов, выявить основные причины фризов и подобрать более полные и ситуативные решения. Суть не в том, чтобы изучить всё, а в том, чтобы видеть за рамками проблемы и устранять причину, а не симптом.

Автор задаётся вопросом, появилась ли эта характеристика только сейчас, и отвечает: быстрый рост IT во времена распространения интернета, мобильных телефонов и пандемии привлёк много людей в отрасль. С появлением ИИ эта тенденция только усиливается: с каждым днём появляется всё больше приложений, порог входа снижается, но это само по себе не усиливает понимание устройства технологий. Комбинация решений со Stack Overflow без погружения не сильно отличается от современного вайбкодинга, хотя использование агентов не характеризует глубину погружения. Практика копирования кода без полного понимания была и до повсеместного использования ИИ. Просто сейчас эти различия всё труднее скрыть за одинаковыми должностями, инструментами и написанными строками кода, а последствия становятся всё существеннее. Для каждой задачи есть подходящий метод: для прототипов, одноразовых скриптов или инструментов для собственного применения глубокое погружение может принести больше вреда, чем пользы. Но при создании сложных систем с высокой ценой ошибки, неопределённости или последствий — например, в области персональных данных, финансов, здравоохранения, массовых сервисов или в военной и космической отраслях — глубинный подход более применим.

Шкала нужна не для оценки объёма знаний конкретного человека или группы и не как призыв отказываться от готовых решений. Её цель — сократить неопределённость. Современные инструменты иногда очень хорошо и быстро находят решения, но инженерное понимание учит задавать правильные вопросы, видеть границы имеющихся моделей и подбирать необходимую глубину анализа. Использовать ИИ предлагается не как заменитель разработчиков, а как экзоскелет для мозга, который позволяет изучать исходники, строить модели, искать и анализировать большие объёмы информации. В перспективе такой подход может способствовать повышению качества программных продуктов и снижению рисков, однако остаётся открытым вопрос, как измерять и развивать эту глубину в командах и как она соотносится с требованиями бизнеса к скорости разработки.