2025 год был годом, насыщенным ИИ, по крайней мере, в моем случае. Я точно не помню, сколько раз я менял свои рабочие процессы, но я много экспериментировал. В целом, могу сказать, что никогда раньше я не работал так много и в то же время так мало. Вы поймете, что это значит чуть позже.
Следить за трендами в области ИИ — это полноценная работа, и я с удовольствием этим занимаюсь. Каждый день меня мотивирует улучшение рабочего процесса, изучение новых инструментов и повышение общей эффективности. Улучшения происходят так быстро, и, как сказал Андрей Карпати: «Люди, которые не следят за трендам хотя бы 30 дней, уже имеют устаревшее мировоззрение по этому вопросу». Я согласен с этим утверждением. Я не говорю, что вы должны это делать, но я люблю быть занятым и учиться, поэтому следить за всем этим — это лишь одна из вещей, которые приносят мне радость.
Эта статья представляет собой всесторонний обзор событий 2025 года. Порядок разделов не имеет большого значения, и я надеюсь, вы найдете здесь много полезной информации о моем рабочем процессе, агентном программировании в iOS, моих мнениях и многом другом, выходящем за рамки нашего iOS-мира.
Отказ от Xcode как текстового редактора
Как iOS-разработчики, мы привыкли к Xcode, но позвольте мне уточнить: в прошлом году я, вероятно, провел в Xcode всего 2% своего времени. Единственным спасением стало расширение GitHub Copilot. Оно позволяет получить опыт, похожий на работу с Cursor, с быстрым и релевантным автодополнением ИИ при нажатии клавиши Tab внутри Xcode.
Когда я говорю, что не использую Xcode активно, я имею в виду текстовый редактор Xcode; агентный рабочий процесс iOS зависит от многих компонентов Xcode, доступных вне Xcode, таких как Swift LSP для работы подсветки кода и навигации в Cursor Swift, Xcodebuild для сборки и т. д.
Однако недавние обновления загромоздили его странными и неработающими элементами интерфейса, и для достижения удовлетворительного результата вам придётся отключить большинство функций.
Тем не менее, я предлагаю вам попробовать; это, вероятно, наиболее удобная настройка, если вы хотите или вам нужно оставаться в рамках Xcode и наслаждаться этим новым миром программирования с поддержкой ИИ, не сильно меняя свой рабочий процесс.
Вы заметите, что я даже не упоминаю локальные модели автодополнения Xcode. Можете попробовать их, но в нынешней гонке за автономным программированием они в своём текущем состоянии неактуальны.
Но я считаю, что позиция Apple по запуску всего локально окупится в ближайшем будущем; просто сейчас это недостаточно хорошо и развивается недостаточно быстро.
Xcode Intelligence
Я немного использовал Xcode Intelligence, и мой отзыв такой же, как и по поводу локальной модели. Она есть; в основном работает, но это совсем не передовые технологии.
Положительный момент заключается в возможности взаимодействия с собственным поставщиком моделей, а значит, и с любым API. Это полезно, если вы хотите использовать новейшие модели и оплачивать использование API.
В моём случае я использую другой подход; у меня есть подписка OpenAI Pro за 200 долларов для использования Codex.
Но вы также можете подключить свои учетные записи OpenAI и Anthropic. Таким образом, вы можете пользоваться своими подписками, работая в Xcode.
В целом, Xcode Intelligence — это неплохой инструмент. Это не совсем агентное программирование. Он разработан для коротких сессий и редактирования кода в реальном времени, позволяя вам оставаться в рамках рабочего процесса.
Apple также прилагает усилия для инжектирования кастомных системных промптов всякий раз, когда требуется новый API (например, Liquid Glass), который выходит за рамки обучающих данных текущих моделей.
Но эти файлы Markdown действительно удобны, я часто использую их в той или иной форме, чтобы внедрять их по своему усмотрению в различные агенты при работе с соответствующим API.
В это время я использую их для отработки навыков Codex, но об этом позже.
Рабочий процесс на основе терминального интерфейса
В начале 2025 года у меня был такой период. Claude Codex, а затем и Codex, каким-то образом сделали терминальные приложения снова популярными.
Все их создавали. Omarchy от DHH выглядел очень привлекательно, и поэтому я отправился в это путешествие по созданию полностью терминального рабочего процесса для программирования и работы с ИИ.
Я остановился на Zellij, простом в настройке терминальном рабочем пространстве.
Я создал понравившуюся мне раскладку. Идея заключалась в том, чтобы с одной стороны располагался проект, а с другой — несколько агентов, а также вкладки для просмотра кода и терминал.
Затем я опубликовал исходный код своей настройки/макета, и, по сути, у меня был один экземпляр этого рабочего пространства для каждого проекта, над которым я работал.
Выглядело круто, вот что я могу сказать. Как человек, не терминально больной, но любящий всё «терминальное», это было максимум, который я мог выдержать. Запоминать все эти сочетания клавиш было слишком утомительно. Но это было весело в процессе.
Я думаю, что для некоторых это, вероятно, самый эффективная раскладка. Чтобы запустить ее в любой папке, требуется всего одна секунда. А поскольку сегодня лучшие агенты — это Claude Code и Codex CLI, использование терминала для всего остального вокруг них имеет большой смысл.
Cursor, конец IDE в том виде, в каком мы их знаем
Я использую Cursor с момента его первого выпуска. Хотя это форк VSCode, он значительно продвинулся в интеграции с ИИ по сравнению с VSCode, даже сегодня.
Революционная функция Cursor — это невероятно быстрая модель автозавершения и автодополнения с помощью клавиши Tab. Для меня это до сих пор лучшая функция. При ручном программировании на рынке нет ничего лучше. Он может давать точные подсказки за доли секунды, и вы можете просто переписывать код с помощью Tab.
Вторая лучшая функция — это их новая собственная модель Composer-1 — самая быстрая модель кодирования, которую я когда-либо использовал, из тех, что не выдают ужасный код.
Это моя основная модель, когда я хочу оставаться в рабочем потоке. Я использую её, когда мне нужно внести небольшие изменения в код или запросить информацию из кодовой базы и т.д. Это также хорошая модель для выполнения четкого плана, проверенного или составленного Codex.
Если вы вручную программируете и редактируете код и вам нужен агент для быстрой и небольшой рефакторизации, чтобы вы могли оставаться в рабочем потоке, попробуйте!
Что касается программирования iOS в Cursor, существенных изменений не произошло. Я по-прежнему использую Sweetpad, и у меня есть сочетания клавиш для сборки и запуска приложения в симуляторе. Подробнее об этом можно прочитать в моей предыдущей статье здесь.
Отдельно стоит упомянуть Flowdeck, замену Sweetpad с большим количеством и лучшими функциями, а также более надежным интерфейсом отладки. Я планирую поэкспериментировать с ним в этом году.
Cursor уже довольно давно является моим домом, и, пробуя другие потоки, я всегда возвращаюсь к нему. Потому что в конечном итоге это самый простой интерфейс для просмотра и навигации по коду, просмотра диффов в Git, агентов Cursor и запуска любого количества терминалов Codex для каждого проекта.
Как вы можете видеть на скриншоте выше, я использую интерфейс Cursor UI для агентов (в основном Composer-1), а также (и в основном) терминальную версию Codex в нижней части окна.
XcodeBuildMCP
Один из важнейших элементов полностью агентного рабочего процесса iOS-разработки — это взаимодействие с Xcodebuild и симулятором.
Мой опыт показывает, что даже последняя модель Codex 5.2 допускает множество ошибок при использовании Xcodebuild напрямую в проекте с большим количеством схем, пакетов и т.д.
На помощь приходит XcodeBuildMCP — для меня он оказался бесценным. Он позволяет агенту без труда обнаруживать ваши схемы, симуляторы и многое другое. Кроме того, он может взаимодействовать с симуляторами, нажимать на цели, читать лог и многое другое.
По сути, всё, что вы можете делать с помощью Xcodebuild или графического интерфейса Xcode, теперь может сделать агент, используя этот MCP.
Питер сказал бы вам, что MCP устарели, но, на мой взгляд, не все из них.
Во всём остальном я прошу агента использовать CLI версии, но не Xcode.
Использование XcodeBuildMCP открывает возможности для длительных агентских рабочих процессов. Вы можете запросить реализацию функции, собрать приложение, реализовать тесты, запустить тесты до тех пор, пока они не будут работать, а затем запустить приложение, сделать скриншоты и взаимодействовать с функцией, чтобы убедиться в её корректной работе, и это лишь некоторые из шагов.
Практически всё, что человек делает с симулятором iOS, агент может сделать с помощью XcodeBuildMCP. Подумайте, как вы обычно реализуете и тестируете свои функции, и передайте эту информацию агенту. Затем наблюдайте, как он выполняет работу за вас.
У меня нередко бывают задачи, выполняемые без контроля, которые длятся более 30 минут, и результаты которых я могу спокойно посмотреть позже и быть на 90% уверенным, что всё будет в порядке.
Выпуск библиотек с открытым исходным кодом
Сейчас, когда порог написания кода практически равен нулю, выпустить библиотеку с открытым исходным кодом стало проще, чем когда-либо.
Например, у меня был шаблон навигации в новом приложении, которое я разрабатывал, и я хотел экспортировать его как отдельную библиотеку. Я просто обратился к Codex: «Можете ли вы посмотреть на мой AppRouter и сделать его отдельным пакетом, который я смогу использовать вне этого приложения?»
И он создал AppRouter, библиотеку и шаблон, который я теперь использую в большинстве своих приложений SwiftUI. Ничего революционного в этом нет; это просто легковесный пакет, который делает навигацию в SwiftUI такой, какой я хочу.
В основном это было упражнение, чтобы посмотреть, как быстро я смогу создать новый репозиторий, проверить и опубликовать исходный код. И это заняло меньше часа, тогда как раньше на это потребовалось бы гораздо больше времени. Codex извлек код, написал README и т.д., и даже добавил пакет в мое приложение.
Codex — конец всему
Мне следует подробнее рассказать о Codex. Если честно, на это, вероятно, приходится более 50% всего использования ИИ. Это то, что я использую чаще всего, и агент, которому я больше всего доверяю. Последняя модель GPT 5.2 Codex делает его лучше, чем когда-либо.
Вы можете спросить его практически о чём угодно, и в большинстве случаев он выдаст результат с первого раза. У меня нет для вас какой-то грандиозной рекомендации, но вот одна: всякий раз, когда вы чувствуете, что застряли, и желательно до того, как это произойдёт, задавайте вопросы.
По сути, больше нет никакого морального превосходства в том, чтобы говорить себе «я сделал это без ИИ» — по крайней мере, когда речь идёт о задачах программирования.
Поиск чего-либо, анализ и поиск в кодовой базе — всё это я делегирую Codex, а сам занимаюсь другими делами.
Я наконец-то могу обсуждать архитектуру, проверять код и проводить рефакторинг с помощью ассистента, имея всегда онлайн и всегда доступного коллегу.
Я не говорю, что я больше не думаю, и обсуждение деградации мозга в эпоху ИИ — это совершенно другая тема, которую я с нетерпением жду возможности обсудить с вами в другой статье.
Я по-прежнему мыслю так же, как и раньше, но теперь это происходит быстрее. Мы можем вдвоем (или больше) обсуждать одни и те же проблемы, сравнивать результаты и так далее.
А затем начинается программирование. У меня довольно своеобразное мнение об архитектуре, но я чувствую себя комфортно с Codex, работая над уже существующими проектами. Он хорошо подходит для поиска и отслеживания шаблонов в кодовой базе.
И самое лучшее? Пока я программирую, я могу изучать то, что хочу сделать дальше. Вот как я это вижу:
Я люблю создавать, и программирование — это лишь один из инструментов, который помогает мне в этом. Теперь я могу делегировать и выполнять эту часть гораздо быстрее, чем раньше.
Для меня это победа.
А как же Claude Code?
Я люблю Claude Code. До Codex я использовал Claude Code в качестве основного инструмента. Моя проблема связана исключительно с моделью. Opus хорош, но не так хорош, как Codex 5.2. В ходе моих тестов выяснилось, что он чаще выходит из-под контроля и генерирует более сложный код и т.д. Вероятно, это очень субъективно, и вам придётся составить собственное мнение, используя оба варианта.
Но их инструменты великолепны. Codex ещё многое предстоит наверстать. У Claude Code лучше форматированный вывод, лучшие инструменты и более быстрое обращение к этим инструментам.
Однако Codex развивается, и быстро.
Codex для всего вашего компьютера
Кэмерон опубликовал кое-что интересное, что напомнило мне, как часто я использую Codex для навигации по своему компьютеру, настройкам и т.д., помимо чистого программирования.
В основном я использую Codex в рамках собственной конфигурации, чтобы можно было запрашивать в изменения в ней. Я часто прошу Codex подправить мой Git-конфиг, профиль Zsh и так далее.
Прошли те времена, когда я делал всё это вручную.
Приглашаю вас попробовать его cdx, чтобы вы могли попросить свой компьютер сделать что угодно: «cdx клонируй этот репозиторий Git и собери проект».
Codex в облаке
Мы мечтали об этом раньше. Использую последнюю сборку своего приложения в TestFlight, обнаруживаю ошибку, но меня нет за компьютером… поэтому мне нужно где-то запомнить или зарегистрировать проблему.
Ну, теперь это не проблема, я могу попросить исправить ошибку.
Я часто использую облачную версию Codex, как через приложение ChatGPT для iOS (да, есть вкладка Codex!), так и через веб-сайт.
Он невероятно удобен для выполнения самостоятельных задач и экспериментов. Когда у меня возникает желание создать прототип какой-либо функции, я достаю телефон и запускаю Codex; он создает новую задачу и работает в облаке.
Позже я могу просмотреть код в приложении и открыть запрос на слияние.
Я также часто использую его для работы с задачами GitHub, Linear и Slack. Я могу использовать @Codex практически из любого места и дать ему контекст.
Вы также можете легко создать тестовое приложение для проверки при открытии запроса на слияние в GitHub. Это очень легко настроить, особенно с Xcode Cloud. Вы можете создать сквозной рабочий процесс для нативных приложений с использованием ИИ, где Codex редактирует код в облаке, отправляет его в GitHub, и вы получаете сборку TestFlight, готовую к тестированию. Даже не прикасаясь к компьютеру!
Я исправлял много подобных ошибок в Ice Cubes. Когда я вижу, что контекста достаточно, я прошу @Codex исправить это.
Нужно быть осторожным, чтобы не стать рабом машины.
Навыки Codex
Одной из последних нововведений Codex является добавление навыков. Навыки представляют собой самодостаточный, активируемый по запросу, агентский поток.
Вместо того чтобы засорять ваш AGENTS.MD всем подряд, навыки позволяют агенту загружать их по запросу, вручную или автоматически — это зависит от вас. Это зависит от того, как вы напишете свою инструкцию по использованию.
Но вы можете перечислить и вызвать их с помощью $:
Это очень удобно. Я создал и опубликовал в открытом доступе множество таких инструментов, которые использую для разработки под iOS. В основном, они соответствуют рабочему процессу, который я оттачивал со временем, и предоставляют полные справочные материалы (в основном, стенограммы сессий WWDC), чтобы модель могла содержать как можно больше информации.
У меня есть один инструмент для генерации списка изменений в App Store, который сравнивает историю коммитов с предыдущим релизным тегом, сканирует коммиты и кодовую базу на предмет изменений для отображения.
Ещё один навык помогает понять проблемы производительности SwiftUI, даёт рекомендации и помогает редактировать код.
И ещё один помогает мне справиться с хаосом, который представляет собой параллелизм в Swift, он содержит контекст для Swift 6.x, изоляцию акторов и т. д. Он поможет вам решить даже самые неочевидные ошибки, сохраняя при этом рассудок.
Не стесняйтесь просматривать их, чтобы понять, насколько мощными они могут быть в вашем рабочем процессе.
Вы также можете посмотреть Axiom, если используете Claude Code. Это полнофункциональный набор навыков для Claude Code.
Фоновый терминал Codex
Еще одна функция, недавно добавленная в Codex, — это фоновый терминал. Пока что он находится в экспериментальной стадии, поэтому его необходимо включить вручную с помощью команды /experimental.
После включения эта функция позволит Codex запускать асинхронную задачу в терминале, которая может работать неограниченно долго. Представьте себе запуск веб-сервера во время работы над проектом и т.д.
В основном я использую её именно так. Я работал над бэкендом и фронтендом, и попросил Codex запустить их в фоновом режиме, чтобы мы могли работать над кодом и видеть изменения в реальном времени в браузере Cursor.
Другие проекты с открытым исходным кодом
В целом, разработка с помощью ИИ позволила мне заниматься любимым делом и одновременно быть более продуктивным. Я мог создавать и выпускать проекты с открытым исходным кодом.
И не просто так, я в основном делал то, что мне нравилось, и это было полезно для меня. Кроме того, это были небольшие проекты, которые выходили за рамки моей зоны комфорта и были связаны с технологическим стеком, с которым я не был полностью знаком.
Это позволило мне учиться гораздо быстрее, чем раньше. И я хочу это подчеркнуть. Создание нового проекта с помощью помощника по программированию — отличный способ начать работу над чем-то, с чем вы не чувствуете себя комфортно.
Например, я создал HyperGit, расширение для Chrome, которое позволяет мне быстро переключаться между недавно открытыми проектами GitHub из любого места (представьте себе это как палитру команд, но для вашего браузера).
Раньше я никогда не работал над расширениями для Chrome, но теперь начал. Я прочитал код, понял большую его часть, и это заняло у меня меньше часа!
А до этого я создал целый набор инструментов «Hyper»: HyperYapper, HyperDrafter и HyperGit. Идея заключалась в создании Hyper Unniverse для небольших, быстродействующих инструментов, но я не стал развивать её дальше.
Но я всё равно создал их, потому что хотел ими пользоваться. HyperGit (веб-версия) кэширует ваши репозитории GitHub и позволяет искать код в любом из ваших репозиториев с молниеносной скоростью (намного быстрее, чем медленный поиск GitHub).
HyperYapper — это инструмент для кросс-постинга в BlueSky, Mastodon, X и Threads. Это непростая задача, потому что API Threads сложен, а API X ресурсоёмкий. На сегодняшний день инструмент ещё не завершен, пока он работает в основном с BlueSky и Mastodon.
И наконец, HyperDrafter — это то, с чем я хотел поэкспериментировать, как человек, любящий писать (да, эта история на 100% моя, без ИИ), я хотел создать небольшой редактор, где ассистент мог бы задавать вам вопросы во время написания.
И все это — небольшие веб-приложения с открытым исходным кодом, которые вы можете найти на моем GitHub, все они созданы с помощью ИИ-помощника в программировании.
Я не говорю, что вы должны создавать и выпускать что угодно, но вы определенно можете это сделать, и это займет гораздо меньше времени, чем раньше. В сочетании с развертыванием в Vercel одним щелчком мыши из любого репозитория, вы можете запустить веб-приложение онлайн буквально за несколько минут.
Бутстрапинг нового проекта
Запуск нового проекта, готового к работе с ИИ, — большой вопрос, и я рад поделиться некоторыми ответами на него, тем более что в этом году Medium нас щедро поддержал. Я вхожу в команду, которая работает над новым проектом и надеется сделать его публичным уже в этом году.
Вкратце: Лучший результат в работе ИИ-агентов достигается в новом проекте с правильной настройкой.
Я разрабатываю новый проект мобильного приложения с нуля. Мы выбрали Kotlin Multiplatform для общей/бизнес-логики, а затем Compose и SwiftUI для нативных интерфейсов Android и iOS.
Я очень доволен этим выбором. Хотя инструменты KMM не идеальны, сейчас всё идёт по плану, и мы очень быстро их улучшаем. Надеюсь, скоро смогу рассказать об этом подробнее.
И вот что я хочу сказать: мы не спешили и осознанно выбирали технологический стек; мы сами заложили все базовые строительные блоки. Сначала — Kotlin-часть, правильный сетевой стек, корректный способ взаимодействия хранилища на Kotlin с потоком данных Android Compose, а также наши окружения SwiftUI.
И как только всё было настроено, я попросил Codex задокументировать всё, свести это в файл Agents, и с этого момента проект пошёл по рельсам.
Добавление новой функции в основном сводилось к дублированию существующего кода, и агент очень хорошо следовал нашим шаблонам. Один из важнейших аспектов — это обеспечение документирования на каждом этапе.
Часть кода на Kotlin полна тестов, и агент запускает и редактирует их на каждом шаге.
Да, работать со старым кодом, созданным до появления ИИ, гораздо сложнее, и я чувствую это каждый раз, когда приходится взаимодействовать с нашим монорепозиторием.
Быстрое прототипирование и итерации
Работа с агентами ИИ также позволила нам быть гораздо более продуктивными и оперативными. В конечном итоге мы написали значительно больше кода, чем раньше, потому что могли, а не потому что должны были.
Изначально мы хотели создать полностью нативный текстовый редактор. Целью было разработать собственный парсер Markdown и HTML на Kotlin с рендерами для SwiftUI и Compose. И мы примерно на 70% продвинулись. Самое сложное — не рендеринг, с ним у нас всё получилось, и, оглядываясь назад, его стоило вынести отдельно до отката. Самое сложное — это редактор.
До появления ИИ мы бы никогда не взялись за это. Наша команда разработчиков мобильных приложений для этого нового проекта состояла всего из двух человек: моего друга-разработчика Android и меня. Но мы чувствовали себя комфортно, поскольку написание кода не было узким местом.
Однако мы решили изменить курс и пойти другим путем. Поскольку мы быстро итеративно добавляли функции в наш веб-редактор, мы решили не реализовывать их на двух платформах и с тремя пользовательскими интерфейсами.
Поэтому мы вернулись к исходной точке и решили создать пользовательские веб-представления с легковесным веб-редактором и нативным пользовательским интерфейсом, а также бриджем JavaScript.
В этом случае наши ИИ-агенты помогли нам перейти на это в очень короткие сроки и с минимальными трудностями.
Мой посыл в этом разделе: не стесняйтесь итеративно работать с ИИ, код теперь практически бесплатен, а создание тестовых приложений и прототипов стало проще, чем когда-либо.
Редактирование кода в нескольких репозиториях
Еще один урок, который я усвоил при разработке этого нового приложения: не ограничивайтесь iOS.
Для этого нового проекта мы не использовали монорепозиторий. У нас есть отдельные репозитории для бэкенда и веб-фронтенда, а также еще один для мобильных приложений.
Оба репозитория полностью документированы как для людей, так и для ИИ. В итоге, когда мне нужно было работать над API (на Go) и фронтендом на JavaScript, я часто ссылался на другой репозиторий в своих подсказках.
Посмотри код бэкенда в ../draft-day и проверь, реализован ли API XYZ, реализуй его, если нет, и добавь его в наш общий код на Kotlin.
Я делаю это несколько раз в неделю.
То, что наши команды распределены по всему миру, также означает, что веб-редактор часто получает новые функции за ночь (для меня), поэтому утром я могу поручить агенту проверить, что изменилось в веб-репозитории по сравнению с мобильным репозиторием, и реализовать недостающие части.
Этот раздел очень важен. Вам нужно понимать, сколько времени это экономит. Речь идёт о простых вещах для человека: чтение обновлений API, изменения во фронтенде и адаптация этих изменений к уже существующим мобильным проектам.
Для человека это заняло бы немного времени, но для машины это идеальная задача. Вы можете попросить её, и она сделает это быстрее, чем вы когда-либо смогли бы это сделать.
Пожалуйста, не стесняйтесь использовать перекрестные ссылки на репозитории и не бойтесь работать и внедрять изменения в нескольких кодовых базах одновременно — именно в этом преуспевает современный инструментарий: в создании контекста и работе с ним.
Создание контекста
Это, вероятно, ещё одна «самая» важная часть. По крайней мере, так было, может быть, полгода назад. Я бы сказал, что создание тщательного контекста и промпта стало менее важным в последней версии инструментария Codex (CLI) + модели.
Если вы используете Claude Code, вам, вероятно, нужно быть немного более подробным и ссылаться на большее количество файлов, но я считаю, что Codex хорош в самостоятельном поиске.
Тем не менее, одна из немногих вещей, которые я часто делаю, это указываю Codex (используя @) на точные файлы, которые я хочу использовать в качестве примера, рассматриваю X и Y перед созданием Z и следую тому же шаблону.
Ещё один хорошо работающий способ — быстрое встраивание. Нашли API, который хотите использовать? Интересную статью, в которой рассказывается, что в SwiftUI не следует использовать ViewModel, а вместо этого нужно использовать чистое представление? Вы можете скопировать и вставить её в подсказку, а затем указать Codex выполнить нужное действие.
Ещё одна вещь, которой я бы не доверился полгода назад, но которая теперь работает, — это вставка изображения. Если вы не хотите объяснять сложную разметку и хотите получить первый черновик, не стесняйтесь вставлять изображение, макет Figma и всё, что напоминает желаемый результат. Codex, по крайней мере, хорошо понимает замысел и строит из изображения.
Думаю, у меня нет других полезных советов по созданию контекста. Правда в том, что раньше это была самая важная часть для получения хорошего результата, но теперь инструменты настолько хороши, что модель лучше справляется с поиском в кодовой базе и использованием инструментов.
Поэтому просто попросите, и, скорее всего, если модели потребуется дополнительная информация, она спросит вас в ответ.
Тесты, ещё больше тестов
Что позволяет мне комфортно работать со многими проектами и агентами в наши дни, так это тестирование. Я никогда раньше не запускал столько тестов.
И раньше я считал мусорные тесты пустой тратой времени. Потому что писать их — безумно сложно, часто на написание тестов тратится больше времени, чем на саму пользовательскую фичу.
Однако теперь, когда я стал добропорядочным гражданином, я часто прошу агентов внедрять тесты, и именно эту часть я тщательно проверяю. Если тест корректен, то и код, окружающий его, скорее всего, тоже корректен.
Так что тестируйте, тестируйте, тестируйте. Я часто прошу рефакторизовать устаревшие части кода, чтобы сделать их тестируемыми, а затем прошу добавить тесты.
А с XcodeBuildMCP очень быстро можно попросить Codex запустить тесты, посмотреть результат и применить необходимые исправления.
Геймдев
Я большой поклонник видеоигр и программирования и разработки игр. Моя мечта — однажды выпустить свою собственную инди-игру в Steam.
В прошлом я работал над несколькими играми и выпустил их, например, Grassland Survivor, игру в стиле Vampire Survivor для Pico-8, фэнтезийной консоли, похожей на Game Boy.
В ней я использовал искусственный интеллект с минимальным применением, так как он был представлен в процессе разработки.
Но я решил попробовать снова и поработал с другим 2D-движком, Love2D, над прототипом 2D-игры Diablo, Diablo2D (да, я такой креативный).
На этот раз я решил сделать её полностью на агентах. Я изучил код, но не слишком подробно. Мне нужна была быстрая итерация различных функций. Поэтому я попросил добавить всё, что хотел, и в основном это сработало. Мне нужно больше времени, чтобы завершить её, но она уже играбельна. Здесь есть монстры и добыча, приятный ретро-стиль и т.д.
Примечание: все ресурсы куплены, пока не сгенерированы ИИ.
Это был фантастический опыт, позволяющий заглянуть в будущее. Моя задача заключалась в том, чтобы быть одновременно и игроком, и тестировщиком. Я давал обратную связь о том, что моя спецификация не совсем соответствует моим ожиданиям, а затем наблюдал, как агент вносит изменения в код, чтобы я мог запустить и протестировать его снова.
Баланс между исследованием и продуктивностью
Приближаясь к заключению, пожалуйста, уделите немного времени размышлениям обо всем, что было обсуждено.
Настройка вашего рабочего процесса и тестирование всего может отнимать много времени, однако это необязательно.
Правда в том, что, вероятно, 80% того, что выпускается в мире ИИ, — это полная ерунда, поэтому вам нужно сосредоточиться на том, что подходит именно вам.
Как я уже упоминал во введении, я никогда не работал так много, но в то же время не работал так мало. На это ушло много времени, но теперь я больше не занимаюсь программированием и написанием кода сам — большую часть работы я делегирую.
И это нормально, работа развивается, и у меня есть время на множество других аспектов моих проектов, помимо программирования.
Вайб-кодинг против разработки с помощью ИИ
В заключение о вайб-кодинге, потому что, наверное, я не хочу, чтобы меня критиковали? Нет, это ложь, мне всё равно, делай, что хочешь, а я делаю, что хочу.
Но я на самом деле не занимаюсь вайб-кодингом. Вайб-кодинг — это стремление к результату. Вероятно, наиболее близко к нему я подошел в моём проекте Diablo2D, о котором я упоминал выше, где я хочу протестировать конечный продукт, а не целый день сидеть за LUA-кодом.
И это нормально; может быть, к 2027 году всё будет писаться с помощью вайб-кодинга? Кто знает? Я знаю, но вам не понравится ответ. Программирование мертво, и оно не вернётся. Оно медленно, но верно угасает.
Сегодня у нас, инженеров-программистов, есть преимущество, потому что мы понимаем код, и, как следствие, лучше подготовлены к тому, чтобы направлять машину к желаемому результату. Но это ненадолго.
Сейчас я занимаюсь разработкой с помощью ИИ, которая объединяет мои навыки с навыками машины, чтобы добиться сверхвысокой эффективности в кодовой базе, которую я знаю так, как если бы написал её сам.
Узкое место: человек в процессе
К сожалению, это правда, мы близки к тому, чтобы проекты могли на 100% управляться ИИ. В прошлые дни самым трудоемким аспектом для меня было переключение контекста. Утомительно управлять всеми открытыми задачами, code review и т.д. Сейчас я могу работать над большим количеством проектов одновременно, но какой ценой? Ценой моего рассудка? Возможно. Посмотрим.
Но это правда. Я — узкое место, так как мои агенты ждут моего одобрения своей работы, чтобы они могли бесконечно добавлять и редактировать код.
Удачного вам не-программирования!