Почему 70 лет не получается обойтись без программиста: от FORTRAN до вайб-кодинга
Если коротко: программиста пытаются «отменить» почти 70 лет — языком для менеджеров, блок-схемами, конструкторами форм, no-code платформами, а теперь нейросетями. Каждая волна честно забирала часть работы, но ни одна не забрала главное: решить, что именно должна делать система, и заметить, когда она делает не то. Это не упрямство профессии, а свойство самой задачи — и его описали ещё в 1986 году.
Это канал «Всё про ИИ и роботов». Поводом для разбора стала одна из самых читаемых статей Хабра последней недели — «Черепашка, Дракон и вайбкодинг. 70 лет попыток обойтись без программиста» Дианы Фиониной. Мы пересказываем её историю своими словами, проверили ключевые факты по первоисточникам и добавили то, чего в ней не хватило: механизм, который объясняет, почему сценарий повторяется с точностью до реплик.
Обещанию «программист больше не нужен» — 72 года
Самая ранняя версия этого обещания стоит не в рекламе стартапа, а в техническом документе IBM. В ноябре 1954 года группа Джона Бэкуса выпустила предварительное описание языка FORTRAN, и там прямым текстом сказано: FORTRAN «должен практически устранить кодирование и отладку». Логика была понятной: из каждого доллара, потраченного на задачу для вычислительной машины, больше четверти уходило на зарплату людей, которые писали и отлаживали машинный код.
FORTRAN действительно избавил учёных от возни с машинными командами. Кодирование и отладка при этом никуда не делись — они переехали на уровень выше. Через пять лет, в 1959-м, комитет CODASYL с участием Грейс Хоппер взялся за COBOL — язык для бизнес-задач с синтаксисом, похожим на английскую прозу. Предполагалось, что программы на нём смогут читать руководители. Вышло наоборот: COBOL до сих пор крутится в банках и госсистемах, а весной 2020 года, когда американские штаты захлебнулись заявками на пособия по безработице, специалистов, способных поправить эти системы, пришлось искать чуть ли не через публичные призывы.
В 1981 году британская компания выпустила программу с говорящим названием The Last One — «последняя». Генератор задавал пользователю вопросы через меню и сам собирал программу на BASIC. Маркетинг обещал, что больше никакие программы писать не придётся. Писать пришлось.
Механизм: суть и случайность
Почему так происходит, лучше всех объяснил Фредерик Брукс — руководитель разработки операционной системы IBM OS/360. В 1986 году он написал эссе, которое в апреле 1987-го вышло в журнале IEEE Computer под названием «Серебряной пули нет: суть и случайности программной инженерии». Главная мысль укладывается в одно различение.
У любой программы есть случайная сложность — всё, что связано с тем, как мы записываем решение: машинные коды, синтаксис, ручная вёрстка окон, сборка проекта. И есть сущностная сложность — сама идея системы: какие в ней сущности, как они связаны, что должно происходить в тысяче пограничных ситуаций, которые никто не проговорил вслух. Первую можно убирать инструментами. Вторую — нельзя, потому что она не в инструменте, а в задаче.
Вот где «ага». Каждая волна «без программиста» была атакой на случайную сложность — и каждая побеждала. FORTRAN убрал машинные коды, Visual Basic убрал вёрстку форм, no-code убрал типовые модули, нейросеть убирает набор текста программы. Но сущностная сложность после каждой победы оставалась ровно там же, и она и есть основная работа программиста. Чем лучше инструменты, тем большая доля труда приходится именно на неё. Отсюда парадокс, который видят все: инструменты становятся мощнее, а разработчиков нужно не меньше.
Самое любопытное: в своём эссе Брукс заранее перебрал почти все будущие «пули». Среди кандидатов у него стоят языки высокого уровня, автоматическое программирование, графическое программирование, искусственный интеллект и экспертные системы. По каждому вывод один: поможет, но на порядок не ускорит, потому что бьёт по оболочке задачи, а не по её ядру. Там же он цитирует Дэвида Парнаса: «автоматическое программирование» всегда было эвфемизмом для программирования на языке более высокого уровня, чем доступный сейчас.
Миф: стоит машине понять человеческий язык — и всё
Самая живучая версия мечты звучит так: сложно не программировать, сложно говорить с машиной на её языке. Научим машину понимать обычную речь — и программист станет переводчиком, который больше не нужен. Сегодня, когда модели действительно понимают просьбы на русском, этот аргумент кажется победившим.
Ещё в конце 1970-х ему возразил Эдсгер Дейкстра в короткой заметке «О глупости „программирования на естественном языке“». Его мысль не о том, что машина не сможет понять. Она о том, что формальная запись — не бремя, а инструмент: её правила отсекают бессмыслицу, которую на родном языке почти невозможно заметить. «Естественность» обычной речи, пишет Дейкстра, во многом сводится к лёгкости, с которой на ней формулируются утверждения, чья бессмысленность неочевидна.
Переведём на сегодняшний язык. Фраза «сделай, чтобы клиенты получали скидку» звучит понятно — пока не спросишь: какие клиенты, с какого момента, суммируется ли с другой скидкой, что при возврате товара. Модель ответит на эти вопросы сама — молча, по своему усмотрению. Код появится, а решения в нём будут приняты наугад. Кто-то всё равно должен их увидеть и принять осознанно, и эта работа и есть программирование, как бы оно ни называлось.
Картинки, блоки и мышка: у наглядности есть потолок
Черепашка и ДРАКОН
Параллельно шла другая линия: убрать текст вообще. В 1963 году Айвен Сазерленд показал Sketchpad — программу, где чертили световым пером прямо на экране. В 1967-м Сеймур Пейперт с коллегами придумал Logo: ребёнок командовал черепашкой «вперёд 100, направо 90», и цикл на глазах превращался в квадрат. Педагогически это было блестяще, но настоящую игру на черепашке не напишешь. В СССР ту же роль играли учебные исполнители Ершова — Робот и Чертёжник, которые и сейчас живут в школьной среде КуМир.
Особняком стоит ДРАКОН — язык блок-схем, который с 1986 года разрабатывали для программы «Буран» под руководством Владимира Паронджанова. Его главной задачей было не генерировать код, а сделать алгоритм одинаково читаемым для программиста и инженера из соседнего КБ: схемы строятся по правилам, без пересечения линий. Как платформа разработки ДРАКОН не прижился, а как язык описания алгоритмов живёт до сих пор — его, например, предлагают для записи медицинских алгоритмов. Выжил он ровно потому, что не притворялся заменой программиста: он помогал человеку видеть и проверять логику.
Visual Basic и граница в 50 элементов
В 1991 году Microsoft выпустила Visual Basic, выросший из прототипа Алана Купера. Формы перетаскивались мышкой, реакция на клик писалась в пару строк, прототип можно было показать заказчику в тот же день. Это был настоящий успех и настоящая ловушка: собирать стало легко, понимать — трудно. Логика расползалась по сотням обработчиков, и предсказать, что сломается от следующей правки, не мог никто.
У этой ловушки есть цифра. Ян Мендлинг с коллегами проверили сотни моделей бизнес-процессов из эталонной модели SAP и обнаружили, что среди схем от 48 узлов и больше ошибки есть уже в большинстве. Позже это превратилось в одно из правил свода 7PMG: модель больше чем из 50 элементов нужно дробить. Схема снимает нагрузку, пока её можно охватить взглядом. Дальше она начинает прятать то, что важнее всего: состояния, гонки и обработку ошибок — та самая сущностная сложность, только нарисованная.
Вайб-кодинг: та же граница, сдвинутая ещё раз
В феврале 2025 года Андрей Карпатый назвал «вайб-кодингом» стиль, когда описываешь задачу словами, принимаешь код модели не читая и правишь по ошибкам. По Бруксу это очередная и очень мощная атака на случайную сложность: теперь не нужно даже набирать текст программы.
Данные пока рисуют двоякую картину. В контролируемом эксперименте GitHub разработчики с Copilot написали HTTP-сервер на JavaScript на 55,8% быстрее контрольной группы. Но это изолированная задача с понятным условием — почти чистая случайная сложность. В больших живых проектах, где важны история кода, архитектура и неписаные договорённости, результаты гораздо скромнее, а иногда и отрицательные: подробно мы разбирали это в статье о том, почему ИИ-ассистент может замедлять опытных разработчиков.
Механизм тот же, что у Visual Basic, только в новой форме. Модель снимает нагрузку с рук и перекладывает её на внимание: код приходится читать, проверять и держать в голове логику, которую ты не строил. А настоящий исходник частично переехал в чат: замысел и договорённости живут в переписке, нигде не версионируются, и тот же запрос завтра даст другой код. Кто не понимает систему, не сможет и проверить, что модель сделала её правильно.
Где «без программиста» действительно работает
Было бы нечестно сказать, что все попытки провалились. Они прижились — просто там, где их никто не продавал как замену профессии, и где сущностной сложности мало или она хорошо очерчена.
Обучение. Scratch, прямой наследник Logo, учит миллионы детей циклам и условиям — и работает именно благодаря ограничениям: сломать язык невозможно.
Простые внутренние инструменты. Форма заявок, отчёт для отдела продаж, панель с цифрами — от Access до нынешних конструкторов такие вещи собираются за часы.
Связки сервисов. Zapier, Make, n8n и Power Automate стали стандартом: сложность там в порядке шагов, а не в состоянии системы.
Профессиональные визуальные среды. Дизайнер рисует интерфейс в Figma, геймдизайнер собирает логику уровня в Unreal Blueprints — это разделение труда, а не отмена программистов.
Правило выводится прямо из механизма: инструмент «без кода» хорош, пока задачу можно охватить взглядом. Как только появляются десятки состояний, деньги, параллельные пользователи и редкие сбои, сущностная сложность выходит на первый план — и снова нужен человек, который её держит.
Отсюда простой фильтр для любого нового «программиста больше не нужен» — будь то конструктор или ИИ-агент. Видно ли, что происходит внутри? Можно ли изменение проверить? Можно ли его откатить? Если на все три вопроса ответ «да», на инструменте можно строить серьёзные вещи — при условии, что за ним стоит человек, который разбирается в деталях. Если нет — демо будет красивым, а понедельник после запуска тяжёлым.
Коротко
— Обещание отменить программиста появилось вместе с первыми языками: в 1954 году FORTRAN должен был «практически устранить кодирование и отладку».
— Брукс разделил сложность на случайную (как записать) и сущностную (что строить). Инструменты побеждают первую, вторая остаётся у человека.
— Естественный язык не убирает сущностную сложность: он лишь позволяет не заметить решения, принятые за вас.
— Наглядность работает до предела: схемы от 50 элементов уже чаще содержат ошибки, чем нет.
— Нейросети — самая сильная атака на случайную сложность за всю историю, и именно поэтому главная работа теперь — формулировать задачу и проверять результат.
— Хороший инструмент не тот, что «умеет всё», а тот, где видно, что внутри, и любое изменение можно проверить и откатить.
Пока нет комментариев