Разговорное программирование: как мы пришли к идее 1960-х и почему это не вайбкодинг

В феврале 2025 года Андрей Карпатый написал пост, после которого у индустрии появилось новое любимое слово — vibe coding.

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

Термин быстро стал мемом. Потом рабочим словом. Потом словарным фактом. Collins назвал vibe coding словом 2025 года, определив его как разработку, где естественный язык превращается в компьютерный код с помощью ИИ. Merriam-Webster тоже описывает vibe coding как практику создания кода, сайтов и приложений через объяснение задачи ИИ-системе.

Звучит как свежая революция.

Но это не совсем так.

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

Теперь она может ответить работающим приложением.

Vibe coding — новое слово. Но сама мечта о программировании как разговоре с машиной появилась ещё в эпоху перфокарт.

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

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

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

Машина не отвечала. Машина молчала.

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

Но в начале 1960-х несколько людей почти одновременно решили: эта экономика мешает человеку думать.

В корпорации RAND стоял компьютер JOHNNIAC, названный в честь Джона фон Неймана. К началу 1960-х он уже считался устаревшим.

Математик Джон Клиффорд Шоу решил использовать эту устаревшую машину для эксперимента: что будет, если несколько человек смогут одновременно работать с одним компьютером, а компьютер будет отвечать каждому сразу?

Так появилась система JOSS — JOHNNIAC Open Shop System.

Восемь терминалов. Один компьютер. Несколько пользователей. Ответ сразу после ввода.

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

Примерно в то же время в Дартмутском колледже Джон Кемени и Томас Курц запускали другую революцию — BASIC.

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

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

Но главное было не только в языке. BASIC работал в интерактивной системе Dartmouth Time-Sharing System. Студент садился за терминал, вводил строку, запускал программу и видел результат.

Не завтра. Не после обработки в машинном зале. Сразу.

Кемени позже формулировал свою мечту примерно так: каждый студент кампуса должен иметь доступ к компьютеру, а любой преподаватель должен иметь возможность использовать компьютер в аудитории.

Для 1964 года это звучало почти утопией. Через десять лет на BASIC писали уже миллионы.

У этой истории есть важная советская линия.

В 1965 году в Институте кибернетики Академии наук УССР под руководством Виктора Глушкова была создана машина МИР-1 — «Машина инженерных расчётов».

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

У неё были экран, световое перо, клавиатура с буквами, цифрами и математическими символами. Для неё был создан язык АЛМИР-65 — диалоговый язык, ориентированный на инженерные расчёты.

Это важно, потому что идея была той же самой: компьютер должен не просто исполнять пакет команд, а отвечать человеку в процессе работы.

JOSS решал эту задачу через терминалы. BASIC — через доступный язык и разделение времени. Глушков пошёл ещё дальше: он проектировал машину под диалог с человеком.

В советской традиции слово «диалоговый» закрепилось особенно прочно. Позже, в 1980-х, появилась ДЕМОС — Диалоговая Единая Мобильная Операционная Система. А в «Словаре по кибернетике» 1989 года был зафиксирован термин:

«Диалоговый (интерактивный, разговорный) язык программирования» — язык, используемый в режиме диалога человек-машина. - Википедия

Три слова рядом: диалоговый, интерактивный, разговорный.

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

Разговорное программирование.

Разговорное программирование — не перевод модного термина. Это забытое русское название старой инженерной идеи.

В 1966 году в IBM запустили интерактивную версию языка APL — APL\360.

APL придумал Кеннет Айверсон. Для него программирование было не просто способом отдавать команды машине, а способом мышления. Он считал, что правильно устроенная нотация открывает мысли, которые обычный язык не позволяет точно выразить.

Когда APL подключили к терминалам, эта нотация стала интерактивной. Человек вводил выражение — машина отвечала.

А в 1967 году IBM вместе с Allen-Babcock запустила CPS — Conversational Programming System.

Слово стояло прямо в названии: Conversational.

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

Это был важный момент: разговор с машиной перестал быть лабораторным экспериментом и стал продуктом.

Программа отвечает — значит, conversational.

Дальше история стала странной.

С одной стороны, компьютеры стали персональными. Apple II, IBM PC, Macintosh. Машины пришли на столы.

С другой стороны, программирование снова стало в основном монологом. Человек писал код в редакторе. Компилятор молчал. Потом ругался. Потом человек читал ошибку, правил код, запускал снова.

Интерактивные среды никуда не исчезли. Были Lisp, Smalltalk, Mathematica, Python REPL, JavaScript-консоль. Но в мейнстриме серьёзная разработка всё равно выглядела примерно так:

написал → собрал → запустил → сломалось → прочитал ошибку → исправил → снова сломалось.

Машина стала ближе физически, но не стала разговорнее по сути.

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

Индустрия много лет жила в парадоксе.

Компьютер стал массовым. Интернет стал массовым. Смартфон стал массовым. А создание программ оставалось закрытым ремеслом.

