Д-р Христо Лесев: Най-опасната илюзия на vibe coding е, че прототипът е завършен продукт

Изкуственият интелект все по-често обещава, че всеки може да създаде собствено приложение, сайт или дигитален продукт без сериозни технически познания. Инструментите за т.нар. vibe coding действително правят разработката по-достъпна от всякога, но поставят и нови въпроси – къде са границите на AI, кога един работещ прототип се превръща в устойчив продукт и може ли технологията да замени експертизата на специалистите?

По тези теми разговаряме с д-р Христо Лесев – основател и изпълнителен директор на българската ИТ компания Diadraw. Завършил е специалност „Информатика“ в Пловдивския университет „Паисий Хилендарски“, където защитава и докторска степен в областта на компютърната графика – негова дългогодишна професионална страст.

За Христо програмирането е преди всичко занаят – умение, което трябва да създава стойност и да решава реални проблеми. Именно тази философия стои и зад разработените от екипа на Diadraw решения AI Estimator и Vibe Coding Deep Audit. Първото помага на предприемачи и организации да структурират и валидират идеите си още преди разработката, а второто дава експертна оценка на продукти, създадени с помощта на AI, преди те да достигнат до реални потребители.

В интервюто говорим за възможностите и ограниченията на vibe coding, за най-честите грешки при AI-създадените продукти и за това защо, въпреки бързото развитие на технологиите, човешката експертиза остава незаменима.

През последните години vibe coding се превърна в една от най-обсъжданите теми около изкуствения интелект. Все повече хора създават дигитални продукти без сериозен технически опит, а обещанието е, че AI може да поеме голяма част от работата. Реалистични ли са тези очаквания?

Зависи какво очакваме от технологията. Хората са казали, че „цвят кола не кара“. Може да имаш много хубаво изглеждаща кола, която отвън е впечатляваща, но ако двигателят не е подходящ за това, за което ще я използваш, рано или късно ще стигнеш до проблем. Същото важи и за софтуера. Много често нещо изглежда добре, работи на пръв поглед и дори създава усещане за завършен продукт, но в крайна сметка се оказва, че не върши работата, за която е създадено.

При vibe coding има една особеност. Много хора започват с очакването, че изкуственият интелект е по-умен от тях и ще може да взема решения вместо тях. Според мен това е заблуда. AI е изключително добър помощник и може да спести огромно количество рутинна работа, но не може самостоятелно да взема правилните решения без насоката на човек, който разбира материята.

Тогава как трябва да гледаме на изкуствения интелект?

Като на нов колега. Представете си, че във фирмата идва човек на първия си работен ден. Той може да има добри технически познания, но все още не познава начина, по който работите, процесите, стандартите и спецификите на продукта. Никой не би го затворил сам в стая с думите: „Имаме нужда от продукт за медицински центрове до утре. Измисли всички детайли и ми дай готово решение“.

В реална работна среда това звучи абсурдно. Забелязвам обаче, че много хора правят точно това, когато работят с изкуствен интелект. Дават му минимален контекст и очакват той сам да измисли всички подробности, да вземе всички решения и да създаде качествен продукт.

Според мен AI трябва да се третира като колега, който тепърва се учи как работи организацията. Трябва да бъде обучен, трябва да получава достатъчно информация и трябва да бъде насочван. Колкото по-добре го направиш, толкова по-добри ще бъдат резултатите.

При vibe coding идеята е AI да свърши голяма част от работата, докато ти го направляваш. Въпросът е, че много хора не знаят къде е границата – колко информация трябва да дадат, какво трябва да опишат и за кои решения могат да разчитат на AI.

Затова напоследък все повече хора започват да работят по това, което аз наричам coding by specification.

Тоест говорим за добре разписана спецификация още преди да започне същинската разработка?

Точно така. И останалата част не е просто да водиш разговор с ChatGPT или с някой друг модел. Идеята е да имаш различни агенти, които разглеждат заданието от различни гледни точки.

Например един агент може да прегледа заданието, друг да започне да задава неудобни въпроси и да търси пропуски. Още преди да е написан какъвто и да е код, той те кара да се замислиш дали наистина си описал достатъчно добре това, което искаш да създадеш. Има ли неясноти? Има ли неща, които приемаш за даденост, но всъщност никъде не са описани?

След това друг агент може да подготви структурата на проекта, следващ да я провери, а накрая човек да валидира дали са спазени всички стандарти и изисквания. Всъщност тези агенти се обучават по абсолютно същия начин, по който се обучава нов колега в компанията. Той може да разбира от програмиране, но в първия си работен ден няма как да познава всички процеси, стандарти и добри практики, които са необходими, за да се създаде качествен продукт.

Вие всъщност пренесохте ли тази логика и в работата си с AI?

Всъщност AI Estimator се появи първоначално като инструмент, който да подпомогне собствената ни работа. От повече от петнадесет години работим по софтуерни проекти и през това време сме видели много добри идеи, които така и не стигат до реализация. Не защото самата идея е лоша, а защото не е достатъчно добре структурирана и хората не успяват да си отговорят на най-важните въпроси още в началото.

Затова обучихме различни AI агенти, които да разглеждат една идея от различни гледни точки. Един анализира пазара и конкурентната среда. Друг се фокусира върху продукта и потребителите. Трети разглежда техническата реализация и възможните рискове.

