Не первый месяц (а может и год) про ИИ из каждого утюга льются восхитительные отзывы, как замечательно он генерит рабочий код. У меня есть подписка на ИИ в IntelliJ Idea, которая предоставляет на его базе простой ИИ чат с выбором из десяток ИИшек где просто вопрос-ответ как google. Недавно увидел в AI плагин добавили возможность выбора не чата для вопрос-ответ, а полноценный агентский режим с доступом для ИИ с write правами в директорию проекта + выполнения bash команд там же. Аналогичный функционал Apple добавил в Xcode 26.3 буквально на днях (https://www.apple.com/newsroom/2026/02/xcode-26-point-3-unlocks-the-power-of-agentic-coding/). До конца месяца у меня еще оставались не используемые токены до их перезагрузки. И я подумал, ведь это идеальная задача для ИИ по шаблонам из How to iOS опен сорс парсеров написать бенчмарки на большой xml файл.

В общем вы думаю уловили суть:

C таким setup я начал эксперимент

  1. Не разбираюсь в ИИ какие хорошие, какие плохие, выставил наугад в AI плагине Codex (gpt-5.2-codex medium)

  2. Использовал Xcode 26.2 и в системе он стоит основной (это важно, потому что ИИ может вызывать Xcode тулы из терминала)

  3. Я сам создал iOS пустой проект с iOS 17 минимум версией (это важно, ниже будет объяснение)

  4. Разработку вел в IntelliJ Idea c AI и Swift плагином (аля AppCode)

Поиск парсеров

Так как ИИ это просто огромная база данных, скорее всего обученная на данных 2025 года или раньше, то в ней точно должны храниться сорцы с GitHub. Поэтому сразу загрузил ее работой — найти популярные xml парсеры под iOS платформу написанные на языке Swift, Objective-C и записать их названия, xml движок и ссылки на репо в файл (на промпт я потратиил 10–20 минут, чтобы не упустить детали и не перезапускать поиск и снова тратить токены). Через 5–10 минут мне выдало около 15 результатов. Чтобы ускорить процесс, я руками сходил в каждый репозиторий и отсеял где мало звезд, где старые версии Swift, где нет интеграции через менеджеры зависимостей (кроме TBXML, потому что у него было очень много звезд хотя и не было поддержки менеджеров зависимостей).

Вот такой финальный список получился:

NSXMLParser

libxml2

Custom

Codable

Тут немного добавлю, что касается поиска репозиториев, то я аплодирую стоя, список репозиториев ИИ сделал крутой. Я параллельно пробовал искать репозитории руками через google, на GitHub через их copilot и просто по языкам с сортировкой по кол-ву звезд, но половину репозиториев с большим кол-вом звезд, что нашел ИИ выше, мне не выдал ни google, ни GitHub, как такое может быть для меня остается загадкой.

Сборка парсеров

На удачу все найденные парсеры поддерживали CocoaPods (кроме TBXML). Попросил Codex создать Podfile и добавить туда все парсеры, на удивление он справился. Потом руками собрал iOS главный таргет чтобы провериить, что всё работает и всё удачно собралось, то есть все парсеры за исключением одного собрались и можно переходить к бенчмаркам. TBXML парсер совсем древний, ему уже 15 лет (там даже есть поддержка MRC!), но у него довольно много звезд. Поэтому решил не исключать его из бенчмарка и руками скачал проект и собрал из него бинарную либу, сам подключил в проект так как почти уверен, что ИИ не смог бы с этой задачей справиться и я просто бы потерял время и токены зря.

ИИшный Podfile, я ни строчки не трогал
platform :ios, '17.6'

use_frameworks!

target 'XmlParserBenchmark' do
  def shared_pods
    pod 'AEXML'
    pod 'SWXMLHash'
    pod 'SwiftyXMLParser'
    pod 'XMLCoder'
    pod 'Kanna'
    pod 'Fuzi'
    pod 'Ono'
    pod 'KissXML'
    pod 'GZIP'
  end

  shared_pods

  target 'XmlParserBenchmarkTests' do
    inherit! :search_paths
    shared_pods
  end
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '17.6'
    end
  end
end

Клиент для каждого парсера

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

let xmlURL = URL(...)

let startTime = Date()
let result = try AEXMLClient().parse(xmlURL)
let endTime = Date()
let result = endTime - startTime

let startTime = Date()
let result = try FuziClient().parse(xmlURL)
let endTime = Date()
let result = endTime - startTime

В общем объяснил подробно свою идею ИИ и для верификации корректности дал ему тестовый xml, который нужно использовать в юнит тестах для каждого клиента (на промпт ушло минут 20–30, чтобы токены зря не тратились, приходится перепроверять промпты перед запуском ИИ). На мой скепсис и удивление одновременно, ИИ написал для 9 испытуемых парсеров как клиентскую часть, так и юнит тесты к ним (18 файлов, 9 клиентов + 9 тестов) минут за 10-20. Я, конечно, полез смотреть как и клиентский код, так и код тестов. В общем было написано неплохо, тесты написаны на современном Swift Testing (за это лайк), так как это всего лишь одноразовый проект, то решил оставить всё как есть. Но для продакшен рэди, конечно, нужно было бы доправлять код клиентов, накрывать их общим протоколом, обобщать ошибки и прочую мелочевку, которую я бы не доверил ИИ. Да и наврятли бы ИИ эту доработку сделал бы хорошо без подробного промпта, а чтобы написать подробный промпт, то проще самому руками доправить, иначе придется тратить усилие как на написание инструкций так и на тщательное ревью, как оно выполнено, а это в 2 раза больше работы чем просто самому сразу всё написать.

Бенчмарк iOS приложение

Захотелось так же проверить на что способно ИИ и в этой части. Попросил его создать список парсеров на главном экране и когда проваливаешься в парсер, то нарисовать кнопку, которая запускает бенчмарк, и вывести на экран результат, потом результат бенчмарка прокинуть обратно на главный экран и отрисовать напротив парсера (потратил на промпт минут 10–20). В общем типичное задание на собеседовании для Junior уровня — отобразить список с деталями. 5 минут ожидания и приложение готово. Но код, конечно, ИИ выдал лапшевидной формации и в одном файле (всё положил в ContentView.swift файл шаблон при создании проекта). Возможно, ИИ нужно прописывать по какой архитектуре раскладывать логику и файлы. Также ИИ не сгенерировал код для SwiftUI Preview, но я его об этом не просил, но подумал, что когда создаешь пустой SwiftUI файл то Xcode всегда прописывает туда #Preview макрос, видимо, этот нюанс ИИ не знает. В общем, тут уже точно нужно перегенеривать весь код с новыми более строгими правилами, потому что, увидев такой одноразовый код на ревью, каждый опытный разработчик (я надеюсь) его завернет. Как бы я хотел видеть сгенереный код:

  1. Каждая вьюшка в отдельном файле со SwiftUI Preview

  2. Бизнес логика и состояния вынесены в отдельные модули, сервисы

  3. Юнит тесты для состояний и бизнес логики

  4. Снапшот тесты для вью компонентов

  5. UI тесты

Также отмечу, что для списка ИИ использовал List, но все мы знаем и Apple рекомендует использовать ScrollView + VStack (VLazyStack) для таких задач, потому что под капотом List использует устарелый UIKit движок (google сказал до iOS 16 там была обычная UITableView, сейчас там UICollectionView). Это минус.

Так как в приложении выставлена минимальная версия iOS 17, то я ожидал увидеть использование новых фич для биндингов как @Observable макрос + @State, но ИИ конечно же использовал старые ObservableObject + @Published + @StateObject. Это минус.

То есть со старта нам ИИ сгенерировал легаси код. Из всего этого я делаю выводы, если вайбкодер не разбирается в мобильной разработке или хотя бы не говорит ИИ "следуй бест практис", то проект обречен, 99% шанс, что проект столкнется со сложностями в дальнейшем развитии, что потребует его полное многократное переписывание, что потребует в свою очередь еще больше токенов. Это нас наталкивает на вывод, что человеку без опыта было бы лучше обратится к опытному специалисту, чтобы тот сразу спроектировал расширяемую и поддерживаемую базу для приложения, это выйдет гораздо дешевле в долгосрочной перспективе, или если хочет сэкономить на специалисте, то хотя бы почитать про архитектуры приложений, best practice и попробовать разобраться самому прежде, чем просить ИИ написать код.

Выводы, которые я сделал относительно генерации кода с помощью ИИ. Если нужен код по какому-то шаблону и много раз повторяющегося, например, как в моем случае написать парсинг определенного xml файла с помощью десяти парсеров, то это почти идеальная задача для ИИ, но опять же до финального адекватного состояния нужно доделывать руками, чтобы ориентироваться в коде и понимать, что там вообще происходит. Остальные нешаблонные вещи лучше писать самому, так как на промпт уходит очень много усилий + потом нужно построчно проверять, что в итоге получилось то что описывал, а ИИ по моему опыту пишет довольно многословно и в итоге выдает (для iOS во всяком случае) рабочий, но низкосортный код по умолчанию (без инструкций к архитектуре кода).

Итог. Я не написал ни строчки кода в этом бенчмарк проекте, но после кода ревью его лучше или просто выкинуть, или сесть и потратить часик другой на подробный промпт и перегенерировать снова, но я не вижу в данном случае смысла тратить столько времени на промпт. Потому что за час я и сам напишу этот проект с вполне хорошим качеством кода (за исключением парсеров, там шаблонный код и ИИ действительно проделал хорошую работу).

Скриншоты приложения

Наконец сам бенчмарк

Первый прогон был на xml со 100 тыс. строк

Как можно заметить, XMLCoder хуже всех в 10 раз и портит всю статистику, поэтому убираю его из тестов и для того же 100к xml файла получаем

Второй прогон уже на xml со 500 тыс. строк

Результат таков, что самый быстрый парсер это парсер 15 летней давности написанный на си без использования какого-либо xml движка под капотом, время его на 500К строк 0.4 секунды. Последнее место занимает парсер со временем 2.5 секунд, что в 6 раз медленнее победителя.

По результатам можно увидеть, что парсеры на базе системного XMLParser в 2–3 раза проигрывают парсерам на базе libxml2, а парсер на базе Codable вообще был дисквалифицирован еще на первом тесте. Но стоит отметить, навряд ли все xml файлы содержат сотни тысяч строк, для обычных небольших файлов можно брать любой парсер, разница будет минимальна (миллисекунды), особенно на фоне декодинга сложных данных (смотри ниже).

Получив результат, я, конечно, немного занервничал. Вспомните начало статьи, что у меня самопальный парсер этот же 500К файл парсит 15 секунд. Я копнул в код ИИ парсеров и обратил внимание, что он парсит поля с датами как строки, но тут я, конечно, сам виноват, не говорил ему конвертировать строки в Date. После этого я пошел в свой парсер выключил конвертер в Date, и к радости тоже получил время 1.5 секунды на весь файл, что как раз на уровне парсеров на базе системного XMLParser. То есть дело оказалось не в медленном парсере, а в декодинге Date, оказалось, что системный DateFormatter очень медленный и 99% времени в парсинге занимал именно он. Тут, конечно, я подумал, что нужно было просто кинуть свой парсер в профайлер и он скорее всего бы показал залипания в DateFormatter и не нужно было бы вообще делать бенчмарки xml парсеров, а всего-навсего нужно было бы просто поправить декодер для Date. Но что сделал, то сделал, и чтобы не пропадать результатам, я заменил парсер в пет проекте на TBXML, и скорость декодинга упала с 1.5 секунд до 0.4, то есть в 3–4 раза, что оказалось приятным бонусом.

Что в итоге с парсингом дат, как удалось снизить парсинг с 15 секунд до 1.5 секунды, а заменой парсера на TBXML до 0.4 секунды? Google и ИИ подсказали мне использовать ручной парсер дат вместо системного DateFormatter. Кому интересно прикладываю код от ИИ для формата дат в моих xml файлах, парсинг через него практически не влияет на финальный результат, то есть без парсинга дат было 0.4 секунды, с этим кастомный парсером дат стало 0.5 секунды.

Ручной парсинг дат на Swift
final class MyDateFormatter {

    func date(from string: String) -> Date? {
        // Format: "20260218135322 +0000"
        // Positions: YYYYMMDDHHMMSS +HHMM
        guard string.count >= 14 else { return nil }

        let yearStart = string.startIndex
        let yearEnd = string.index(yearStart, offsetBy: 4)
        let monthEnd = string.index(yearEnd, offsetBy: 2)
        let dayEnd = string.index(monthEnd, offsetBy: 2)
        let hourEnd = string.index(dayEnd, offsetBy: 2)
        let minuteEnd = string.index(hourEnd, offsetBy: 2)
        let secondEnd = string.index(minuteEnd, offsetBy: 2)

        guard let year = Int(string[yearStart..<yearEnd]),
              let month = Int(string[yearEnd..<monthEnd]),
              let day = Int(string[monthEnd..<dayEnd]),
              let hour = Int(string[dayEnd..<hourEnd]),
              let minute = Int(string[hourEnd..<minuteEnd]),
              let second = Int(string[minuteEnd..<secondEnd]) else {
            return nil
        }

        var components = DateComponents()
        components.year = year
        components.month = month
        components.day = day
        components.hour = hour
        components.minute = minute
        components.second = second
        components.timeZone = TimeZone(secondsFromGMT: 0)

        return Calendar.current.date(from: components)
    }
}

Так как в сети я не увидел свежих бенчмарков по xml парсерам, решил поделиться своими экспериментами, может кому-то будет полезно.

Еще раз про ИИ

Минусы

  1. В общем вайбкодинг без технического понимания на данный момент генерит одноразовый код.

  2. Написание промпта иногда требует больше времени чем просто руками написать код.

  3. Если технологии быстро эволюционируют (например как экосистема Swift), то этих данных будет мало во время обучения ИИ и сетка будет генерировать код в старом стиле.

Плюсы

  1. ИИшке классно делегировать простой mvp который потом можно сразу выбросить

  2. Писать какую-то шаблонную логику по уже написанному промпту или спецификации.

Кто дочитал до конца, вот тут ребята из JetBrains объясняют как использовать Codex без установки дополнительных приложений, а работать сразу в привычной IntelliJ Idea.

Youtube