Geoffrey Huntley: Будущее кода без ручного ввода

Мы живем в эпоху, когда границы между человеком и машиной в сфере программирования стираются с каждым днем. Еще недавно искусственный интеллект воспринимался как вспомогательный инструмент, «умный автозаполнитель», который помогает писать функции или искать баги. Однако, как отмечает один из ведущих экспертов в области агентной инженерии, Geoffrey Huntley, мы стоим на пороге фундаментального сдвига. Его тезис прост, но радикален: «Никто больше не должен писать код вручную. Вот что осталось от нашей профессии».

Эта цитата, собранная Саймоном Уиллисоном (Simon Willison) 13 октября 2026 года, стала своего рода манифестом нового направления — agentic engineering. В то время как большинство разработчиков все еще борются с тем, чтобы заставить ИИ-ассистентов писать корректный код, Huntley предлагает взглянуть на проблему с другой стороны. Если агент не использует специализированные библиотеки диагностики, мы можем вмешаться, обновить документацию AGENTS.md, но всегда остается «дельта» — разрыв между тем, что хочет агент, и тем, что разрешено системой. Этот разрыв неизбежно приводит к дрейфу качества (drift).

Решение Huntley элегантное и жесткое одновременно. Он не пытается переубедить агента через долгие диалоги. Вместо этого он внедряет pre-commit хук (предкоммитный хук), который сканирует git-дифф на наличие прямых вызовов модулей наблюдаемости (observability modules), обходящих его собственную библиотеку диагностики. Результат? Коммит отклоняется, и агенту автоматически подается промпт с инструкцией использовать правильную библиотеку. С этого момента качество кода, генерируемого ИИ, стабильно достигает отметки «десять из десяти».

В этой статье мы подробно разберем, как работает эта парадигма, почему ручное написание кода становится анахронизмом, и какие технические и этические вызовы несет за собой переход к полностью агентной разработке. Мы рассмотрим контекст 2026 года, когда модели стали настолько мощными, что задача программиста сместилась с написания синтаксиса на архитектуру ограничений и контроль качества.

01От написания кода к архитектуре ограничений

Традиционная роль разработчика программного обеспечения десятилетиями сводилась к умению формулировать логику на языке, понятном машине. Мы учили синтаксис Python, Java или C++, оттачивали умение писать чистые функции и оптимизировать алгоритмы. Но в мире, где LLM (большие языковые модели) и специализированные AI-агенты способны генерировать сложные, работающие системы за секунды, этот навык теряет свою первичную ценность.

Geoffrey Huntley подчеркивает, что «никто не должен писать код вручную» не означает, что люди перестанут участвовать в процессе. Напротив, роль человека становится более высокой, более абстрактной. Мы переходим от роли «каменщика», укладывающего кирпичики кода, к роли «архитектора правил», который определяет, как эти кирпичики могут быть уложены. Если агент генерирует код, который нарушает архитектурные стандарты, использует небезопасные библиотеки или не соблюдает паттерны логирования, задача человека — не исправить этот код вручную, а изменить систему так, чтобы агент никогда не мог его сгенерировать.

Это требует глубокого понимания не только кода, но и механизмов взаимодействия агентов с окружением. В 2026 году это означает создание сложных систем валидации, которые работают на уровне CI/CD (continuous integration/continuous deployment) пайплайнов. Вместо того чтобы проверять код после его написания, мы внедряем проверки в момент его создания. Это превращает разработку в непрерывный процесс обучения агента, где каждое нарушение правила становится возможностью для улучшения системы, а не просто ошибкой, требующей исправления.

02Проблема «дрейфа» и роль AGENTS.md

Одной из самых больших проблем в использовании AI-агентов для разработки является так называемый «дрейф» (drift). Даже если вы предоставили агенту исчерпывающую документацию, например, файл AGENTS.md, который описывает лучшие практики, стандарты кодирования и архитектурные паттерны, агент со временем может начать отклоняться от этих правил. Это происходит потому, что контекстное окно модели ограничено, а новые задачи могут требовать нестандартных решений, которые агент интерпретирует как возможность обойти старые ограничения.

Huntley указывает, что простое обновление AGENTS.md не решает проблему полностью. Если агент не использует вашу библиотеку диагностики, вы можете попытаться интерпретировать его действия и обновить документацию, но всегда остается зазор между тем, что агент *думает*, что он делает, и тем, что он *фактически* делает. Этот зазор — источник багов, уязвимостей и нестабильности.

Решение заключается в переходе от декларативных инструкций (что должно быть сделано) к императивным проверкам (что запрещено делать). Файл AGENTS.md становится скорее справочником, чем законом. Закон же пишется на языке, который понимает машина: скриптах валидации, хуках Git и статических анализаторах. Это позволяет создать среду, где агент не может «забыть» правила, потому что техническая возможность их нарушения просто отсутствует.

03Техническая реализация: Pre-commit хуки как учителя

Ключевой момент в подходе Huntley — использование pre-commit хуков. Git позволяет запускать скрипты перед тем, как изменения будут зафиксированы в репозитории. Huntley использует эту возможность для внедрения «обучающего момента» прямо в процесс разработки.

Сценарий выглядит следующим образом:

