Нейросети обещали избавить от главной рутины — написания кода. С этим‑то они справились, тот генерируется практически молниеносно. Однако спустя несколько мгновений, при осмыслении разницы между старым и новым кодом в 2 000 строк, наваливаются вопросы: почему агент переработал несвязанные файлы, безопасна ли новая логика и какое именно безобидное изменение привело к регрессии?
Кодогенерация подешевела до копеек, но главное бутылочное горлышко так никуда и не исчезло — оно просто сместилось с написания на осмысление, валидацию, тестирование, интеграцию, сопровождение и поддержку.
Red Hat в последние дни привлекает к себе внимание не только переходом CERN с RHEL на Debian, но и высказываниями по поводу ИИ‑разработки: ее будущего и настоящего. Что ж, бегло взглянем на идеи, озвучиваемые одним из лидеров IT-индустрии.
Куда уходит время
На самом деле, набор команд никогда и не был главной проблемой разработки. Настоящая сложность — в проектировании. Нужно предусмотреть интеграцию со сторонними системами, CI/CD‑конвейер, вопросы безопасности. Теперь, с фантастической скоростью написания кода, затор особенно ощущается на следующих этапах — и чем крупнее организация и масштабнее проекты, тем явственнее.
Человек никогда не угонится за машиной. На генерацию 300 строк сложной логики уйдет, скажем, пять секунд, но на проверку пограничных случаев живому инженеру потребуется столько же времени, сколько и раньше.
Уроки опыта
Чтобы упростить жизнь разработчика, Red Hat приводит несколько простых советов. Большинство читателей не найдет в них ничего для себя нового, но начинающим они могут оказаться полезными.
Сделай сам
Одно из самых неприятных открытий при освоении ИИ — тот далеко не всегда экономит время. Нужно быстрое решение, а в ответ — необъятная «простыня» или переделка половины файла.
Порой быстрее сделать самому, нежели объяснять старательному, но бестолковому помощнику.
Memento
Вроде бы агент хорошо понимает контекст, но несколько итераций — и… будто части разговора и не было. Именно поэтому инструкции должны сохраняться в файлах репозитория. Модель не всегда будет пытаться помнить о файлах, соглашениях, связях и решениях. Лучше не надеяться, что она каждый раз станет пытаться все осмыслить самостоятельно. Вот пример:
Правила API
‑ Сервисы не могут напрямую обращаться к таблицам базы данных вне своего домена.
‑ Используй только слой репозитория.
‑ Все внешние HTTP-вызовы требуют явного указания таймаутов и обработки повторных попыток.
‑ Используй структурированное логирование (никакого сырого вывода в консоль).
‑ Не добавляй новые зависимости без явного согласования.Прототип, но не продакшен
ИИ — отличный инструмент для проверки идей, но ему не место в ответственных процессах. С другой стороны: разумно ли отказываться от быстроты разработки?
В Red Hat предлагают компромиссное «прототипирование атмосферы». Получается цикл из трех шагов.
- Быстро создается высококачественный интерактивный прототип — скажем, до 2 000 строк кода.
- Проверяется идея, «щупается» пользовательский интерфейс, собираются требования.
- Прототипный код безжалостно выбрасывается. Остается наработанная суть: проверенные требования, UI/UX-опыт, технические предположения — вот с ней и ведется дальнейшая работа.
Агент должен понимать текущую роль
Нельзя путать режимы или комбинировать их. Направление движения для агента должно быть очевидным: рефакторинг, создание тестов, исправление ошибок, устранение проблем в релизных ветках… да, что угодно.
Работа ведется атомарными проверяемыми шагами и в конкретной области. Не должно быть никаких незапланированных изменений в стиле «кстати, хорошо бы и это подкрутить».
Модель не должна быть одна
Разные направления поручаются разным агентам. Так сэкономятся не только деньги, но и время:
- сложные модели — рассуждения о проектировании архитектуры, продумывание комплексной рефакторизации, построение логики распределенных систем, углубленная отладка;
- простые, но быстрые и недорогие модели — для шаблонного кода, простой структуры модульных тестов, документации и рутинных преобразований.
Нужна не самая лучшая модель, а просто подходящая для конкретной задачи.
Атрофия навыков из‑за фастфуда для мозга
Плохой код можно отловить на ревью. Намного опаснее — деградация инженерного мышления. Интуиция разработчика рождается из боли: многочасовой отладки, чтения чужих исходников, докапывания до причин собственных ошибок.
Если джуниор всегда просит готовое решение у нейросети до того, как попытается вникнуть в проблему, он выдаст рабочий результат, но так и не сформирует нужные ментальные связи.
Со временем под угрозой окажется и цель разработки — не код побыстрее, а продукт понадежнее.
Еще сохраняется поколение, представители которого умеют писать код сами, а значит могут разобраться и в чужом.
Но что будет через двадцать лет, если останутся только те, кто не учил языки программирования и не писал, не отлаживал сам? Насколько агрессивно поведут себя ИИ‑вендоры, глядя на складывающуюся ситуацию и понимая зависимость от их продуктов?
Не исключено, что те, кто не забросит математику и программирование, станут на вес золота — ведь никто, кроме них, уже не будет способен разобраться в странных письменах и взаимосвязях.
