В последнее время в Твиттере часто проскакивает мысль, что рынок ПО радикально изменится. Модели стали настолько мощными, что можно написать любое приложение именно под свои потребности, а не покупать готовое. Я решил проверить эту гипотезу и разработать своё Android-приложение, не написав ни строчки кода.

Я часто работаю с телефона - по пути на работу и с работы, в командировках, из кровати. Телефон у меня большой - Huawei Mate XT, он может раскладывать в квадратик и в целый планшет, так что работать с него довольно удобно. Но вот типичный рабочий день сейчас чаще всего выглядит так - 6 вкладок Claude Code, три в “ИИ-мозге” и ещё три в каких-нибудь конкретных репозиториях. Соответственно я очень хочу иметь возможность подключаться к своему рабочему компу по SSH. Исторически я всегда пользовался JuiceSSH, но о каких-то особенных удобствах там речи не идёт - неудобно работать с несколькими соединениями, постоянно рвётся сессия при любом лаге интернета, не так много кастомных настроек. Я посмотрел ещё пару вариантов типа Termius, ничего не зашло, и я приступил к разработке.

“Заваншотить” нужное мне приложение я даже пытаться не хотел - что бы сказочники в Твиттере ни рассказывали, это работает только для совсем простых штук. Всяких spec-driven development фреймворков существует уже великое множество, мне хотелось попробовать два - BMAD и CodeSpeak.

Этап CodeSpeak

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

По факту для моей идеи это оказалось не очень удобно. Мне не хотелось сильно погружаться в детали имплементации - я на Котлине ни строчки кода в жизни не написал, да и про SSH-протокол мало чего знаю. Плюс в отличие от BMAD тут не было никаких специальных скиллов для этапа рисёча и планирования. Поэтому от CodeSpeak в итоге остался только файл spec.cs.md, который содержал ТЗ с целями и контекстом проекта, ограничениями, способами верификации. На входе я просто описал, что должно делать приложение, какую основную функциональность я хочу:

  • Поддержка мультитабов - эта основная фича и дала название проекту, Multitab SSH
  • Возможность открыть несколько табов на одном экране - телефончик большой, надо пользоваться
  • Нормальная работа на всех вариантах “разложенности” телефона - особенно чтоб он мог спокойно переключаться между ними
  • Автоматический реконнект при потере соединения - очень бесит, когда попадаешь в какую-то зону без интернета или если самолёт взлетает, и все сессии летят в мусорку
  • Дополнительные плюшки - типа настраиваемого ряда дополнительных клавиш, например, чтоб можно было нормально в Claude Code нажимать Shift + Tab несколько раз

BMAD - этап планирования

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

Этап создания Product Requirements Document с функциональными и нефункциональными требованиями я (возможно зря) пропустил, так как у меня уже было ТЗ, которое по сути и являлось подобием PRD. Но BMAD заточен под работу именно с определённой структурой документов, поэтому лучше не отклоняться от заложенного процесса.

Первым делом я запустил technical research, он изучил ТЗ, поискал в интернете и нашёл кучу пробелов в моём ТЗ, в том числе связанных конкретно с раскладными телефонами. Затем я запустил UX research, обсудили мои пожелания по интерфейсу, итоговым артефактом стали HTML-витрины, уже выглядело приятно (но пока не работало хехе):

post-2026-06-11-14-21-38.png

Обычно дополнительные вопросы используют встроенный инструмент Claude Code AskUserQuestion, который предлагает несколько опций на выбор. Можно уточнить или просто согласиться на рекомендуемую опцию.

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

BMAD - этап разработки

Соблазн запустить агента в лупе, пока он не закончит проект, был, но есть три стоп-фактора:

  • Лимиты. Даже на подписке за 100 баксов BMAD-процесс выжирает кучу токенов. Чтоб имплементировать даже минимальную стори нужно её создать, разработать и потом запустить ревью с тремя разными субагентами (один ищет рандомные баги по диффу, второй проверяет на соответствие фичи спеке, третий пытается найти сломанные корнер-кейсы). В общем, BMAD - довольно дорогое удовольствие и вряд ли подходит для проектов-однодневок. Поэтому разработка в итоге затянулась на пару месяцев, хотя рабочую версию с урезанной функциональностью я получил достаточно быстро
  • Изменения требований - любой крупный проект практически невозможно целиком и полностью спланировать заранее. Выбранные фреймворки и библиотеки могут не подойти (например, терминальный движок termlib не удавалось подключить, пришлось его форкать), пользователь (я) может понять, что какая-то функциональность не нужна, а какая-то была упущена. Например, я в какой-то момент понял, что функциональность нескольких табов на одном экране нафиг не нужна, а вот возможность загружать и скачивать файлы с телефона на комп - супер-пушка (например, чтоб кидать скриншоты с телефона Клоду на анализ)
  • Баги, которые не ловятся тестами - в конце некоторых эпиков мы специально запланировали полное ручное тестирование. Да, это довольно утомительно, но часть тестов в интерфейсе он может прогонять сам через adb и делать скриншоты через screencap. Благодаря таким тестам (плюс реальному использованию приложения) вскрылась куча багов, в основном связанных с UI в tmux-сессиях

Что получилось

В итоге у меня есть на руках полностью рабочее приложение, которое умеет:

  • Подключаться по SSH, можно выбирать между обычным коннектом и tmux из коробки
  • Открывать несколько вкладок, создавать дубликаты и переименовывать вкладки
  • Скачивать файлы с компа на телефон и наоборот
  • Добавлять сниппеты для быстрого запуска команд из строки дополнительных клавиш
  • Сортировать, удалять, добавлять дополнительные клавиши
  • Создавать forwarding rules, чтоб на телефоне открывать локальные адреса с компа
  • Настраивать тему, размер шрифта, поведение кнопок и скролла

post-2026-06-11-16-09-33.png

Например, я могу открыть Claude Code в tmux с телефона, кинуть какую-то картинку с телефона на анализ, а потом сесть в самолёт, сесть в Москве, открыть и увидеть результаты.

В результате получился репозиторий примерно на 33 тысячи строчки кода, а в ходе разработки было сгенерено 80 маркдаун-файлов.

В общем, я очень доволен результатом и каждый день пользуюсь своим приложением. Можно ли сказать, что традиционный рынок ПО мёртв? Нет, абсолютно точно нет:

  • Даже в таком процессе всё ещё нужны технические навыки
  • Это всё сложно назвать “ваншотом” - процесс длительный, иногда нужно вмешательство пользователя
  • Это не бесплатно - думаю, я бы сжёг API-токенов на несколько тысяч долларов, если бы у меня не было подписки
  • Полученное приложение нужно поддерживать, в нём всё ещё есть всякие мелкие баги

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