1. AI-агент генерирует код и пытается сделать коммит.
2. Pre-commit хук сканирует изменения (git diff).
3. Хук ищет прямые вызовы к модулям наблюдаемости (observability modules), которые не проходят через централизованную библиотеку диагностики.
4. Если такие вызовы найдены, коммит отклоняется.
5. Агенту автоматически отправляется промпт с объяснением ошибки и инструкцией, как исправить код, используя правильную библиотеку.

Этот цикл «ошибка — исправление — обучение» происходит автоматически. Агент не просто получает ошибку; он получает контекст и решение. Со временем, благодаря повторению, агент учится избегать этих паттернов, и количество ошибок стремится к нулю. Huntley отмечает, что после внедрения этой системы качество кода становится стабильно высоким — «десять из десяти».

Это пример того, как программирование превращается в программирование ограничений. Вы не пишете код для агента; вы пишете код, который управляет поведением агента. Это требует навыков в области DevOps, безопасности и системного администрирования, которые становятся такими же важными, как и навыки написания бизнес-логики.

04Почему ручное написание кода становится анахронизмом

Аргумент Huntley о том, что «никто не должен писать код вручную», основан на нескольких ключевых факторах, ставших очевидными к 2026 году:

• Скорость и масштаб: ИИ-агенты могут генерировать код быстрее, чем любой человек, и в масштабах, недоступных для ручной работы. Писать код вручную для простых, повторяющихся задач экономически неэффективно.
• Консистентность: Человек устает, делает опечатки, забывает о лучших практиках. Агент, управляемый строгими правилами, соблюдает стандарты безупречно.
• Интеграция знаний: Современные агенты имеют доступ к огромным базам знаний, документации и примерам кода. Они могут интегрировать лучшие практики из тысяч проектов, чего невозможно достичь при ручном написании.
• Фокус на решении проблем: Когда агенты берут на себя рутинное написание кода, разработчики могут сосредоточиться на решении сложных архитектурных проблем, дизайне систем и взаимодействии с пользователями.

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

1. Формулировать четкие, недвусмысленные требования для агентов.
2. Проектировать системы валидации и контроля качества.
3. Анализировать поведение агентов и выявлять скрытые ошибки или уязвимости.
4. Интегрировать ИИ-компоненты в существующие инфраструктурные решения.

Это переход от «кодера» к «архитектору интеллектуальных систем».

05Роль диагностики и наблюдаемости (Observability)

В цитате Huntley упоминается «библиотека диагностики» и «модули наблюдаемости». Это ключевые компоненты современной агентной разработки. Наблюдаемость (observability) — это способность понять внутреннее состояние системы на основе внешних выходных данных. В контексте AI-агентов это означает, что каждый шаг, который делает агент, должен быть задокументирован, логирован и проанализирован.

Если агент вызывает внешнее API, это должно быть зафиксировано. Если он обращается к базе данных, это должно быть проверено. Если он генерирует код, это должно быть валидировано. Централизованная библиотека диагностики позволяет собрать все эти данные в одном месте, что дает разработчикам полную картину того, как работает система.

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

Поэтому pre-commit хук, который блокирует такие вызовы, является не просто бюрократическим препятствием, а критически важным элементом безопасности. Он гарантирует, что вся информация о работе агента доступна для анализа, отладки и аудита.

06Этические и социальные последствия

Переход к агентной разработке поднимает серьезные этические вопросы. Если код пишут машины, кто несет ответственность за ошибки? Как обеспечить справедливость алгоритмов, если они обучаются на данных, сгенерированных агентами? Как защитить приватность пользователей, если агенты имеют доступ к большим объемам данных?

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

Кроме того, возникает вопрос о будущем труда. Если агенты могут писать код лучше и быстрее людей, что делать разработчикам? Ответ, который предлагает Huntley, заключается в том, что разработчики должны эволюционировать. Они должны стать архитекторами, дизайнерами, аудиторам и стратегами. Это не потеря рабочих мест, а трансформация профессии.

07Что это значит на практике

Для разработчиков, работающих в 2026 году, подход Geoffrey Huntley означает необходимость пересмотра своих рабочих процессов. Вот несколько практических шагов, которые можно предпринять:

1. Внедрите pre-commit хуки. Начните с простых проверок: форматирование кода, наличие комментариев, использование определенных библиотек. Постепенно усложняйте их.
2. Централизуйте диагностику. Создайте единую библиотеку для логирования и мониторинга действий агентов. Запретите прямые вызовы к внешним модулям.
3. Обучайте агентов через ошибки. Используйте автоматические промпты для исправления ошибок. Это создаст петлю обратной связи, которая улучшит качество кода со временем.
4. Фокусируйтесь на архитектуре. Перестаньте писать рутинный код. Вместо этого проектируйте системы, которые управляют поведением агентов.
5. Изучайте DevOps и безопасность. Навыки работы с CI/CD, контейнеризацией и сетевой безопасностью станут критически важными для управления агентными системами.

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

Будущее программирования — это не замена людей машинами. Это сотрудничество, в котором люди определяют цели и ограничения, а машины выполняют рутинную работу. И как показывает Geoffrey Huntley, ключ к успеху в этом сотрудничестве — не в том, чтобы писать больше кода, а в том, чтобы писать умнее правила, которые управляют кодом.

Источник: Simon Willison ↗