Как разработчику оставаться конкурентоспособным с ИИ

Руководитель просит активнее применять ИИ, коллега за вечер собирает прототип, а ты смотришь на сгенерированный pull request и думаешь: если код достаётся почти бесплатно, за что будут платить разработчику?

Навыки разработчика в эпоху ИИ смещаются от набора кода к постановке задач, проектированию и проверке результата. Разберём это на отмене заказа и соберём план развития без попытки изучить всё сразу.

Модель за минуты подготовит функцию, SQL-запрос или каркас сервиса. Но основное время уходит на работу, для которой нет готового ответа: понять предметную область, найти противоречие в требованиях, выбрать компромисс и проверить последствия.

Конкурировать с ИИ в скорости написания типового кода бессмысленно. Ценность создаёт тот, кто ставит машине точную задачу и замечает правдоподобное, но неверное решение.

Представь задачу: «Добавить отмену заказа». ИИ создаст endpoint, метод сервиса, миграцию и тесты. Сначала команде придётся ответить на вопросы: можно ли отменить заказ после передачи курьеру, кто возвращает деньги, что делать при сбое платёжного провайдера и какая система владеет статусом?

Ответы лежат между бизнес-правилами, устройством систем и договорённостями команд. Даже безошибочный код закрепит плохую модель, если она не учитывает возврат или распределённую ответственность.

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

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

Domain-Driven Design (DDD) связывает устройство программы с предметной областью. Clean Architecture отделяет бизнес-правила от базы данных, фреймворка и HTTP. Системный дизайн заставляет проверить нагрузку, задержки, согласованность и частичные отказы.

Не внедряй эти подходы целиком ради резюме. Если команда спорит о терминах, начни с единого языка. Если изменение задевает несвязанные модули, проверь границы ответственности. Если правила смешаны с SQL и HTTP, отдели политику от технических деталей.

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

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

Одноразовому скрипту не нужны DDD и архитектурная сессия. Чем дешевле ошибка и откат, тем больше работы можно сразу отдать ИИ.

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

Не теряй инженерную глубину. Для проверки сгенерированного кода нужны знания языка, платформы, безопасности и тестирования. T-shaped-профиль расширяет специализацию, а не заменяет её поверхностным знакомством со всеми технологиями.

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