Целта не е да се даде готов отговор, а човек да получи по-ясна картина за това какво всъщност иска да създаде. Накрая цялата информация се обобщава в структуриран доклад, който описва пътя от идеята до реализацията – какви са основните етапи, какви ресурси ще бъдат необходими, какви рискове съществуват и какво би струвала разработката и поддръжката на подобен продукт в дългосрочен план. По този начин хората могат да валидират идеята си много по-рано и да вземат по-информирано решение дали и как да продължат с нея.

От наблюденията ви какви проекти се опитват да създават хората най-често? Има ли нещо характерно по отношение на това къде започват проблемите и какво най-често остава непреценено?

Най-често виждаме хора, които се опитват да създадат решения за реални ежедневни проблеми. Много от проектите са свързани с автоматизация на документи, автоматизация на повтарящи се задачи или оптимизация на различни бизнес процеси.

Интересното е, че при нас достигат и доста по-сложни проекти. Наскоро например разглеждахме решение за оценка на индустриални имоти. Идеята беше много добра, защото в тази сфера има огромно количество ръчна работа, която потенциално може да бъде автоматизирана.

Това, което наблюдаваме обаче, е че AI инструментите работят много добре, докато задачата е сравнително проста. В момента, в който проектът започне да става по-сложен, започват да се появяват решения, които на пръв поглед изглеждат логични, но създават проблеми в дългосрочен план.

Например нещо, което може да бъде реализирано като една услуга, изведнъж е разделено на десет различни услуги. От гледна точка на кода това може да изглежда модерно и добре организирано, но всяка от тези услуги трябва да бъде поддържана, наблюдавана и хоствана. Вместо една машина да върши необходимата работа, се оказва, че трябват десет. А това означава и десет пъти повече разходи.

Друг често срещан проблем е, че решенията започват да се изграждат на парче. В една част на проекта са спазени добри практики за сигурност и скалируемост, а в друга – не. Когато разглеждаме подобни системи, понякога имаме усещането, че са разработвани от двадесет различни екипа с двадесет различни идеи за това как трябва да изглежда продуктът. Отделните части работят сами по себе си. Проблемът идва, когато трябва да работят заедно. Тогава започват да се появяват несъответствия, затруднения при поддръжката и проблеми с развитието на продукта.

Тоест на практика продуктът изглежда завършен, но реално не е подготвен за следващия етап от развитието си?

Точно така. Много хора стигат до добре изглеждащ прототип и остават с впечатлението, че най-трудната част е зад гърба им. Истинските въпроси обаче започват тогава.

Ще може ли този продукт да обслужва повече потребители? Ще издържи ли реално натоварване? Ще може ли да се развива във времето? Няма ли да генерира неочаквано високи инфраструктурни разходи? Има ли рискове за сигурността?

Това са въпроси, които рядко се виждат в началото, но точно те определят дали един продукт ще остане просто интересен прототип или ще се превърне в устойчив бизнес.

Спомена част от проблемите, които виждате при такива проекти. Как точно помагате на хората, които вече са стигнали до работещ продукт, но не са сигурни дали е готов за реална употреба?

Именно заради такива случаи създадохме Vibe Coding Deep Audit. Виждаме все повече хора, които успяват сами да стигнат до работещ продукт с помощта на AI. Това само по себе си е страхотно, защото им позволява много по-бързо да валидират идеите си и да стигнат до първа версия.

Проблемът е, че в един момент им трябва увереност какво всъщност са създали. Не просто дали работи, а дали е изградено по начин, който ще им позволи да го развиват спокойно занапред.

Точно това е ролята на одита – да даде независима експертна оценка и да покаже както силните страни на решението, така и местата, които биха създали проблем на по-късен етап.

По този начин човек може да вземе информирано решение какви са следващите стъпки и дали има неща, които е добре да бъдат подобрени, преди продуктът да започне да расте.

След всичко казано дотук за кого всъщност е подходящ vibe coding?

Според мен това е страхотен инструмент за хората, които искат бързо да валидират една идея. Той ти дава възможност да създадеш прототип за кратко време, да го покажеш на реални потребители и да получиш първа обратна връзка. Това е изключително ценно, защото ти помага да изчистиш идеята си още преди да си започнал сериозна разработка.

Ако трябва да направя аналогия, vibe coding е като инструментите за интериорен дизайн, с които можеш да подредиш мебелите в едно помещение и да видиш как ще изглежда крайният резултат. Можеш да експериментираш, да пробваш различни варианти и да изясниш какво искаш. Когато обаче дойде време за истинския строеж, тогава се обръщаш към архитект, инженери и строителна компания. Същото важи и тук.

Да разбираме ли, че според теб AI не отменя нуждата от експерти?

Изкуственият интелект е много добър помощник. Аз често го сравнявам с чирак. Можеш да го обучиш, можеш да му възложиш много задачи и той може да ти спести огромно количество време. Но поне към момента не може да замени човек, който има години практически опит зад гърба си. Опитът е безценен, защото идва от реални проекти, реални проблеми и реални решения.

Както един художник не разчита четката сама да нарисува следващото произведение, така и ние не можем да разчитаме AI сам да създаде продукта, с който искаме да променим света.