Восемь задач разработчика: что отдать ИИ, а что оставить людям

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

ИИ перекроил этот цикл. Опишите задачу обычным языком, и ассистент за секунды выдаст код, тесты, документацию, SQL-запросы, регулярные выражения, идеи для рефакторинга и зацепки для отладки. Но в спорах о том, что «ИИ заменит разработчиков», обычно теряется одно различие: генерация кода — это ещё не инженерия.

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

1. Шаблонный код

Пожалуй, это проще всего делегировать. Обычный список: CRUD-эндпоинты, модели базы данных, UI-компоненты и формы, API-клиенты, правила валидации, конфиги, сериализаторы, DTO и базовая обработка ошибок. Ничего сложного здесь нет. Просто однообразно.

Возьмём API для управления пользователями. Если писать вручную, придётся выстраивать длинную цепочку слоёв:

User Model
    ↓
Schema
    ↓
Repository
    ↓
Service
    ↓
Controller
    ↓
Validation
    ↓
Tests

Это много набора текста. ИИ-ассистенту хватит простого описания, например: эндпоинт регистрации на FastAPI с PostgreSQL, который проверяет email, хеширует пароль, не пускает дубликаты и возвращает ID нового пользователя. Рабочий первый черновик появляется почти сразу.

Но есть серьёзная оговорка: сгенерированный код никогда не принимают вслепую. Аутентификация, авторизация, валидация, SQL-запросы, обработка ошибок, версии зависимостей, безопасность, производительность и пограничные случаи — всё это должен посмотреть человек. ИИ даёт первую реализацию, а за финальную отвечает разработчик.

Арифметика времени выглядит заманчиво. Задача, которая вручную занимает 45 минут, может дать первую версию за 2 минуты, плюс примерно 10 минут на ревью и тесты. Ускорение приятное, но главный выигрыш в том, что реже приходится переключаться. Никому не нужно бросать настоящую задачу, чтобы набрать ещё 30 строк обвязки.

2. Юнит-тесты

Тесты — идеальный пример помощи, которая не снимает ответственности. Вот небольшая функция:

def calculate_price(price, discount):
    return price - (price * discount / 100)

Разработчику пришлось бы продумать обычные скидки, ноль, 100%, отрицательные значения, некорректный ввод, поведение чисел с плавающей точкой и неожиданные типы. Вместо того чтобы писать первый набор тестов руками, попросите ассистента сделать pytest-кейсы для обычных значений, границ, некорректного ввода и пограничных случаев. Он может вернуть что-то такое:

def test_no_discount():
    assert calculate_price(100, 0) == 100


def test_full_discount():
    assert calculate_price(100, 100) == 0


def test_half_discount():
    assert calculate_price(200, 50) == 100

Дальше ревью, и именно здесь кроется опасность. Тесты, написанные ИИ, могут вводить в заблуждение. Набор может давать 100% покрытия и всё равно быть ужасным, потому что покрытие — не корректность. Ассистент может просто пересказать, что делает текущий код, и если код ошибочен, тесты бодро подтвердят ошибочное поведение.

Поэтому спрашивать нужно, какое поведение на самом деле должно быть гарантировано. Это часть человека. ИИ пишет однообразный тестовый код, а разработчик решает, что стоит тестировать.

3. Документация

Документация важна, а начинать её с чистого листа мучительно. Команды откладывают её с обещанием написать потом, и через полгода уже никто не может объяснить, как работает система.

С ИИ первый черновик даётся гораздо легче. Дайте ему исходный код, описания API, конфигурацию, заметки по архитектуре, существующий README и инструкции по деплою, а потом попросите README с установкой, переменными окружения, локальной разработкой, настройкой базы, эндпоинтами, тестами и деплоем. Вернётся структурированный документ, который проверяет человек.

Особенно это удобно для:

• README, где объясняется, как запустить проект
• документации API с эндпоинтами и форматами запросов и ответов
• комментариев к запутанным участкам кода
• чейнджлогов с кратким описанием различий между релизами
• внутренних документов, собранных из черновых технических заметок
• материалов для онбординга, которые помогают новичкам разобраться в проекте

4. Regex, SQL и прочие задачи из серии «знаю, но забыл синтаксис»

Это мелкие отвлечения, которые ИИ убирает. Цель понятна, нечёток только синтаксис. Это может быть регулярка, сложный SQL-запрос, shell-команда, заклинание для Git или метод JavaScript. Вместо того чтобы продираться через десять страниц документации, опишите, что нужно, например: найти пользователей, у которых не меньше трёх покупок за последние 30 дней, и вернуть сумму их трат.

Ассистент пишет запрос, человек его проверяет. ИИ отвечает за синтаксис, человек — за логику.

Допустим, есть схема с такими таблицами:

users
orders
payments

Пусть нужен топ-10 клиентов по сумме платежей за последние 30 дней. Первый вариант запроса приходит быстро, но человек всё равно проверяет джойны, дубли строк, поведение NULL, индексы, границы дат, часовые пояса, агрегацию и производительность. Запрос, верный на 1 000 строк, может еле ползти на 100 миллионах, а ассистент не знает продакшен-окружения. Сгенерированный SQL — это черновик, а не автоматически готовый к продакшену код.

5. Отладка

В отладке ИИ, возможно, экономит больше всего времени. Дорого обходятся редко глубокие баги. Часто виновник банально глуп: не задана переменная окружения, не совпадает версия пакета, опечатка в имени, гонка по времени, расходятся настройки окружений, случайный null или ответ API неожиданной формы. Больнее всего найти причину, и в этих поисках ИИ хорошо помогает.

