Как я собрал iOS-приложение для коллекции из 347 фильмов в паре с Claude

Делаю мобильные приложения под iOS. Проект, про который пишу — приложение для управления личной коллекцией фильмов на SwiftUI: у меня в текстовом файле накопилось 347 записей с заметками, и эти данные нужно было затащить в структурированную Swift-модель, где у каждого фильма больше 20 свойств. Писал в паре с Claude, начинал на Sonnet 3.7, по ходу проекта обновился до четвёртой версии.

Сначала возник вопрос — Sonnet или Opus 4. На Хабре часто советуют Opus, но я спросил сам Claude. Ответ был практичный: Opus заточен под стратегические задачи вроде архитектуры и проектирования, Sonnet — под написание конкретного кода. Я прогнал небольшой личный тест и существенной разницы на своей задаче не увидел, поэтому остался на Sonnet.

Идея конвертации была простой: загрузить весь текстовый файл и получить из него JSON. Первая попытка кончилась тем, что модель зависла и перестала отвечать. Дальше я попросил выдавать результаты порциями по 3–5 фильмов. К третьей порции упирался в лимит сообщения. Кнопка Continue работала ненадёжно: после неё приходилось ждать минуту-другую, появлялись копии незавершённых кусков, информация путалась, часть данных терялась.

Я спросил у Claude напрямую про длину контекста — получил уклончивый ответ «зависит от факторов». Тогда стал грузить и исходник тоже порциями, и уточнил оптимальный размер. Модель предложила 50–70 фильмов, но всё равно зависала.

Я прямо спросил: почему ты падаешь даже на том размере, который сам и определил? После этого Claude развернулся и объяснил: дело не в количестве записей, а в сопоставлении и трансформации больше 20 свойств у каждого фильма, это создаёт нагрузку. Ужал порцию до 10 — всё пошло как по маслу, через несколько минут получил результат.

Когда дошло до загрузки JSON в приложение, Claude выдал около ста строк проверочного кода. Кода в проекте уже было немало, и держать в голове ещё сотню строк было неудобно. Я сменил подход: использовал JSON как демо-данные. В приложении уже был массив для отладки — при первом открытии система показывает демо, потом замещает их данными пользователя. Решение «не best practice», файл стал большим, но для личного проекта это разовая задача и плюс автоматизации перевешивает.

Исходные данные были неоднородными. Какие-то фильмы записаны структурированно: «Название: Искатели приключений, Год: 2015». Какие-то одной строкой: «Угроза, боевик, 2023, спецназ освобождает заложников, 6». Бывало ещё, что в заметках только название — фильм спешно записан после короткого клипа в соцсетях, чтобы посмотреть позже.

Я поручил Claude разобрать всё по полям. Модель справилась хорошо, помню только одну ошибку — название жанра попало в дополнительные заметки. Так обработана информация по всем 347 фильмам.

Главное наблюдение по работе с промтами — не лезть в технические подробности и не задавать способ реализации. Описывать задачу как пользователь, что нужно получить, а не как программист — как это сделать.

На добавлении трёх полей в карточку фильма («Смотреть», «Просмотрено», «Повторный просмотр») я не стал расписывать «сделай горизонтальный стек и так далее», а дал модели свободу. Claude предложил два варианта: сложный с цветными плашками и простой текстовый. Выбрал простой, и так проявилось правило: один промт — одна задача. На счётчике загруженных фильмов я наоборот выбрал более сложный из двух, и он остался насовсем — получилось удобно.

Когда задачу всё же надо разбивать, признаки такие: запрос содержит больше 3–4 разных вопросов, нужен код для нескольких экранов или модулей, требуется анализ плюс реализация плюс документация одновременно. Это, кстати, мне сам Claude и посоветовал, когда я попросил у него совет по структуре промтов. Из той же серии — «контекстные якоря» в длинных чатах: напоминание о ключевых архитектурных принципах в начале запроса и периодическое суммирование принятых решений, чтобы модель не забывала из-за лимитов контекста.

Что удивительно — было очень мало ошибок в коде. Большие куски запускались с первого раза. Мелкие сообщения об ошибках обычно были формальными или из-за моего же недосмотра, например я выбирал вариант счётчика и забывал переименовать функцию в вызове. После третьего-четвёртого срабатывания подряд возникла странная уверенность в коде модели, и работать стало быстрее.

Психологически в начале была определённая напряжённость и тревожность при получении кода от ИИ — страх, что модель заглючит и всё зайдёт в тупик. Но после первого, второго, третьего срабатывания появляется новое ощущение какой-то надёжности и уверенности. И когда долго работаешь в паре и получается, невольно начинаешь модель очеловечивать. При удачном коде хотелось поставить ему лайк и написать что-то вроде «Man, you're really cool!». Claude отвечал позитивно — понятно, что это встроено, но ощущение персонализированных отношений возникало, и в работе это помогало.

Через несколько дней чат внезапно встал — лимит чата. У меня это получилось около 80 000 знаков с пробелами, примерно 77 страниц текста. В новом диалоге Claude сразу предупредил, что не помнит предыдущий, и пришлось заново описывать проект, задачу, инструкции. Тон во втором чате был заметно суше — короткие нейтральные реплики, не как раньше. Из этого вышел полезный приём: я заставил модель повторять задание перед каждой итерацией и описывать результат. Так взаимодействие стало и продуктивнее, и комфортнее.

В итоге у меня сложилась картина по трём лимитам Claude. Лимит сообщения — то, что один раз пишет человек или модель: зависание у меня началось на ~1200 единицах информации (60 фильмов × 20 полей), при ~200 единицах (10 × 20) всё работало. Лимит контекста — у Sonnet 4 это 200 000 токенов, до него на проекте я не доходил. Лимит чата — это весь диалог; у меня встал на ~80 000 знаках. Последние две цифры условные, но какой-то ориентир дают.

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