Craftify
Компилира се — значи работи
Експериментът с “vibecoding” може да се счита за завършен. Целта на експеримента беше да се оцени доколко жизнеспособен е този метод на разработка, колко ефективен може да бъде и какви са неговите ограничения.
Като тестова задача избрах разработката на iOS приложение. Първо, защото не съм се интересувал от iOS разработка през последните 10 години. Второ, защото действително имах нужда от такова приложение. Основната му идея е да автоматизира рутинни операции с помощта на LLM. В моя случай това означава коригиране на моите недодялани текстове на английски и украински, преводът им на английски и български, както и обобщаване на уеб страници. Вече бях сглобил нещо подобно за Raycast за една вечер. Така че истинското предизвикателство беше именно iOS разработката. И тази част трябваше да бъде изцяло поета от LLM, с минимална помощ от моя страна.
Ето и крайният резултат: успях да създам приложението за 60 часа. То работи и изпълнява задачата си. Има 6 екрана, персонализиран потребителски интерфейс и около 6500 реда Swift код (според cloc). Има около дузина нерешени проблема, но нищо критично. Качено е в TestFlight, така че мога да го споделя оттам. Вероятно обаче няма да премине прегледа в App Store поради несъответствие с насоките им :)
Заключения:
- В никакъв случай не бих могъл да изградя такова приложение сам за 60 часа. Щеше да се наложи да науча твърде много неща.
- Загубих около 15 часа в борба с xcodegen, създаване на инструменти около него, интегриране на swiftlint, swiftformat и т.н. Ако бях избрал Tuist от самото начало, вероятно нямаше да губя часове за тривиални неща като „приложението не се показва в share sheet поради грешна вложеност в YAML“ или „иконата на приложението не се появява поради печатна грешка в името му“.
- От друга страна, ако не бях се опитал да настроя среда, в която всичко се стартира чрез CLI, все още щях да се ровя в бутоните на Xcode, следвайки уроци.
- Това подчертава важността на изграждането на възможно най-бърз цикъл на промяна/тест за LLM — чрез CLI или може би MCP. Колкото по-бърз е той и колкото по-добри са съобщенията за грешки, толкова по-бързо върви разработката.
- Наличието на някои основни концептуални познания би ускорило нещата значително, помагайки за избягване на грешки и „кръпки“.
- Моделът няма усет за обобщаване на съществуващия код. Опитният разработчик често интуитивно усеща къде да заложи абстракции, за да предвиди бъдещи промени (така нареченият „технически буфер за бъдещи хакове“). Имах постоянна инструкция към LLM да предлага два начина за подобряване на кода в края на всяка задача — и нито веднъж тя не предложи нищо смислено на архитектурно ниво. Трябваше специално да изисквам архитектурни прегледи, за да получа действително полезни предложения.
- Трябва постоянно да прецизирате инструкциите си, добавяйки често срещани грешки, нови изисквания и т.н. И дори това не помага по време на дълги сесии — моделът започва да „забравя“ по-ранния контекст. В моя случай той постоянно се опитваше да импортира код от модула Common, въпреки че той вече беше видим без импорти.
- Проектът трябва постоянно да се поддържа в валидно състояние по отношение на линтера и тестовете.
- Понякога е по-лесно да започнете задача от нулата, отколкото да разберете какво не е наред с текущото решение.
- Поддръжката на изображения в Cursor е убийствена функция за обясняване на проблеми. Можете дори да решавате проблеми с подравняването на потребителския интерфейс и оформлението по този начин. Правите екранна снимка, подчертавате проблемната област, качвате я в IDE — и ако LLM не се обърка за това какво причинява проблема с разстоянието, може дори да го поправи ;)
- Следващият път, когато се впусна в разработка от нулата в непозната инфраструктура, ще:
- внимателно избера инструменти, които предлагат максимална валидация и ясни съобщения за грешки,
- подготвя изключително подробна спецификация, която постоянно се актуализира (може би ще премахна
architecture.mdиimplementation.mdот паметта), - настроя кратък и удобен за модела цикъл на промяна/тест с ясна обратна връзка за грешки.
Все пак приложението е написано и:
- работи с посочения OpenAI ключ,
- превежда, опростява, обобщава и коригира грешки,
- и да, може дори да превежда на клингонски.