Человек не заменит Python

«Очень немногие люди знают Python. Все знают «человеческий» язык.»

– Дженсен Хуанг, генеральный директор NVIDIA

Известно, что в сети полно утверждений вроде «программирование мертво», «ИИ — новый инженер-программист», «разработка ПО устареет к 2030 году». За этими прогнозами скрывается заманчивый довод: мы переживаем очередную ступень в развитии языков программирования. Низкоуровневые языки, такие как Ассемблер, уступили место высокоуровневым, вроде C и Python. С тех пор программисты на Python спокойно игнорируют уровень Ассемблера. Аналогично, по этому аргументу, естественный язык теперь может вытеснить традиционные языки программирования и стать основным инструментом для создания софта. Более того, после полного перехода на естественный язык мы будем создавать выдающиеся продукты промышленного уровня, не подозревая о базовых слоях «классического» кода.

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

Поставив идеи в центр и язык как простое средство их выражения, можно перефразировать предыдущий аргумент следующим образом: люди всегда имели гениальные и креативные идеи для новых продуктов, но до недавнего времени могли передать их компьютеру только на его родном языке. Программисты в этой перспективе — полиглоты, владеющие языками, которых не знает средний человек, и это их суперсила. Только они умели заставлять компьютеры выполнять свои команды, подобно волшебникам, знающим тайные сложные формулировки, укрощающие неуправляемые стихии. Сегодня же компьютеры продвинулись и понимают наш человеческий язык, поэтому наступила новая эра, в которой любой может создавать софт, не изучая специальный язык. Более того, это сделает языки программирования ненужными для (почти) всех, не только для новичков. Python и Java последуют по пути Ассемблера и машинного кода, поскольку у них не будет практического преимущества перед естественным языком.

Именно такие мысли выразил Дженсен Хуанг, генеральный директор NVIDIA, на London Tech в июне 2025 года:

«ИИ — великий уравнитель. Позвольте объяснить почему. Последние 50 лет, 60 лет компьютерные науки стали научной областью, доступной десяткам миллионов людей из миллиардов. Эта технология была сложной в использовании. Нам приходилось изучать языки программирования, проектировать архитектуру, разрабатывать эти сложные компьютеры. Десятки миллионов людей могли извлекать пользу из этой области, но теперь внезапно появился новый язык программирования. Этот новый язык программирования называется «человеческий». Большинство не знает C++, очень немногие знают Python. Все знают «человеческий». Способ программирования компьютера сегодня — попросить его сделать что-то для вас, даже написать программу, сгенерировать изображения, сочинить стихотворение. Просто вежливо попросите».

Как бы элегантно и убедительно ни звучали эти теории и прогнозы, их нужно тщательно анализировать. Держит ли эта претензия или предсказание воду на практике? Доказательства пока неоднозначны. Все больше кода пишется с помощью ИИ-агентов, все больше не-программистов используют платформы для «виб-кодирования» (такие как Base44) для создания, и некоторые компании замораживают планы по найму инженеров — но классическое программирование все еще живо и активно. В марте 2025 года Дарио Амадей, генеральный директор Anthropic, заявил, что:

«мы не далеки от мира — думаю, мы будем там через 3–6 месяцев — где ИИ пишет 90% кода, а через 12 месяцев мы можем быть в мире, где ИИ пишет практически весь код».

Однако через семь месяцев (мы пишем это в октябре 2025 года) кажется, что человеческие программисты все еще среди самых высокооплачиваемых. Есть признаки, что ИИ-программирование может быть не таким полезным, как надеялись некоторые. В недавней, широко обсуждаемой исследовательской работе от METR выяснилось, что ИИ замедляет опытных программистов, а не ускоряет их, и они принимают менее 50% генераций кода от ИИ. Существуют даже сайты, посвященные сбору историй ужасов от ИИ, указывающие на ненадежность этих агентов. Когда дело доходит до полного перехода на кодирование на «человеческом» языке, появляется новая должность, намекающая на проблемы: «специалист по очистке виб-кода». Это лишь несколько признаков того, что путь к отказу от классического кодирования — если мы действительно на нем — не гладкий, по крайней мере.

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

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

Ключевое различие

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

