Примечание переводчика: на тему «ИИ в кодинге» есть много «хайповых» текстов, но мало технических. Вместо красивых общих слов хотелось бы видеть разборы реальных ситуаций. Такой пост есть у Митчелла Хашимото (создателя терминала Ghostty), и мы решили перевести его для Хабра. Он опубликован ещё осенью, поэтому что-то могло устареть, но главные выводы остаются актуальными. Далее повествование идёт от лица Митчелла.
Недавно я выпустил нетривиальную функцию для Ghostty (ненавязчивые автоматические обновления для macOS), которую разработал в основном с помощью ИИ.
Меня часто просят поделиться нетривиальными примерами того, как я использую ИИ и инструменты агентного написания кода. И здесь я усмотрел отличную возможность разобрать мой процесс на примере отдельной фичи, реальной и уже выпущенной.
В этом посте я поделюсь всеми сессиями агентного кодинга на пути к её выпуску — ничего не вырезая и не редактируя. А также дам дополнительный контекст о моём процессе и рассуждениях. И да, заодно сообщу стоимость токенов для тех, кому это интересно.
Важно: здесь также много «человеческого» кодинга. Я почти всегда после работы ИИ прохожусь по коду и сам. Вместо того, чтобы повторять об этом в каждой части текста, говорю один раз здесь. Поэтому вы можете заметить некоторые расхождения между тем, что выдал ИИ, и тем, что в итоге попало в финальный код. Это сделано намеренно: я считаю, что хорошие «водители» ИИ являются экспертами в своих областях и используют ИИ как помощника, а не как замену.
Сама фича
Фича, о которой речь в этом посте — ненавязчивые уведомления об обновлении на macOS. Она показывает статус обновления в окне терминала, не прерывая работу пользователя созданием новых окон, захватом фокуса и тому подобным.
Предыстория у её появления такая. Во время громкой презентации OpenAI их демонстрация была бесцеремонно прервана окном предложения обновить Ghostty:
Я хотел удостовериться, что такое больше никогда не произойдёт. (Да, получился неплохой маркетинг. Но ненамеренно, и я такому не рад: пользователь не должен бояться, что инструмент использует его в своих целях. Хочется, чтобы к инструменту было доверие. Я хочу, чтобы спикеры, да и люди в целом, хотели пользоваться Ghostty, и забота о подобных вещах тут имеет значение.)
Поэтому я решил сделать уведомления об обновлениях ненавязчивыми. Приложение должно не открывать окно об обновлении, а показывать небольшой немодальный элемент графического интерфейса где-то, где он не будет прерывать работу пользователя.
Планирование до использования ИИ
Итак, я достал свои ИИ-инструменты. Нет, совершенно не так. Я начал с составления примерного плана «как я хочу, чтобы это работало». Ghostty использует Sparkle, очень популярный фреймворк для обновлений на macOS. Я покопался в их документации и обнаружил, что они поддерживают кастомный UI с помощью протоколов Objective-C. Для этого требуется заново реализовать кучу всего с нуля, но это возможно.
Итак, у меня было примерное представление о бэкенде. Насчет фронтенда я не был уверен (и это не моя сильная сторона). У меня была очень смутная идея, что стоит сделать маленькую кнопку, встроенную в строку заголовка, и я знаю, что macOS поддерживает кастомный UI в строке заголовка через titlebar accessory controllers, но помимо этого у меня не было особого понимания, как это должно выглядеть или ощущаться.
Но этого достаточно, чтобы начать. ИИ очень хорош в прототипировании, поэтому даже знание «чего я не знаю» полезно для старта. У меня было достаточно чёткое представление об общей идее.
Первая сессия: Прототипирование UI
Вот моя первая сессия агентного кодинга, которая начинается с такого промпта:
Я хочу реализовать кастомные, ненавязчивые уведомления об обновлении и установке, кастомизировав SPUUserDriver. Давай начнём с планирования кастомного UI, который нам понадобится. Мы будем работать ТОЛЬКО над UI. Сделай план создания SwiftUI views, которые могут отображать различные состояния, требуемые SPUUserDriver. Я думаю, что лучшее место для их отображения — в строке заголовка окна macOS сверху справа. Создай план, как разместить их там. Проконсультируйся с оракулом.
Часто меня спрашивают: «Что такое оракул?» Так в инструменте Amp называется специальный субагент с правами только на чтение файлов, который использует более медленную и дорогую модель, лучше справляющуюся с размышлениями. Я консультируюсь с оракулом при любом планировании.
Для начала я решил прототипировать UI.
Заметьте, что я не отправил агента сразу реализовать всю фичу. На то есть пара причин. Во-первых, я всё ещё даже сам не знаю, каким хочу видеть UI/UX, так что у меня нет оснований ожидать, что ИИ в числе прочего разберётся и с этим. Во-вторых, когда работа поделена на небольшие фрагменты, её проще ревьюить, понимать и итерировать дальше.
Также заметьте, что я прошу его только создать план, а не писать код. Поскольку у меня относительно расплывчатый запрос, мне важно просмотреть план, прежде чем он пойдёт делать прорву работы (и потратит на это прорву токенов).
Совет: Создать полный план вместе с агентом в интерактивном режиме — это очень важный первый шаг в любой нетривиальной задаче. Обычно я также сохраняю его (с помощью агента) в файл вроде spec.md, и тогда в следующих сессиях могу сказать: «Обратись к @spec.md и поработай над такой-то задачей».
Агент предложил достаточно приемлемый план, чтобы я разрешил ему приступить к реализации. Вы можете увидеть в остальной часть моих диалогов с агентом, как я итерировал дальше.
С UI он пошёл в правильном направлении. Там была куча мелких проблем (отступы, цвета и т. д.), но когда я увидел предложенный интерфейс, это дало мне искру вдохновения, позволившую понять, чего именно я хочу.
Совет: Я очень часто использую ИИ для вдохновения. В этом случае я оставил большую часть UI-кода от агента, но очень часто даю ему промпт, а потом выбрасываю все, что он сделал, и переделываю сам (вручную!). Для меня создавать «с нуля» очень сложно и долго, а ИИ отлично справляется с ролью моей музы.
Упираемся в стену
В переписке с агентом в моих промптах с 11 по 14 видно, что мы входим в «зону слопа». Код, созданный агентом, содержит критический баг, и он совершенно не может его исправить. И я тоже понятия не имею, как его исправить.
Зачастую я делаю попытки «наудачу» исправить баг с помощью агента. Если он сможет во всём разобраться, я смогу изучить его результат и научиться сам. Если и не сможет, мне это почти ничего не стоит. А если агент находит решение, но я его не понимаю, то откатываю изменения. Я не выпускаю код, который не понимаю. А пока агент безуспешно пытается, я также ищу проблему и пытаюсь разобраться в ней самостоятельно.
На этом моменте я понимаю, что мне нужно отступить, просмотреть то, что он сделал, и составить свои собственные планы. Пришло время заняться самообразованием и мыслить критически. ИИ здесь уже не является решением, а становится обузой.
Сессии «очистки кода»
В следующих сессиях я направлял агента, чтобы он сделал код чище.
Вторая сессия была посвящена перемещению некоторых методов в более подходящие места, выбранные мной:
Давай переместим функции pill background, foreground и badge из @macos/Sources/Features/Update/UpdateAccessoryView.swift в @macos/Sources/Features/Update/UpdateViewModel.swift и сделаем их более общими (background, foreground, badge)
Третья сессия добавила документацию к коду:
Обнови документацию для @UpdateBadge.swift
Совет: Добавление документации — очень важный шаг, потому что он помогает подтвердить ваше собственное понимание кода, а также обучает будущих агентов, которые могут читать и изменять этот код. По моему опыту, агенты работают гораздо лучше, когда у них есть как описания на естественном языке, так и сам код.
Четвёртая сессия перемещает view model в глобальную область приложения, так как изначально она оказывалась в области окна, а информация об обновлении относится ко всему приложению.
Перемести данные view model обновления в AppDelegate, так как информация об обновлении будет глобальной для приложения.
Во время такого процесса я обычно заглядываю сам и вношу незначительные ручные изменения.
Этап «очистки кода» очень важен. Чтобы эффективно его проводить, вы должны довольно хорошо понимать код, так что это заставляет меня не принимать слепо написанный ИИ код. А впоследствии лучше организованный и задокументированный код помогает будущим агентным сессиям быть успешнее.
Иногда я иронично называю это «антислоп-сессией».
Лицом к лицу с «тем самым багом»
Пора вернуться к багу, который я обнаружил в той начальной сессии. Я снова провёл несколько сессий, пытаясь заставить агента разобраться в этом. Я начинаю с расплывчатых формулировок и постепенно становлюсь всё конкретнее в том, как бы я подошел к решению.
Сначала расплывчатая сессия:
В случае стандартных нативных вкладок update accessory view не отображается. А надо, чтобы оставался видимым в строке заголовка окна.
Неудача. Затем я становлюсь более конкретным:
Нам нужно обновить ограничения таб-бара в @macos/Sources/Features/Terminal/Window Styles/TerminalTabsTitlebarTahoe.swift, чтобы выровнять его правый край с левым краем update accessory view, оставляя его видимым.
Неудача. Затем я пробую другой конкретный подход:
Что, если мы изменим @macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift, сделав таб-бар верхним accessory view, а не нижним, чтобы наши вкладки оказывались в строке заголовка?
Неудача. Последняя попытка:
«Right accessory view» и макет @macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift конфликтуют с сетапом update accessory view в @macos/Sources/Features/Terminal/Window Styles/TerminalWindow.swift. Можем ли мы ограничить таб-бар так, чтобы он всегда был слева от уведомления об обновлении?
Неудача.
Всё это время я также пытался решить это самостоятельно с помощью ручного исследования и человеческих усилий. Мои более конкретные промпты основаны на вещах, которые я узнал в ходе этого процесса. Но в целом это явно не работало.
Я не думаю, что смогу разобраться в этом самостоятельно, поэтому решаю сменить тактику. Я решил, что в случае с этими проблемными стилями строки заголовка можно помещать уведомления об обновлении в нижний правый угол окна поверх контента, а не в строку заголовка.
Мне в любом случае нужно это поддерживать, потому что у Ghostty есть настройка, позволяющая полностью скрыть строку заголовка. Так что, даже если я и смогу позже решить проблему со стилизацией строки заголовка, мне всё равно понадобится поддерживать этот альтернативный режим.
Моя следующая сессия действует по этому плану с очень конкретным промптом:
Дополни систему @macos/Sources/Features/Update, чтобы она также поддерживала оверлей-подход в @macos/Sources/Features/Terminal/TerminalView.swift. Уведомление об обновлении должно появляться в нижней части окна. Оно должно идти поверх текста (чтобы не менять размер терминала). В остальном все поведения при нажатии должны быть такими же, как у accessory view.
ИИ справился с этим очень хорошо. После этого я много полировал вручную (перемещал элементы, переименовывал вещи и т. д.), но основная работа была проделана как следует.
Вот видео фичи вскоре после этой сессии, демонстрирующее, как уведомление об обновлении появляется в нижнем правом углу окна при определённых стилях строки заголовка или когда она скрыта:
Начинаем работу над бэкендом
UI ощущался достаточно хорошим. Я отметил кучу мелких проблем, которые хотел решить позже, но мне хотелось перейти к работе над бэкендом — главным образом, чтобы увидеть, не обнаружу ли я какие-либо «неизвестные неизвестные», которые спутают мои планы.
Я вручную создал файл с основой незавершённых функций и различными комментариями TODO. Затем я начал сессию, чтобы эту работу доделали за меня:
Допиши @macos/Sources/Features/Update/UpdateDriver.swift. Читай документацию Sparkle по мере необходимости, чтобы понять функциональность. https://sparkle-project.org/documentation/api-reference/Protocols.html
Совет: ИИ очень хорошо справляется с «заполнением пробелов» или «дорисовыванием совы». Этот паттерн «создай каркас с описательными именами функций, параметрами, комментариями TODO и т. д.» я использую очень часто, и он работает очень хорошо.
Но в данном случае получилось очень плохо, и в итоге я выбросил весь этот код. Созданный агентом код работал, но это был явно неправильный подход. Он смешал много разных задач, и способ хранения состояния в driver был явно неверным.
Когда я изучил сделанное им, понял, что причина — view model была структурирована неоптимально. Так что я переключился в режим очистки кода, чтобы дать ИИ (и людям, если бы я решил писать сам) лучшую систему для работы.
Снова чистка, теперь масштабная
Опыт научил меня, что чистота UI-фронтенда и бизнес-логики бэкенда часто зависит от качества view model между ними. Поэтому я потратил некоторое время на её ручную реструктуризацию. В том числе это означало переход к tagged union вместо struct с кучей optionals. Я переименовал некоторые типы, переместил некоторые вещи.
Я знал по опыту, что эта небольшая ручная работа в середине поможет агентам быть успешными в будущих сессиях как для фронтенда, так и для бэкенда. Завершив её, я продолжил марафон сессий по очистке кода.
После реструктуризации я первым делом попросил агента снова «дорисовать сову», на этот раз изучив мои изменения и обновив зависимый код под новый стиль, удалив старый:
Обнови @macos/Sources/Features/Update/UpdateViewModel.swift, чтобы использовать исключительно новый
UpdateState. Переименуйstate2вstate(удали старый state).
Затем я попросил его удалить дополнительный мёртвый код:
Я думаю, мы можем избавиться от UpdateUIActions. Они больше не используются, так как в нашем UpdateState есть колбэки.
Затем я сам сломал сборку, подчищая некоторые вещи. Мне нужно было бежать на встречу, поэтому я решил дать агенту исправить это, пока я занят:
Запусти сборку и исправь ошибки
Совет: «Я тут кое-что сломал, пожалуйста, разберись» — ещё один мой частый сценарий использования агентов. Я бы сказал, что в целом это вписывается в тот же паттерн заполнения пробелов, что и раньше.
Позже я снова начал делать рефакторинг некоторых views:
Преврати каждый кейс в @macos/Sources/Features/Update/UpdatePopoverView.swift в отдельную fileprivate Swift view, которая принимает типизированное значение в качестве параметра, чтобы мы могли удалить проверки.
Измени
iconNameв @macos/Sources/Features/Update/UpdateViewModel.swift на optional, возвращай nil для пустого значения. Обнови использование.
Симуляция
В моей первой UI-сессии я заставил агента создать демо-код, чтобы увидеть UI в действии без реальных проверок обновлений. Но в процессах обновления есть ряд разных сценариев, и до этого момента я тестировал только «happy path».
В следующей сессии я извлёк код симуляции в отдельный файл и попросил агента создать больше сценариев:
Извлеки код симуляции обновления из @macos/Sources/App/macOS/AppDelegate.swift в отдельный файл в @macos/Sources/Features/Update. Он должен содержать несколько сценариев симуляции (happy path, не найдено, ошибки и т. д.), чтобы мы могли легко проверить разные.
Совет: Агенты отлично справляются с генерацией тестов и симуляций. Код симуляции, который он сгенерировал здесь, честно говоря, довольно паршивый, но он работает и не является частью релизного бинарника, так что качество для меня не имеет значения. Я даже не стал его подчищать, за исключением базовых вещей, которые вы можете увидеть в сессии.
Затем я запустил различные симуляции и увидел ряд возможных улучшений UX.
Последняя миля
К этому моменту у меня были работающие бэкенд и фронтенд, и оставалось всё это соединить.
В следующей сессии я сказал агенту сделать это:
Создай класс
UpdateController, такой же как https://github.com/sparkle-project/Sparkle/blob/2.x/Sparkle/SPUStandardUpdaterController.m, но для наших типов updater.
Это потребовало некоторых уточнений и ручной полировки, но результат был достигнут.
Затем я внёс несколько небольших улучшений:
Для нашего состояния доступного обновления с appcast, посмотри на https://sparkle-project.org/documentation/api-reference/Classes/SUAppcastItem.html и покажи другие релевантные метаданные, если они заданы. Например, длину контента для размера.
Что-нибудь ещё?
В последнем промпте агенту я всегда спрашиваю, не упустил ли что-нибудь. Я делаю это вне зависимости от того, писал ли я код вручную или нет.
Видишь ли ты еще какие-нибудь улучшения, которые можно внести в фичу @macos/Sources/Features/Update? Код не пиши. Проконсультируйся с оракулом. Подумай, для каких частей кода можно добавить больше юнит-тестов.
Это выявило несколько реальных проблем, поэтому я попросил его разобраться с ними. По-моему, легче сказать агенту: «Окей, просто сделай всё это», чем просить его делать конкретные вещи, так как я всегда могу легко подчистить это позже в выборочных коммитах.
Забавный момент в этой сессии: агент начал уходить в какие-то совсем безумные дебри, поэтому я вмешался, чтобы остановить его:
Стой, стой, стой. Отмени все, что касается main actor.
Я также заметил, что одну вещь он сделал довольно плохо, хотя был способ лучше:
В случае с сообщением об ошибке сейчас используется обрезание текста, разве в SwiftUI нет стандартного способа для этого? Нам стоит добавить дополнительный элемент интерфейса, который можно использовать для просмотра всего сообщения.
Стоимость и время
Работа заняла в общей сложности 16 отдельных сессий общей стоимостью 15,98 долларов США в токенах на Amp. (Конечно, поэтичнее тут было бы использовать OpenAI Codex. Уверен, он бы справился отлично! Этот пост — не реклама Amp, просто этим инструментом агентного кодинга сейчас пользуюсь чаще всего.) Я не буду рассуждать, дорого это или дёшево в целом, но скажу лично за себя: я потратил больше в кофейнях за те два календарных дня, что я провел над этой фичей.
Общее «чистое время», которое я потратил на неё, оцениваю примерно в 8 часов. Я провожу за компьютером всего около 4 часов в день, первый и последний коммиты разделяют 3 дня. Но я не тратил всё время только на это. Например, я выпустил обновление Ghostty, поучаствовал в стриме ThePrimeagen в течение часа и выступил с презентацией на ежегодном собрании Zoo — и всё это в те часы, которые у меня отведены для «работы за компьютером», в те же дни, когда я работал над этой фичей. (У меня дома маленький ребенок, поэтому мое «компьютерное время» очень четко спланировано и сильно ограничено 😁.) Так что, думаю, оценка в 8 часов щедрая.
Многие в интернете спорят, позволяет ли ИИ работать быстрее. В данном случае думаю, что я выпустил это быстрее, чем если бы делал всё сам, в частности потому, что мелкое стилистическое итерирование SwiftUI для меня лично очень утомительно и трудозатратно, а ИИ справляется с этим очень хорошо.
Думаю, спор «быстрее/медленнее» для меня лично ощущается упускающим то, что мне нравится больше всего: ИИ может работать для меня, пока я отхожу заняться другими делами. Вот фотография, которую я сделал во время одной из моих сессий по очистке кода, пока готовил завтрак для своей семьи:
На этот счет есть разные возражения, вроде «Я не хочу кодить, пока готовлю», «Больше присутствуй в жизни» и тому подобное. Если вы хотите жить так — это нормально. В моём случае, в этом конкретном примере, я просыпаюсь первым в своём доме и готовлю завтрак, пока все остальные ещё спят. Я не делаю это каждую свободную минуту.
Всё это к тому, что для меня лично это работает. При этом я совсем, совсем не пытаюсь вас уговорить. Я финансово не связан ни с одной ИИ-компанией. Но поскольку я добился больших успехов с ИИ-инструментами и люблю говорить об этом, люди постоянно просят меня поделиться примерами. Это я здесь и делаю.
Заключение
Я считаю, что фича получилась прекрасной, отлично работает, и после финального живого ревью я влил ее в основную ветку. («Финальное живое ревью» — это супер-супер-супер-важно. Вероятно, это не должно быть в скобках, но я не нашел лучшего места, чтобы подчеркнуть это. Пожалуйста, никогда не выпускайте написанный ИИ код без тщательной проверки вручную.) Для пользователей Ghostty, использующих tip release, она доступна уже сейчас. Для пользователей Ghostty на тегированных релизах эта функция будет доступна в Ghostty 1.3.
Я активный сторонник важности публичного обмена сессиями агентного кодинга (об этом можно написать отдельный пост), и одна из причин в том, что это невероятно мощный способ обучения других тому, как эффективно использовать эти инструменты. Надеюсь, этот пост помогает продемонстрировать это.
Автор: Kodik_AI
