Когда программы растут быстрее, чем наше понимание

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

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

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

Программа продвинулась вперёд. Ваше понимание осталось на прежнем месте.

1. Как сохранять понимание по мере изменения программы

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

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

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

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

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

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

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

2. Более совершенный ИИ не лишает нас права решать

Естественный ответ — делать модели надёжнее: улучшать код, обнаружение ошибок и тщательность проверок. Если модель станет достаточно хорошей, останется ли людям необходимость понимать и решать, чем должна стать их работа?

Наше право направлять собственную работу не зависит от того, продолжит ли ИИ ошибаться.

«ИИ может писать код, но людям всё равно придётся проектировать архитектуру». Такой ответ связывает нашу роль с умением, в котором у нас пока есть преимущество. А если модели станут и отличными архитекторами? Отступление к проверке или пониманию системы приводит к тому же вопросу: когда модель хорошо освоит и это, исчезнет ли причина нашего участия?

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

Пока хотя бы кто-то хочет творить согласно собственным требованиям и выбирать направление своей работы, этот вопрос остаётся.

Способность принять более удачное решение сама по себе не даёт права решать за другого.

Вы можете передать ИИ многие суждения, оставив конкретное решение за собой. Можно принять совет, передумать или признать прежний выбор ошибочным. Важно, чтобы выбор был осознанным, а не выяснилось задним числом, что программа уже изменилась.

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

Пока хотя бы один человек хочет оставаться автором своей работы, нам нужен ответ на вопрос, как сохранять силу его требований.

3. Что нужно, чтобы продолжать влиять на свою программу

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

Если после завершения работы агента вы можете только нажать «Принять», не зная, какие важные решения содержит результат, ваш контроль ограничен. То же верно, если вы можете отвергнуть результат, но не можете найти способ его изменить, или если явно указанное вчера требование незаметно перестаёт выполняться в сегодняшней реализации. Вы можете по-прежнему одобрять работу, теряя при этом возможность формировать её согласно своим требованиям.

Чтобы сохранять такую возможность, нужно уметь отвечать на конкретные вопросы:

• По-прежнему ли ясно, какой должна стать программа?
• Видите ли вы, как текущая реализация отвечает вашим требованиям?
• Можете ли вы отличить свои важные решения от выбора агента?
• Меняя направление, можете ли вы понять вероятные последствия и вмешаться?
• Сохранятся ли ваши явно принятые решения после следующего изменения реализации?

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

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

Тесты могут помочь установить, что программа ведёт себя определённым образом. Но вам всё равно нужно решить, приемлемо ли такое поведение и соблюдает ли оно решения, которые вы хотите сохранить.

Агент может реализовать синхронизацию, проверить правильность передачи данных и исправить ошибки. Но ответы на вопросы, должны ли данные покидать устройство, каких доказательств достаточно для принятия изменения и кто отвечает за последствия ошибки, выходят за рамки самой реализации. Ваше суждение должно определять, куда движется работа и когда ей остановиться, а не служить только подписью под готовым результатом.

Практический способ проверить эти утверждения в Noea описан в статье Читайте объяснения и доказательства. Руководство различает описания реализации, подтверждающие доказательства и решения, для которых всё ещё нужно ваше суждение.

4. Можно ли сохранить авторство, читая весь код?

Проверка кода предлагает прямой ответ. Агент пишет код; человек читает его и проверяет, что он делает.

Код может содержать поведение, о котором модель не упомянула в отчёте, структуры, влияющие на сопровождение, и проблемы, оценить которые можно только при внимательном изучении реализации.

Но если код создаётся всё быстрее, останется ли чтение каждого изменения устойчивым способом сохранять контроль?

Даже если не читать код построчно, день может быть заполнен работой: уточнять расплывчатые требования, замечать отклонения результата, решать, какие доказательства подтвердят правильность, и возвращать агента на нужный путь. Каждый шаг требует опыта и сосредоточенности. Можно почти не читать код и при этом работать напряжённо.

Чтение кода — ещё и возможность развивать понимание. Проверяя изменения коллеги, команда узнаёт, что система делает теперь, почему она устроена так и на что обращать внимание при будущих изменениях. Если мы читаем меньше кода, нам нужны другие способы развивать такое понимание.

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

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

5. Что, если заменить код длинными спецификациями?

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

Ясные требования уменьшают риск недопонимания. Документация сохраняет контекст. Хорошее объяснение облегчает знакомство с неизвестным кодом. Но естественный язык не избавляет от затрат на чтение.

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

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

То, что программа делает, то, что агент говорит о её работе, и то, что мы действительно понимаем и готовы отстаивать, — три разные вещи.

Даже полная запись и подробное объяснение могут не дать уверенности в том, как продолжать развивать программу. Нам нужно находить важное, понимать, как оно воплощено в текущей реализации, и видеть доступные варианты, когда программа изменится снова.

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

Сохраняя авторство за людьми

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

Эта свобода выходит за пределы программирования. В любой творческой работе человек должен иметь возможность выбирать, что поручить ИИ, а что решить самостоятельно.

Задача Finite Ground — помогать людям творить согласно собственным требованиям и продолжать формировать свою работу по мере того, как ИИ расширяет возможное.

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

Если наступит день, когда общий искусственный интеллект возьмёт на себя каждую часть человеческой жизни и все откажутся от самостоятельности, этот вопрос потеряет значение. У Finite Ground больше не будет причины существовать.

Пока хотя бы один человек не готов отказаться от самостоятельности, есть причина продолжать работу.

ИИ может воплотить в мире больше идей. Право решать, чем эти идеи станут, по-прежнему принадлежит людям, которые хотят его сохранить.

Начните с одной проверки

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

Если вы ещё не настроили Noea и агента, начните со статьи Установка и подготовка.