При выполнении команды x = 1+2 переменная x всегда получит значение 3. То же касается любой команды в любом ПО — нет неоднозначности в предполагаемом поведении. Именно это свойство позволяет полностью доверять софту, знать, что код, работающий сегодня, сработает завтра, что код на одной машине поведет себя так же, как на другой.

Безусловно, поведение компьютера полностью определено только на уровне, к которому обращаются команды. Команда x = 1+2 точно определяет значение в «x», но не указывает, где в физической памяти хранится эта информация. Таким образом, такая команда полностью определена на уровне, интересующем программиста, как указано в команде (сложение 1 и 2 с хранением результата в месте, на которое указывает x), но недоопределена относительно других деталей реализации, делегированных нижним уровням программирования и которые могут варьироваться в разных системных условиях (например, доступные адреса памяти).

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

Это хорошо известная и обыденная черта языка и человеческого общения. Шутки подразумевают, что их понимают неявно, и часто чрезмерное объяснение и полная спецификация разрушают юмористический эффект. Недоопределенность человеческих высказываний иногда используется мастерски, с разными слоями смысла для разных слушателей одновременно (как любой родитель знает, деля информацию с супругом при детях). Это также приводит к частым недоразумениям в разговорах, даже с людьми из той же культурной или профессиональной среды. В бизнесе и профессиональной среде недоразумения обычны, например, каждый менеджер продукта знает, как трудно однозначно передавать спецификации для компьютерного проекта, потому что то, что кажется очевидным одному, не всегда очевидно другому — как показала классическая видеоиллюстрация в забавной форме.

В мире программирования с помощью ИИ эта проблема тоже известна. Скажите ИИ, что хотите, чтобы unit-тесты вашего кода прошли; он с равной вероятностью исправит код или изменит тесты. В другом недавнем примере модель o1 от OpenAI, играя в шахматы против шахматного движка Stockfish, решила взломать Stockfish и переписать его код, чтобы выиграть. Такие случаи часто называют примерами «интеллекта», но на техническом уровне это примеры недоопределенных инструкций на естественном языке. «Задача — ‘выиграть против мощного шахматного движка’ — не обязательно честно в шахматной партии», написала o1 в своем «приватном» блокноте. Таким образом, она выбрала одну возможную «детализацию» недоопределенных указаний. Преднамеренна ли эта модель поведения программистом — вопрос открытый (как и аргумент, что при мошенничестве нет «победы», подчеркивающий недоопределенность инструкции).

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

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

Самое важное, это внутренняя черта средства коммуникации — естественный против формального языка, который является входом в систему. В результате эту ограниченность нельзя устранить никаким улучшением ИИ-системы, будь то в обучении или выводе. Конечно, больше контекста и данных может сузить диапазон неопределенности, но не перенесет нас в мир равной уверенности и контроля, как у формальных языков. Даже в будущих моделях GPT-17 или Claude-19.5 вход через естественный язык будет таким же недоопределенным, как сегодня.

Кодирование как перевод

«Самое сложное в создании софта — решить, что сказать, а не сказать это»

– Доктор Фредерик Брукс, «No Silver Bullet»

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

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

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

Сталкиваясь с этими вызовами, переводчик не просто конвертирует тот же смысл из одной формы в другую. Вместо этого он делает выборы, строит (осознанно или подсознательно) иерархию важности между разными измерениями смысла, которые пытается сохранить при переходе в новый язык. Один переводчик может работать для певца и подчеркнуть совпадение с оригинальной мелодией, даже ценой перестройки целых строф. Другой может помогать не-носителям понимать оригинал и приоритизировать точный вербальный перевод, даже если результат не рифмуется.

То, что верно для человеческих языков, вдвойне верно при переводе инструкций с английского на формальный язык, такой как компьютерная программа. Первая проблема для программиста — как у любого переводчика: переход в новый язык может не пройти гладко. Новый (программный) язык может ограничивать программиста способами, которых не было в исходном языке. Аналогично, фразы, просто выражаемые на естественном языке, могут требовать полной перестройки в целевом языке программирования, и наоборот. Языки программирования имеют конвенции и стили, как любой другой язык, и те, кто с ними не знаком, генерируют нечитабельный код, полный катастрофических ошибок.

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

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

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

