ИИ-агенты сделали нативные GUI выгоднее TUI, считает автор

Автор анонимного поста в блоге sockpuppet.org (обсуждение, на Hacker News) утверждает, что появление ИИ-агентов, способных быстро писать нативный код GUI, обесценивает главный довод в пользу терминальных интерфейсов (TUI), их якобы низкую стоимость разработки. Тезис поста: создавать CLI (интерфейс командной строки) почти всегда правильно, а создавать TUI, почти никогда не стоит, потому что при равных трудозатратах ИИ-агент способен собрать полноценный нативный графический интерфейс.

В подтверждение автор перечисляет семь собственных macOS-приложений на SwiftUI, которые он «надиктовал» ИИ, почти не написав кода сам: просмотрщик Markdown-файлов MDV.app; калькулятор-фронтенд для системы компьютерной алгебры SageMath (стандартный инструмент криптографов), с рендером формул в LaTeX и точечным вызовом функций Sage вместо ручного набора команд; плеер Apple Music «DJ Roomba» со встроенным LLM-агентом, который по текстовому запросу («еду в подвал делать раму для картины, собери плейлист без провисаний») составляет плейлист, опираясь на библиотеку и историю прослушиваний, и своими силами воспроизводит около 90% интерфейса штатного Music.app; «самопишущуюся вики» LLMwiki, которая под капотом дёргает claude -p и монтирует базу SQLite как файловую систему для агента; трекер калорий, где агент на базе GPT5 переводит короткое текстовое описание еды в оценку калорийности; монитор температуры в доме на дешёвых датчиках TP-Link; и пульт для Apple TV (а заодно для Roku и ресивера Denon) в виде приложения в строке меню.

Дальше, разбор происхождения TUI. Автор напоминает, что и CLI, и TUI родом из 1970-х, из ограничений телетайпов и «глупых» видеотерминалов, но считает, что эти ограничения свойственны именно TUI, а не CLI. По его версии, TUI существуют всего по двум причинам: из-за модемов и потому что юниксовые разработчики в своё время не хотели учить графическую библиотеку Motif, свой личный опыт работы с Motif в середине 1990-х автор называет причиной, по которой избегал разработки UI следующие 29 лет (для сравнения, на освоение библиотеки curses для TUI, по его оценке, хватает 5 минут). Здесь же он критикует эссе Нила Стивенсона 1999 года «In the Beginning Was the Command Line» («В начале была командная строка»): по мнению автора поста, эта работа отбросила область человеко-компьютерного взаимодействия примерно на 20 лет назад, и спустя 25 лет большая часть её выводов не выдержала проверки временем.

Дальше пост разбирает три стандартных довода в пользу TUI. Довод про плотность информации и скорость работы с клавиатуры автор признаёт верным, но настаивает: ничто не мешает сделать такой же плотный и «клавиатурный» графический интерфейс, просто раньше эта работа была дороже, а с приходом ИИ-агентов подешевела. Довод про работу по SSH на проде он отвергает: по его мнению, на проде нужен не пользовательский интерфейс, а интерфейс командной строки, которым может управлять графическое приложение на ноутбуке разработчика (в пример приводит режим TRAMP в Emacs, который прозрачно работает с удалёнными файлами через SSH). Довод про доступность (accessibility) для людей с нарушениями зрения автор тоже считает, скорее всего, ложным: со ссылкой на выступление незнакомого ему специалиста по доступности он описывает, как экранный диктор зачитывает построчные обновления TUI как последовательность «решётка, решётка, решётка, тире, тире», и противопоставляет этому SwiftUI, которая, по его словам, ведёт для интерфейса два дерева, визуальное и семантическое (accessibility-дерево), заточенные под доступность с самого начала.

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

Ключевые факты

  • Автор поста на sockpuppet.org (обсуждение на Hacker News) утверждает: раз ИИ-агенты дёшево пишут нативный GUI-код, делать TUI почти никогда не стоит, в отличие от CLI.
  • В доказательство он показывает семь macOS-приложений на SwiftUI, которые почти целиком написал ИИ: Markdown-вьюер MDV.app, фронтенд для SageMath, плеер Apple Music «DJ Roomba» (воспроизводит около 90% интерфейса Music.app), самопишущаяся вики на claude -p, трекер калорий на GPT5, монитор температуры и пульт для Apple TV/Roku/Denon.
  • По версии автора, TUI существуют лишь из-за модемов и нежелания юниксовых разработчиков осваивать библиотеку Motif; эссе Нила Стивенсона 1999 года про командную строку он считает отбросившим область человеко-компьютерного взаимодействия примерно на 20 лет назад.
  • Автор отвергает три стандартных аргумента за TUI: по плотности интерфейса ничто не мешает сделать такой же плотный GUI; для работы на проде по SSH достаточно CLI, которым управляет GUI на ноутбуке (пример, Emacs TRAMP); TUI, по его мнению, скорее хуже доступны людям с нарушениями зрения, чем нативные GUI вроде SwiftUI с отдельным accessibility-деревом.

Почему это важно

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

Кому это важно

В первую очередь, разработчикам, которые сегодня выбирают между TUI-фреймворками (Ratatui, Textual, Bubbletea) и нативными GUI-фреймворками вроде SwiftUI для внутренних утилит и личных инструментов; также тем, кто проектирует доступ к прод-серверам и заботится о доступности ПО для пользователей с нарушениями зрения, именно эти два случая пост разбирает отдельно.

Как это применить

Автор описывает практический приём: не писать GUI-код руками, а «надиктовывать» его ИИ-агенту, в том числе вызывая инструменты вроде claude -p из командной строки внутри собственных приложений. Для доступа к прод-серверам он предлагает не городить TUI, а держать CLI на сервере и графический клиент (пример, Emacs TRAMP через SSH) на своей машине.

Можно ли доверять

Это авторская колонка (мнение), а не новостная заметка о продукте или релизе, выводы построены на личном опыте автора и семи его pet-проектах, а не на исследовании или статистике. По доводу про доступность TUI автор сам оговаривается, что не пользуется вспомогательными технологиями и опирается на чужие рассказы, а не на собственную экспертизу.

Риски и подводные камни

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

«Создавать интерфейс командной строки, почти всегда хорошая идея. Создавать терминальный интерфейс, почти никогда.»

— автор поста на sockpuppet.org