Как мы сегодня измеряем работу разработчиков: velocity, story points, lead time, cycle time, число PR и закрытых тасок. Строим красивые дашборды, считаем DORA-метрики, прогнозируем сроки, оцениваем загрузку команд.

А вот измерение инженерных решений на зачаточном уровне. В лучше случае ADR и запись в трекере техдолга. Чаще — вообще ничего.

Существующая оценка качества инженерии субъективна.

Обычно это мнение тимлида с 3–5 годами опыта в одной-двух предметных областях. При этом именно инженерные решения определяют стоимость разработки через год-два: смогут ли десять разработчиков одновременно работать над кодом и можно ли вообще масштабировать продукт без переписывания половины кодовой базы.

Сегодняшняя парадигма проста: чтобы большой проект не развалился, достаточно вытягивать DESIGN + держать выше среднего CODE QUALITY. А 2026 год показал, насколько все забивают на SECURITY, а с перформансом справляются тем, что бигтехи держат под это отдельные перф-команды: как будто уже написание (или проектирование+генерация) эффективного алгоритма больше не влияет на то, кто действительно Senior.

Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта.

Мы научились измерять скорость разработки. Но почти не измеряем качество инженерии. 

Что вообще такое инженерный уровень?

За 12 лет в роли тимлида и архитектора я написал десятки матриц компетенций и сам и прошел и провел сотни перформанс-ревью. И каждый раз инженерная часть оценки оставалась самой невнятной.

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

Все эти решения остаются в репозитории. А значит, их можно анализировать.

Почему существующих анализаторов недостаточно?

Я прогонял код через почти все популярные статические анализаторы, что смог найти: CodeQL, ESLint, Detekt, SwiftLint, clang-tidy, PVS-Studio и еще с десяток.

Почти никто не отвечает в полной мере на вопросы, которые на самом деле характеризуют инженера. Особенно удивило почти полное отсутствие анализа алгоритмов и структур данных. Именно это — центр технических собеседований, но в реальных репозиториях это почти никто не считает (Так что можно залететь в IT через собес с помощью нейрноки и дальше весь путь костылить все решения на array)

Можно ли по коду отличить Junior от Senior?

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

Сеньйорский код явно отличим

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

Джуновские отмазки я слышал многие: «тесты же проходят», «это не аффектит основной функционал», «в статьях про это не пишут» :)

Формально есть класс задач, где высокие степени неизбежны — NP-полные: задача коммивояжёра, точное решение судоку, оптимальное расписание. Но open-source продукты редко их решают. Куда чаще это просто вложенный 2–4 раза for, потому что так было проще написать (нейронке кстати тоже).

Почему это станет важнее в текущих реалиях?

За последние два года индустрия сильно изменилась. LLM научились писать код и делают это всё лучше. Но плохую архитектуру просто не исправит даже самая сильная модель: Неудачные зависимости и неправильные структуры останутся. Неэффективные алгоритмы тоже останутся — если только вы не будете точечно объяснять нейронке, что именно не так в каждом решении и как это аукнется остальному проекту.

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

Есть и общий тренд: LLM имеет смысл использовать для написания статических алгоритмов, которые раньше было дорого или муторно писать руками. Уже видно, что подобные оптимизации внедряют даже под капотом самих нейронок — например, спекулятивный декодинг. Я который мне попадается через свой ArchScope, чтобы получить нужные метрики кода без сжигания токенов.

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