6.4 Разработка программ с помощью ИИ

Обзор и мотивация

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

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

Для больших команд трудность в согласованности и безопасности в масштабе. Когда сотни разработчиков используют ИИ-помощников, малые индивидуальные привычки складываются в организационные результаты. Если все принимают предложения некритично, нагрузка на рецензирование и доли дефектов растут. Если вы даёте ясные нормы, хорошие умолчания и сильную проверку, те же инструменты повышают пропускную способность, не снижая качества. История производительности также тоньше, чем предполагают заявления поставщиков. Реальные выигрыши сильно различаются по задачам, а наивное измерение вроде подсчёта принятых предложений введёт вас в заблуждение.

Корпоративная и государственная среда добавляют более острые ограничения. Коду, касающемуся регулируемых систем, обращающемуся с чувствительными данными или управляющему критичной инфраструктурой, нельзя доверять только потому, что его произвёл ИИ. Происхождение лицензий важно, когда порождённый код может эхом повторять обучающие данные под ограничительными лицензиями. Некоторые организации обязаны держать исходный код локально и не могут отправлять его во внешние сервисы вовсе. Установление ясных принуждаемых норм для помощи ИИ теперь часть ответственного инженерного лидерства. Среди доступных помощников инструменты на основе моделей Claude от Anthropic один ведущий вариант наряду с другими; приведённые ниже практики применимы, что бы вы ни приняли.

См. также: глава 2.5 (рецензия кода и сотрудничество), глава 2.4 (стратегия тестирования) и глава 6.5 (ответственный и надёжный ИИ).

Ключевые принципы

• Инженер, а не помощник, отвечает за каждую зафиксированную строку.
• Код, порождённый ИИ, это черновик для рецензии и проверки, а не готовый продукт, которому можно доверять.
• Усилия проверки должны масштабироваться с риском кода, а не с тем, как уверенно выглядит вывод.
• Измеряйте производительность результатами, которые важны (поставленная ценность, качество, время цикла), а не числом предложений.
• Защищайтесь от рисков безопасности и лицензирования, вносимых порождённым кодом.
• Сохраняйте и развивайте человеческое инженерное мастерство; не позволяйте помощникам его выхолащивать.
• Будьте прозрачны в том, где и как используется помощь ИИ.

Рекомендации

Используйте парное программирование с ИИ как инструмент черновика и исследования

Направляйте помощников на задачи, где они блистают и где ошибки дёшево ловить: шаблонный код, каркас тестов, преобразования форматов, объяснение незнакомого кода и исследование подходов. Воспринимайте их вывод как первый черновик. Оставайтесь за рулём. Читайте, понимайте и редактируйте каждое предложение, а не принимайте на автопилоте. В незнакомых областях используйте помощника для обучения, но сверяйте его утверждения с авторитетной документацией. Помощники могут изобретать API и искажать поведение с полной уверенностью.

Рецензируйте, тестируйте и проверяйте порождённый ИИ код как недоверенный ввод

Применяйте к порождённому ИИ коду ту же тщательность, что и к коду нового члена команды, или большую. Человеческий рецензент должен понимать его достаточно, чтобы объяснить и сопровождать. «Это написал ИИ» никогда не приемлемый ответ на «почему это работает?». Настаивайте на тестах и остерегайтесь порождённых ИИ тестов, лишь утверждающих текущее поведение, а не задуманное. Запускайте статический анализ, сканирование безопасности и проверки зависимостей. Для высокорискового кода (аутентификация, криптография, финансовая логика, системы безопасности) воспринимайте вывод ИИ как отправную точку, требующую экспертной человеческой проверки, никогда как авторитетный.

Измеряйте производительность честно и задавайте реалистичные ожидания

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

Управляйте рисками безопасности и лицензирования

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

Задайте нормы команды, раскрытие и сохранение навыков

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

Компромиссы: плюсы и минусы

Измерение	Выгода помощи ИИ	Риск помощи ИИ
Скорость	Быстрее шаблонный код и черновики	Время, потерянное на рецензию неверного кода
Знакомство	Легче вход в новые языки/фреймворки	Поверхностное понимание, изобретённые API
Качество	Больше тестов, быстрее рефакторинг	Правдоподобный, но тонко неверный код
Безопасность	Может предлагать исправления и сканирование	Может вносить уязвимости
Навыки	Освобождает время для более ценной работы	Размывает основы при чрезмерном использовании
Лицензирование	Быстрее повторное использование общих шаблонов	Происхождение и лицензионная экспозиция

Центральный компромисс это скорость против проверки. ИИ смещает усилия с написания на рецензирование. Чистый выигрыш зависит от того, достаточно ли сильны ваши практики рецензии и проверки, чтобы поймать то, в чём помощник ошибается. Слабая рецензия ведёт к падению качества. Сильная рецензия и ясные нормы улавливают выгоду.

