Забудьте о первоначальном ослеплении от ИИ-ассистентов, строчащих код, как неутомимый стажёр на эспрессо. Это День 1. Мы говорим о том, что происходит после того, как новизна исчезла, когда ИИ работает на полную мощность, код поставляется быстрее, чем когда-либо, и тут… что-то начинает ломаться. Не так драматично или катастрофически, как можно было бы подумать, а скорее в этом коварном, бытовом виде трения, который тормозит инженерные команды.
Речь идёт о тонких, но глубоких «проблемах второго дня» внедрения ИИ-технологий в продакшен-код. Это то, что не исправить быстрым туториалом или мотивирующей речью менеджера. Здесь настоящая проверка реальностью для обычных людей, реальных команд и долгосрочного здоровья самого процесса разработки ПО.
Представьте это так: вы только что установили на свою команду сверхмощный автопилотируемый космический корабль. День 1 — это восхищение его скоростью, его способностью автономно ориентироваться в астероидных полях. День 2 — это осознание того, что центр управления полётами завален уведомлениями, навигационные карты — полный хаос, а капитан проводит весь день, пытаясь расшифровать непонятные бортовые журналы. Вот где мы сейчас.
Узкое горлышко ревью кода: больше кода, меньше ясности?
Самое немедленное влияние генерации кода с помощью ИИ ощущается в процессе ревью кода. Внезапно ваш когда-то управляемый поток пул-реквестов (PR) превращается в настоящий потоп. Тысячи, возможно, десятки тысяч строк кода, сгенерированного ИИ, ежедневно поступают в очереди на проверку. Для инженеров это означает, что ревью кода, которое и так многим в тягость, становится экспоненциально более тяжёлой ношей. Это как просить кого-то вычитать «Войну и мир» после того, как её перевёл с чрезмерной любовью к многословию машинный переводчик.
Дело не только в объёме; дело в доверии и ответственности. Как отметил один техлид крупного предприятия:
Инженеры отправляли ИИ-вывод, не проверив его сначала самостоятельно. PR стал первым моментом, когда кто-то критически взглянул на то, что произвёл агент.
Перед старшими инженерами встаёт мучительная дилемма: насколько детально они могут scrutinized? Построчное глубокое погружение в 5000 строк кода, сгенерированного ИИ, — это практически полная занятость. Однако поверхностный просмотр ощущается как неисполнение долга, потенциальное рассадник для тонких ошибок или уязвимостей безопасности.
Автоматизация привратников и переобучение писцов
Итак, как это исправить? Дело не в отказе от ревью; дело в их эволюции. Ваш CI/CD-пайплайн — ваш друг в этом деле. Инструменты для ревью кода на основе ИИ — например, CodeRabbit, Greptile или Claude Code review от Anthropic — могут выступать в роли утончённых первых респондентов, выявляя поверхностные проблемы, такие как очевидные ошибки, отсутствующие тесты и нарушения стиля. Они не заменят человеческое суждение, но они значительно сокращают поверхность, которую должны покрывать старшие инженеры.
Обучение инженеров начального уровня отличать реальные проблемы от ИИ-сгенерированных «ложных срабатываний» также является ключевым. Научить их чётко формулировать, почему определённый ИИ-вывод является приемлемым или нет, — это критически важный навык в этом новом ландшафте.
Более фундаментально, нам нужно восстановить ответственность автора. Внедрение «предварительного ревью» — где автор должен тщательно проверить свой собственный код, созданный с помощью ИИ, перед его отправкой на ревью коллегами — может вернуть ответственность. Легкость ревью и конечное качество кода по-прежнему отражаются на инженере, независимо от того, кто (или что) написал первоначальный черновик.
Узкое горлышко в начале цепочки: неясные тикеты, замедленная скорость
Но пайплайн начинается не с кода; он начинается с идей. Фаза планирования и создания тикетов — JIRA, Linear, GitHub Issues — не ускорилась магическим образом благодаря ИИ. Неясные тикеты создают волновой эффект задержек. Инженеры тратят драгоценное время на уточняющие вопросы, на многократные переписки, которые накапливаются. Чёткие критерии приёмки, детальные шаги воспроизведения и достаточный контекст системы — это больше не просто лучшие практики; это существенное топливо для ускоренной ИИ-разработки.
Это распространяется на всю «бумажную работу» разработки ПО: обновления статусов, проектные документы, заметки о передаче. Это связующие ткани, которые поддерживают команду в синхронизации. Когда ИИ ускоряет написание кода, эти более медленные, более человеко-ориентированные процессы становятся разительными узкими местами. Это как дать вашему космическому кораблю гипердрайв, но забыть обновить систему связи центра управления полётами.
Что можно сделать с отслеживанием проблем и сбором требований?
Эксперименты — ключ ко всему. Представьте, что вы создаёте ИИ-навыки, которые могут проактивно анализировать входящие тикеты. Чётко ли поставлена цель? Определены ли требования? Есть ли названный стейкхолдер? Для отчётов об ошибках предоставлены ли шаги воспроизведения? Речь идёт не о полной замене человеческого суждения, а о его дополнении, маркировке потенциальных проблем до того, как они замедлят весь цикл разработки. Цель — гарантировать, что ИИ получает высококачественную информацию, предотвращая усиление существующих неэффективностей.
В конечном счёте, эти проблемы «второго дня» — не препятствия для внедрения ИИ; это необходимые трудности роста фундаментального изменения платформы. Они заставляют нас переосмысливать наши рабочие процессы, переобучать наши ожидания и дорабатывать наши процессы. Будущее разработки ПО — это не просто более быстрое написание кода; это построение более устойчивых, более эффективных и более человеко-ориентированных систем вокруг ИИ, который теперь является неотъемлемой частью уравнения.
🧬 Связанные идеи
- Читать далее: PRDraft: GitHub-приложение, которое наконец-то исправит ваши паршивые описания пул-реквестов
- Читать далее: RADV впервые получает поддержку Primitive Restart Index Vulkan: тихий ход Linux-графики
Часто задаваемые вопросы
Что такое «проблемы второго дня» при внедрении ИИ-кодинга? Проблемы второго дня относятся к операционным проблемам и проблемам рабочего процесса, которые возникают после первоначального внедрения и интеграции ИИ-инструментов для кодинга, в отличие от первоначальных проблем установки и онбординга (проблемы первого дня).
Как ИИ-инструменты могут улучшить ревью кода? ИИ-инструменты могут автоматизировать обнаружение поверхностных проблем, таких как ошибки, нарушения стиля и отсутствие тестов. Это сокращает объём кода, который старшие инженеры должны вручную проверять, освобождая их для более сложных задач.
Заменит ли ИИ человеческих ревьюеров кода? Хотя ИИ может значительно дополнить и помочь в ревью кода, обрабатывая рутинные проверки, он вряд ли полностью заменит человеческих ревьюеров. Человеческое суждение по-прежнему необходимо для понимания контекста, архитектурных последствий и нюансов логики.