Если вставить одну голую ошибку вроде этой, толку будет мало:

TypeError: undefined is not a function

Контекст меняет всё. Укажите фреймворк и версию, скажите, какой компонент бросает ошибку и когда (например, при отправке формы), приложите код компонента, стек вызовов и ожидаемое поведение и попросите назвать самые вероятные причины плюс минимальное безопасное исправление.

Типичный процесс выглядит так:

Error
   ↓
Collect Context
   ↓
Ask AI for Possible Causes
   ↓
Rank the Causes
   ↓
Test the Hypothesis
   ↓
Apply Fix
   ↓
Run Tests
   ↓
Verify

ИИ не заменяет процесс отладки. Он ускоряет расследование, и это куда более реалистичная картина разработки с ИИ.

Три задачи, которые стоит оставить людям

Если ИИ умеет писать код, тесты, SQL и документацию, почему бы не отдать ему всё? Потому что инженерия — это больше, чем генерация кода. Некоторые решения требуют контекста, суждения, ответственности, понимания бизнеса, опыта и общения, и в этих областях люди должны оставаться глубоко вовлечёнными.

6. Архитектура системы

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

Frontend
   ↓
API Gateway
   ↓
Microservices
   ↓
Message Queue
   ↓
Databases
   ↓
Cache
   ↓
Monitoring

Выглядит внушительно. Но представьте компанию с тремя разработчиками, 10 000 пользователей, скромным бюджетом, одним продуктом и умеренным трафиком. Нужны ли ей 15 микросервисов? Вряд ли. Модульный монолит мог бы оказаться в разы проще.

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

ИИ может всё это объяснить. Чего он сам по себе не знает, так это какой компромисс подходит именно этой компании. Это и есть инженерное суждение.

7. Продуктовые решения

ИИ может анализировать варианты, но владеть роадмапом он не должен. Допустим, стартап может сделать одну из двух фич. Первая займёт два месяца и, возможно, поднимет выручку. Вторая займёт три дня и улучшит удержание. Какая победит?

Ассистент поможет взвесить трудозатраты, возможный эффект, рыночные тренды и отзывы клиентов. Но решение зависит от бизнеса. Может быть, ближайшая цель — привлечь инвестиции. Может быть, главная беда — удержание. Может быть, первую фичу попросил крупный клиент или её только что выпустили конкуренты. У ИИ нет этого контекста, пока его не дадут.

Слабый вопрос звучит как «что нам сделать?». Сильный — «с учётом наших целей, клиентов, ограничений и ресурсов, что нам сделать следующим?». Второму вопросу нужен контекст, поэтому продуктовое мышление и остаётся таким ценным.

8. Нестандартное решение задач

Эту область важнее всего оставить за людьми. Шаблоны помогают со знакомыми задачами, но некоторые инженерные проблемы по-настоящему новые: существующая архитектура не работает, требования противоречат друг другу, производительность странно плохая, у продукта необычные ограничения или очевидное исправление порождает новую проблему. Здесь и нужна изобретательность.

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

Из автора в ревьюера

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

• Это правильно? Решает ли код настоящую задачу?
• Это безопасно? Есть ли что-то, чем может воспользоваться злоумышленник?
• Это поддерживаемо? Разберётся ли в этом коллега через полгода?
• Это эффективно? Справится ли код с реальными продакшен-данными?
• Это протестировано? Что происходит на границах?
• Это совместимо? Вписывается ли код в остальную систему?
• Это нужно? Не добавляется ли сложность, которая никому не нужна?

Будущее, скорее всего, не за тем, кто генерирует больше всего кода. Оно за теми, кто хорошо оценивает код.

Плохие разработчики тоже ускоряются

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

Представьте человека, который не понимает SQL и просит у ИИ запросы к базе. Результат работает — до продакшена:

100 users
   ↓
Works perfectly

100,000 users
   ↓
Slow

10,000,000 users
   ↓
Production incident

Пробел в знаниях создал не ИИ. Он лишь ускорил появление результата.

Другой набор навыков

Современным разработчикам нужен чуть более широкий набор умений. Одного программирования уже недостаточно:

Programming

Лучше картина выглядит так:

Programming
     +
System Design
     +
AI Collaboration
     +
Code Review
     +
Testing
     +
Security
     +
Product Thinking

ИИ — ещё один инструмент в инженерном арсенале.

Реалистичный день

Обычный рабочий процесс с ИИ может выглядеть так:

1. Сначала разберитесь в задаче. Прочитайте требование сами и не отдавайте его сразу ИИ: сначала задача должна стать понятной.
2. Попросите альтернативы. Опишите проблему и запросите три подхода с компромиссами. Так часто всплывают варианты, о которых никто не думал.
3. Выберите. Этот шаг остаётся за человеком. Учитываются сложность, опыт команды, производительность, стоимость, поддерживаемость и безопасность.
4. Сгенерируйте шаблонный код. Теперь модели, интерфейсы, обработчики API, тесты, документацию и базовые компоненты может сделать ассистент, и здесь появляется экономия времени.
5. Сделайте ревью. Прочитайте сгенерированный код целиком, а не только первые строки.
6. Протестируйте. Запустите юнит-тесты, интеграционные тесты, ручные проверки и пограничные случаи. Если что-то падает, передайте ошибку обратно ИИ.

ИИ берёт на себя набор текста, а думать остаётся людям.