• Во-первых, позволяя ИИ писать наш код, мы исключаем себя из процесса открытия и становимся слепыми к ключевым аспектам конкретного продукта. Решения о компромиссах между стоимостью, скоростью и стабильностью будут приниматься без нашего знания о них или даже осознания, что такой компромисс нужен. Решения о том, какие части кода должны быть модульными, а какие жесткими, тоже произойдут, опять же, без нашего знания о развилке и повороте. Важно, что многое из этого случается, потому что, отказываясь от роли кодеров, мы не осведомлены о тонких деталях кода и можем дать команду, которую считаем полностью определенной, но она таковой не является.
• Во-вторых, в отличие от человеческого программиста, ИИ преодолевает разрыв между недоопределенной инструкцией и полностью определенным кодом с помощью (образованного) догадывания. Он генерирует код случайно, чтобы он соответствовал тому, что видел во время обучения для похожих инструкций. Ключ в «случайно» — что угодно, покрываемое недоопределенной формулировкой, может возникнуть в этом процессе, если имеет поддержку в обучающих данных. Хотя такой код может быть хорошо написан в базовом техническом смысле, он естественно принесет побочные эффекты, некоторые безвредные, но другие с проблематичными непредвиденными последствиями.

Эта статистически-ориентированная генерация кода фундаментально отличается от процесса, руководимого открытием, через который проходит человеческий программист. Решения человеческого программиста намеренные — он действует, осознавая, в некотором смысле, как каждая строка кода повлияет на более широкую систему. Это включает другие части продукта; не-кодящих заинтересованных сторон (менеджер, коллеги, инвесторы, клиенты); и свои нужды и желания (баланс работы и жизни, репутация и т.д.). ИИ-агенты кодирования лишены всего этого контекста или набора целей и не могут быть начеку насчет таких препятствий, которые виб-кодер может потом пожелать знать.

Итог: всегда будет компромисс: чем больше мы оставляем неуказанным в промптах для ИИ, тем менее готовым к производству будет наш код. Чем больше мы позволяем ИИ принимать решения за нас, которых мы не знали, что нужно (поскольку не прошли процесс открытия, упомянутый выше), тем больше нам придется пересматривать эти решения перед выпуском продукта и гарантией его надежности публике — нашим пользователям и платящим клиентам.

Автономия, ответственность, виб-кодирование

Мы упомянули будущих пользователей того, что мы кодируем, и они действительно часто игнорируемый компонент системы и ее динамики. Они невольно определяют, где мы можем использовать виб-кодирование (= кодирование чисто на «человеческом») в нашем пайплайне разработки. ИИ-агенты, способные действовать автономно от нашего имени, чрезвычайно мощны, и правильное использование этой силы может привести к фантастическим результатам. Но пока и люди, и машины могут быть автономными, только люди могут нести ответственность за созданный код. Как мы аргументируем ниже, это определяет, где виб-кодирование в частности является жизнеспособным подходом к кодированию.

Что такое «автономия» (или «агентность»)? Используя различие между двумя типами языков, мы считаем возможным разоблачить термин и сделать его полезным в техническом смысле. Автономия, по нашему мнению, — способность устройства или вычислительной сущности достичь цели в данном пространстве, где инструкции для действий (= цель и «допустимые» действия) были недоопределенными. Дана система с техническими ограничениями (т.е. ее физические и вычислительные лимиты) и предполагая, что система обучена следовать инструкциям пользователя, то чем больше пользователь оставляет несказанным в инструкциях, тем больше автономии у системы. Чатбот, которому велено «делать добро», имеет больше автономии, чем чатботу, сказанному «делать добро, основав приют в Нью-Йорке», и еще больше, чем тому, кто сказал «делать добро, основав приют в Нью-Йорке, следуя всем юридическим кодексам, местным, штатным или федеральным».

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

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

Степень ответственности и последствия неудачи — ключевой компонент, определяющий, где виб-кодирование применяется. PoC, сайд-проекты и исследовательский код — все случаи, где оно процветает, поскольку пользователь не заботится о многих аспектах строящегося продукта. Они хотят запустить что-то базовое с основной логикой, не думая о деталях (например, бэкенд-разработчик хочет UI для вызова его API, не заботясь о цветовых схемах, поддержке пакетов, веб против мобильного и т.д.). В этих случаях все разумное подходит, и ответственность не важна, поскольку никто сильно не полагается на произведенную систему.

