Проблемите, генерирани от вибрационното кодиране, които обсъдихме в предишни статии, са достатъчно сериозни, за да станат причина за следващата голяма компютърна катастрофа. Време е да преминем към програмиране с изкуствен интелект, което включва по-професионален (и по-малко рисков) подход. Идеално е, когато имате нужда от програми в ситуации, изискващи сигурност и стабилност.
В тази статия ще започнем с обсъждане на най-често срещаните проблеми с вибрационното кодиране и защо, въпреки шума, вдигнат от някои промоутъри, то не представлява новата индустриална революция. В следващите раздели ще разработим процедурата за преминаване от vibe кодиране към AI-асистирано програмиране в Linux.
Проблеми с вибрационното кодиране
Да вземем един пример: Двама души отиват в луксозен ресторант. Единият не разбира нищо от готвене, другият е експерт-готвач. Първият знае само какво иска да яде и най-много ще прецени качеството на сервираното по цената или по това, което му подсказва неопитното му небце. Вторият ще може да различи дали са използвани пресни съставки, дали подправките са използвани в правилните количества и дали му таксуват прекалено много.
Не е случайно, че използваме ресторант като пример. Андрей Карпати, експерт по изкуствен интелект, е един от съоснователите на OpenAI и директор на отдела за изкуствен интелект в Tesla. Желаейки да реши проблема с това да не знае какво да поръча, той създаде приложение, използващо вибрационно кодиране, което показва снимка на ястията. Ето как той описва преживяването си:
„Създаването на MenuGen с vibe код беше забавно като локална демонстрация, но доста трудно като истинско приложение. Изграждането на модерно приложение е като сглобяването на мебели от IKEA на бъдещето: много услуги, API, конфигурации, ограничения и цени.“ Специалистите по право имат остарели знания, правят фини грешки и халюцинират. И най-смешното е, че почти не прекарах време в кодиране, а по-скоро конфигурирах услуги в браузъра. Всичко това дори не е достъпно за LLM специалист. Как се очаква да автоматизираме всичко до 2027 г. по този начин?
Нека разгледаме по-подробно какво се е случило с Андрей, който, между другото, Той не е уеб разработчик, което вероятно го е накарало да направи нещата по-сложни от необходимото.
„Използвах Cursor + Claude 3.7, дадох му описание на приложението и той написа всички компоненти на фронтенда в React много бързо, изграждайки красив уебсайт с меки многоцветни шрифтове, малки CSS анимации, адаптивен дизайн и всичко останало, с изключение на самата функционалност на бекенда.“
Фронтендът и бекендът са двете страни на една и съща монета в дизайна на приложенията. Фронтендът е частта, с която потребителите взаимодействат, докато бекендът е мястото, където се обработва и съхранява информация. Фронтендът работи локално, докато бекендът обикновено е разработен на външен сървър.
Клод е, поне сред феновете на vibe кодирането, Великият моделен език на момента. Причините за това са по-скоро идеологически, отколкото технически. Anthropic, компанията, която го разработва, влезе в конфликт с Пентагона заради неконтролираното използване на нейните модели във военните.
Cursor е редактор на код, в който установеният модел на изкуствен интелект действа като спътник в програмирането. По-късно ще поговорим за това как да инсталирате Cursor на Linux.
React е библиотека за създаване на динамични графични интерфейси. Не съм запознат с приложението, така че не мога да преценя дали използването на React е подходящо, но въз основа на моя собствен опит с vibe кодирането, моделите са склонни да използват библиотеки за неща, които биха могли да се направят перфектно с чист HTML, CSS и JavaScript.
Нещата започнаха да се усложняват за Карпати в бекенда. Тяхното приложение започва със снимка на менюто и използване на оптично разпознаване на символи, за да търсят подробности за всяко ястие. Нека видим тяхното описание на случилото се:
„Тук започнаха някои проблеми. Трябваше да извикам OpenAI API, за да извърша OCR на елементите от менюто от изображението. Трябваше да получа API ключовете. Навигиране в донякъде сложни менюта за „проекти“ и подробни разрешения.“ Клод беше изумен от остарелите API, имената на моделите и наскоро променените конвенции за вход/изход.Това беше объркващо, но беше решено след няколкократно копиране и поставяне на документацията. След като API извикванията заработиха, веднага се натъкнах на някои доста строги ограничения на скоростта, които ми позволяваха да правя само няколко заявки на всеки 10 минути.
Това е класически пример за склонността на моделите да използват оръдие, за да убиват мухи. Разпознаването на изображения от менюто можеше да се извърши с локална библиотека като Tesseract.js
Tesseract.js е базиран на едноименния инструмент на Google и поддържа над 100 езика. Може да се използва безпроблемно от браузъра и най-важното е, че не консумира токени, не изисква API ключове и няма ограничения.
За съжаление, няма решение за халюцинациите, причинени от остарели API и работа с остаряла документация. Освен че се учат да програмират и не използват автоматизирани инструменти.
Той имаше подобни проблеми с втората част на приложението: преобразуването на описанието на всяко ястие в изображения.
"Регистрирах се, получих ключ за репликативен API и се сблъсках с подобни проблеми. Заявките не работеха, защото знанията за LLM бяха остарели, а този път дори официалната документация беше малко остаряла поради скорошни промени в API. който вече не връща директен JSON, а стрийминг обект, който нито Клод, нито аз разбирахме напълно. След това отново се сблъсках с ограничения за употреба, което затрудни отстраняването на грешки. По-късно ми казаха, че това са често срещани мерки за борба с измамите, но също така затрудняват стартирането на легитимни нови акаунти. Казаха ми, че Replicate мигрира към модел на предплатен кредит, което може да помогне.“
Андрей би могъл да реши това, без да прибягва до генератори на изображения. Има няколко инструмента, които могат да търсят реални изображения на ястия (избягвайки потенциални илюзии, свързани с изкуствен интелект). Сред тях са два API за бази данни с рецепти: TheMealDB и Spoonacular Food API.
Проблемите не свършиха дотук за нашия приятел, vibe кодера. При качване на приложението във Vercel (платформа, която позволява внедряване и хостване на приложения от хранилище на GitHub) се появиха грешки, които не се появиха локално.Отне ни час, за да осъзнаем, че API ключовете не са качени на сървъра. Опитен програмист би разбрал и би си спестил разходите за токени.
Идеята на автора е да се таксува за използването на приложението (чудя се кой ще плати за нещо, което може да получи безплатно, като попита Gemini или Siri). За целта му е необходимо удостоверяване на потребителя. По предложение на Клод, Karpathy се обърна към друга облачна платформа, известна като Clerk. Clerk обработва всичко необходимо за регистрация и достъп. Нямам възражения срещу това решение.
Проблемът е в това Клод написа кода за остаряла версия на Clerk API и забрави да му каже, че ако иска да го използва в продукцията, му е необходим собствен домейн. Не безплатният, който Vercel предоставя. Трябваше да го купи и конфигурира.
Имаше и усложнения при настройването на платформата за плащане. Когато най-накрая успя да я пусне в производство, той откри, че:
„Цялата обработка се извършваше в реално време, без постоянство. Ако отнемаше твърде много време, се проваляше. Ако обновявахте, губехте всичко. Правилното решение би било база данни плюс система за опашки. Но това означаваше повече услуги (напр. Supabase, Upstash), повече сложност. Твърде много. Оставих го за в бъдеще.“
По-скоро решението е да се научите да програмирате или да платите на някой, който знае какво прави. В следващата статия ще започнем да разглеждаме стъпките за постигане на първото.