Вопросы для обсуждения с командой

1. Какие части нашей кодовой базы полностью закрыты для помощи ИИ и как мы принуждаем эту границу? Единообразное доверие ловушка: применение той же лёгкой тщательности к аутентификации, криптографии, финансовой логике и системам безопасности, что и к шаблонному коду, то, как тонкие уверенные ошибки достигают критичных путей. Для большой команды явный список исключённых модулей или модулей только с экспертной рецензией превращает индивидуальное суждение в организационную защиту. Принесите вашу карту рисков кодовой базы, текущую политику (если есть) и как вы на самом деле остановили бы порождённый код от попадания в ограниченный модуль: проверки конвейера, правила владения или барьеры рецензии. В оборонной, регулируемой среде и среде, критичной для безопасности, некоторые модули должны полностью исключать помощь ИИ. Ответ должен масштабировать усилия проверки с риском кода, а не с тем, как уверенно выглядит вывод.

2. Каковы наши реальные тренды неудачных изменений и ускользнувших дефектов с момента принятия помощников и измеряем ли мы их или гадаем? Заявления поставщиков о производительности и подсчёты доли принятия метрики тщеславия, вводящие в заблуждение, потому что время, сэкономленное на написании кода, может быть потеряно снова на рецензии и отладке. Чтобы руководство вкладывалось на основе свидетельств, а не шума, нужны сигналы поставки и качества во времени: время цикла, доля неудачных изменений, доля ускользнувших дефектов и сообщаемая разработчиками эффективность. Принесите любые реальные числа, какие у вас есть, и будьте честны, где их нет. Риск, за которым стоит следить: команды под давлением принимать небезопасные предложения лишь ради метрики. Ответ должен заменить подсчёты предложений мерами результата и задать ожидания, что выигрыши реальны, но неравномерны, велики для одних задач и отрицательны для других.

3. Если порождённый код эхом повторяет обучающие данные с ограничительной лицензией или втягивает рискованную зависимость, кто это ловит и когда? Порождённый код может напоминать лицензированный материал или рекомендовать заброшенные или вредоносные пакеты, и эта экспозиция ложится в ваш продукт, заметил ли кто-либо. Для корпораций и государства происхождение лицензий и риск цепочки поставки несут юридический вес, который не переживает пожимание плечами «это написал ИИ». Принесите ваше текущее сканирование секретов, проверки лицензий и отслеживание происхождения зависимостей и определите, где в конвейере работает каждая. Обсудите, что направляет сомнительный код на юридическую рецензию и кто владеет этим решением. Если секреты могут быть вставлены во внешние инструменты или непроверенные пакеты могут слиться без возражений, закройте эти пробелы, прежде чем масштабировать использование помощников по команде.

4. Как мы держим инженеров, особенно младших, изучающими основы, а не отдающими своё понимание помощнику на аутсорс? Атрофия навыков медленный риск, никогда не проявляющийся в скорости этого квартала, а затем проявляющийся годы спустя как команда, не способная отлаживать, проектировать или рецензировать без промпта. Для большой организации конкурирующее тяготение реально: помощники позволяют младшим инженерам поставлять быстрее сегодня, а давление достижения целей поставки борется с более медленной работой построения глубокой экспертизы. Принесите свидетельства того, как ваши люди на самом деле растут: какая доля младших может объяснить код, который они слили, сколько самостоятельного решения задач ваше знакомство всё ещё требует и ловят ли рецензии поверхностное понимание или лишь штампуют работающий вывод. Намеренно ротируйте людей через работу, строящую мастерство, и воспринимайте чрезмерное полагание как риск возможностей, а не личный недостаток. В государстве и долгоживущих критичных системах персоналу может понадобиться строить и проверять системы десятилетиями без инструментов поставщиков, поэтому путь обучения, гарантирующий прямые основы, требование непрерывности, а не любезность.

5. Какими помощниками нам на самом деле разрешено пользоваться с учётом того, где должны оставаться наш исходный код и данные, и как мы не даём секрету когда-либо достичь промпта? Ограничения обращения с данными решают инструмент раньше производительности: помощник, передающий ваш исходный код внешнему сервису, может быть дисквалифицирован сразу, каковы бы ни были его возможности. Для большой команды напряжение между удобством лучшего размещённого инструмента и требованием, чтобы проприетарный код, учётные данные и чувствительные данные никогда не покидали вашу границу. Принесите вашу карту классификации данных, варианты развёртывания, которые предлагает каждый кандидатный инструмент (размещённое, частное, локальное), и конкретные средства контроля, держащие секреты вне промптов: сканирование перед коммитом, фильтрацию промптов и обучение инженеров. Решите, какие инструменты разрешены для каких классов кода, и сделайте границу принуждаемой, а не рекомендательной. В регулируемой, оборонной и секретной среде локальное или изолированное развёртывание может быть единственным законным вариантом, а отправка исходного кода любому внешнему сервису должна быть запрещена и технически заблокирована, а не просто не рекомендуема.

