Практический ориентир прост: развивайся в сторону архитектуры и системного анализа, сохраняя глубокую экспертизу в своей технологии. Тогда ИИ ускоряет твою работу, но не принимает решения вместо тебя.
Почему скорость написания кода больше не главный показатель
В разработке всегда были задачи, похожие на набор текста: создать DTO, написать миграцию, добавить однотипный обработчик. Их легко оценить и автоматизировать. Генеративный ИИ расширил этот класс задач и снизил стоимость первой версии кода.
Код занимает лишь часть работы. До него команда выясняет требования, ограничения и границы системы. После него проверяет корректность, безопасность, производительность и совместимость с остальной системой. Получить ещё сто строк кода стало почти бесплатно. Доказать, что это нужные сто строк и они не ломают систему, по-прежнему дорого.
Исследования показывают этот разрыв. В эксперименте
METR 16 опытных разработчиков решали 246 задач в знакомых open-source-репозиториях. С AI-инструментами начала 2025 года они работали на 19% медленнее, хотя субъективно ощущали ускорение. Результат нельзя переносить на все команды и современные модели, но он показывает: быстрая генерация ещё не означает быструю поставку.
DORA 2025 сообщает похожее на уровне команд: ИИ связан с ростом пропускной способности и одновременно со снижением стабильности поставки. Пользу чаще получают команды со слабосвязанной архитектурой, автоматическими тестами и быстрой обратной связью. В тесно связанном legacy дополнительный код быстрее попадает в очередь на ревью и тестирование.
Это согласуется с мыслью из
главы об устройстве разработки: разработка ПО состоит из обучения и принятия решений. В начале задачи конечное решение часто неизвестно. Строки кода плохо отражают ценность, потому что выбор имени, библиотеки или границы компонента может влиять на проект годами.
Где ИИ заканчивает работу, а инженер начинает
Представь задачу для сервиса заказов: «Разрешить отмену заказа». ИИ быстро сгенерирует метод:
type OrderStatus = "new" | "paid" | "shipped" | "cancelled";
function cancelOrder(status: OrderStatus): OrderStatus {
if (status === "shipped") {
throw new Error("Shipped order cannot be cancelled");
}
return "cancelled";
}
Код запускается, но требование остаётся неполным. Можно ли отменить оплаченный заказ без возврата денег? Что делать, если склад уже начал комплектацию? Кто имеет право отменять заказ? Нужен ли аудит? Как повторный запрос повлияет на платёж и остатки?
Ответы зависят от бизнеса и связей между системами. Модель может перечислить правдоподобные варианты, но не знает договорённостей компании и не отвечает за их последствия. Работа инженера здесь состоит в том, чтобы превратить расплывчатую просьбу в согласованные правила, а затем проверить реализацию по этим правилам.
Какие навыки разработчика с ИИ развивать
Исследование предметной области
Учись задавать вопросы владельцу процесса и восстанавливать цепочку событий. Для отмены заказа это могут быть события «оплата принята», «комплектация начата», «доставка передана курьеру» и «возврат создан». Они показывают, где меняются бизнес-правила и какие команды зависят друг от друга.
Полезный результат такого исследования: словарь терминов, список событий, команды, бизнес-инварианты и открытые вопросы. Эти материалы дают ИИ точный контекст и снижают число правдоподобных, но неверных решений.
Системный анализ
Разработчик должен видеть путь изменения через всю систему. Для каждой задачи выясняй:
- кто запускает сценарий и с какой целью;
- какие данные служат источником истины;
- какие сервисы, очереди и внешние системы участвуют;
- что произойдёт при повторе, задержке или частичном сбое;
- как команда поймёт, что изменение работает в продакшене.
Этот список полезен и системному аналитику. Он помогает довести требование до состояния, при котором разработчик может реализовать его без догадок.
Архитектурное мышление
Сначала определи ответственность компонентов, направление зависимостей и место бизнес-правил, а затем выбирай брокер или базу данных. Если правило отмены размазано между интерфейсом, сервисом заказов и платёжным адаптером, ИИ будет уверенно размножать эту связанность.
Подходы Domain-Driven Design помогают отделить модель предметной области от технических деталей. Event Storming помогает совместно с бизнесом найти события, команды, спорные правила и границы контекстов. Используй эти инструменты в задачах с запутанными правилами и несколькими участниками.
Проверка решений ИИ
Не ограничивай ревью вопросом «работает ли код». Проверь, откуда взялись предположения, какие негативные сценарии покрыты, не нарушены ли границы модулей и можно ли наблюдать результат в эксплуатации. Запрос к модели тоже проверяй как техническое решение: контекст должен содержать правила и ограничения, а не только желаемый фрагмент кода.
T-shaped профиль: глубина в технологии, ширина в системе
T-shaped специалист глубоко знает свою основную область и понимает соседние. Для backend-разработчика вертикалью может быть Java и JVM, а горизонталью: предметная область, API, данные, интеграции, безопасность и эксплуатация.
Цель не в поверхностном знании всего. Достаточно уметь заметить зависимость, задать вопрос профильному специалисту и учесть ответ в решении. Такая ширина особенно полезна при работе с ИИ: ты быстрее находишь пропущенный контекст и точнее ставишь задачу модели.
Где этот подход не окупится
Для короткого скрипта, прототипа или изолированной CRUD-функции глубокое моделирование может стоить дороже ошибки. Зафиксируй минимум ограничений, сгенерируй решение и проверь результат тестами.
Чем больше денег, персональных данных, команд и внешних интеграций затрагивает изменение, тем дороже неверное предположение. В таких задачах сначала исследуй процесс и границы системы. ИИ подключай после этого: для вариантов реализации, чернового кода, тестов и поиска пропущенных сценариев.
Что сделать на следующей задаче
Навыки разработчика с ИИ начинаются с понимания системы. Конкурентоспособность дают исследование предметной области, системный анализ, архитектурное мышление и проверка результата. На следующей задаче до генерации кода выпиши события, инварианты, зависимости и сбои. После выпуска оцени lead time до проверенного результата, число итераций из-за требований и дефекты вместо объёма AI-кода.
---