Оценка разработчика и ПМа: L10-L60, workflow и ИИ

Классическая оценка разработчика часто смотрела на стек, стаж, скорость закрытия задач и субъективную сеньорность. В AI-native среде эти признаки быстро теряют вес.

Исследование Microsoft/GitHub по Copilot показало ускорение выполнения контролируемой задачи на 55,8%. Anthropic в Economic Index по разработке описывает coding-agent сессии как заметно автоматизируемый класс работы. DORA при этом дает важное ограничение: AI повышает индивидуальную продуктивность, flow и удовлетворенность, но без инженерных основ может ухудшать стабильность и throughput поставки.

Вывод для оценки простой: ИИ ускоряет руки, но не отвечает за систему.

Если ценность человека - писать куски кода по чужому ТЗ, ИИ действительно выглядит угрозой.

Если ценность человека - держать workflow, проектировать слабую связанность, ставить задачи агентам, проверять гипотезы и доводить результат до использования, ИИ становится рычагом.

Разработчик в KT.Team - не кодер, который закрывает таски.

Это инженер, который самостоятельно доставляет бизнес-ценность через изменение workflow, использует AI как базовый инструмент, общается с конечным пользователем и отвечает за результат на продуктиве.

Минимально достаточное состояние по регламенту - L20-инженер на 4 балла и DEVOPS на 4 балла.

Если человек ниже, ИПР должен показывать понятный путь к этому уровню максимум за 6 месяцев. L20 требует end-to-end ответственности.

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

Нельзя засчитать L30 только потому, что ПМ назвал работу эпиком.

Но публичные материалы Amazon хорошо объясняют, почему такая шкала появилась. В статье AWS The New Unit of Software Delivery: The Workflow

Шварц пишет, что с agentic AI единицей разработки становится workflow: сквозной процесс с бизнес-целью, который можно специфицировать, доставлять, тестировать и улучшать как единое целое.

Это почти прямое описание нашего L30: workflow как единица результата, а не экран, API или user story. Amazon two-pizza teams строятся вокруг малых автономных команд и single-threaded ownership.

Публичное описание AWS подчеркивает, что такие команды владеют полным customer experience и жизненным циклом продукта или сервиса.

Это близко к нашему требованию end-to-end ответственности: L20 для ценности, L30 для workflow.

Фогельса 2026 года про возвращение к two-pizza culture показывает ту же логику уже в AI-продуктовой команде: малая команда, автономия, использование собственного продукта с первого дня и правило ownership.