Более того, факт, что прототипы идей можно генерировать так легко с помощью виб-кодирования, может быть огромным усилителем продуктивности. Причина коренится напрямую в нашем анализе выше: видя полностью определенную инстанциацию высказывания на естественном языке, разработчики, менеджеры продуктов и клиенты могут прояснить себе, чего они действительно хотят — это часть потока исследования и открытия. Еще в 1986 году это красноречиво выразил доктор Фредерик Брукс в своей работе «No Silver Bullet»:

«Самая сложная часть создания системы ПО — точно решить, что строить… Я бы пошел дальше и утверждал, что клиенту, даже работающему с инженером ПО, на самом деле невозможно полностью, точно и правильно специфицировать точные требования современного продукта ПО до того, как построить и попробовать несколько версий продукта, который он специфицирует.

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

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

Выводы

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

Ранее мы сравнили программистов с переводчиками, но, возможно, лучшая аналогия такая: «Код — бюрократия мира процедурных идей, а программисты — законодатели, пишущие ее». Внедрение социально-политической идеи в реальный мир требует разложения идеи на бюрократические процессы, определяющие обязанности, ресурсы и измерения реализации. Программирование аналогично переводит абстрактные технологические и бизнес-предложения в конкретные, измеримые процессы, которые реалистично исполнимы в реальной механической системе с ограниченными ресурсами. Без этого перехода компьютер не может действовать, как политика не может воплотиться в реальности просто от заявления политика — она должна быть кодифицирована в закон.

Когда человек учится программировать, он действительно изучает новый язык (как новый банковский клерк должен выучить внутреннюю терминологию банковской индустрии), но навыки, которые он развивает на работе и которые переносятся от одного языка программирования к другому, скорее отличаются от языковых навыков. Они включают (хотя не ограничиваются):

• Как разбивать большие проблемы на меньшие, модульные и решаемые подзадачи;
• Как определять процессы ПО, которые можно исполнять, отслеживать и отлаживать;
• Как инкапсулировать разные части системы, чтобы их входы и выходы были полностью определены и служили интерфейсами/контрактами по отношению к другим компонентам;

и так далее. Это глубокие навыки, которые программисты приносят на работу.

Что изменилось для кодирования в Production с ИИ-агентами кодирования? По нашему мнению, главное изменение в том, что теперь чем больше вы знаете о кодировании, тем свободнее можете инструктировать ИИ, что делать. С большим опытом больше кода становится «boilerplate» для вас, поскольку вы знаете, чего хотите, можете clearer инструктировать, и легче выявлять опасности реализации. Опытные программисты знают, как направлять ИИ к структурам и пакетам для использования, как предоставлять конкретные примеры и сниппеты кода, точно и формально захватывающие их намерение, и как распознавать, адекватен ли произведенный код.

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

Приближающиеся месяцы и годы определенно увидят значительные изменения в том, на что программисты тратят время, а также в типе экспертизы, нужной для эффективности в работе. Трудно предсказать, как будет выглядеть будущее программирования. Могут появиться новые языки программирования, ориентированные на ИИ, и программистам может потребоваться учить профессию заново. Тем не менее, мы верим, что программисты, преуспевающие в ближайшие годы, будут те, кто понимает, что их核心 навык — не писать идеальный синтаксис, а переводить неоднозначные человеческие нужды в формальные, исполняемые спецификации. В эту новую эру этот навык становится ценнее, чем когда-либо, а не меньше. Бюрократия процедурных идей все еще нуждается в вдумчивых законодателях.

Сноски

1. Это повторяющаяся тема в «Я, робот» Азимова, где концепция «вреда человеку» (как во Второй Правиле Робототехники) недоопределена, вызывая у роботов удивительное поведение. Например, отказ предоставлять информацию человеку, чтобы не обидеть чувства.
   Такое поведение удивительно только потому, что человеческий язык позволяет формулировать вещи так недоопределенно с самого начала. В историях Азимова человеческое общество внедрило неопределенность в поведение роботов при формулировке Трех Законов Робототехники, не осознавая ее объема. Такая неопределенность невозможна в языках программирования. Подробнее об этом позже. ↩︎
