AI: Край на софтуерното инженерство или нова ера?

Първият път, когато използвах ChatGPT за кодиране в началото на 2023 г., се сетих за „Маймунската лапа“, класическа хорър история за прокълнат талисман, който изпълнява желания, но винаги по най-зловещия начин. ChatGPT изпълняваше промените, които исках, но също така разбъркваше десетки несвързани редове. Изходът беше обикновено прекалено сложен, често с ненужни фрагменти от код. Имаше някои използваеми редове, но разплитането на бъркотията беше като отклонение. Когато започнах да използвам AI-инструменти по-рано тази година, се почувствах решително надминат. Опитът беше като програмиране с гениален стажант — компетентен, но странно подчинен, все още малко прекалено нетърпелив да угоди и да прави мащабни промени по моя команда. Но когато беше натоварен с по-локализирани промени, той се справяше с завидна ефективност. Трикът е да се ограничи пространството на проблема. Наскоро го накарах да изпълни дузина редове код, всеки от които работеше за 40 милисекунди последователно — времето се натрупваше — и да ги изпълни всички паралелно, така че цялата задача да завърши за времето, което преди отнемаше само един. По някакъв начин, това е като използване на високопрецизен 3D принтер за изграждане на самолет: използвайте го за производство на малки персонализирани части, като хидравлични уплътнения или О-пръстени, и той доставя безупречно; поискайте нещо по-малко локализирано като цял кокпит, и може да получите кокпит, който прилича на смъртоносна камера с нефункционално табло и случайни копчета, хаотично свързани заедно. Настоящите модели са достатъчно гъвкави за потребители с малък или никакъв опит в кодирането да създават продукти с различно качество чрез това, което се нарича — в милиард-доларова модна дума — вайб-кодиране. (Google дори пусна отделно приложение за това, наречено Opal.) Въпреки това, може да се твърди, че вайб-кодирането не е напълно ново. Като инструмент за непрофесионалисти, то продължава дълга линия от приложения без код. Като начин на програмиране, който включва по-малко префронтален кортекс, отколкото гръбначен рефлекс, всеки честен програмист ще признае, че е участвал в недостойна практика, известна като „шотган дебъгинг“. Подобно на безсмислено въртене на куб на Рубик и пожелаване цветовете магически да се подредят, програмист, изтощен след часове безплоден дебъгинг, започва произволно да променя кода — изтрива случайни редове, разменя няколко променливи, или обръща булева условие — стартира програмата отново и се надява на правилния резултат. И двете, вайб-кодирането и шотган дебъгингът са форми на интуитивно махане, заместващи догадки и късмет с умишлено разсъждение и разбиране. Използвали сме машини, за да облекчим натоварването на когницията, но за първи път прехвърляме самата когниция на машината. Както се случва, не се счита за добра форма самоуважаващ се програмист да се занимава с шотган дебъгинг. Скоро разбрах, че най-продуктивната форма на AI-подпомогнато кодиране може да бъде редакторска — подобно на това как тази статия се оформи. Моят редактор ми възложи тази статия с няколко насочващи точки, и писателят — вашият покорен слуга — подаде приемлив чернови, който никой трезвен редактор не би публикувал както е. (Преди „подканяй и моли“, имаше „възложи и чакай“.) По същия начин, вайб-кодер — отговорен такъв, тоест — трябва да приеме вид редакторство. Разпръснатите блокове код, произведени от AI, първо се нуждаят от структурни редакции, последвани от редакции на ниво ред. Чрез поредица от подканяния — като последователни кръгове от редакции — редактор-кодерът минимизира разликата между своята визия и изхода. Често, това, което намирам за най-полезно в тези инструменти, дори не е писането на код, а разбирането му. Когато наскоро трябваше да навигирам в непозната кодова база, поисках да ми обясни основния й поток. AI генерира диаграма на потока на това как основните компоненти се вписват заедно, спестявайки ми цял следобед на изследване на кода. Имам двояко мнение за това колко може да направи вайб-кодирането. Писателят в мен празнува как то може да подкопае определен вид снобизъм в Силициевата долина — отвратителната самодоволност, която инженерите често показват към нетехническите роли — като помага да се размие тази измамна граница. Но инженерът в мен вижда това като повърхностно изказване, защото изграждането на нетривиално, производствено приложение без години на реален опит в софтуерното инженерство е трудна задача. Винаги съм мислил, че най-добрата метафора за голяма кодова база е град. В кодова база има буквални тръбопроводи — данни тръбопроводи, опашки за събития и съобщителни брокери — и потоци от трафик, които изискват сложно маршрутизиране. Точно както градовете са разделени на райони, защото нито един човек или екип не може да управлява цялата сложност, така и системите са разделени на единици като модули или микросервиси. Някои части са толкова стари, че е по-безопасно да не ги докосвате, за да не взривите нещо — подобно на неизбухналите бомби, все още заровени под европейските градове. (Три бомби от Втората световна война бяха обезвредени в Кьолн, Германия, това лято.) Ако разработването на нова продуктова функция е като отваряне на нов салон на авиокомпания, по-задълбочен проект е като изграждане на втори терминал. В този смисъл, изграждането на приложение чрез вайб-кодиране е като отваряне на изскачащ магазин в конкорса — точката е, че е самостоятелно и не изисква интеграция. Вайб-кодирането е достатъчно добро за самостоятелна програма, но най-сложните проблеми в софтуерното инженерство не са свързани с изграждането на отделни единици, а с тяхното свързване за съвместна работа. Едно е да реновирате един апартамент, а друго е да свържете система за пожарогасене и аварийно захранване на всички етажи, така че да се активират в правилната последователност. Тези опасения се простират далеч отвъд интериора. Въвеждането на един нов възел в разпределена система може също толкова лесно да наруши мрежата, подобно на това как самото съществуване на нова сграда може да преоформи околната среда: нейния аеродинамичен профил, как променя слънчевата светлина за съседните сгради, пренасочването на пешеходния трафик и безбройните вълнови ефекти, които предизвиква. Опасенията за сигурността около вайб-кодирането, по мое мнение, са нещо като плашило. Не казвам, че това е някаква възвишена експертиза, а по-скоро мълчаливият, трудно спечелен вид — не само да знаеш как да изпълниш, но и какво да попиташ след това. Можеш да изведеш почти всеки отговор от AI при вайб-кодирането, но истинското предизвикателство е да знаеш правилната последователност от въпроси, за да стигнеш там, където трябва. Дори ако сте ръководили вътрешна реновация, без да стоите на строителна площадка и да гледате как бетонът се излива в основата, не можете наистина да разберете как да създадете сграда. Разбира се, можете да използвате AI, за да съберете нещо, което изглежда функционално, но както казва поговорката в софтуера: „Ако мислите, че добрата архитектура е скъпа, опитайте лоша архитектура.“ Ако трябва да вярвате на Линус Торвалдс, създателят на Linux, има и въпрос на „вкус“ в софтуера. Добрата софтуерна архитектура не се създава само с един замах, а възниква от безброй здрави — и вкусни — микро-решения, нещо, което моделите не могат да направят на един замах. Такава интуиция може да се развие само в резултат на специфични невронни увреждания от добър брой 3AM повиквания. Може би тези аналогии ще стигнат само до определена степен. Преди няколко месеца, AI можеше надеждно да работи само върху един файл. Сега, той може да разбира контекста в множество папки и, докато пиша това, в множество кодови бази. Това е като AI, натоварен с следващия си ход в шаха, премина от гледане на дъската през очите на един пешак до наблюдение на цялата игра със стратегическо прозрение. И за разлика от артистичния вкус, който има безкрайно повече параметри, „вкусът“ в кода може просто да бъде сумата от дизайнерски модели, които AI може да абсорбира от книги на O'Reilly и години на спорове в Hacker News. Когато последният инцидент с приложението Tea разкри десетки хиляди шофьорски книжки на своите потребители — провал, който хор от онлайн коментатори бързо обвиниха на вайб-кодирането — това беше моментът, за който скептиците на вайб-кодирането се молеха. Както винаги, можехме да разчитаме на AI влиятелите в X да благословят времевата линия със своите блестящи мнения, и на определен вид тех критики — тези с твърд навик на ритуално преследване на линейки — да анатематизират всяко използване на AI. В странно обръщане на обичайната си роля като бичи момчета, софтуерните инженери внезапно бяха издигнати до пазители на сигурността, използвайки момента, за да ударят безгрижните вайб-кодери, които нахлуват в тяхната професионална област. Когато беше разкрито, че вайб-кодирането вероятно не е причината, инцидентът разкри по-малко за вайб-кодирането, отколкото за нашия устойчив импулс да дихотомизираме техническите инциденти в аутсайдери и насилници, измамени и измамници, жертви и извършители. С риск да изглеждам като легитимиращ AI търговците на хип, опасенията за сигурността около вайб-кодирането, по мое мнение, са нещо като плашило — или поне нетният ефект може да бъде не-негативен, защото AI може също да ни помогне да пишем по-сигурен код. Разбира се, ще видим гафове на „апликативна каша“ и несигурни кодови фрагменти, които се споделят онлайн с радост, но подозирам, че много от тези недостатъци могат да бъдат поправени, като просто добавите „изпълнете одит на сигурността за тази заявка за изтегляне“ към контролен списък. Вече автоматизирани инструменти маркират потенциални уязвимости. Лично използването на тези инструменти ми позволи да генерирам много повече тестове, отколкото обикновено бих се грижил да напиша. Освен това, ако моделът е достатъчно добър, когато попитате: „Хей, имам нужда от база данни, където мога да съхранявам шофьорски книжки“, AI може да отговори: „Разбира се, но забравихте да обмислите сигурността, идиот. Ето код, който криптира номерата на шофьорските книжки в покой, използвайки AES-256-GCM. Също така съм настроил система за управление на ключове за съхранение и ротация на ключа за криптиране и съм я конфигурирал така, че декриптирането на нещо да изисква одобрение от двама души. Дори ако някой открадне данните, ще им трябва до топлинната смърт на вселената, за да го разбият. Няма защо.“ В моята ежедневна работа съм старши софтуерен инженер, който работи главно върху бекенд, понякога върху машинно обучение и върху фронтенд — ако трябва — неохотно. В някои части на ролята, AI донесе значително усещане за лекота. Няма повече парсинг на дълги API документи, когато моделът може да ми каже директно. Няма повече ритуално срамуване от модераторите на Stack Overflow, които смятаха въпроса ми за недостоен за задаване. Вместо това, сега имам партньор-програмист, който не съди моите въпроси, които могат да завършат кариерата ми. Еволюцията на софтуерното инженерство е история на абстракцията. За разлика от писането, нямам особена привързаност към блоковете код и с готовност ще позволя на AI да ги редактира или регенерира. Но съм защитен към собствените си думи. Не използвам AI за писане, защото се страхувам да не загубя тези редки моменти на удовлетворение, когато успея да подредя думите, където са били предназначени да бъдат. За мен това надхвърля сантименталната благочестие, защото, като писател, който не пише на родния си език — „екзофоничен“ е изисканият термин — знам колко бързо може да ерозира придобит език. Видях неговите корозивни ефекти от първа ръка в програмирането. Първият език, който научих наново след пристигането на AI, беше Ruby, и имам забележимо по-слабо разбиране на неговите по-фини точки от всеки друг език, който съм използвал. Дори с езици, които някога знаех добре, усещам как моята плавност се оттегля. Дейвид Хайнмайер Хансън, създателят на Ruby on Rails, наскоро каза, че не позволява на AI да пише код за него и го изрази точно: „Мога буквално да усетя как компетентността изтича от пръстите ми.“ Някои от тривиалните, но рутинни задачи, които някога можех да правя под обща анестезия, сега ми причиняват мигрена при мисълта да ги правя без AI. Може ли AI да бъде фатален за софтуерното инженерство като професия? Ако е така, светът поне би могъл да се наслади на злорадството от гледането как професия, унищожаваща работни места, се автоматизира в незначителност. По-вероятно, в междинния период, парадоксът на Джевънс — по-голяма ефективност води до повече потребление — ще надделее, неутрализирайки всяко увеличение на продуктивността с по-голям обем работа. Друг начин да се види това е като естествена прогресия на програмирането: еволюцията на софтуерното инженерство е история на абстракцията, отдалечаваща ни все повече от голия метал до все по-високи концептуални слоеве. Пътят от асемблерен език до Python до AI, за илюстрация, е като преминаване от даване на инструкции като „завърти тялото си на 60 градуса и отиди 10 фута“, до „завий надясно на 14-та улица“, до просто казване на GPS, „заведи ме вкъщи“. Като програмист от това, което по-късно ще се счита за пред-ChatGPT поколение, не мога да не се чудя дали нещо жизненоважно е оставено назад, докато се изкачваме на следващото ниво на абстракция. Това не е нищо ново — това е познат цикъл, който се разиграва отново. Когато C се появи през 1970-те години, асемблерните програмисти може би са го видели като загуба на по-фин контрол. Езици като Python, от своя страна, трябва да изглеждат ужасно бавни и ограничителни за програмист на C. Следователно може би е най-лесното време в историята да бъдеш програмист, но може би е по-трудно от всякога да станеш софтуерен инженер. Добър програмист може да напише компетентен код, но велик програмист знае как да реши проблем, без да пише никакъв код. И е трудно да си представим, че ще се придобие трезво разбиране на основите на компютърните науки без мъчителните часове в общежитието, прекарани в ръчно кодиране, например, на алгоритъма на Дейкстра или червено-черно дърво. Ако някога сте се опитвали да научите програмиране, гледайки видеоклипове и сте се провалили, това е защото единственият начин да го усвоите е като го напишете сами. Не можете да забивате кошница, гледайки акценти от НБА. Журито все още не е решило дали AI-подпомогнатото кодиране ускорява работата изобщо; поне едно добре разгласено проучване предполага, че може да е по-бавно. Вярвам го. Но също така вярвам, че за AI да бъде истински експонент в уравнението на продуктивността, ни е необходима умение, което ще нарека вид ментален прекъсвач: способността да забележите, когато сте изпаднали в безсмислен автопилот и да се измъкнете от него. Ключът е да използвате AI достатъчно, за да преминете през препятствие и след това да се върнете към упражняване на вашето сиво вещество отново. В противен случай ще загубите ядрото на разбирането зад целта на задачата. В оптимистични дни, обичам да мисля, че докато определени способности атрофират, ще се адаптираме и развием нови, както винаги сме правили. Но често има пълзящ песимизъм, че този път е различно. Използвали сме машини, за да облекчим натоварването на когницията, но за първи път прехвърляме самата когниция на машината. Не знам накъде ще се обърнат нещата, но знам, че винаги е имало определена надменност да вярваш, че собственото ти поколение е последното, което знае как да мисли наистина. Каквито и да са печалбите, има истинско усещане за загуба във всичко това. В своя есе от 2023 г. в New Yorker „Програмист обмисля намаляващите дни на занаята“, Джеймс Сомърс улови това чувство, след като се намери „искащ да напише елегия“ за кодирането, тъй като „стана възможно да се постигнат много от същите цели без мислене и без знание.“ Минаха по-малко от две години от публикуването на това есе и изразените от него чувства само са станали по-резонантни. За едно, чувствам се по-малко мотивиран да уча нови програмни езици за забавление. Удоволствието от изучаването на нов синтаксис и престижът от придобиването на владеене на нишови езици като Haskell или Lisp са намалели, сега когато AI може да изрече код на всеки език. Чудя се дали мотивацията за изучаване на чужд език би ерозирала, ако приложенията за автоматичен превод станат повсеместни и безупречни. Софтуерните инженери обичат да се оплакват от дебъгинга, но под мърморенето винаги е имало тиха гордост в споделянето на военни истории и техните умни решения. С AI, ще има ли място за такъв вид разговори? Има два типа софтуерни инженери: градски планировчици и миниатюристи. Градските планировчици са от типа „голяма картина“, по-фокусирани върху системата, работеща в мащаб, отколкото върху детайлите на кода — всъщност, те рядко могат да пишат код сами. Миниатюристите носят грижата на часовникар за фина работа върху вътрешната работа на кода. Този нов начин на кодиране може да бъде благодат за градските планировчици, но да остави полето негостоприемно за миниатюристите. Веднъж имах привилегията да видя велик доайен на програмирането в действие. В колежа взех клас с Брайън У. Керниган, жива легенда, на която се приписва превръщането на „Здравей, свят“ в програмистка традиция и член на оригиналния екип на Bell Labs зад Unix. Точно пред очите ни, той кодираше на живо на прост терминал, използвайки спартански текстов редактор, наречен vi — не vim, имайте предвид — за да изгради парсер за сложен синтактичен дърво. Не само че нямаше нужда от съвременни инструменти като IDE-та, той също отговаряше на имейли, използвайки имейл клиент, работещ в терминал. Имаше определена естетика в това. Скоро програмирането може да се разглежда като смесица от жестове за писане и заклинания, които някога са квалифицирани като занаят. Точно както гледаме с възхита на старата банда на Bell Labs, непривлекателната работа по ръчно дебъгване на проблеми с конкурентността или писане на код за уеб сървър от нулата може да се разглежда като героична. От време на време, все още можем да видим старите романтици, които се задържат над всяко натискане на клавиш — акт, който е достоен, майсторски и безнадеждно извън времето.