• „Както и да интегрираме ИИ, накрая всеки ред код трябва да бъде прочетен от човек.“

 

• „Пълно безумие е да вярваме, че генерален ИИ може да бъде постигнат с големите езикови модели.“

 

• „Светът, такъв, какъвто го познавахме, е мъртъв и няма да се върне.“

 

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

На 29 август се задава 10-ото юбилейно издание на най-мащабното според мен ежегодно ИТ събитие – DEV.BG All in One. „AI: Adopted or Addicted“ – усвояваме или се пристрастяваме към ИИ, пита в мотото си тазгодишното издание, на което лектор е днешният ни гост.

В прелюдия към прелюбопитната му лекция се срещаме, за да поговорим за софтуерния свят днес. Предварително се извиняваме за чуждиците, които са неизбежни, и… никак не се извиняваме за искрения и провокиращ разговор в търсене на големите въпроси пред ИТ бранша в ерата на ИИ.

Как се промени ИТ светът, какво се задава и как да оцелеем в бурята?

---

– „Чичо Боб“ Мартин неотдавна написа, че вече не чете кода си. Доста от водещите авторитети говорят за това, но спомена ли го като идея пред някои колеги, работата отива почти на бой. Какво мислиш по тази тема?

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

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

След 20 години ще сме загубили умения много активно!

Винаги давам примера с ракетата „Сатурн-5“. И сега американците искат да отидат на Луната, направиха „Артемис“, а хората се чудят защо е нужна напълно нова ракета при условие, че „Сатурн-5“ няма нито един провал. Защо не вземат нея за основа, да обновят материалите, да минат през новите инженерни практики, да се спестят няколко милиарда долара в разработка? Отговорът е, че технологията е загубена.

Хората, които са я правили, вече ги няма. Те са оставили документацията, но не са оставили знанието. И няма как да бъдат репродуцирани.

 

I’m significantly older than you. I started coding in the late 60s. My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit…

— Uncle Bob Martin (@unclebobmartin) July 23, 2026

 

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

– Един-два непълни комплекта двигатели на „Сатурн 5“ и това е. Всичко останало са тънкости в занаята, които просто са загубени и единственият вариант е да ги изградиш наново.

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

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

 

– Все пак наистина ли трябва да четем всеки ред код, написан от агентите, ако проектът е важен, но някои негови части не са критични? Аз например съм фронтенд програмист и не мисля, че има големи области от кода, за които това важи.

– Съжалявам да го чуя, но… фронтендът обикновено е първото звено на кибератака. Открадване на cookie, XSS, DDoS атаки. Ето това е проблемът на целия менталитет. Казах го преди няколко години.

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

Ясно е, че всеки иска да взима заплатата, без да пипа нищо, обаче… Създава се много тежък прецедент.

Технически деградираме. Абсолютно всички деградираме! Няма кой да научи новите, започва да се губи знание.

В един момент имаме модели, които не знам какво правят. В следващ тези модели „откачат“ и започват да хакват други платформи, както в новините отскоро.

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

 

 

– Доста хора обаче са на мнение, че просто се вдига нивото на абстракция. Че агентните системи вече са достатъчно добри, за да им се доверяваме за всичко, случващо се под повърхността, в компютърния код. И дават пример с това, че днес почти никой не знае езици на по-ниско ниво като асемблер, а не е и нужно. Може пък агентите да се окажат и много по-добри по отношение на киберсигурността – уж затова беше спрян един водещ модел – Mythos. В крайна сметка и програмистите далеч не винаги са перфектни.

– Хората, които си мислят, че асемблер не се използва, са в голяма грешка. За правене на уебстраници не се използва, но нека любезно да им кажем да си разширят мирогледа, не всичко е Node.js. Най-критичните компоненти по световната инфраструктура са чист асемблер. Ще дам пример. Наскоро излезе един много интересен хак за Linux Kernel-а, който ти позволява да пробиеш системата. Отваряш два handler-а и го подменяш в точно определено време, така получаваш контрол над машината. Това нещо е било изтървано от абсолютно всички системи, включително Mythos, който одитира Linux Kernel.

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

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

Но всички тези модели, които виждаме в момента, са лимитирани до това, което вече е намерено, а не откриват нови пропуски в сигурността.

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

