Новият модел на OpenAI направи своя дебют този месец с бляскав livestream, групови прожекции и… усещане за разочарование. В секцията с коментари в YouTube скептицизмът беше осезаем: „Мисля, че всички започват да осъзнават, че това няма да промени света, както се очакваше. Вижда се в лицата им“, пише един от зрителите. Но ако за масовия потребител ефектът е под въпрос, спасението може би се крие в програмирането.

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

През април Сатя Надела, главен изпълнителен директор на Microsoft, заяви, че до 30% от кода на компанията вече се пише с помощта на AI. Същото твърди и Сундар Пичай от Google. Salesforce дори замрази инженерните си наемания, а Марк Зъкърбърг каза пред Джо Роуган, че Meta използва AI като „средно ниво инженер“, който пише код.

Междувременно стартъпи като Replit и Anysphere (с продукта Cursor) популяризират идеята, че с AI „всеки може да програмира“. Теоретично – всеки служител може да се превърне в софтуерен инженер.

Но защо това не се случва масово? Една от причините е, че сферата все още е твърде непозната. Хората, които професионално пишат код, обаче смятат, че реалният проблем е непредсказуемостта. „Много хора пропускат колко странно и забавно всъщност е това начинание. Програмист съм от 30 години и AI моделите не се държат като нормални компютри,“ казва Саймън Уилисън, популярен в инженерната общност с експериментите си с изкуствен интелект.

Уилисън описва себе си като vibe coder – използва LLM модели, за да генерира код чрез прости текстови инструкции. GPT-5 е новият му любим модел, но сам предвижда „катастрофа на vibe coding“, ако бъде използван за създаването на сериозен софтуер.

Програмният код е език, а генеративният AI владее почти всички, включително и остарели като Cobol. Това не означава, че програмистите приемат всяко предложение. Уилисън обича да тества границите – например иска svg илюстрация на пеликан, който кара велосипед, или програма, която „помни по име“ кокошките в градината му. Понякога моделът вместо това пише стихотворение.

Въпреки това той демонстрира и практическа полза. С помощта на Claude Code от Anthropic е изградил инструмент за OCR (разпознаване на текст от изображения), софтуер за обобщаване на коментари и планира система, която да го уведомява, когато китове се появяват край дома му на Тихия океан. Всичко това – само с инструкции, написани на английски.

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

Уилисън подчертава, че не би използвал AI-код за реални проекти, без да прегледа внимателно всеки ред: „Естествено, че има риск от халюцинации, а желанието на чатбота да бъде съгласен с всичко може да доведе до неработещи идеи.“ Това е особено проблематично за хора без опит в редакцията на код, защото рискуват да създадат софтуер с вградени дефекти.

Освен това AI не винаги спестява време. Проучване, проведено през юли от Model Evaluation and Threat Research, стига до извода, че програмисти, използващи AI, са смятали, че работят по-бързо, но всъщност са им били нужни с 20% повече време.

AI като „говорещо гумено пате“

Доста разработчици намират изкуствения интелект за полезен в дискутирането на проблеми – наподобявайки популярната в програмистките среди техника „rubber ducking“. При нея специалистът обяснява ред по ред кода си на гумено пате (или друг предмет на бюрото), за да открие къде греши. Разликата е, че в случая „патето“ този път може да отговаря обратно.

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