Почему виброкодирование — это не шаг вперёд по сравнению с «классическим» кодированием, и почему это важно
Делиться
«Мало кто знает Python. Все знают Human».
– Дженсен Хуанг, генеральный директор NVIDIA
Примечание: эта статья написана в соавторстве с Эйтаном Вагнером .
Когда ИИ преодолевает языковой барьер
Знаете, интернет полон заявлений вроде «кодирование умерло», «ИИ — новый инженер-программист», «разработка ПО устареет к 2030 году». За этими прогнозами стоит захватывающий аргумент: мы переживаем очередной виток эволюции программирования. Низкоуровневые языки, такие как Assembly, уступили место языкам более высокого уровня, таким как C и Python. С тех пор программисты на Python спокойно игнорировали уровень Assembly. Аналогичным образом, как гласит аргумент, естественный язык теперь может заменить классический язык программирования и стать инструментом для разработки программного обеспечения. Более того, как только переход на естественный язык завершится, мы будем создавать потрясающие программные продукты промышленного уровня, в блаженном неведении относительно базовых уровней «классического» кода.
На первый взгляд, этот аргумент имеет смысл, особенно учитывая динамику исторических прецедентов, которыми он вдохновлён. Языки программирования уже несколько десятилетий повышают уровень абстракции и выразительности. Вполне логично проследить эту тенденцию до её естественной кульминации, чтобы достичь вершины иерархии абстракций: человеческого языка. Кроме того, язык — это всего лишь вместилище идей, не так ли? Поэтому, пока идеи можно выразить, конкретный язык, который мы используем, кажется досадной деталью, не имеющей особого значения.
Помещение идей в центр, а языка как не более чем технического инструмента для их выражения, позволяет переформулировать предыдущий аргумент следующим образом: У людей всегда были удивительные и творческие идеи для новых продуктов, но до недавнего времени они могли передать их компьютеру, только изложив их на его собственном языке. Программисты, с этой точки зрения, были полиглотами, знавшими языки , которых не знал среднестатистический человек, и в этом была их сверхспособность . Только они знали, как заставить компьютеры выполнять свои приказы, подобно волшебникам, знающим секретные замысловатые фразы, которые могут подчинить себе дикие стихии. Сегодня, однако, компьютеры продвинулись вперед и могут понимать наш человеческий язык, и, таким образом, началась новая эра, в которой каждый может создавать программное обеспечение без необходимости изучать специальный язык. Более того, это сделает языки программирования излишними для (почти) всех, а не только для этих новичков. Python и Java последуют по пути ассемблера и машинного кода, поскольку у них будет мало или вообще не будет практически никаких практических преимуществ по сравнению с естественным языком.
Именно такие мысли высказал Дженсен Хуанг , генеральный директор NVIDIA, в London Tech еще в июне 2025 года:
«ИИ — это великий уравнитель. Позвольте объяснить, почему. За последние 50–60 лет компьютерные науки стали отдельной областью науки, доступной десяткам миллионов из миллиардов. Эта технология была сложной в использовании. Нам приходилось изучать языки программирования, разрабатывать её архитектуру, проектировать эти невероятно сложные компьютеры. Десятки миллионов людей смогли воспользоваться преимуществами этой области, но теперь внезапно появился новый язык программирования. Этот новый язык программирования называется «человек». Большинство людей не знают C++, очень немногие знают Python. Все знают «человека». Сегодня программирование компьютера заключается в том, чтобы попросить компьютер что-то сделать для вас, например, написать программу, сгенерировать изображения, написать стихотворение. Просто попросите вежливо».
Какими бы элегантными и убедительными они ни казались, теории и прогнозы следует анализировать с осторожностью. Соответствует ли это утверждение или прогноз практике? Пока что доказательства неоднозначны. Всё больше кода пишется с помощью ИИ-агентов, всё больше непрограммистов используют платформы Vibe Coding (например, Base44) для создания контента, а некоторые компании замораживают планы по найму инженеров, — но классическое программирование всё ещё живо и процветает. Ещё в марте 2025 года Дарио Амодеи, генеральный директор Anthropic, заявил:
«Мы недалеки от мира — я думаю, мы будем там через 3–6 месяцев — где ИИ будет писать 90% кода, а затем через 12 месяцев мы можем оказаться в мире, где ИИ будет писать по сути весь код».
Тем не менее, спустя семь месяцев (мы пишем это в октябре 2025 года), похоже, что программисты-люди по-прежнему остаются одними из самых высокооплачиваемых. Есть признаки того, что программирование ИИ может быть не таким полезным, как некоторые надеялись. В недавней широко обсуждаемой исследовательской работе METR было обнаружено, что ИИ замедляет работу опытных программистов, а не ускоряет их, и принимает менее 50% кода, генерируемого ИИ. Существуют даже сайты, посвященные сбору страшилок об ИИ, что указывает на ненадежность этих агентов. Когда дело доходит до полного погружения в программирование на «человеческом» языке, появляется новый тип должности, намекающий на назревающие проблемы: «Специалист по очистке кода Vibe». Это лишь некоторые признаки того, что путь к отказу от классического программирования — если мы действительно идем по этому пути — по крайней мере, не гладкий.
Как разобраться в этих, казалось бы, противоречивых закономерностях: очевидной мощи ИИ-агентов и их неоднозначных успехах в этой области? Революция всегда полна замешательства, поскольку сложно понять, что является преходящими тенденциями и экспериментами, обречёнными на провал, а что — временными неудачами и опытом обучения, которые подготавливают почву для кардинальных перемен, как только мы разберёмся с проблемами.
В настоящее время необходима прочная концептуальная основа для анализа текущего положения дел и будущего развития. Далее мы попытаемся представить такую основу и на её основе доказать, что программисты и языки программирования никуда не денутся , а естественный язык не станет следующим шагом в иерархии кодирования.
Критическая разница
Давайте перейдем сразу к сути вопроса: причина, по которой языки программирования никуда не исчезнут, заключается в том, что они (в отличие от естественных языков) являются формальными , и поэтому программы, написанные на них, представляют собой последовательность полностью определенных инструкций.
При выполнении команды x = 1+2, x всегда получит значение 3 после выполнения. То же самое относится к любой команде в любом программном обеспечении — нет никакой двусмысленности относительно предполагаемого поведения команды. Именно это свойство позволяет нам полностью доверять программному обеспечению, знать, что код, работающий сегодня, будет работать и завтра, что код на одной машине будет вести себя так же на другой и т. д.
Конечно, поведение компьютера полностью определена только на уровне, к которому обращаются команды . Команда x = 1+2 точно определяет, какое значение будет сохранёно в «x», но не указывает, где в физической памяти эта информация будет сохранена. Таким образом, такая команда полностью определена на уровне, представляющем интерес для программиста, как указано в его команде (суммирование 1 и 2 и сохранение результата в ячейке, на которую указывает переменная x), но недостаточно определена в отношении других деталей реализации, которые делегируются на более низкие уровни программирования и могут вести себя по-разному в различных системных условиях (например, доступных адресах памяти).
Всё это справедливо для языков программирования, которые являются формальными. Инструкция на естественном языке, с другой стороны, изначально недоопределена, даже на уровне интереса, к которому она относится . Например, если женщина просит мужа «сходить за молоком в супермаркет», муж, естественно, (в большинстве случаев) предположит, что глагол «получить» означает «купить», а не «украсть». Дело в том, что команда («получить молоко») не полностью определяет, как должно быть выполнено действие, оставляя мужу возможность заполнить пробелы при выполнении задачи.
Это хорошо известная и распространённая особенность языка и человеческого общения. Шутки должны восприниматься как нечто неявное, и, действительно, зачастую чрезмерное объяснение и полное раскрытие смысла сводят на нет юмористический эффект. Недостаточная конкретика человеческих высказываний иногда мастерски используется, когда разные уровни смысла предназначены для разных слушателей одновременно (что прекрасно известно любому родителю, который делится информацией с супругом/супругой, пока дети слушают). Это также приводит к частым недопониманиям в наших разговорах, даже когда мы общаемся с людьми, разделяющими наши культурные или профессиональные контексты. Конечно, в деловой и профессиональной среде недопонимание — обычное дело. Например, каждый менеджер по продукту знает, как сложно однозначно донести спецификации для компьютерного проекта, потому что то, что один считает очевидным, не всегда таковым считает другой, как это забавно демонстрирует этот классический видеоролик:
В мире программирования с использованием ИИ эта проблема также хорошо известна. Скажите ИИ, что вы хотите, чтобы модульные тесты вашего кода прошли; он с такой же вероятностью исправит ваш код, как и изменит тесты. В другом недавнем примере, когда модель OpenAI o1 играла в шахматы против шахматного движка (Stockfish), она решила взломать Stockfish и переписать свой код, чтобы победить. Подобные случаи часто называют примерами «интеллекта», но на более техническом уровне такое поведение является примерами недостаточно определённых инструкций на естественном языке. «Задача — „выиграть у мощного шахматного движка“, а не обязательно честно выиграть в шахматной партии», — написал o1 в своём «личном» блокноте. Таким образом, он принял одно из возможных «уточнений» недостаточно определённых правил. Было ли такое поведение задумано программистом, остаётся только гадать (как, впрочем, можно утверждать, что жульничество не приносит «победы», что ещё раз подчёркивает недостаточно определённый характер инструкции).1
У этой особенности естественного языка в контексте LLM есть и обратная сторона. Если у вас есть целевой фрагмент кода или конкретное изображение, а также мощный LLM в вашем распоряжении, существует ли подсказка, которая генерирует именно этот код или изображение? И ещё один вопрос: если такая подсказка существует, знаем ли мы, как её найти, проведя обратную разработку? Ответ на оба вопроса, вероятно, будет отрицательным при разумных допущениях2. Следовательно, естественный язык, по-видимому, не подходит для точной формулировки целей и задач, для решения которых были разработаны языки программирования.
В этом и заключается загвоздка: компьютеры смогли интегрироваться в человеческое общество благодаря своей предсказуемости — программисты могут с уверенностью определить, что компьютеру приказано делать (или, если в коде есть ошибка, программисты могут просмотреть, найти и исправить эти инструкции, чтобы добиться такой уверенности). Переходя от формальных языков к неформальным как способу программирования, мы навсегда теряем уверенность в том, что инструкции были определены достаточно точно, чтобы компьютер мог выполнить наше намерение. Мы также теряем контроль над тем, как машина в конечном итоге подстроится под наше намерение, поскольку нет гарантии, что существует команда (например, подсказка), которая сможет передать наше намерение таким образом, что LLM его выполнит.
Самое главное, это неотъемлемое свойство средства коммуникации — естественного языка в отличие от формального, который представляет собой входные данные для системы. В результате это ограничение невозможно устранить никаким усовершенствованием самой системы ИИ, будь то на этапе обучения или вывода. Конечно, предоставление большего количества контекста и данных может помочь сузить диапазон неопределенности, но не перенесет нас в мир такой же определённости и контроля, как и в случае формальных языков. Даже в будущих моделях GPT-17 или Claude-19.5 входные данные на естественном языке будут столь же недоопределенными, как и сегодня.
Кодирование как перевод
«Самое сложное в разработке программного обеспечения — это решить, что сказать, а не сказать это»
– Доктор Фредрик Брукс, «Серебряной пули нет»
Проведя четкое различие между двумя типами языков, мы теперь можем пролить новый свет на то, что происходит, когда мы переходим от одного к другому, и, что самое важное, что происходит, когда мы передаем этот шаг от людей (программистов) компьютерам (агентам ИИ).
Начнём с того, что рассмотрим программистов как переводчиков : особый класс переводчиков, которые переводят с одного типа языка (естественного, недостаточно определённого) на другой (формальный, полностью определённый). Чему нас учит эта аналогия, анализ сложностей перевода в целом, применительно к нашему конкретному случаю?
Перевод никогда не бывает таким простым, как кажется сторонним наблюдателям. Разные языки имеют разные структуры и правила, что затрудняет достижение идеального перевода. Например, переход с английского на французский означает переход от языка без родовой принадлежности к языку с родовой принадлежностью, и в некоторых случаях такой переход радикально меняет восприятие и восприятие абзаца. Или представьте себе перевод текста песни и связанные с этим сложности: сохранение ритма, смысла, игры слов, культурных отсылок и т. д. Всё это нетривиально при преодолении межъязыкового барьера.
Таким образом, сталкиваясь с этими трудностями, переводчик не просто преобразует один и тот же смысл из одного представления в другое. Вместо этого он делает выбор, выстраивая (сознательно или подсознательно) иерархию важности между различными аспектами смысла, которые он пытается сохранить при переходе на новый язык. Один переводчик может делать это для певца и поэтому стремится к точному соответствию мелодии оригинала, даже ценой перестройки целых куплетов. Другой может делать это, чтобы помочь неносителям языка понять исходный текст, и поэтому отдает приоритет точному дословному переводу, даже если результат даже отдаленно не рифмуется.
То, что верно для человеческих языков, вдвойне верно при переводе инструкций с английского на формальный язык, например, в компьютерную программу. Первая проблема, с которой сталкивается программист, — это та же проблема, что и для любого переводчика: переход на новый язык может пройти нелегко. Новый язык программирования может ограничивать программиста в тех пределах, в которых исходный язык не был ограничен3. Аналогично, фразы, которые можно просто сформулировать на естественном языке, могут потребовать полной перестройки в целевом языке программирования, и наоборот. В языках программирования, как и в любом другом языке, есть свои соглашения и стили4, и те, кто с ними не знаком, будут генерировать нечитаемый код, полный катастрофических ошибок.
Более того, переход от недостаточно определённого к полностью определённому языку требует от программиста/переводчика большей чёткости понимания поставленной задачи. Процесс детального описания (=полной спецификации) того, как следует обрабатывать различные случаи, — это не просто пересказ того, что уже известно; это процесс обнаружения и раскрытия всех скрытых предположений и последствий, которые не были учтены из-за недостаточной специфичности исходного языка.
Важно ясно понимать этот момент: зачастую в процессе кодирования обнаруживается не «то, что изначально подразумевалось в спецификации, разработанной человеком», а скорее «то, что осталось неуказанным в спецификации, разработанной человеком, поскольку никогда не было полностью продумано ».5 Чтобы писать код, необходимо указать вещи, которые ранее не были указаны, и, таким образом, это творческий процесс , а также процесс обнаружения фактических потребностей и направления, в котором должно развиваться кодирование.6
Именно этот факт позволяет нам, наконец, осознать значительные изменения, которые происходят всякий раз, когда мы передаем этот этап перевода от людей машинам:
- Во-первых, когда мы позволяем ИИ писать наш код, мы отстраняемся от процесса открытия и забываем о ключевых аспектах конкретного продукта, который мы создали. Решения о компромиссах между стоимостью, скоростью и стабильностью будут приниматься без нашего ведома или даже без осознания необходимости такого компромисса. Решения о том, какие части кода должны быть модульными, а какие — более жёсткими, также будут приниматься, опять же, без нашего ведома о достижении точки пересечения и повороте. Важно отметить, что во многом это происходит потому, что, отказываясь от своей роли кодировщиков, мы не осознаём тонкостей кода и, следовательно, можем отдать команду, которая, по нашему мнению, полностью определена, но на самом деле это совсем не так.
- Во-вторых, в отличие от программиста-человека, ИИ преодолевает разрыв между недостаточно определённой инструкцией и полностью определённым кодом с помощью (обученного) угадывания . Он генерирует код случайным образом , чтобы он соответствовал тому, что он видел во время обучения для аналогичных инструкций. Ключевое слово здесь — «случайно» — всё , что попадает под недостаточно определённую формулировку, может возникнуть в ходе этого процесса, если это подкреплено обучающими данными. Хотя такой код может быть хорошо написан в каком-то базовом техническом смысле, он, естественно, будет иметь побочные эффекты, некоторые из которых будут безвредны, но другие могут иметь проблемные непредвиденные последствия.
Эта статистически управляемая генерация кода принципиально отличается от процесса, управляемого открытием, которому подвергается программист-человек. Решения программиста-человека осознанны — он действует, в некотором смысле осознавая, как каждая строка кода повлияет на более широкую систему, в которой он работает. Это включает в себя другие части продукта; заинтересованных лиц, не связанных с кодированием (менеджера, коллег, инвесторов, клиентов); а также их собственные потребности и желания (баланс работы и личной жизни, репутация и т. д.). Агенты кодирования ИИ лишены всего этого контекста или набора целей и, следовательно, не могут выявлять препятствия такого рода, о которых программист-виртуоз задним числом хотел бы знать.
Суть в том, что компромисс всегда будет: чем больше неопределённостей мы оставляем в наших запросах ИИ, тем менее готовым к использованию будет наш код. Чем больше мы позволяем ИИ принимать за нас решения, о необходимости которых мы и не подозревали (поскольку не прошли упомянутый выше процесс обнаружения), тем чаще нам придётся пересматривать эти решения, прежде чем выпустить продукт и гарантировать его надёжность широкой публике — нашим пользователям и платящим клиентам.
Автономия, ответственность, кодирование вибрации
Мы упомянули здесь будущих пользователей нашего кода, и действительно, они являются часто игнорируемым компонентом системы и её динамики. Они невольно определяют, где мы можем использовать виброкодирование (= кодирование исключительно «человеческим» языком) в нашем конвейере разработки. Агенты ИИ, способные действовать автономно от нашего имени, чрезвычайно мощны, и правильное использование этой силы может привести к фантастическим результатам. Но хотя и люди, и машины могут быть автономными , только люди могут взять на себя ответственность за создаваемый ими код. Как мы покажем ниже, это определяет, где именно виброкодирование является жизнеспособным подходом к программированию.
Что такое «автономия» (или «агентность»)? Используя исследованное нами различие между двумя типами языков, мы считаем возможным демистифицировать этот термин и сделать его полезным в техническом смысле.7 Автономия, по нашему мнению, — это способность устройства или вычислительной сущности достигать цели в заданном пространстве, где инструкции для действий (= цель и «допустимые» действия) были недостаточно определены . Если учесть систему с техническими ограничениями (т. е. ее физические и вычислительные ограничения), и предположить, что система обучена следовать инструкциям пользователя, то чем больше пользователь оставляет недосказанным в своих инструкциях, тем большей автономностью обладает система. Чат-бот, которому поручено «творить добро», обладает большей автономностью, чем чат-бот, которому поручено «творить добро, создав детский дом в Нью-Йорке», и даже больше, чем чат-бот, которому поручено «творить добро, создав детский дом в Нью-Йорке, соблюдая все правовые нормы, будь то местные, государственные или федеральные».8
Однако автономность в этом смысле ничего не говорит о том, что определило действия ИИ. ИИ действительно автономен, поскольку он способен принять недостаточно конкретизированную команду и перейти к полностью конкретизированной, но способ, которым он совершает этот переход, полностью определяется его программой, моделью, подсказкой и начальным значением случайной последовательности. С этой точки зрения, именно пользователь принял решение выдать недостаточно конкретизированный набор инструкций и надеяться, что ИИ не заполнит пробелы неожиданной интерпретацией его инструкций.9
В свете всего вышесказанного, ответственность за любые действия ИИ целиком и полностью ложится на плечи пользователя. Он должен объяснить, какие гарантии были у него, что ИИ не устроит, скажем, кровопролитие по пути за чашкой кофе. Ответ может быть найден в соглашении об обслуживании с компанией, разработавшей ИИ, но, конечно, это просто перекладывает ответственность на другого человека, а не на сам ИИ. Цепочка ответственности, ведущая к человеку или группе людей, никогда не прерывается.
Степень ответственности и последствия неудач — ключевой фактор, определяющий применение вайб-кодинга. PoC, сторонние проекты и исследовательский код — всё это примеры, где он процветает, поскольку пользователю не важны многие аспекты создаваемого продукта. Он хочет получить что-то простое, работающее с базовой логикой, не задумываясь о многих деталях (например, бэкенд-разработчик хочет, чтобы пользовательский интерфейс вызывал его API, не заботясь о цветовых схемах, поддержке пакетов, поддержке веб- и мобильных устройств и т. д.). В этих случаях приемлемо всё разумное, а ответственность не важна, поскольку никто не будет сильно полагаться на создаваемую систему.
Более того, тот факт, что прототипы идей можно с такой лёгкостью генерировать с помощью виброкодирования, может значительно повысить производительность. Причина этого напрямую вытекает из нашего анализа, приведённого выше: полностью конкретизированная реализация утверждения на естественном языке может помочь разработчикам, менеджерам по продукту и клиентам понять, чего они действительно хотят – это часть процесса исследования и открытия. Ещё в 1986 году доктор Фредрик Брукс красноречиво сформулировал это в своей статье «Нет серебряной пули»:
«Самая сложная часть создания программной системы — это решить, что именно создавать… Я бы пошел дальше и заявил, что клиенту, даже работающему с инженером-программистом, на самом деле невозможно полностью, точно и правильно указать точные требования к современному программному продукту , не создав и не опробовав несколько версий продукта, который он определяет .
Поэтому одним из наиболее перспективных современных технологических направлений, которое направлено на устранение сути, а не случайностей проблемы программного обеспечения, является разработка подходов и инструментов для быстрого прототипирования систем в рамках итеративной спецификации требований».
Именно здесь программисты с радостью используют автономную природу ИИ-агента, и именно здесь мы восхищаемся всеми решениями, которые нам не пришлось принимать, чтобы что-то запустить. Но экстраполировать эти случаи на мир кода промышленного уровня, где на кону миллионы долларов, было бы ошибкой.
Выводы
В этой статье мы попытались обосновать утверждение, что классическое программирование не исчезнет в ближайшее время и не будет заменено «человеческим». Мы утверждали, что для сохранения многих свойств современных программных продуктов формальный язык должен стать языком общения с компьютерами. В заключение мы хотели бы поделиться некоторыми мыслями о будущем программирования.
Ранее мы сравнивали программистов с переводчиками, но, возможно, более удачная аналогия будет такой: «Код — это бюрократия мира процедурных идей, а программисты — законодатели, которые его пишут». Реализация социально-политической идеи в реальном мире требует разложения идеи на бюрократические процессы, определяющие ответственность, ресурсы и показатели реализации. Программирование, аналогичным образом, преобразует абстрактные технологические и бизнес-предложения в конкретные, измеримые процессы, которые могут быть реально реализованы в реальной механической системе с ограниченными ресурсами10. Без этого перехода компьютер не может действовать, так же как политика не может быть реализована в реальном мире просто благодаря её формулированию политиком — она должна быть закреплена в законе.
Когда человек учится программировать, он действительно осваивает новый язык (точно так же, как новый банковский кассир должен изучить внутреннюю терминологию банковской отрасли), но навыки, которые он развивает на работе и которые переносятся с одного языка программирования на другой, существенно отличаются от языковых навыков. К ним относятся (хотя и не ограничиваются ими):
- Как разбить большие проблемы на более мелкие, модульные и решаемые подзадачи;
- Как определить программные процессы, которые можно выполнять, отслеживать и отлаживать;
- Как инкапсулировать различные части системы, чтобы их входы и выходы были полностью определены и могли служить интерфейсами/контрактами по отношению к другим компонентам;
и так далее. Это более глубокие навыки, которые программисты привносят в свою работу.
Что изменилось в процессе разработки кода для промышленной эксплуатации с использованием агентов ИИ? На наш взгляд, главное изменение заключается в том, что теперь, чем больше вы знаете о программировании, тем свободнее вы можете давать ИИ команды, что делать. С накоплением опыта всё больше кода становится для вас «шаблонным», поскольку вы знаете, чего хотите, можете более чётко указать, что именно нужно, и легче выявлять риски реализации. Опытные программисты знают, как указать ИИ нужные структуры и пакеты, как предоставлять конкретные примеры и фрагменты кода, которые точно и формально отражают его намерения, и как определить адекватность полученного кода.
Итак, именно эти более глубокие навыки приносят дивиденды. Как их развить? Как это всегда и происходило: сидя и самостоятельно программируя. Разрабатывая проекты, терпя неудачи, отлаживая и снова создавая их. Начните без ИИ, используйте его, когда это необходимо, анализируйте свои ошибки и повторяйте. Только так вы сможете стать человеком, который умеет реалистично и эффективно разбивать проблемы на логические компоненты, которые действительно соответствуют существующим и осуществимым вещам, а также будут соответствовать потребностям клиентов.
В ближайшие месяцы и годы, безусловно, произойдут серьёзные изменения в том, на что программисты тратят своё время, а также в том, какие навыки им понадобятся для эффективной работы. Сложно предсказать, каким будет будущее программирования. Могут появиться новые языки программирования, ориентированные на искусственный интеллект, и программистам, возможно, придётся осваивать свою профессию с нуля. Тем не менее, мы уверены, что в ближайшие годы преуспеют те программисты, которые понимают, что их основной навык — это не написание идеального синтаксиса, а перевод неоднозначных человеческих потребностей в формальные, исполняемые спецификации. В эту новую эпоху этот навык становится ценнее, чем когда-либо, а не меньше. Бюрократия процедурных идей по-прежнему нуждается в вдумчивых законодателях.
Сноски
- Эта тема также повторяется в произведении Азимова «Я, робот», где понятие «причинения вреда человеку» (как во Втором правиле робототехники) не конкретизировано, что приводит к неожиданным действиям роботов. Например, они отказываются предоставлять информацию человеку, опасаясь, что она заденет его чувства.
Такое поведение удивительно лишь потому, что человеческий язык изначально позволяет нам формулировать вещи столь неопределённо. В рассказах Азимова человеческое общество смогло заложить неопределённость в поведение роботов, формулируя Три закона робототехники, не осознавая масштаба этой неопределённости. Такая неопределённость невозможна в языках программирования. Подробнее об этом далее. ↩︎ - Например, мы не рассматриваем подсказки, в которых по буквам и по пикселям описывается, как должна быть построена программа или изображение.
Для большей формальности рассмотрим возможные строки длиной N. Для 32 символов нашего словаря (буквы с пробелами и некоторыми знаками препинания) существует 32N = 25N возможных строк. Сравним это с небольшими изображениями размером 250×250 пикселей со значениями RGB от 0 до 255. Всего существует 2563 * 250 * 250 = 21500000 возможных изображений. Чтобы строки покрывали все возможные изображения, N должно быть около 300 тыс. символов. Таким образом, небольшое изображение соответствует строке длиной, сравнимой с романом. Этот расчёт, конечно, является верхней границей, и пространство изображений, которое люди могут захотеть создать, меньше. Приведённый здесь расчёт просто демонстрирует, насколько больше пространства, чем может охватить естественный язык. ↩︎ - Современные языки программирования постоянно развиваются именно для этой цели. Возникают новые потребности, и, следовательно, программистам необходимо предоставлять новые функции, чтобы они могли легко программировать и находить нужное «слово» (команду), соответствующее их замыслу. ↩︎
- Например, идея рекурсии широко распространена в программировании, но очень сложна для понимания неспециалистами. Даже циклы часто сбивают с толку непосвященных. Это приводит к очень разным спецификациям на уровне ввода естественного языка, в зависимости от того, знакомы ли вы с этим соглашением (=опытный программист) или нет (неспециалист). ↩︎
- По этой причине она не решается с помощью классического подхода «большего контекста», поскольку дополнительный контекст изначально недоступен пользователю — он его еще не обнаружил. ↩︎
- Простой пример: в системах Linux команда rm используется для удаления файла или папки. Человек, запрашивающий код «удалить папку X», не указывает, что следует делать с содержимым папки и при каких условиях следует предотвратить удаление, но каждая версия команды rm полностью описывает поведение в отношении этого содержимого. Только переписывая код, мы вынуждены разобраться, что человеческий язык позволил нам оставить неопределённым. ↩︎
- Похоже, что при использовании этого термина в контексте ИИ возникает много путаницы, во многом обусловленной нашей естественной склонностью к антропоморфизации. Люди говорят об автономности ИИ, утверждая что-то вроде: «Дрон сможет самостоятельно решать, что делать», приписывая право принятия решений дронам, роботам и другим окружающим нас ИИ-сущностям. Такие заявления — краткая формулировка, но они замалчивают тот факт, что дроны просто следуют своему коду буквально, без какой-либо инициативы или свободы воли. Более того, поскольку автономия человека подразумевает ответственность за свои действия, мы уже начинаем слышать, как некоторые возлагают «вину» на агентов ИИ, когда они причиняют вред. Сколько времени пройдёт, прежде чем некоторые заявят, что ИИ должны предстать перед судом своих (ИИ) коллег и быть наказаны? ↩︎
- То, что мы здесь описываем, можно назвать «слабой автономией», при которой пользователь задаёт системе ИИ нечётко определённую цель, а система ИИ, обученная действовать в соответствии с инструкциями, выбирает один из (фактически бесконечных) полностью определённых планов действий, используя некую статистическую модель. Таким образом, слабая автономия применима к существующим системам, цели которых диктуются или внедряются извне (в нашем случае, людьми). «Сильная автономия», то есть способность системы иметь собственные цели, возможно, в рамках приобретения сознания, выходит за рамки нашего обсуждения. ↩︎
- Это верно даже в самых простых сценариях. Если программист на Python написал x=3+5, а отладчик обнаружил, что после этой операции x==1, мы знаем, на кого свалить вину: что-то в базовой системе глючит, и программист не виноват. Теперь представьте параллельную вселенную, где эта простая операция заменена подсказкой «установить x равным сумме следующих двух чисел: три и пять» — поймём ли мы, в чём проблема? Можем ли мы так же легко освободить программиста от ответственности в этом сценарии? Нет, поскольку возможно — хотя и маловероятно — что ИИ воспринял эту команду не так, как предполагалось, например, он сделал x = 3+5 (mod 7). Кроме того, существуют случаи, когда x в итоге окажется x=»eight»… Тот факт, что это даже маловероятно, подчёркивает, как мы теряем контроль и уверенность с каждым переходом на естественный язык, и программист будет нести ответственность за создание продукта с более свободными компонентами. ↩︎
- Этот пункт также связан с тезисом Чёрча-Тьюринга, который выходит за рамки нашего обсуждения. ↩︎
- Ещё один намёк на это различие можно увидеть в распространённом использовании псевдокода при обсуждении нового алгоритма или потока. Псевдокод — это то, что получается, когда код «раздевается» до синтаксиса, специфичного для языка, и остаётся с идеей в её формализованном виде. ↩︎
Источник: towardsdatascience.com