6. Как мы превращаем разрозненные индивидуальные привычки в согласованные нормы по организации и кто владеет политикой по мере эволюции инструментов? Когда сотни разработчиков каждый импровизируют свой подход, малые привычки складываются в организационные результаты, а несогласованная проверка то, где проскальзывают дефекты и экспозиция. Конкурирующее соображение автономия: команды обижаются на тяжёлые центральные мандаты, но свобода для всех порождает неравное качество и никакой общей защиты. Принесите ваше текущее руководство (если есть), свидетельства того, насколько единообразно ему следуют, и предложение хороших умолчаний, встроенных в конвейер, чтобы безопасный путь был лёгким. Назовите владельца, поддерживающего политику актуальной по мере того, как помощники меняются каждые несколько месяцев, и норму раскрытия, чтобы рецензенты знали, когда помощь ИИ сформировала вклад. Для корпорации или государственного органа привяжите нормы к аудиту и подотчётности: документированный принуждаемый стандарт, который может проверить аудитор, лучше народной практики, различающейся по командам и исчезающей, когда уходит ключевой человек.

Взгляд по секторам

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

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

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

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

Примеры

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

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

TCO включает лицензирование инструментов, защищённое или локальное развёртывание, сканирование безопасности и лицензирования и нередко недооцениваемую цену рецензии и исправления вывода ИИ. Цена непринятия конкурентная: равные могут поставлять быстрее и привлекать талант, ожидающий современных инструментов. Цена небрежного принятия эрозия качества, инциденты безопасности и юридическая экспозиция. Обосновывайте перед руководством пилотом, измеряющим реальные результаты поставки и качества, в паре с конкретным планом норм, проверки и защиты данных.

Антипаттерны и ловушки

• Принятие на автопилоте. Коммит предложений без чтения или понимания.
• Метрики тщеславия. Оценка успеха долей принятия или числом порождённых строк.
• Секреты в промптах. Вставка учётных данных или чувствительных данных во внешние инструменты.
• Доверие тестам ИИ. Принятие порождённых тестов, фиксирующих текущее поведение, а не задуманное.
• Игнорирование происхождения. Упущение лицензионных рисков и рисков зависимостей в порождённом коде.
• Атрофия навыков. Позволение младшим отдавать понимание на аутсорс и никогда не изучать основы.
• Единообразное доверие. Применение той же низкой тщательности к критичному для безопасности коду, что и к шаблонному.

Модель зрелости

1. Начальный. Люди используют помощников стихийно и реактивно; нет политики, нет измерения; секреты и интеллектуальная собственность под угрозой, а порождённый код сливается с той тщательностью, какую случайно применит каждый.
2. Развитие. Существуют базовое руководство по использованию и правила данных, и работает некоторое сканирование безопасности, но практика непоследовательна по командам: глубина проверки зависит от человека, заявления о производительности анекдотичны, а высокорисковый код ненадёжно ограничивается.
3. Стандартизация. Нормы по уровню риска документированы и принуждаются по организации: обязательная человеческая рецензия, сканирование безопасности и лицензирования в конвейере, защищённое или локальное развёртывание там, где требуется, практики раскрытия и явный список исключённых модулей или модулей только с экспертной рецензией.
4. Управление. Практика измеряется и контролируется относительно базовых значений: время цикла, доля неудачных изменений и доля ускользнувших дефектов отслеживаются до и после принятия, цена рецензии и исправления выражена числом, инциденты утечки секретов и лицензионной экспозиции подсчитываются, а решения «пускать или нет» по инструментам и расширению опираются на эти свидетельства, а не заявления поставщиков.
5. Оркестрация. Помощь ИИ непрерывно улучшается и интегрирована по организации: проверка встроена в конвейер как путь по умолчанию, развитие навыков намеренно и отслеживается, политика адаптируется по мере смены инструментов каждые несколько месяцев, а организация регулярно переоценивает, заменяет и пересматривает помощников по мере сдвигов свидетельств и картины рисков.

Идеи для обсуждения

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

Главные выводы

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

Источники и дополнительное чтение

• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps.
• Andrew Ng, Machine Learning Yearning (on realistic expectations and measurement).
• OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
• Peter Naur, Programming as Theory Building (on understanding versus code artifacts).
• Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google.
• GitClear and related industry studies on AI-assisted code quality trends.