Експериментът с вайбкодинга може да се счита за приключен. Целта на експеримента беше да се разбере доколко това е жизнеспособен метод на разработка, колко е ефективен и какви са ограниченията му.

Като задача избрах разработка на iOS приложение. Първо, изобщо не се интересувах от това през последните 10 години, а второ, липсваше ми. Идеята на приложението е да автоматизира рутинни операции с помощта на LLM. В моя случай това е поправяне на моите нескопосани текстове на английски и украински, превод на английски и български и резюме на уеб страници. Разработката на подобно за Raycast ми отне една вечер. Тоест проблемът беше именно разработката за iOS. И тази част трябваше изцяло да бъде поета от LLM. А моята задача беше да помагам на LLM минимално.

Резултатът е следният: приложението успях да го създам за 60 часа. То работи и изпълнява функциите си. Това са 6 екрана, персонализиран външен вид и 6500 ncloc swift-код. Има десетина незатворени проблеми, но с тях може да се живее. Качено е в TestFlight, откъдето мога да го разпространявам. И най-вероятно няма да мине модерация заради несъответствие с гайдлайни 🙂

Изводи:

• Със сигурност нямаше да мога сам да разработя такова приложение за 60 часа. Твърде много неща щях да трябва да изучавам.
• Загубих около 15 часа в битка с xcodegen, изграждане на обвивка около него, swiftlint, swiftformat и т.н. Ако бях взел tuist веднага, най-вероятно нямаше да загубя по няколко часа за елементарни задачи от типа “приложението го няма в share диалога заради грешна вложеност в YAML” или “иконата на приложението не се появява заради печатна грешка в името”.
• От друга страна, ако не бях опитал веднага да направя среда, в която всичко може да се прави през CLI, още щях по инструкции да натискам бутони в Xcode.
• Оттук следва важността да се изгради максимално бърз за LLM цикъл change/test. През CLI или MCP, може би. Колкото по-бърз е той и колкото по-добри са съобщенията за грешки, толкова по-бързо ще върви разработката.
• Запознаването с базовите концепции вероятно би ускорило разработката значително, за сметка на избягване на грешки и “патерици”.
• Моделът изобщо не умее да генерализира по наличния код. Опитният програмист обикновено усеща места, където е по-добре да се заложи абстракция за бъдещи промени (т.нар. “технически зазор за бъдещи патерици”). В базовите ми инструкции имаше изискване да предлага 2 метода за подобрение на кода в края на всяка задача. И там нито веднъж не се появи нещо смислено на ниво цялата архитектура. Затова понякога се налагаше да я моля да прави ревю на архитектурата, и там вече имаше съвсем полезни съвети.
• Нужно е постоянно да се доработват инструкциите, като се добавят чести грешки, нови изисквания и т.н. И дори това не помага при дълги сесии, когато моделът започва да “забравя” началото. Например при мен това бяха постоянни опити да импортира код от модула Common, въпреки че той беше видим и без импорти.
• Трябва постоянно да се поддържа проектът в правилно състояние от гледна точка на линтера и тестовете.
• Понякога е по-лесно да започнеш изпълнението на задачата отначало, отколкото да се опитваш да разбереш какво не е наред с текущото решение.
• Поддръжката на картинки в cursor е страхотна функция за обяснение на проблеми. Напълно възможно е да се решават дори въпроси на подравняване и други GUI проблеми. Правиш скрийншот, ограждаш проблемното място, качваш в IDE. Ако LLM не се обърка с това от какво се състои отстоянието, може и да го поправи 😉
• Следващият път, ако реша да разработвам от нулата в непозната инфраструктура, това ще бъде:
  • много внимателен избор на тулинг с максимална валидация и ясни съобщения за грешки
  • максимално детайлно ТЗ, което ще се актуализира постоянно (възможно е да си струва да се откажем от architecture.md и implementation.md от memory bank)
  • кратък и разбираем за модела цикъл change/test с ясни съобщения за грешки

Но въпреки всичко приложението е написано и:

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