В 2021 году GitHub и OpenAI выпустили технический preview GitHub Copilot.

Сначала он выглядел как очень умный автокомплит. Программист начинал писать функцию, Copilot предлагал продолжение. Можно было нажать Tab — и код появлялся.

Это ещё не был разговор. Скорее подсказка.

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

Потом появился ChatGPT.

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

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

Так программирование начало смещаться от набора кода к управлению созданием кода.

Следующим большим шагом стал Cursor.

Важность Cursor была не в том, что это «ещё один редактор кода с ИИ». Таких быстро стало много.

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

Человек мог не просто просить подсказать строку. Он мог сказать:

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

Это уже не автокомплит. Это диалог о системе.

Роль человека начала меняться. Он всё ещё должен думать. Даже больше, чем раньше. Но его работа всё меньше похожа на механическое написание строк и всё больше — на работу постановщика, редактора, архитектора и проверяющего.

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

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

И вот тут появляется Карпатый со своим vibe coding.

Он описал не инструмент, а новое ощущение работы. Когда ты не читаешь каждый diff. Не держишь в голове каждую строку. Не пишешь код вручную. Ты говоришь, смотришь, запускаешь, копируешь, снова говоришь.

Для профессиональных инженеров это звучало одновременно заманчиво и тревожно.

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

Поэтому вокруг vibe coding быстро возник спор.

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

И обе стороны правы.

Потому что «говорить с ИИ» и «создавать рабочий продукт с ИИ» — не одно и то же.

Первое доступно почти всем. Второе требует навыка.

Слабый vibe coding — это «ИИ, сделай мне красиво».Сильное разговорное программирование — это постановка задачи, проверка результата и управление системой.

В 2025 году Anthropic вывела Claude Code в веб. Разработчики получили возможность запускать и управлять несколькими coding agents прямо из браузера.

Это важный сдвиг.

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

Один агент чинит баг. Другой пишет тесты. Третий обновляет документацию. Четвёртый разбирается, почему всё снова сломалось, хотя «я ничего не трогал» — главная молитва разработчика с 1970-х годов.

Claude Code быстро стал одним из главных продуктов Anthropic. Это уже не игрушка для энтузиастов. Это огромный рынок.

И он растёт не потому, что люди внезапно полюбили писать промты. А потому, что агентная разработка меняет экономику создания софта.

Мне не очень нравится слово «вайбкодинг».

Оно звучит так, будто человек сидит в кресле, пьёт матчу, излучает вайб, а где-то в облаке само рождается приложение.

На практике всё намного прозаичнее. И интереснее.

Ты не «вайбишь». Ты формулируешь задачу. Разбиваешь её на части. Объясняешь контекст. Проверяешь результат. Споришь с агентом. Заставляешь его читать ошибки. Откатываешь плохие решения. Просишь упростить. Просишь не фантазировать. Просишь сначала составить план. Потом просишь сделать. Потом просишь объяснить, что именно он сделал.

А потом выясняется, что всё работает, кроме самого важного места.

И вот здесь начинается не магия, а работа.

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

Это не новое слово. Оно старое. Почти архивное. Но именно поэтому хорошее. Оно не обещает чудес. Оно говорит о сути: человек создаёт программу через последовательный диалог с машиной.

Есть соблазн свести всё к слову «промптинг».

Мол, научись правильно писать запросы — и ИИ сделает всё сам.

Это слабое понимание процесса.

Промпт — это одна реплика. Разговорное программирование — это цепочка решений.

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

Это не «напиши мне сайт».

Это скорее:

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

Вот это уже не промптинг.

Это управление созданием цифрового продукта.

Главная ошибка — думать, что разговорное программирование касается только разработчиков.

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

Раньше между идеей и продуктом стояла длинная цепочка:

идея → ТЗ → подрядчик → ожидание → бюджет → первая версия → непонимание → правки → ещё бюджет → ещё ожидание → «мы сделали не совсем то, что вы имели в виду».

Теперь появляется другой путь:

идея → разговор с ИИ → прототип → проверка → доработка → запуск.

Это не отменяет профессиональную разработку. Сложные системы всё равно требуют инженеров, безопасности, архитектуры, тестирования, сопровождения.

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

Лендинг. Бот. Внутренняя CRM. Мини-сервис для обработки заявок. Автоматизация отдела продаж. Парсер. Личный кабинет. Прототип продукта. Инструмент для команды.

Раньше всё это было «надо найти разработчика». Теперь всё чаще это становится «надо научиться правильно разговаривать с машиной».

В 1981 году Андрей Ершов выступил с докладом «Программирование — вторая грамотность».

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

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

Теперь ситуация перевернулась.

Машина начала учить язык человека.

И поэтому старая идея Ершова неожиданно возвращается в новом виде.

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

Не в стиле «сделай красиво», а точно, последовательно, с пониманием результата, с проверкой, с ответственностью, с нормальной взрослой дисциплиной.

Потому что ИИ не отменяет мышление. Он очень быстро наказывает за его отсутствие.

