Как мы сегодня измеряем работу разработчиков: 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 нужно было показать «свою работу»)
Комментарии (20)
Dhwtj
21.07.2026 17:07Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта
Core команде проще: разработчик знает, что если он сейчас схалявил, ему ещё несколько лет жить с этим. Но это должен быть долгий жизненный цикл и доверие команде.
А вот когда команды начинают бешено тасовать по проектам/продуктам тогда и получается продукт без хозяина. Product owner даже если и есть (а скорее, его нет или 1/10 ставки/FTE из экономии) за этим не уследит.
За 12 лет в роли тимлида и архитектора
вы так и не научились кратко объяснять. Так какую метрику вы хотите минимизировать? Эти, которые на экране? Методики расчета есть? Обоснованные оценки их влияния на бизнес результаты есть?
А те, кто получает неуд становятся очень нервными. Они вам ещё не вломили?
Для оценки компетенций это конечно же не годится.
Но неплохо иметь постоянный контроль проекта за метриками деградации. Только они для каждого проекта разные. И когда метрика превысила порог значит техдолг/архитектура уже требует ремонта
Например
Категории:
1. Контрактная гигиена (связь с каскадной системой)
2. Доменная целостность (illegal states)
3. Слоистость/зависимости
4. Тестовое покрытие/ археология
5. Изменчивость/частота правок
Exeypan Автор
21.07.2026 17:07на soft-skills у нас Data Science еще был 5 лет назад, я кстати более ценные для корпорации измеряю, типа насколько разработчик ориентирует в корп-ландшафте
Спасибо за метрики, некоторые в динамике измеряю тоже
некоторые есть в моем стат-анализаторе, Spec-coverage еще вот надо тюнитьDhwtj
21.07.2026 17:07Честно говоря, такие метрики вызывают большое раздражение.
Допустим, я применил тут анемичную модель, потому что это бизнес правило относится только к конкретному сценарию, а не к всему домену. И что? Какие-то оценки моих компетенций? Ты спроси почему я отошёл от типичных паттернов, я тебе объясню что другие архитектурные свойства были важнее.
Большая часть метрик это просто code style, а проверка обходится, команда пойдет оптимизировать код под них. Переименовывают DAO в Entity, добавляют папку /domain/, получают зеленый радар и думают, что работают хорошо.
Да, метрики я бы контролировал. Но не для программиста, а для проекта. Для программиста всё сильно сложнее.
Запомни студент: сейчас к людям надо помягше а на вопросы смотреть ширше©
Exeypan Автор
21.07.2026 17:07Вес анемичности моделей не настолько высок в вычислении сеньорности кода
кстати когда у нас бизнес-требования хорошо изолированы у нас лучше DDD получается, давно наблюдаю эту закономерность.
В остальном оценка не упирается в конкретные паттерны.
Я могу согласится что следование DDD не везде обосновано, ну и поэтому не такой большой вес у этой метрики.
К людям я мягок, так как еще параллельно преподаю эти 12 лет, и вырастил многих c уровня trainee/juniorDhwtj
21.07.2026 17:07Меня никто никогда не учил. Бросили в воду и плыви как хочешь.
Но я всегда был первым/главным или максимум вторым человеком в проекте (в небольших долго живущих командах это не удивительно) и понимал свою ответственность и сам от себя требовал обоснованность решений и проводил post mortem.
Что в больших командах творится не знаю даже. Если мои компетенции так будет мерять у меня глаза на лоб полезут
Exeypan Автор
21.07.2026 17:07Я специально не делал разбор по коммиту -- хотя это возможно. я понимаю что можно оценить кодовую базу только целиком.
Кстати своей команде я так уже не раз собирал техдолг и очень бодро его всегда делали и даже сейчас.
Всех же false positive не выловишь и отчет можно еще прогнать через LLM на выявление онных, и отчет -- это точка отсчета для архитектурного анализа, поэтому там везде ссылки vscode://
FixicusMaximus
21.07.2026 17:07За 12 лет в роли тимлида и архитектора я написал десятки матриц компетенций и сам и прошел и провел сотни перформанс-ревью. И каждый раз инженерная часть оценки оставалась самой невнятной.
Да, это имеено то, что нужно делать для оценки того, как человек пишет код.
Поэтому уже пора разработчиков оценивать иначе: не по количеству написанного кода, а по качеству инженерных решений, которые они принимают каждый день.
90% таких решений это - тяп-ляп и в продакшен, а там зажариться как-нибудь. И да, смысла от оператора LLM требовать инженерии как-то глупо, так как для этого нужно хотя бы своим мозгом обладать.
guility
21.07.2026 17:07Пожалуйста, вставьте в начале статьи большой дисклеймер: "ЭТО МЕТРИКИ, А НЕ ЦЕЛЬ!"
Даже если для вас это очевидно.
И, да, многим даже высшим менеджерам всё ещё нужно рассказывать про закон Гудхарта.
В целом - штука отличная, но "продающий" заголовок и связанные с ним пояснения сделали из отличного инструмента для отслеживания параметров кода - концепцию, которую ненавидят все адекватные разработчики мира, отличающуюся от замера по "количеству строк кода" только сложностью :)
Void-Cowboy
сомнительно, местами криво - но как же о-ху-е-н-н-о!
Больше всего кайфанул от скорости, у меня литнеры дольше работают чем этот комплекс.
Из забавного - кривой вайбкодинг-проект оно оценило очень высоко, а сложную проработанную и провереную до кровавых мозолей тулзу на уровне джуна/мидла))
Но я не думаю что проблема с тем, что оно гонит много невалидного - я просто пробегая глазами уже вижу что актуально и нужно обратить внимание, а что мусор.
Но самое главное это киллер-фича для кодовых агентов!
То что оно может в MD очень круто (сразу видно человек думал сразу в комплексе) - быстрая тулза в помощь кодовым агентам, для улучшения вайбкодинга.
Вам бы еше правила/инструкции в бинарь зашить, что бы можно одной cli-командой получить подробную инструкцию и можно на ее основе строить скил который будет востребован. Главное прописать что бы не верило в анализ, а использовало его в качестве точки отчета.
Void-Cowboy
подтверждаю такие моменты
Вайбкодинг оно оценивает выше реальности. Даже если это вайбкодинг по плану с проверками и тд что бы попасть в бизнес-логику то такое все равно ниже по оценке чем чистый вайбкодинг
Не всегда подхватывает больше проекты. Может у меня такой стиль, но 1/5 только распознало более менее, остальное явно пропустило целые папки и модули что используются.
Странная система оценок - может мелкой фигне поставить джун/мид/сеньйор, а может огромному проекту с годами истории коммитов оставить без оценки.
Лучше всего работает с вебом. Голанд 20-30% ориентировочно, Си столько же, хотя определяет вроде-бы все файлы в отличии от Го.
В целом как я понял чуда не произошло и такая ошеломительная скорость потому что оно не замечает большую часть кода на больших проектах. Огромный фронт-енд проект он уже прожевывал ожидаемо несколько секунд и в анализ все файлы вошли.
Но все равно я думаю полезная тулза, допилить бы ее только что бы или можно точечно на модули и подмодули фокусировать для анализа или что бы таки захватывало все, пусть и ценой долгих рассуждений на анализ.
Exeypan Автор
я долго оптимайзил I/O на Go + эффективные алгоритмы и алго, которые пока archscope не видит
Void-Cowboy
запилите нормальную версионность с релизами что бы можно было по гитхабу отслеживать обновления и качать новые версии
Exeypan Автор
да, сейчас сделаю, она у меня в stash
Exeypan Автор
Я еще пилю слоп-детектор, а сколько строк кода в навайбкоденном?
Void-Cowboy
по разному
проверял и на мелком (до тысячи) и на крупном (дохрена, на том проекте я отлаживал рой кодовых агентов и стыковку кодекса с клаудом)