Когато умната система се проваля по тъпи причини

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

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

Каквото трябваше да проработи

Стекът се състоеше от три компонента, представящи най-съвременното в локалната AI разработка: CLI за писане на код, независим от доставчика на модела; Ollama, който сервира OpenAI-съвместим API от локален хост; и Qwen3.8 27B, работещ локално. За ориентир — това не е някаква оскъдна конфигурация. Моделът от 27 милиарда параметъра (17GB) се побира удобно в 32GB унифицирана памет и поддържа tool calling с прилични способности за разсъждение.

Първоначалните резултати бяха обещаващи. За около петнайсет минути агентът беше произвел пълна HTML структура и почти 200 реда CSS в стил NES с вдлъбнати ръбове и подходяща цветова палитра. По-впечатляващото беше, че агентът хвана собствена грешка в движение: написа файл, прочете го отново, забеляза несъответствие между това, което възнамеряваше, и това, което се получи, и го оправи без подканване. Това е истинско агентично поведение и подсказваше, че моделът е готов за задачата.

След това агентът се опита да запише файла с логиката на играта и всичко спря.

Спиралата на смъртта

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

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

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

Какво всъщност показваха логовете

Когато се върнах към логовете на сървъра, историята беше съвсем различна. Нямаше нито една грешка от типа "out of memory" в нито един от тях. Свободната системна памет седеше удобно между 21 и 27 гигабайта през цялото време, при модел от 17 гигабайта. Паметта никога не беше проблемът.

Истинският проблем беше несъответствие в конфигурацията, което не произвеждаше видима грешка. Конфигурацията на агента рекламираше контекстен прозорец от 32,768 токена. Но Ollama сървърът беше рестартиран с таван от 8,192 токена и това разминаване остана незабелязано. Агентът щастливо планираше файл от 800 реда да бъде написан на един път, защото според него разполагаше с 32k пространство. Когато действителното генериране удареше стената от 8k по средата на tool call-а, връзката се прекъсваше без съобщение за грешка, върху което агентът да разсъждава.

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

DevOps дисциплината, която AI разработката изисква

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

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

Практическият извод за разработчиците, които проучват локални AI агенти за писане на код, е прост: валидирай средата си толкова старателно, колкото би валидирал production deployment. Провери дали конфигурацията на агента съответства на твоите runtime параметри. Чети сървърните логове, не само изхода на агента. Разбери какви функции архитектурата на твоя модел реално поддържа — спрямо това, което инструментариумът се опитва да активира.

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

Tetris build-ът накрая успя. Отне четири и половина часа в рамките на два дни, произведе чист код в три файла и функционира правилно. Но поуките дойдоха не от успеха, а от разбирането защо се случиха провалите — и от осъзнаването, че понякога най-скъпите проблеми нямат нищо общо с интелигентността.