Как мы сегодня измеряем работу разработчиков: 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 нужно было показать «свою работу»)