Если человек плохо понимает задачу, ИИ быстро создаст плохо понятный продукт.

Просто красиво.

Раньше человек учил язык машины. Теперь машина учит язык человека. Но думать за человека она всё ещё не обязана.

Я пришёл к разговорному программированию не из академического интереса.

Я не классический разработчик. Мой основной опыт — медиа, PR, продажи, городские сообщества, агентский бизнес, упаковка продуктов и воронки.

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

За несколько месяцев я сделал через работу с ИИ-агентами набор внутренних и коммерческих инструментов: сервисы для продаж, CRM-логику, ботов, автоматизации, инструменты для рекламных кампаний, обработки заявок и управления контентом.

Не потому что внезапно стал программистом.

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

Именно здесь для меня и возникло слово «разговорное программирование».

Не как красивая вывеска. А как точное описание процесса.

Я разговаривал с машиной — и из этого разговора появлялся продукт.

Многие думают, что главный барьер — технический.

Не знаешь Python, JavaScript, базы данных, серверы — значит, не сможешь.

На практике барьер другой.

Человеку сложнее всего научиться ясно думать о продукте.

Что именно должно работать? Для кого? В какой последовательности? Какие данные нужны? Что будет считаться успешным результатом? Какая минимальная версия нужна сначала? Что можно не делать? Где ИИ может ошибиться? Что нужно проверить руками? Где нужна безопасность? Где достаточно прототипа? Где уже начинается настоящая инженерия?

Разговорное программирование — это не путь «обмануть систему» и стать senior-разработчиком за две недели.

Нет.

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

Не вместо профессиональных инженеров. А до них. Рядом с ними. И иногда — без них, если задача достаточно простая.

Когда я начал показывать свои сервисы предпринимателям и знакомым, я постоянно слышал один и тот же вопрос:

«Подожди, ты сам это сделал?»

Ответ был сложный.

Нет, не сам в старом смысле. Я не сидел ночами и не писал каждую строку кода.

Но и не «ИИ сам сделал».

Я ставил задачу. Разбирал ошибки. Менял архитектуру. Проверял. Пересобирал. Доводил.

То есть делал то, что в новой реальности становится отдельной профессией — управлял созданием продукта через ИИ.

Так появилась идея курса по разговорному программированию.

Не курса «стань программистом за 14 дней». Таких обещаний и так много. Ими уже можно утеплять балкон.

Курс про другое: как человеку без классического технического образования научиться создавать собственные цифровые продукты через диалог с ИИ-агентами.

Лендинги. Боты. Внутренние сервисы. CRM. Автоматизации. Прототипы. Инструменты для бизнеса.

С нормальной логикой: от идеи и постановки задачи до запуска первой рабочей версии.

Раньше главный вопрос звучал так:

«Умеете ли вы писать код?»

Потом:

«Умеете ли вы управлять разработчиками?»

Теперь появляется третий вопрос:

«Умеете ли вы объяснить машине, что должно существовать?»

Это очень большой сдвиг.

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

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

Конечно, это не отменяет сложность.

ИИ ошибается. Код ломается. Безопасность важна. Архитектура важна. Проверка важна.

Но это уже не аргумент против разговорного программирования. Это аргумент за то, что ему нужно учиться серьёзно.

Шестьдесят лет назад инженеры мечтали о компьютере, который отвечает человеку сразу.

Они сделали JOSS, BASIC, CPS, МИР, диалоговые системы, интерактивные языки.

Но тогда разговор был ограничен. Человек спрашивал — машина считала. Человек вводил строку — машина проверяла. Человек писал программу — машина исполняла.

Сегодня разговор стал другим.

Человек говорит:

«Мне нужен сервис».

И машина может начать его собирать.

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

Поэтому мне кажется, что мы переживаем не просто очередную волну инструментов для программистов.

Мы переживаем возвращение старой идеи в новом масштабе.

Компьютер должен быть собеседником.

Просто впервые за шестьдесят лет этот собеседник научился не только отвечать.

Он научился делать.

И теперь главный навык человека — не знать все команды машины.

А уметь вести с ней такой разговор, после которого в мире появляется что-то работающее.

Разговорное программирование — не модный мем, а старая идея interactive/conversational computing.

Новое в 2025–2026 годах не в том, что машина отвечает. Она отвечает давно.

Новое в том, что теперь она может превращать разговор в работающий цифровой продукт.

Vibe coding — популярное, но немного легкомысленное имя для этого сдвига.

Мне ближе другое название: разговорное программирование.

Потому что оно точнее. И потому что это не про вайб.

Это про новый навык: ясно думать, точно формулировать и управлять созданием программ через диалог с ИИ.

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

Не вместо мышления.

А с новым типом мышления.

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

А те, кто умеет объяснить машине, что именно должно существовать.
П.С.: Больше всего мне интересно посмотреть, как будет выглядеть мир, в котором благодаря доступности разработки, у каждого будут свои приложения и сервисы. И в чем мы будем конкурировать.
Спасибо, что дочитали.