Deep tech от България: какво се променя, когато агентът не може сам да си одобри промяната

Преди две седмици един от AI кодовите агенти, с които работя, пусна git clean -fd върху непочистено работно дърво. Изтри 186 некомитнати тестови файла. Без злонамереност, без класически бъг — просто изпълни командата такава, каквато е.

Този инцидент е причината да съществува процесът, който описвам по-долу.

Аз съм solo founder и строя NEMO — физичен сурогатен модел за мултифизична инженерна симулация — от България. Нямам инженерен екип. Лостът ми са AI кодови агенти, които вършат голяма част от имплементацията, върху комбинация от локален хардуер и EuroHPC компютърно време. Тази комбинация вече не е нещо необичайно. Интересното е какво се чупи, ако ги оставиш без надзор, и какво съм построил, за да не чупят неща, които не виждам навреме.

Компютърният стек е нарочно скромен. Proxmox хост с потребителска RTX 3090 в контейнер върши smoke тестовете — проверката “изобщо тръгва ли”. Self-hosted GitLab е CI авторитетът: нищо не се мърджва без него. Реалните тренировки отиват на EuroHPC Discoverer, петаскейл машината на България, с алокация от 5000 GPU-часа. Опашката на Discoverer дава на всяка задача таван от 4 часа — без изключения, дори когато тренировката иска 40. Затова дългите ранове са верижно рестартирани job-масиви: чекпойнт, нова заявка, продължение, отново. Един скорошен ретрен мина така през 100 000 стъпки, на хапки по 4 часа, защото корпусът и токен-оформлението се бяха променили достатъчно, че продължаване от предишния модел вече не важеше — трябваше да тръгне от нула. Не е елегантно решение по избор — това е, което твърдият лимит на опашката налага, и работи.

Локално MOOSE солверът — истинският FEM двигател, спрямо който се проверява всяко предсказание на сурогата — работи на около 36 секунди на решение, което дава резерв от порядъка на 140 000 решения на ден, ако някога потрябват. Споменавам числото, защото в тази работа времето не се мери в седмици. Мери се в GPU-часове и брой решения. Старая се да не обещавам дати, защото реално не аз ги контролирам — опашката ги контролира.

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

• Всяка промяна се класифицира по риск (ограничена, споделен контракт, или високорискова — auth, миграции, инфраструктура, политика).
• Всяка промяна изисква прясно доказателство — тестове, които реално са се изпълнили, не резюме на тестове, които уж са минали.
• Кодовият агент не може сам да мърджне собствената си работа. Никога. Без повишени права, без bypass флаг.
• За всичко над най-ниския риск мърджването изисква човешки Ed25519 подпис, обвързан с точния commit SHA — не “одобрих клона”, а “одобрих точно това комитнато състояние”. Ребейз, нов комит, амендван комит — одобрението умира, търси се ново.
• Самото право да мърджне седи при изолиран бот, който проверява подписа, резултата от пайплайна и SHA-то точно преди мърджването. Зелен резултат на моя лаптоп не е доказателство за нищо, което системата приема.

Нищо от това не съществуваше преди инцидента с git clean -fd. Не е тук, защото не вярвам на конкретния агент — тук е, защото вярвам на процеса, не на актьора, и го построих едва след като научих, че ми трябва.

Два по-малки урока станаха твърди закони, платени скъпо. Първо: double precision на всеки FEM solve път, преди да е създаден какъвто и да е масив. Едно зле обусловено решение с penalty гранични условия може да носи число на обусловеност около 10^12, докато float32 дава около 10^7 точност — шест порядъка недостиг. Резултатът не е леко неточен, той е произволен, а обичайните проверки не го хващат, защото проверяват грешното нещо. Второ: преди да сравняваш два модела, изравни параметрите на изсемплирване на данните им. Веднъж сравних модел с 8192 точки на форма срещу базов модел, обучен на 200 000 — и получих уверен, напълно грешен извод кой е “по-добър”. Двата корпуса просто не мереха едно и също нещо; сравнението беше бъгът.

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

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