Craftify

Компилируется — значит работает

Эксперимент с “vibecoding” можно считать завершенным. Целью эксперимента было оценить, насколько жизнеспособен этот метод разработки, насколько он может быть эффективным и каковы его ограничения.

В качестве тестовой задачи я выбрал разработку iOS-приложения. Во-первых, потому что я не интересовался iOS-разработкой последние 10 лет. Во-вторых, потому что мне действительно нужно было такое приложение. Его основная идея — автоматизировать рутинные операции с помощью LLM. В моем случае это исправление моих неуклюжих текстов на английском и украинском языках, перевод их на английский и болгарский, а также саммари веб-страниц. Я уже собрал что-то подобное для Raycast за один вечер. Так что настоящим вызовом была именно iOS-разработка. И эта часть должна была полностью контролироваться LLM, при моей минимальной помощи.

Вот итог: мне удалось создать приложение за 60 часов. Оно работает и выполняет свою задачу. В нем 6 экранов, кастомный UI и около 6500 строк кода на Swift (по cloc). В нем около десятка нерешенных проблем, но ничего критичного. Оно загружено в TestFlight, так что я могу им поделиться. Хотя, скорее всего, оно не пройдет проверку в App Store из-за несоответствия гайдлайнам :)

Выводы:

  • Я бы ни за что не смог собрать такое приложение в одиночку за 60 часов. Мне пришлось бы изучить слишком много всего.
  • Я потратил около 15 часов на борьбу с xcodegen, создание оберток для инструментов вокруг него, интеграцию swiftlint, swiftformat и т.д. Если бы я с самого начала выбрал Tuist, я бы, вероятно, не тратил часы на банальные вещи типа «приложение не отображается в share sheet из-за неправильной вложенности YAML» или «иконка приложения не отображается из-за опечатки в названии».
  • С другой стороны, если бы я не пытался настроить среду, где всё запускается через CLI, я бы до сих пор копался в кнопках Xcode, следуя туториалам.
  • Это подчеркивает важность построения максимально быстрого цикла изменений/тестирования для LLM — через CLI или, возможно, MCP. Чем он быстрее и чем лучше сообщения об ошибках, тем быстрее идет разработка.
  • Наличие базовых концептуальных знаний существенно ускорило бы процесс, помогая избежать ошибок и “костылей”.
  • У модели нет чувства обобщения существующего кода. Опытный разработчик часто интуитивно чувствует, где нужно заложить абстракции, чтобы учесть будущие изменения (так называемый «технический буфер для будущих хаков»). У меня была постоянная инструкция для LLM предлагать два способа улучшения кода в конце каждой задачи — и ни разу она не предложила ничего значимого на архитектурном уровне. Мне приходилось специально запрашивать архитектурные ревью, чтобы получить действительно полезные предложения.
  • Нужно постоянно совершенствовать инструкции, добавляя туда типичные ошибки, новые требования и так далее. И даже это не помогает во время длинных сессий — модель начинает «забывать» ранний контекст. В моем случае она постоянно пыталась импортировать код из модуля Common, хотя он и так был виден без импорта.
  • Проект должен постоянно поддерживаться в валидном состоянии с точки зрения линтера и тестов.
  • Иногда проще начать задачу с нуля, чем разбираться, что не так с текущим решением.
  • Поддержка изображений в Cursor — это киллер-фича для объяснения проблем. Так можно решать даже проблемы с выравниванием UI и версткой. Делаешь скриншот, выделяешь проблемную область, загружаешь в IDE — и если LLM не запутается в том, что вызывает проблему с отступами, она может даже ее исправить ;)
  • В следующий раз, когда я погружусь в разработку с нуля в незнакомой инфраструктуре, я:
    • тщательно выберу инструментарий, предлагающий максимум валидации и понятные сообщения об ошибках,
    • подготовлю максимально детальную спецификацию, которая постоянно обновляется (возможно, стоит убрать architecture.md и implementation.md из памяти),
    • настрою короткий и удобный для модели цикл изменений/тестирования с четкой обратной связью по ошибкам.

Тем не менее, приложение написано и:

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