Ведущий инженер-программист Joy Ebertz описала программирование с помощью ИИ как разделение между vibe coding для некритичных инструментов и строго заданной, тщательно проверяемой работой для ключевых систем. В подкасте Architect's Podcast на InfoQ в беседе с Michael Stiefel она сказала, что ревью кода выглядят неэффективными для результатов работы ИИ, а проверка стала тяжелым бременем. Такая оценка важна для бизнеса, потому что долгосрочная жизнеспособность систем теперь зависит меньше от написания кода и больше от формулировки требований.
Ограниченные задачи, неоднозначность и старый код
Ebertz работает в Imprint, где она занимается backend-разработкой и упорядочиванием конфигурации, после ролей уровня staff-plus в Harness, Split и Box. Ее опыт включает архитектуру микросервисов, системы авторизации, стандарты REST API и управление feature flagging. В подкасте она отнесла себя к роли архитектора, хотя формально такого титула не имела, связав этот путь с работой над domain-driven design при разделении монолита на микросервисы. Это обсуждение напрямую соединило прошлый опыт с практикой кодирования с ИИ.
Модели ИИ работают лучше в ограниченных рамках, сказала Ebertz, когда они видят небольшой фрагмент кода и получают узко поставленную задачу. Это наблюдение затрагивает спор о монолитах и микросервисах, поскольку четкие границы сервисов дают ИИ понятные рамки для работы. Большой монолит усложняет контроль контекста и оценку сгенерированных изменений. Для компаний выбор архитектуры теперь влияет на то, насколько безопасно ИИ может участвовать в разработке без побочных эффектов.
Неоднозначность требований стала главным узким местом. Архитекторы должны объяснять бизнес-цели инженерам и технические компромиссы менеджерам, а теперь еще и четко формулировать цели для агентов ИИ. Тесты нуждаются в однозначной формулировке, потому что расплывчатые критерии приемки оставляют результат работы ИИ непроверенным. Проблема особенно остра в старых системах, где никто не помнит исходных требований, и сложно решить, исправлять ли код постепенно или пересоздавать модуль заново.
Что кодирование с ИИ значит для команд разработки
Для компаний, использующих ИИ в разработке, два режима работы требуют разного управления. Внутренние инструменты допускают несовершенство и подходят для быстрого vibe coding, а клиентские или регулируемые системы требуют детальной спецификации и тщательной проверки, фактически парного программирования с ИИ. Небольшие фирмы могут быстро двигаться в первом режиме, а крупным организациям нужны контрольные проверки, дисциплина тестирования и ответственность за второй. Без такого разделения скорость прототипов превращается в производственный риск.
Ограничения связаны с проверкой, обучением и управлением изменениями. В отрасли пока не сложилась практика включения отчетов об ошибках или новых требований в код, созданный ИИ, а repeated regeneration может потерять исправления или вызвать расхождения. Начинающие инженеры получают более узкий путь обучения, потому что ИИ теперь выполняет рутинные задачи, на которых раньше строилось базовое понимание. Покупателям стоит спрашивать поставщиков, как тестируется сгенерированный код, как фиксируются допущения и как сохраняется понимание системы людьми.
Практическим маркером станет то, будут ли команды публиковать явные ограничения и допущения вместе с компонентами, созданными ИИ, и учитывать трудоемкость проверки в каждом выпуске. Если списки ограничений, однозначные тесты и записи проверок станут стандартными артефактами в ближайших продуктовых циклах, модель парного программирования закрепилась. Если их не будет, вывод ИИ накопится как непрозрачное наследие, которое будущие команды не смогут безопасно менять.
