Vibe coding на SwiftUI: мониторинг производительности MacBook Pro

Материал основан на разборе simonwillison.net. Ниже — главное и практические шаги, которые можно быстро применить в работе.

У меня новый ноутбук — MacBook Pro M5 с 128 ГБ памяти, и, судя по первым впечатлениям, он прекрасно справляется с запуском мощных локальных больших языковых моделей (LLM). Меня несколько раздражал Activity Monitor, и я решил создать альтернативные инструменты для мониторинга производительности MacBook Pro с помощью AI — результатом я действительно доволен

Это мой второй эксперимент с vibe coding macOS-приложений — первым было приложение для презентаций несколько недель назад.

Почему SwiftUI идеален для vibe coding macOS-приложений

Оказывается, Claude Opus 4.6 и GPT-5.4 оба хорошо работают со SwiftUI, и полноценное SwiftUI-приложение можно уместить в одном текстовом файле, что позволяет создавать нечто новое, не открывая Xcode.

Я собрал два приложения: Bandwidther отражает, какие приложения используют сетевую пропускную способность, а Gpuer показывает состояние GPU. По совету Claude оба приложения представлены в виде иконок в строке меню, при нажатии на которые открывается панель с подробной информацией.

Bandwidther: мониторинг сетевого трафика по приложениям

Это приложение я собрал первым, потому что хотел посмотреть, что делает Dropbox. Вот как оно выглядит:

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

Покажи мне, какая сетевая пропускная способность используется на этой машине для подключения к интернету, в отличие от локальной сети LAN

(Изначально мне было интересно, передаёт ли Dropbox файлы через локальную сеть со старого компьютера или скачивает их из интернета.)

mkdir /tmp/bandwidther и напиши нативное SwiftUI-приложение там, которое показывает мне эти данные в режиме реального времени на постоянной основе

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

git init и git commit то, что есть на данный момент

Поскольку я собирался начать добавлять новые функции.

Теперь предложи функции, которые мы могли бы добавить в это приложение, цель — предоставить как можно больше деталей об использовании сети, в том числе разными приложениями

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

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

добавь Per-Process Bandwidth, перезапусти приложение после этого

теперь добавь функцию обратного DNS, но убедись, что оригинальные IP-адреса по-прежнему видны, хотя и более мелким шрифтом

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

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

Исходный код и инструкции по сборке доступны в simonw/bandwidther.

Gpuer: мониторинг GPU и памяти

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

Вот переписка. Этот раз потребовал ещё меньше запросов, потому что я мог использовать Bandwidther в процессе разработки как пример:

Я хочу знать, сколько RAM и GPU использует этот компьютер, что непросто, потому что данные о GPU и RAM, похоже, не отображаются в Activity Monitor

Это собрало информацию с помощью system_profiler и memory_pressure и дало мне ответ — что важнее, это показало мне, что такое вообще возможно, поэтому я сказал:

Посмотри на /tmp/bandwidther и затем создай похожее приложение в /tmp/gpuer, которое показывает приведённую выше информацию на постоянной основе, или, может быть, делает это лучше

После нескольких дополнительных изменений в приложении Bandwidther я попросил его наверстать:

Теперь посмотри на последние изменения в /tmp/bandwidther — это приложение теперь использует иконку в системном трее, повтори это

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

Код Gpuer можно найти в simonw/gpuer на GitHub.

Насколько точны данные мониторинга: честный разбор

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

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

Я добавил предупреждения в оба репозитория на GitHub именно по этой причине

Сегодня утром я заметил, что Gpuer показывал, что у меня осталось всего 5 ГБ памяти, хотя это не соответствовало действительности (по данным Activity Monitor). Я вставил скриншот в Claude Code, и он скорректировал данные; новые цифры выглядят правдоподобно, но у меня всё еще есть сомнения насчет их точности

Я поделился ими на GitHub только потому, что считаю их интересными как пример того, что Claude умеет делать с SwiftUI.

Что я вынес из этих двух проектов

Несмотря на мою неуверенность в самих приложениях, из этих проектов удалось извлечь кое-что конкретное и полезное:

• SwiftUI-приложение может сделать очень многое с помощью одного файла кода — вот GpuerApp.swift (880 строк) и BandwidtherApp.swift (1063 строки)
• Обернуть различные команды терминала в аккуратный интерфейс с помощью Swift легко достижимо
• У Claude на удивление хороший вкус в дизайне SwiftUI-приложений
• Превратить приложение в приложение строки меню — это всего несколько дополнительных строк кода
• Для создания такого рода приложений не нужно открывать Xcode

Эти два приложения заняли совсем мало времени на создание и убедили меня, что разработка macOS-приложений на SwiftUI — это реальная возможность, которую стоит рассмотреть для будущих проектов

Когда такой подход действительно экономит время

Vibe coding особенно полезен там, где нужно быстро собрать прикладную утилиту вокруг системных команд и API macOS. Если задача звучит как «покажи мне метрику в строке меню», «собери простой инспектор состояния» или «заверни CLI в нативный интерфейс», SwiftUI вместе с сильной LLM даёт очень короткий цикл эксперимента. Вы быстро получаете первый рабочий интерфейс, а затем итеративно уточняете логику через конкретные запросы и живой пример соседнего проекта.

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

Мини-чеклист перед публикацией таких macOS-утилит

Перед тем как выкладывать подобное приложение на GitHub или отдавать коллегам, стоит пройти короткий технический чеклист: сверить цифры с системными инструментами macOS, проверить поведение на разных версиях системы, вынести предупреждение о неточности метрик в README и отдельно описать, какие системные команды используются под капотом. Тогда даже экспериментальный проект выглядит не как «магия AI», а как понятный инженерный прототип.

Частые вопросы о vibe coding и мониторинге на macOS

Нужно ли знать Swift, чтобы собирать SwiftUI-приложения в режиме vibe coding? Нет. Оба приложения — Bandwidther и Gpuer — были собраны без знания Swift: Claude генерировал весь код, а запросы формулировались на обычном языке.

Можно ли обойтись без Xcode при разработке SwiftUI-приложений? Да, для сборки и запуска простых SwiftUI-приложений достаточно командной строки. Xcode не обязателен, если приложение умещается в одном файле.

Насколько можно доверять данным, которые выдают такие инструменты? С осторожностью. Gpuer, например, однажды показал некорректные данные по памяти. Проверка через Activity Monitor и итеративная правка через Claude Code помогли скорректировать вычисления, но полной уверенности в точности нет.

Какой приём помогает получить более точный результат от AI-агента при разработке? Ссылаться на уже готовый проект в соседней директории. Запрос «посмотри на /tmp/bandwidther и сделай похожее» даёт модели конкретный образец, а не абстрактное описание.

Сколько запросов потребовалось, чтобы собрать оба приложения? Bandwidther потребовал около десяти запросов, Gpuer — ещё меньше, потому что Bandwidther уже служил готовым примером для переноса паттернов.