От две години обяснявам, че сме в пика на LLM-ите, и се оказах прав. Те не са мръднали кой знае колко нагоре.

 

– Дали наистина е така? Факт е, че не говорим за някакви коренно нови подходи, но във всяка една област платформите стават по-добри, достатъчно е да видим как се промени нивото на писане на код за тези две години.

– Отдавна сме в пика. LLM-ите няма да стигнат нивото на генерален ИИ. Кой каквото и да казва, това е инструмент, който никога няма да надмине човешките възможности. Затова и всички се отказват от тях, включително и оригиналните създатели на transformers моделите.

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

Там изглежда, че има някакъв прогрес.

Започват да помагат, но това е резултат от тясна специализация заедно с множество външни инструменти. Самите LLM-и стават по-бързи, заемат по-малко ресурси, тренират се на повече примери, но прогрес по отношение на генерализация, креативност и подобни няма.

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

 

 

– Дали обаче това е обща тенденция? В технологичния сектор не изглежда тя да се обръща, съкращенията си вървят.

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

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

Това е нормализирането на пазара, процеси, които отнемат 2-5 години, за да се стабилизират.

Другият проблем е, че голяма част от младите по-трудно влизат. Защото процесът е като махало – като се засили от единия край, му трябва няколко пъти да се разклати наляво-надясно, докато застане по средата. Младите ще страдат още няколко години от това, че фирмите взеха твърде много хора. В целия западен свят всеки си е стегнал бюджетите и не наема повече. Гледа да оптимизира с това, което има. Инфлацията скочи твърде много и има твърде голяма несигурност.
Тоест, в момента младите са попаднали в една „перфектна буря“ – лоши икономически очаквания, стагнация, международна несигурност.

И това ще отмине, но нека не губят това време а да развиват умения!

 

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

– Моделът може да свърши работа, но ще ти дам един пример, реален експеримент. Един и същ сетъп, една и същата задача, едни и същите инструменти, даваме ги на синиър, мид и джуниър. Използвайте тези инструменти, това е целта. Синиърът след 15 минути е готов, буквално с една итерация. На мидлевъл програмиста му трябват 3, 4, 5 итерации, малко повече време, но пак докарва задачата горе-долу до същото ниво.

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

LLM-ите са инструмент. И като всеки друг инструмент, на теб ти трябва ниво на знание, за да го използваш. Ако не знаеш даже какъв въпрос да зададеш, нищо не може да ти помогне.

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

Незнанието на младите как да работят с тези инструменти води до доста интересни ситуации, като примерно да пуснеш GPT 5,5, за да ти смени H таговете на един темплейт и да го оставиш без надзор. И като се върнеш от кафе почивката да видиш, че е зациклил, отклонил се е и е издухал $700. Реален случай!

 

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

– Точно за това ще говоря на конференцията DEV.BG All in One, ще дам няколко практични съвета. Защото хората трябва да вземат нещата в свои ръце. Няма генерални промени в процесите, има такива в инструментите. Не мога да разбера защо доказани практики от над 50 години се отхвърлиха.

Ясно е, че всички в ИТ сектора използват вече ИИ. Все едно някой да те пита в миналото използваш ли IDE. Подразбира се, очаква се, че имаш някакви умения.

Научете инструментите, както едно време учехме VIM и Emacs!

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

а много хора не го разбират.

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

 

 

– Според мен и самите компании все още не знаят как точно да подходят и се ориентират в мътните води и в поставянето на граници.

– Ориентираха се вече. Поне повечето, ще мине още малко време, преди да се стабилизира всичко.

 

– Как? Ако няма лимити за моделите, стигаш до случаи като този, който разказа. Как точно подготвяш хората? Как им създаваш рамката? Ако се върнем в началото, кога трябва да се чете всеки ред код и кога – не?

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

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

Първоначално инвестицията е голяма, защото най-успешните компании, които са имплементирали ИИ, ползват основно локални модели. Така имат сигурност, че поведението на модела не се променя, той е под техен контрол, а и заради сигурността на данните. Още една причина е, че когато започне този процес, се откриват повтаряемите грешки и се елиминират – например в стила на писане, именуването на променливи. В един момент моделът, когато не се променя през два дни, ако е от външна компания, започва доста добре да се съобразява с тези правила.

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

 

– А какво мислиш за производителността? Как човек да насмогне на хилядите редове код във всеки merge request?

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

