Зачем писать код, если это лучше делает AI

Вопрос, который всё чаще звучит на собеседованиях, в чатах и в голове у разработчиков: зачем вообще писать код, если AI-агент делает это быстрее, без усталости и не просит повышения зарплаты?

Это не риторический вопрос. Это честный вопрос, на который нужен честный ответ.

Сначала признаем очевидное

AI-агенты уже сейчас пишут код лучше среднего разработчика в типовых задачах. Бойлерплейт, CRUD, юнит-тесты, миграции базы данных, REST-обёртки - всё это генерируется за секунды и в большинстве случаев работает с первого раза.

Если ваша работа состоит только из этого - проблема реальна.

Но вот в чём парадокс: компании, которые начали заменять разработчиков AI-агентами, столкнулись с тем, что агенты отлично пишут код, но плохо понимают, зачем его писать. И ещё хуже - когда не надо.

Что на самом деле делает разработчик

Код - это не продукт работы разработчика. Код - это побочный эффект.

Продукт - это решение проблемы. А между “проблемой” и “кодом” стоит огромная работа, которую AI пока делает плохо:

• Формулировка задачи. “Нам нужна кнопка регистрации” - это не задача. Задача - понять, почему пользователи не регистрируются, и выяснить, решит ли кнопка эту проблему вообще.
• Выбор, что не строить. Лучшее решение часто - не писать код совсем. Купить SaaS, использовать существующий инструмент, изменить процесс. AI не предложит “не делать это”.
• Понимание контекста системы. Агент не знает, что этот модуль трогали шесть команд за три года, что в нём есть скрытые инварианты, которые нигде не задокументированы, и что последний раз, когда кто-то “просто добавил поле”, упал продакшен.
• Принятие ответственности за решение. Агент может сгенерировать три архитектурных варианта. Кто-то должен выбрать один и объяснить, почему - совету директоров, команде, будущему себе.

Опытный разработчик: сместите фокус

Если у вас за плечами 5+ лет опыта, ваш главный актив - не умение писать код. Это умение читать ситуацию.

Что становится важнее

Навык постановки задачи агенту. Качество выходного кода AI прямо пропорционально качеству входного контекста. “Напиши сервис аутентификации” и “Напиши сервис аутентификации для B2B SaaS с поддержкой SAML SSO, где тенант может иметь несколько доменов и настраивать политики сессий” - это разные задачи, и разница в выходе колоссальная.

Навык ревью AI-кода. Агент пишет уверенно, даже когда ошибается. Он не скажет “я не уверен” - он напишет код, который выглядит правильно, но содержит race condition, который проявится под нагрузкой. Умение это найти - человеческий навык.

// AI сгенерировал. Выглядит нормально.
func (s *Service) GetUser(id string) (*User, error) {
    if cached, ok := s.cache[id]; ok {
        return cached, nil
    }
    user, err := s.db.Find(id)
    if err != nil {
        return nil, err
    }
    s.cache[id] = user
    return user, nil
}

// Проблема: map без мьютекса в конкурентном коде.
// AI не знал, что этот метод вызывается из горутин.
// Вы должны были это знать.

Системное мышление. Агент видит функцию. Вы должны видеть систему: как эта функция ведёт себя под нагрузкой в 100x, что происходит при частичном сбое, как её будут дебажить в 3 часа ночи.

Управление техдолгом AI. AI-код накапливается быстро. Без архитектурного надзора через полгода получается свалка, где каждый модуль написан “в своём стиле”, нет единой модели данных, и никто не понимает, как это всё связано.

На что тратить время меньше

• Написание бойлерплейта вручную
• Запоминание синтаксиса и API (пусть агент смотрит в документацию)
• Ручное написание юнит-тестов для тривиальных случаев

Новый разработчик: не пропустите фундамент

Здесь я скажу непопулярную вещь.

Если вы пришли в разработку недавно и сразу делегируете написание кода AI - вы строите карьеру на песке. Не потому что “нужно страдать и писать всё вручную”. А потому что нельзя проверить то, чего не понимаешь.

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

Что нужно знать “руками”

Не всё. Но некоторые вещи нужно именно прожить, а не прочитать:

• Отладка. Умение читать стектрейс, ставить breakpoint, строить гипотезы о причине бага. Это мышца, которая развивается только практикой.
• Работа с памятью и производительностью. Хотя бы однажды написать код с утечкой памяти и найти её. Хотя бы однажды сделать N+1 запрос и понять, почему страница грузится 10 секунд.
• Понимание асинхронности. Дедлоки, гонки данных, проблемы с порядком событий - их нужно хотя бы раз поймать и починить самостоятельно.
• Чтение чужого кода. Самый недооценённый навык. AI генерирует код, но индустрия живёт на чтении и понимании существующего.

Как использовать AI правильно

Используйте агента как строгого преподавателя, а не как решебник.

Плохо: "Напиши мне функцию сортировки"
Хорошо: "Я написал эту функцию сортировки, найди в ней проблемы"

Плохо: "Объясни мне, как работает HTTP"
Хорошо: "Я думаю, что HTTP - это X. Где я ошибаюсь?"

Плохо: "Напиши тест для этого кода"
Хорошо: "Я написал тест. Какие edge-кейсы я пропустил?"

Разница: в первом случае вы получаете ответ. Во втором - понимание.

Навыки, которые не устаревают

Есть вещи, которые AI не заменит в обозримом будущем - не потому что они “слишком сложные”, а потому что они требуют контекста, который живёт в людях и организациях:

• Политика и коммуникация. Убедить команду принять архитектурное решение, договориться с бизнесом о компромиссе, объяснить технический долг CFO - это переговоры, а не задача для агента.
• Этика и ответственность. Кто принимает решение о том, как система обрабатывает персональные данные? Кто несёт ответственность за ошибку алгоритма? Агент - нет.
• Доверие и репутация. Команды работают с людьми, которым доверяют. Доверие строится годами и не передаётся по API.
• Навык задавать правильные вопросы. “А зачем мы это вообще делаем?” - самый ценный вопрос в разработке. И самый редкий.

Что произойдёт с рынком

Честный прогноз: количество разработчиков, которые занимаются написанием типового кода, сократится. Количество людей, которые умеют управлять AI-системами, проверять их output и принимать архитектурные решения - вырастет.

Это не конец профессии. Это смена её содержания - примерно как появление IDE не убило программистов, а калькуляторы не убили математиков. Но те, кто не адаптировался, действительно оказались невостребованы.

Практические выводы

Если вы опытный разработчик:

• Инвестируйте время в навык работы с AI-агентами как инструментом, а не противником
• Развивайте архитектурное мышление и навык ревью
• Станьте человеком, который понимает, когда AI-решение неприемлемо

Если вы начинающий разработчик:

• Не делегируйте понимание, только рутину
• Используйте AI для объяснений и проверки своего кода, а не для замены его написания
• Сфокусируйтесь на отладке, чтении кода и понимании систем - этому AI пока не научит

Код - это язык, на котором вы общаетесь с машиной. AI стал хорошим переводчиком. Но переводчик не заменяет человека, который знает, что сказать.