Изграждане на Pi с Pi: Ерата на AI и натискът върху отворения код

В личния си блог известният разработчик Армин Ронахер сподели критични наблюдения и практически опит от работата си като поддържащ на проекта Pi – минималистичен AI агент за кодиране. Инструментът за автоматизирано програмиране сега е част от организацията Earendil, но негов основен създател остава Марио Зехнер. За разработването на Pi екипът прилага класическата практика на „dogfooding“ (самозахранване), използвайки самия агент за промени по неговия собствен код [1].

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

„Dogfooding“ и променената роля на списъка с проблеми

Практиката да се изгражда Pi с помощта на Pi променя фундаментално начина, по който разработчиците взаимодействат с платформата GitHub. Традиционно списъкът с проблеми (issue tracker) служи за директна комуникация между потребителите и поддържащите софтуера. При работа с AI агенти обаче, тези описания започват да изпълняват нова роля – те се превръщат в директни инструкции (prompts) за сесиите на агента.

Когато разработчикът иска да отстрани дефект, той подава описанието на проблема на своя AI агент (наричан разговорно в блога „clanker“) с очакването машината да го разбере, да го възпроизведе, да инспектира кода и да предложи корекция. Поради тази причина структурата и качеството на написаното в доклада за проблем придобиват критично значение за успеха на автоматизираната сесия [1].

Проблемът с AI спама: Доклади от „5% човек и 95% машина“

Вместо да улесни процеса, масовото навлизане на генеративен изкуствен интелект е довело до появата на нов тип нискокачествен трафик, който Ронахер определя като AI slop (машинен спам). Поддържащите се сблъскват с огромен брой доклади, които са съставени от 5% човешко наблюдение и 95% генериран от машина текст. Потребителите просто взимат някакъв софтуерен симптом, изпращат го към езиков модел и след това публикуват готовия пренаписан отговор в GitHub.

Тези доклади се характеризират с няколко основни дефекта [1]:

• Техническите заключения са поднесени с изключителна увереност, но са погрешни по същество.
• Правят се необосновани предположения за първопричините (root causes) за проблемите.
• Генерират се неработещи или фиктивни минимални примери за възпроизвеждане (repros).
• Предлагат се сложни и неподходящи стратегии за имплементация.
• Правят се погрешни аналогии с други части от кода, които нямат общо с дефекта.

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

Командата /is и необходимостта от независимо потвърждение

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

За да се справят с това поведение, разработчиците на Pi внедряват специална команда /is (за анализ на проблеми) в работната среда. Тя съдържа твърдата инструкция:

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

Въпреки това Ронахер признава, че това решение не винаги работи. Причината е, че машината, пренаписала първоначалния проблем, разширява обхвата му твърде рано, превръщайки ясен и конкретен бъг в сложен лабиринт от хипотези. Затова авторът призовава потребителите да ограничават докладите си до четири прости факта [1]:

1. Каква команда е изпълнена.
2. Какво е било очакваното поведение.
3. Какво се е случило в действителност.
4. Точният лог или съобщение за грешка.

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

Локални заобикаляния срещу глобални инварианти

Лошото качество на генерирания текст е пряко свързано с лошото качество на кода, създаван от автоматизираните системи. Според наблюденията на Ронахер, моделите са склонни към прекомерно усложняване (over-engineering).

Когато на един AI агент бъде съобщено, че повреден сесиен лог срива четеца на Pi, стандартната реакция на модела е да добави толерантен четец, след това резервен механизъм (fallback), миграция на данни, допълнителни дебъг логове и тестове за всички тези нови елементи. Всичко това изглежда логично в изолация, но е пагубно за софтуерната архитектура.

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

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

Черната статистика: 3145 външни доклада за 90 дни

За да илюстрира мащаба на натиска, Ронахер споделя данни от публичното хранилище на Pi за период от 90 дни. Без да се броят приносите на членовете на Earendil, проектът е получил 3145 външни доклада за проблеми и заявки за сливане (pull requests).

Статистиката за тяхното управление е следната:

• 2504 от докладите (приблизително 80%) са били автоматично затворени, тъй като са изпратени от неодобрени нови потребители.
• Едва 17% от затворените автоматично доклади са били отворени повторно след преглед.
• При заявките за сливане (PR) ситуацията е още по-лоша: под 10% от външните предложения са били приети в хранилището.

Като основни източници на този автоматизиран спам се посочват инстанции на OpenClaw, както и зле настроени потребителски среди („skills“), които насърчават автоматичното създаване на проблеми. Ронахер е категоричен, че вината за това не е на GitHub, а на самите потребители, които позволяват на своите AI агенти да затрупват чуждите хранилища с непроверено съдържание [1].

Директорията .pi и автоматизираният конвейер

Въпреки критиката към спама, екипът на Pi използва автоматизацията за оптимизиране на собствената си работа чрез три основни инструмента, разположени в директорията .pi на проекта [1]:

1. Командата /is: Използва се за анализ на проблеми в GitHub. Тя поставя етикети, назначава отговорници, прочита цялата нишка с линкове и инструктира агента да изведе собствена диагноза независимо от твърденията на потребителя.
2. Разширение prompt-url-widget: Следи подканите към модела. Когато разпознае GitHub URL адрес за проблем или PR, то използва командата gh, за да изтегли заглавието и автора, визуализира ги в малък интерфейсен елемент и преименува сесията. Този статус се запазва и при превключване на сесиите.
3. Командата /wr (Wrap it up): Служи за финализиране на промените. Тя автоматично разбира контекста на GitHub от сесията, обновява файла с промени (changelog), подготвя финалния коментар под проблема (с предупреждение за ползването на AI), прави коммит само на файловете от сесията, добавя съответното съобщение за затваряне на проблема (closes #...) и изтласква промените към основния клон (main).

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

Изображение: Svetni.me / Авторско изображение

Устойчивостта на отворения код в ерата на AI

Ронахер обръща внимание, че под влиянието на изкуствения интелект отвореният код е подложен на безпрецедентен натиск. Появяват се безброй проекти и купища код, които често нямат реални потребители, а популярността им в GitHub избледнява за броени седмици.

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

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

Източници:

[1]: Building Pi With Pi - Armin Ronacher's Thoughts and Writings