Рано или поздно к вам приходит сотрудник с запросом о повышении зарплаты. Вы видите: за прошедший период он многое сделал, заметно прокачал технические и организаторские навыки. Сомнений в том, что он может пойти на повышение грейда, нет. Но прежняя шкала оценки уже не годится: она не учитывает умение работать с новыми инструментами. ИИ изменил разработку, однако осознали это далеко не все.

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

Зарплатные ожидания

Меня зовут Станислав Решетнев, я руководитель направления разработки Link Building в Sape. История с зарплатными ожиданиями реальна. Наверняка вы сталкивались с подобным в последнее время. И я хотел бы поделиться соображениями, которые могут помочь вам правильно настроить сотрудников.

Начнем с симптомов. Еще с 2023 года крупные западные IT-компании — IBM, Dropbox, Stack Overflow, Google, Microsoft и другие — либо заморозили найм, либо перешли к выборочным сокращениям. Примерно с 2025 года эта тенденция добралась до России. Оптимизации продолжаются и сегодня, хотя их прямо не связывают с ИИ, а из-за репутационных рисков зачастую вообще не называют сокращениями.

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

Фонд оплаты труда — оплата ключевого актива в IT-компаниях — зарплаты разработчиков и менеджеров. На него приходится 65-75 % всех расходов (в стартапах и аутсорсинге доля еще выше). После прихода ИИ в процесс создания кода позволить себе прежние зарплатные модели мало кто может. Поясню, почему это так.

Переоценка IT-активов

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

Скорость ручного написания кода больше не является определяющей ценностью.

Процесс разработки с использованием ИИ уже проник в BigTech и дал ощутимое ускорение. Например, Яндекс на конференции Infrastructure’2026 сообщил о росте производительности внутри компании в 2-10 раз. Вскоре AI SWE (AI Software Engineering) оформится как промышленный стандарт, как это произошло, например, с платформами контейнеризации (Docker/Containerd), оркестрации контейнеров (Kubernetes), облачными платформами (Amazon), да и, чего далеко ходить, с API LLM (благодаря OpenAI).

При должной оптимизации процесса производство может вырасти на порядок. Это вдохновляет: мы можем получить в десять раз больше фич за то же время. Но нужны ли они бизнесу? Сможет ли пользователь освоить такой объем нововведений или существует естественный предел?

Бизнес сейчас находится на этапе переоценки. С одной стороны, необходимо оптимизировать скорость разработки, чтобы не отстать от конкурентов. С другой — есть риск распылить усилия и потерять ориентир в потоке новых функций.

Техническая и организационная сторона вопроса

Выше я говорил об ИИ-агентах для написания кода как о средстве, ускоряющем разработку (точнее, усиливающем уже сформированные в компании возможности). Однако важно разделять ИИ как инструмент индивидуального ускорения и как корпоративный инструмент с ожидаемой отдачей. Если с персональным использованием все более-менее понятно и такие практики стоит стимулировать, то внедрение на уровне компании тесно связано с платформеризацией.

Вот почему платформа так важна:

• Микросервисы и ИИ. Для эффективной работы генеративным моделям необходим замкнутый контекст. Он естественным образом ограничен рамками микросервиса. ИИ лучше справляется с небольшим и понятным приложением, чем с большим, запутанным, написанным в разных стилях и подходах. Платформа может предоставлять единый шаблон и стандарт для написания микросервисов.

• Деление на слои и ИИ. Чистая архитектура Роберта Мартина, MVC/MVVC неожиданно обретают особую ценность. Получается, что не только человеку проще разобраться и написать понятный код, но и ИИ. Платформа может определять уровни приложения и четко их описывать.

• Manifest First и ИИ. Если у микросервиса есть контракт в виде спецификации (например, OpenAPI), ИИ предельно ясны «намерения» разработчика. Понятно, какой функциональности мы ждем на выходе. Идеально, если спецификация задает каркас приложения.

• TDD (Test Driven Development) и ИИ. Приемочные автотесты гарантируют корректность реализации, так и было задумано в методологии. Но в случае с микросервисами, создаваемыми ИИ, мы дополнительно снижаем технологические риски (ИИ может сильно ошибаться), а сами автотесты теперь обходятся дешево.

Интересно, что микросервисная архитектура органично ложится на идею генерации кода ИИ. «Кирпичики» в виде микросервисов легко заменяются на другие, а качество кода полностью определяется контрактом микросервиса и приемочными автотестами.

Отмечу, что в Sape мы начали внедрение ИИ-агентов кодирования именно со стороны внутренней Платформы разработки (IDP). Мы предоставили разработчикам персональных ИИ-агентов с автоматизированными типовыми и наиболее трудоемкими задачами, провели обучение их использованию. Об этом опыте я обязательно расскажу в последующих статьях.

Программист, разработчик, технический менеджер

Роль кодера за последние десятилетия не раз менялась. Мы привыкли называть его программистом, но со временем пришло понимание, что это понятие не в полной мере отражает необходимую степень ответственности за результат. Мы не хотим, чтобы к программисту прилагался отдельный менеджер, разбирающийся, насколько код соответствует ожиданиям бизнеса. Это слишком дорого.

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

С приходом ИИ формируется новая роль — менеджер ИИ-агентов, он же тимлид/техлид. По сути, разработчик становится тимлидом для команды из ИИ-агентов.

Теперь от него требуются следующие качества:

• Системность в мышлении и в организации работы. Важно строить план выполнения и тщательно следить за тем, как агент движется по этому плану.

• Отличное архитектурное видение. На первый план выходит понимание архитектур приложений и умение выбрать оптимальную. Разработчик должен знать все аспекты микросервисной архитектуры.

• Умение работать с 4-5 ИИ-агентами. Это непростая задача с учетом того, что происходит частое переключение контекста. При этом разработчик не имеет права быть ведомым нейросетями. Он сам должен корректировать ход работы, применяя свое видение.

Обратите внимание: уровень ответственности разработчика повышается сразу по двум направлениям: управленческому (тимлид ИИ-агентов) и архитектурному (техлид для ИИ-агентов). 

Пока не выработан промышленный стандарт, именно разработчик может стать драйвером изменений — перестроить свои подходы и помочь компании адаптироваться.

Подытожим

Человеку всегда тяжело даются перемены. Особенно сложно, когда он полностью погружен в свою работу и у него нет времени переосмыслить, как меняется отрасль. Задача руководителя — помочь разработчику сначала принять новые реалии, а затем адаптироваться к ним. Надеюсь, эта статья поможет вам сориентироваться в изменениях и задать сотрудникам верные ориентиры для развития.