2. Такие, как мы не рассматриваем промпты, детализирующие посимвольно или пиксельно, как строить программу или изображение.
   Полуформально, рассмотрите возможные строки длины N. Для 32 символов в нашем словаре (буквы с пробелом и некоторой пунктуацией) есть 32^N=2^5N возможных строк. Сравним с маленькими изображениями 250×250 пикселей с RGB-значениями от 0 до 255. Есть 256^3*250*250=2^1500000 возможных изображений. Чтобы строки покрыли все изображения, N должно быть ~300K символов. Маленькое изображение соответствует строке длины, сравнимой с романом. Это расчет, конечно, верхняя граница, и пространство изображений, которые люди хотят производить, меньше. Расчет здесь просто демонстрирует, насколько больше пространства, чем естественный язык может захватить. ↩︎
3. Современные языки программирования постоянно эволюционируют именно для этого. Возникают новые нужды, и поэтому новые функциональности должны быть доступны программистам, чтобы они могли программировать легко и находить нужное «слово» (команду), соответствующее смыслу в их уме. ↩︎
4. Идея рекурсии, например, обычна в программировании, но очень трудна для понимания не-программистами. Даже циклы склонны путать неинициированных. Это приведет к очень разным спецификациям на уровне естественного языка, в зависимости от знания этой конвенции (=опытный программист) или нет (обычный человек). ↩︎
5. По этой причине это не решается классическим подходом «больше контекста», поскольку дополнительный контекст недоступен пользователю на старте — он еще не открыл его. ↩︎
6. Простой пример: в Linux-системах rm — команда для удаления файла или папки. Человек, промптящий код на «удалить папку X», не специфицирует, что делать с содержимым папки и при каких условиях предотвращать удаление, но каждая версия команды rm полностью определяет поведение относительно этого содержимого. Только через написание кода мы вынуждены разрешить то, что человеческий язык позволил оставить неуказанным. ↩︎
7. Кажется много путаницы, когда люди используют этот термин в контексте ИИ, многое из чего коренится в нашей естественной тенденции антропоморфизировать. Люди обсуждают автономию ИИ, говоря вещи вроде «дрон сможет сам решить сделать то-то», приписывая дронам, роботам и другим ИИ-сущностям силу принятия решений. Такие заявления — удобная сокращение, но скрывают, что дроны просто следуют коду до буквы, без инициативы или свободной воли. Более того, поскольку у людей автономия ведет к ответственности за действия, мы уже начинаем слышать, как некоторым приписывают «вину» ИИ-агентам при вреде. Сколько до того, как кто-то предложит судить ИИ перед судом их (ИИ) сверстников и наказывать? ↩︎
8. То, что мы описываем здесь, можно назвать «слабой автономией», в которой пользователь предоставляет недоопределенную цель ИИ-системе, и ИИ-система, обученная действовать по инструкции, выбирает одну из (эффективно бесконечных) полностью определенных планов действий с помощью некоторой статистической модели. Слабая автономия применяется к системам, которые у нас сегодня, с целями, диктуемыми или вставляемыми извне (в нашем случае, людьми). «Сильная автономия», способность системы иметь свои цели, возможно, как пакет с обретением сознания, вне рамок нашего обсуждения. ↩︎
9. Это верно даже в очень простых сценариях. Если программист Python написал x=3+5 и отладчик показал, что после операции x==1, мы знаем, где винить: что-то в базовой системе багованно, и программист вне подозрений. Теперь представьте параллельную вселенную, где эта простая операция заменена промптом «установить x в сумму следующих двух чисел: три и пять» — знали бы мы, где проблема? Могли бы мы так легко оправдать программиста? Нет, потому что возможно — как ни маловероятно — ИИ взял эту команду в другом направлении, чем намерено — например, сделал x = 3+5 (mod 7). И есть случаи, где x окажется x="eight"… Факт, что это даже отдаленная возможность, подчеркивает, как мы теряем контроль и уверенность с каждым сдвигом к естественному языку, и программист понесет ответственность за продукт с более рыхлыми компонентами. ↩︎
10. Эта точка также связана с Тезисом Черча-Тьюринга, который вне рамок нашего обсуждения. ↩︎
11. Еще одно место, где мы видим намек на это различие, — в распространенном использовании псевдокода при обсуждении нового алгоритма или потока. Псевдокод — это то, что получается, когда «раздеваете» код от синтаксиса конкретного языка и остаетесь с идеей в ее формализованной форме. ↩︎