Преди две години, на лекцията си за DEV.BG казах, че работата,

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

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

Разбира се, има хора, които пускат изцяло 100% агенти, те генерират 1 милион реда код. Но това е сериозен знак за проблем. Ако моделът започне да ти пуска стотици хиляди редове, нещо тотално не е наред. Трябва да си видиш пайплайна, промптове, модела, harness-а, дефиницията на задачата и така нататък. Това е част от код ревюто, просто трябва да го спреш в такъв момент.

Един добър модел трябва да генерира същото количество код, колкото един добър програмист.

Ако тази задача добър програмист ще я направи с 1000 реда код, моделът също трябва да я направи с 1000-2000 реда.

 

 

– Дали обаче редовете са чак толкова показателен критерий винаги?

– Искам да кажа нещо много важно.

Не третирайте LLM-ите като по-добри програмисти от тези, които имате!

Не си мислете, че моделът е по-добър от всичко, което сме направили до момента. На моменти може да изглежда, че е така, той е и по-бърз. Но не е по-добър!

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

Не става така! Ако си с този подход, умрял си като компания!

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

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

 

– Именно за такъв тип обучения и подготовка говоря, че повечето компании така и не стигат дотам.

– Ако ги оставиш на базовите настройки, гледай какво става! Това е друга причина страшно много хора да избират да работят на локални модели, оказва се, че 60% от качеството на генерирания код е harness-ът, не моделът.

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

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

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

Мързел ли е? Глупост ли е?

Глупост не е, защото твърде много хора го правят. Толкова умни хора, които познавам. Има някаква колективна психоза покрай цялото нещо, в която има много аспекти.

Бизнес аспект, личностен и какъв ли още не. И като се паникьосваш, действаш по инстинкт. Но вече мина време, нещата започват да улягат. Върни се в реалността!

 

– Отново за лесното делегиране на знания – каква е твоята лична рецепта да си ги опазиш? Аз също усещам, че ставам по-„слаб“ програмист с всеки следващ ден, в който почти не пиша код.

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

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

Огромна част от итерациите ми с ИИ са точно в тази посока. По принцип не бях привърженик на test-driven development, но в случая с ИИ съм и за него. Давам му задачи, следя как се движи. И като виждам нещо, просто му казвам, че не е така. По този начин не губя разбирането какво се е случило. Трябва да си в цикъла. Просто трябва да си в цикъла на разработка, но не и да гледаш всяка буквичка и знак в кода.

Ако си настроиш LLM-а да пише чисти функции, които са unit tested, може да не обръщаш толкова внимание на конкретната им имплементация и стилистика. Но как тази функция взаимодейства с другите – това никой не трябва да го изпуска от контрол. Нещата ескалират доста бързо. Имаше една популярна публикация за pull request, който изтрива 4 милиона реда код и ги замества с 20 000.

 

– Според мен обаче всички неща, които спомена, са напълно по силите на ИИ. Виждал съм много хора да пишат по-нечетим код, с пропуски от този тип, отколкото допуска Claude Code.

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

архитектурата и фактическото писане на код са различни неща.

Ще ти дам пример с един клиент, който работи с огромни заявки, на ден минава цял петабайт! Не гигабайт, не терабайт. Мултимилиардна компания. Трябваше да направи много сложна заявка и, разбира се, използваха ИИ и сработи. Бавно, много данни минават, ще чакаме…

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

 

– Всеки разговор с теб дава много поводи за замисляне, пък понякога и за когнитивен дисонанс.

– Понякога има полезен когнитивен дисонанс, много хора минават през него. И аз минах през това, когато цялата тази работа започна да навлиза масово. Отначало отказвах да ползвам тотално какъвто и да е harness и агент за код, дълго пишех кода само на ръка, старата школа и нещата си вървяха.

Но в един момент започнах да осъзнавам, че ставам неадекватен, че изоставам, че нещата са се променили много.

И понеже разбирам LLM-ите, но нямах такова детайлно познание за агентите върху тях, при първите ми тестове изпаднах в когнитивен дисонанс абсолютно отвсякъде.

Човек трябва да премине през него и чак след това може по-смело и обективно да гледа на нещата.

 

– Сигурен съм, че и в лекцията си на All in One ще го предизвикаш у доста хора. Определено ще съм там, за да гледам и слушам.