Пагаварылі з Яўгенам Сяргеевым, які да нядаўняга часу працаваў у Flo Health на пасадзе Director of Engineering. Цяпер ён сканцэнтраваўся на AI-трансфармацыі ў кампаніі на пазіцыі Head of AI Platform.
Пагаварылі з Яўгенам Сяргеевым, які да нядаўняга часу працаваў у Flo Health на пасадзе Director of Engineering. Цяпер ён сканцэнтраваўся на AI-трансфармацыі ў кампаніі на пазіцыі Head of AI Platform.
Чаму радкі кода і колькасць PR — гэта памылковыя метрыкі для ацэнкі AI-трансфармацыі? На чым сфакусаваліся ў Flo? Які адопшэн AI-інструментаў лепшы — зверху ці знізу? Як аптымізаваць выдаткі на токены? І колькі айцішнікаў у свеце імітуюць працу з AI, каб пазбегнуць звальнення?
— Як у Flo Health вымяраюць эфектыўнасць выкарыстання AI? І як вы прыйшлі да высновы, што ён сапраўды памагае ў працы, а не стварае ілюзію высокай прадукцыйнасці?
— Існуе вельмі шмат фрэймворкаў вымярэння прадукцыйнасці інжынераў, частку з іх я разбіраў у адным з выпускаў падкасту 3AImigo, які мы вядзём з Сашам Паламодавым. Там мы закраналі і DX, і DORA-рэпорты, і SPACE. Усе яны даволі складаныя, комплексныя.
У Flo мы даўно сканцэнтраваліся на некалькіх метрыках, якія, як мне здаецца, даволі добра могуць паказаць імпакт і тое, наколькі інжынірынг у цэлым добра працуе.
Але пачну з таго, што НЕ працуе. Токены, колькасць ліцэнзій, доля кода, напісанага AI, — гэта метрыкі актыўнасці, такія ж самыя Lines of Code. Агенты лёгка павялічваюць і аб’ём кода, і колькасць PR — гэта і ёсць ілюзія прадукцыйнасці. Мы падрабязна разбіралі гэта ў другім выпуску нашага падкасту.
Галоўная метрыка для нас — гэта cycle time: колькі часу праходзіць ад моманту, калі задачу ўзялі ў працу, да моманту, калі каштоўнасць даходзіць да карыстальніка. Яна паказвае, на якім этапе праца запавольваецца. Калі AI паскарае адзін этап, вузкае месца пераязджае на наступны, і яго трэба расшываць. Звычайна для гэтага мы пераглядаем сам працэс і пераносім праверкі левей.
Самы наглядны прыклад цяпер — код-рэв’ю. Агенты пішуць у 5–10 разоў больш дыфаў, а людзей і гадзін на рэв’ю засталося столькі ж. Вузкім месцам стала рэв’ю, а адразу за ім — QA. Калі выправіць толькі рэв’ю, праца папросту будзе чакаць у чарзе на QA. Таму мы робім некалькі рэчаў:
Рэв’юім не толькі код, але і план. Сеньёр глядзіць намер і план, якія адыходзяць агенту, яшчэ да таго, як з’явіцца код. Таму што памылку ў архітэктуры танна выправіць на паперы і дорага ў кодзе.
Кожная заўвага на рэв’ю становіцца правілам. Задача рэв’юера — не напісаць LGTM, а ператварыць заўвагу ў правіла або skill, каб агент не паўтарыў памылку наступны раз. Раз на месяц правілы, якія не працуюць, выкідаем.
Механічную частку рэв’ю аддаём AI. Да коміту распрацоўшчык запускае лакальны skill для рэв’ю і праверкі бяспекі. На кожным PR працуюць security-праверка ў CI і AI-рэв’ю, дзе некалькі агентаў паралельна шукаюць багі і адсейваюць шум. Чалавек вырашае тое, што патрабуе меркавання: юрыдычныя рызыкі, дапушчальная рызыка, прадуктовае адчуванне, межы даверу.
Кожная змена праходзіць сваю дарогу. Арыенцір такі: змена даходзіць да main за некалькі дзён. Калі даўжэй — працэс зламаны.
Пачынаць трэба з малога. Мы пачалі з абнаўленняў залежнасцяў праз Dependabot і давялі гэты паток да поўнай аўтаномнасці: PR мержыцца без чалавека, калі праходзяць юніт-тэсты і праверкі бяспекі. Каб гэта стала магчымым, прыйшлося дапрацаваць праверкі ў CI/CD, напісаць правілы і дамовіцца з security-камандай. За чатыры месяцы доля PR, якія мержацца цалкам аўтаматычна, вырасла з 0 да 10,7%. Цяпер на гэтым фундаменце пашыраем аўтаматызацыю на іншыя класы змен.
Адопшэн — гэта важная проксі-метрыка, але не мэта. Яна паказвае, якія інструменты і як выкарыстоўваюць у камандах. На старце важна ўкладвацца менавіта ў адопшэн і нічога не абмяжоўваць: хай інжынеры эксперыментуюць з рознымі інструментамі і практыкамі. Уніфікаваць і ўводзіць стандарты можна пазней. Калі ў нейкай каманды або функцыі адопшэн ніжэй, гэта нагода для размовы, а не для пакарання: трэба зразумець, што ў людзей не працуе. З такіх размоваў і нараджаюцца задачы на паляпшэнне.
Дадам, што кошт трэба лічыць з першага дня, трэба адразу вылучыць бюджэт. З ростам адопшэну ён дакладна будзе расці. З часам з’яўляюцца правілы аптымізацыі, і іх трэба ўключаць па замоўчванні ў харнесе, а не пакідаць на сумленне кожнага інжынера. Напрыклад, самая дарагая мадэль па замоўчванні выключана, наладкі раздаюцца цэнтралізавана. Пасля таго як мы ўключылі такія дэфолты, кошт Claude Code на чалавека ў дзень знізіўся на 28%.
Добры разбор гэтай тэмы — артыкул Uber Running a Software Factory Efficiently at Uber Scale: яны раскладаюць выдаткі на множнікі і аптымізуюць кошт сесіі і запыту, а не агульны рахунак. Частку аптымізацый мы падгледзелі ў іх.
— Ці можна гэта неяк выразіць у лічбах? Дапусцім, ёсць інжынер без AI-інструментаў ды інжынер з AI-стэкам. Ці атрымаецца з вашымі метрыкамі наўпрост параўнаць іх прадукцыйнасць?
— У нас цяпер няма інжынераў (і нават не інжынераў) у кампаніі, якія не выкарыстоўваюць AI у сваёй працы. Таму што мы імкнёмся аптымізаваць усю руціну праз такія інструменты.
Але мы бачым, што cycle time у камандах, якія ўкаранілі ў распрацоўку mature-практыкі з выкарыстаннем AI, зменшыўся да двух дзён. І мы хочам зменшыць яго яшчэ больш — да аднаго дня.
— А колькі часу такі тыповы цыкл займаў у каманд да ўкаранення AI?
— Прыкладна чатыры дні, калі ўзяць нейкі медыянны паказчык.
— Ці ёсць нейкія метрыкі або прыклады ўкаранення AI, якімі ты найбольш ганарышся?
— Ганаруся рабочай групай па company skills (на дадзены момант у рэестры ў нас 109 скілаў), якую я запусціў. Skills аўтаматызуюць розныя этапы працы. Ішлі мы да гэтага так:
Сабралі skills, якія ў кагось ужо ляжалі лакальна.
Сталі прасоўваць іх на AI gatherings, дзе людзі паказваюць, які skill зрабілі.
Зрабілі так, каб skills аўтаматычна былі даступны ўсім, і пачалі збіраць аналітыку выкарыстання.
Цяпер дадаём да іх тэсты, каб падымаць якасць, і збіраем golden set skills.
Важна, што гэта не толькі пра інжынераў. У нас ёсць skills, якія зрабілі дызайнеры, аналітыкі і маркетынг. З асобных skills ужо збіраюцца цэлыя AI-native workflow, дзе крокі аднаго працэсу — skills розных функцый.
Дарэчы, пра тое, што адрознівае AI-native кампанію ад кампаніі, дзе ўсе проста карыстаюцца AI, мы казалі ў восьмым выпуску нашага падкасту.
— Adaptavist нядаўна апытала тысячу айцішнікаў з ЗША, Вялікабрытаніі, Германіі, Нідэрландаў ды Іспаніі. І аказалася, што 50% апытаных імітуюць працу з AI-інструментамі толькі для таго, каб паказаць кіраўніцтву, што ўмеюць. Наколькі рэалістычнай табе здаецца гэтая ацэнка?
— Мне гэтая лічба здалася вельмі сумніўнай. Я бачу, што ўжо ніхто не можа адмаўляць, што гэта добрыя productivity-інструменты. Раней, вядома, былі сеньёры, якія з цяжкасцю прымалі новыя інструменты або адмаўляліся ад іх выкарыстання. Мне наогул здаецца, што сеньёры адмаўляюць любыя новыя інструменты да таго моманту, пакуль тыя не становяцца настолькі добрымі, што даюць прырост прадукцыйнасці, добра бачны простым вокам.
Але цяпер я дакладна бачу, што інструменты выкарыстоўваюцца, і нейкай імітацыі працы з імі ў Flo я дакладна не бачу. Плюс, мабыць, усё гэта яшчэ вельмі залежыць ад кампаніі.
У мяне няма доступу да інфармацыі пра тысячы кампаній па ўсім свеце. Але, калі судзіць па тым, што я бачу і чую ад знаёмых, такая імітацыя адбываецца ў кампаніях, дзе выкарыстанне AI-інструментаў насаджаецца зверху ўніз, дзе ёсць нейкая дырэктыўнасць накшталт «альбо вы выкарыстоўваеце інструмент, альбо мы вас звальняем».
— Падобна на тое. З гэтага ж апытання вынікае, што частату выкарыстання AI ўнеслі як KPI ўжо для 58% апытаных спецыялістаў.
— У нас у Flo гэта ўкараненне ішло як знізу ўверх, так і зверху ўніз. Зверху мы, як інжынірынг-лідары, сказалі: «Окей, нам важна, каб вы авалодалі гэтымі інструментамі. Пры гэтым мы цяпер не ведаем, які інструмент будзе лепшы — умоўны Claude, Codex або Cursor? Мы іх усіх заанбордзілі, спрабуйце». Але нават рух зверху не павінен быць дырэктыўным, ён павінен працаваць праз тлумачэнні.
А знізу інжынеры пачалі спрабаваць інструменты, у іх атрымліваліся нейкія цікавыя кейсы, яны сталі імі дзяліцца ў камьюніці.
У кампаніях, у якіх усе гэтыя навіны і метрыкі навязваюцца зверху, людзям нічога не застаецца, акрамя як паводзіць сябе ў адпаведнасці з законам Гудхарта [Калі мера становіцца мэтай, яна перастае быць добрай мерай]. «Дайце мне любую метрыку, і я буду яе гейміць». Для мяне гэта выглядае менавіта так.
У мяне інжынерны бэкграўнд. Ведаеш, чаму я стаў інжынерам? Таму што я захапляюся новымі тэхналогіямі, і пры гэтым я лянівы. Для мяне праграмаванне было спосабам аўтаматызаваць руціну. І цяпер з AI-інструментамі для інжынераў адбываецца нешта падобнае. Гэта добры інструмент, які дазваляе быць прадукцыйным, рабіць больш, даведвацца больш.
І тут чалавек, які імітуе працу з AI-інструментамі, уваходзіць у канфлікт з самім сабой. Навошта табе імітаваць тое, у чым ты бачыш карысць для сябе? Думаю, такая імітацыя адбываецца менавіта там, дзе людзі не бачаць для сябе карысці ў новых інструментах і дзе адпаведныя метрыкі ставяць як мэту.
Калі ў якасці метрыкі ставіць імпакт на карыстальніка, дастаўку фіч, я думаю, укараненне AI адбудзецца даволі арганічна. Таму што людзі будуць успрымаць гэтыя інструменты як паскаральнік сваёй прадукцыйнасці.
— Ці дапускаеш ты, што ў Flo ёсць вельмі класны інжынер, які выдатна справляецца са сваёй працай без AI-інструментаў або выкарыстоўвае іх вельмі павярхоўна? І проста каб не выбівацца з агульнай карціны, ён імітуе, што працуе з іх дапамогай?
— Думаю, я б вельмі здзівіўся гэтаму. З некалькіх прычынаў.
Па-першае, каб імітаваць, табе трэба неяк траціць токены. А на што іх траціць, калі гэта не нейкія рабочыя задачы? Для мяне такі ланцужок выглядае даволі дзіўным.
Па-другое, мы ў Flo спачатку наймаем сеньёр-інжынераў з вопытам мінімум ад пяці гадоў у індустрыі. Мы не наймалі мідлаў і джуніёр-інжынераў. І яшчэ на этапах інтэрв’ю як прадуктовая кампанія правяраем, наколькі людзям цікава рабіць прадукт. Калі чалавеку сапраўды гэта цікава, ён будзе рабіць прадукт, а не сімуляваць нейкую бурную дзейнасць.
Акрамя таго, навошта нешта імітаваць, калі адопшэн — гэта не KPI? Ну і, нарэшце, цяпер ужо для ўсіх відавочна, што AI дае буст да прадукцыйнасці.
— Распрацоўшчыкаў паводле іх стаўлення да AI можна падзяліць на тры ўмоўныя групы: тых, хто фанацее ад AI, тых, хто не адчувае ад яго асаблівага захаплення, але ахвотна капіруе згенераваны код, і скептыкаў, якія не любяць AI і супраціўляюцца яго ўкараненню праз розныя асцярогі ды кансерватызм. У вашых камандах ёсць людзі з усіх гэтых груп? Ці не канфліктуюць яны паміж сабой?
— Я бачу гэты падзел крыху па-іншаму. Не ў стаўленні да AI, а ў тым, як людзі ўвогуле прымаюць новыя тэхналогіі. Для гэтага ёсць класічная мадэль Technology adoption life cycle: наватары і ранніяя паслядоўнікі, ранняя большасць, позняя большасць і адстаючыя. Яна карысней, чым падзел на фанатаў і скептыкаў, таму што апісвае не стаўленне чалавека, а момант, калі новае становіцца для яго карысным. І ў кожнай групы ёсць свая роля ва ўкараненні.
Наватары і раннія паслядоўнікі — гэта тыя, каму цікава прабаваць усё новае. Яны прабуюць навінку, а потым дзеляцца ўражаннямі з іншымі. Гэта касцяк, на якім трымаецца любая змена, і для менеджара вельмі важна рабіць стаўку на такіх людзей: даваць ім час, доступы і пляцоўку. Мы іх называем AI champions. Раз у два тыдні мы збіраемся на AI gathering — форум, дзе людзі паказваюць, што прабавалі і што спрацавала: новы skill або новы падыход да задачы. Калі цікава, менавіта мадэль з AI-чэмпіёнамі мы абмяркоўвалі ў першым выпуску падкасту.
Тое, што знайшлі чэмпіёны, ператвараецца ў харнес. Удалы прыём становіцца правілам або skill, skill трапляе ў агульны маркетплэйс, а адтуль аўтаматычна на ноўтбук кожнага інжынера. Праверкі ўбудоўваюцца ў CI. У выніку большасць атрымлівае AI ўжо не як новую тэхналогію, якую трэба асвойваць, а як рабочы інструмент, убудаваны ў SDLC. Чалавеку не трэба разбірацца, як правільна промптаваць і якую мадэль выбраць. Найлепшыя практыкі ўжо ляжаць у інструментах, якімі ён карыстаецца.
Гэтым жа спосабам закрываецца і разрыў у кампетэнцыях. Калі кожны асвойвае AI сам, разрыў паміж энтузіястам і ўсімі астатнімі толькі расце. Калі вопыт энтузіяста становіцца агульным харнесам, разрыў скарачаецца: звычайны інжынер працуе з тымі ж skills і праверкамі, што і самы прасунуты.
Канфлікту паміж групамі мы не бачым, таму што нікога не караем за нізкі адопшэн. Калі ў нейкай каманды ён ніжэй, гэта нагода пагаварыць і зразумець, што ў людзей не працуе. Асцярогі скептыкаў часта бываюць разумнымі: гэта і пра якасць кода, і пра бяспеку, і пра адказнасць за вынік. Такія асцярогі мы ператвараем у праверкі і правілы. У выніку атрымліваецца, што скептык таксама ўносіць уклад: дзякуючы яму харнес становіцца надзейней.
— Твая новая пасада была створана пад цябе? Або яна існавала ў кампаніі і раней?
— Гэта новая пасада. Яна з’явілася ў сувязі з тым, што мы сталі выкарыстоўваць AI у прыкладанні.
— На ранейшай пазіцыі інжынернага дырэктара тваё кола абавязкаў было шырэйшае, чым тут? Цяпер ты паглыбіўся менавіта ў AI?
— Абавязкі засталіся прыкладна ў тым жа дыяпазоне. Папросту там я адказваў за некалькі каманд, а цяпер за адну каманду. У цэлым у мяне была вельмі падобная схема, падобныя праблемы, якія мы вырашалі. Ну і раней я быў, хутчэй, кансьюмерам, а цяпер мая каманда робіць платформу, у якой мае папярэднія каманды будуць выступаць як кансьюмеры. Я ведаю праблемы з боку AI-агентаў і, адпаведна, магу іх вырашаць.
— Уваход глыбей у бок AI — гэта твая ініцыятыва? Або папросту так склалася?
— Так, гэта тое, што мне падабаецца. Я таму і вяду падкаст 3AImigo, бо мне цікавая гэтая тэма. Выступаю на канферэнцыях, распавядаю пра AI-трансфармацыю. І мне падабаецца вырашаць складаныя задачы, звязаныя з AI.
Напрыклад, у мяне была каманда інтэрнацыяналізацыі, якая займалася перакладамі. Здаецца, простая задача: папрасіць ChatGPT перакласці нешта на ўсе неабходныя мовы. Але адразу ўзнікае куча нюансаў. У нас медычны кантэнт, у якім мы расказваем, які ў карыстальніцы дзень цыкла, што яна будзе адчуваць, якія сімптомы магчымы. Пры даслоўным перакладзе на іншую мову могуць з’явіцца нейкія нюансы, праз якія гэтая інфармацыя прагучыць па-іншаму. Адпаведна, табе трэба спецыялісты ў розных мовах, якія правераць гэтыя пераклады з пункту гледжання семантыкі, нейкіх іншых нюансаў. І аўтаматызаваць такія рэчы за кошт AI — гэта ўжо даволі цікавая задача. Не зусім трывіяльная, я б сказаў.
Я, як канчатковы карыстальнік гэтых чатаў, бачу, што пакуль яны з цяжкасцю разумеюць, што семантычныя палі ў розных мовах у адных і тых жа паняццяў могуць быць рознымі. І гэта часам прыводзіць да вельмі кур’ёзных сітуацый.
— Ці адчуваеш ты сябе ініцыятарам AI-трансфармацыі ў Flo? Або гэта ідзе аднекуль яшчэ?
— Я дакладна не скажу, што я адзін яе запусціў. Інжынірынг-лідары ў Flo падтрымалі гэтую трансфармацыю. А ідзе яна, як мне здаецца, ад нашага CTO [Рамана Бугаева]. Ён у нас вельмі актыўны, паказвае прыклад, як карыстаецца AI у жыцці, аўтаматызуе руціну, расказвае, як гэта важна для кампаніі — трансфармавацца.
Я, хутчэй, на пазіцыі тэхнічнага дырэктара працаваў з камандамі, шукаў «бутэльныя горлышкі», разбіраўся, якія працэсы мы можам аўтаматызаваць. Нагадаю, што трансфармацыя адбывалася і знізу ўверх: актыўныя інжынеры разумелі, наколькі гэта крута дзяліліся з камьюніці, імкнуліся зрабіць нейкі агульны стандарт для ўсіх, каб пасля кожнаму не прыходзілася вынаходзіць ровар.
— Фінансавым планаваннем на гэтым напрамку ты таксама займаўся?
— Так. Мы планавалі headcount, бюджэты на вендараў для розных каманд.
— Цяпер вашыя выдаткі на токены акупаюцца за кошт эканоміі працоўных рэсурсаў або не акупаюцца? Вашы фінансавыя чаканні ад AI-трансфармацыі апраўдаліся?
— Калі ў нас быў адопшэн, мы хацелі паспрабаваць як мага больш інструментаў. Пакуль мы спрабавалі і не прыйшлі да нечага канкрэтнага, мы не асабліва абмяжоўваліся ў выдатках. Але потым, калі мы ўбачылі, што выдаткі пастаянна растуць, прыйшоў час запускаць цыкл аптымізацый. Каля двух месяцаў таму мы зрабілі чарговую аптымізацыю і ўбачылі, што нашы выдаткі на AI сталі прыкладна плоскімі. Нават пачалі крыху прасядаць. З’яўляюцца мадэлі крыху танней, мадэлі, якія эфектыўней справляюцца з задачамі пры тых жа выдатках.
Аптымізацыі рабілі і на ўзроўні канфігаў і харнесаў. Дзесь, напрыклад, абмежавалі выкарыстанне звышмагутных дарагіх мадэляў для вырашэння нескладаных задач, накшталт «зрабіць summary нейкага дакумента». Базавыя гайдлайны ў выглядзе скілаў, якія на твой запыт адказваюць: «Окей, калі ты просіш зрабіць summary, табе хопіць Sonnet-а». І харнес усё гэта падхоплівае сам, чалавеку нават не трэба будзе самому ўсё гэта пераліваць. Але калі трэба, ёсць магчымасць пераключыцца і на больш дарагую мадэль.
А яшчэ ў нас ёсць ліміты.
Базавы ліміт, з якога мы пачынаем — гэта $1000 на чалавека. Калі ты ўпіраешся ў гэты ліміт, можаш зрабіць запыт на павелічэнне. Гэта зноў тое, што я называю «добрай бюракратыяй». Запыт прыйдзе менеджеру на апрув. Менеджар амаль заўсёды апруўне, але можа задаць пытанне: што ты такое рабіў, што перавысіў ліміты? Але не з пункту гледжання нейкага магчымага пакарання, а з цікаўнасці: што тут можна аптымізаваць?
Можа аказацца, што чалавек проспапросту выконваў складаную задачу. І такі расход можа быць апраўданым, таму што калі б гэтую задачу выконвалі людзі, яна расцягнулася б і абышлася значна даражэй. Добры прыклад — нядаўняя міграцыя. Пасля змены кантракту Scala-бібліятэкі інжынер з дапамогай Fable перанёс яе рэалізацыю на Python і TypeScript і мігрыраваў сервісы, якія яе выкарыстоўваюць.
Раней гэта быў бы крос-камандны праект. Цяпер такую працу можна і трэба рабіць у адзіночку. Мы нават запісалі гэта як інжынерны прынцып: міграцыю можа правесці адзін чалавек, а не каманда. Нават складаная і вялікая змена на 95% можа весці адзін інжынер або адна каманда, і за 10% ранейшага часу.
Але калі міграцыя таннее, цана яе якасці расце: нават дробная шурпатасць ламае калегам уяўленне пра код, які вы падтрымліваеце разам. У выніку ўплыў меркавання асобнага інжынера на кампанію цяпер вышэй, чым некалі.
— Супрацоўнікі звычайна ўпісваюцца ў ліміты?
— У сярэднім на чалавека ў нас цяпер сыходзіць каля $20 у дзень.
— То бок ліміт у $1000 на месяц — гэта з добрым такім запасам?
— Так.
— Распрацоўшчыкі топавых мадэляў не хаваюць, што працуюць у страту. У таго ж Anthropic паводле ўдакладненых дадзеных чыстыя страты за першае паўгоддзе 2026 склалі $80,7 млрд. І ёсць такая папулярная гіпотэза, што яны прадаюць топавыя мадэлі ніжэй сабекошту для таго, каб «падсадзіць» кампаніі ды інжынераў на свае прадукты. А потым пачнуць падымаць цэны. Ці можаш ты пацвердзіць гэтыя асцярогі? Або не?
— Я дакладна не ведаю, якія ў іх планы, таму маё меркаванне можа выглядаць спекулятыўным. Але давай спрабуем. Ёсць канкурэнцыя. Калі тое, пра што ты кажаш, пачне рабіць Anthropic, гэтага, магчыма, не будзе рабіць OpenAI. А ўсе гэтыя настройкі, харнесы, скілы — яны вельмі лёгка пераносяцца. І міграцыя з аднаго AI-прадукту на другі для кампаніі суперпростая. А яшчэ ёсць Google, які крыху адстае ў гэтай гонцы, але іх Gemini-мадэлі даволі нядрэнныя.
Я думаю, што падпісачная мадэль на кароткай дыстанцыі сапраўды можа быць для іх стратнай. Але яны ж таксама прадуктовыя кампаніі, для іх важны Feedback Loop, разуменне таго, як выкарыстоўваюцца іх інструменты і якія інструменты трэба выпускаць на рынак яшчэ. І ўсё гэта патрабуе выдаткаў.
Цяпер відаць, як паскорыўся выпуск мадэляў. Яны шукаюць Loop, як зрабіць так, каб мадэлі маглі навучаць наступныя пакаленні мадэляў, зрабіць новае паскарэнне. І, як любая тэхналогія, якая зараджаецца, такія прадукты спачатку могуць быць дарагімі і цяжкадаступнымі.
Але з часам, як калісь інтэрнэт, усе гэтыя мадэлі стануць камодзіці. Інтэрнэт цяпер даступны, мы з табой лёгка праз яго сазвоньваемся, нават не задумваючыся пра яго кошт. І з мадэлямі, я думаю, мы таксама да гэтага прыйдзем.
Як зменяцца падпісачныя мадэлі ды доступ да іх у бліжэйшай будучыні? ці павялічаць цану на яго або не? Мне здаецца, што калі яны пачнуць павышаць цану, кампаніі папросту актыўней пачнуць праводзіць аптымізацыі. Пяройдуць, можа быць, на кітайскія open-weight мадэлі, ад чаго ў выніку выйграюць дата-цэнтры і правайдэры, а не Anthropic. Думаю, што палітыку, якую ты апісаў, можна параўнаць з выстрэлам сабе ў нагу.
Ужо існуюць тэхнікі аптымізацыі такіх кастаў, якія дазваляюць трымаць выдаткі ва ўмеркаваным дыяпазоне. Зноў жа, усё вельмі залежыць ад кампаніі. Я бачыў, што на рынку цяпер кампаніі пачынаюць перарасходваць AI-бюджэты паміж рознымі праектамі. Напрыклад, калі гэта нейкі важны праект — так, мы вылучаем на яго токены. А калі гэта нейкая internal сістэма — можна яе і сіламі інжынераў распрацоўваць, не марнуючы токены.
Мне складана сказаць, слушная гэта палітыка ці не. Я б не хацеў працаваць у камандзе, дзе мне кажуць: «А цяпер пішыце код па-старому». Пасля таго, як спрабаваў пісаць код з агентамі, напісанне кода па-старому можна параўнаць, мабыць, са стварэннем кода на асэмблеры.
— Ёсць такі інструмент, як Anthropic Code Review, які ўмее рабіць рэв’ю, але абыходзіцца вельмі дорага. На твой погляд, ці атрымаецца вам далучыць яго да сваёй AI-трансфармацыі? Можа, цэны на яго ўпадуць, або ты зможаш угаварыць кіраўніцтва на большы бюджэт?
— Хутчэй за ўсё, неабходнасць у гэтым інструменце папросту адпадзе. Нейкі verification loop убудуецца ў цыкл інтэнту і распрацоўкі, і яшчэ раз рэв’юіць pull request нам папросту будзе непатрэбны. І калі агент зробіць код, я ўжо змагу яму давяраць.
Прагрэс у гэты бок мы ўжо бачым у апошніх мадэлях, якія сталі значна лепш спраўляцца з падобнымі задачамі. Раней трэба было шмат «абвязу», каб накіроўваць агента. А цяпер ужо можна з аднаго шота атрымаць даволі нядрэнны код. Калі агент пачне з дакладнасцю прытрымлівацца інструкцый і правілаў, якія мы ў яго ўводзім, неабходнасць у рэв’ю кода можа адпасці. Механічная праца адыдзе агентам, а меркаванне чалавека пяройдзе на рэв’ю плана ды інтэнту.
Тут кітайцы паказвалі інструменты з падобнай функцыяй. Яны робяць патэрн з «суддзём», у якім на pull request кідаюць адразу некалькі мадэляў. Адна мадэль крытыкуе, другая крытыкуе, потым усё гэта збіраецца, праходзіць яшчэ нейкі цыкл. І калі ва ўмоўнага Anthropic парадак цэн каля $30 за PR, у кітайскага вось гэтага аналага ён ужо парадку $8 за PR. Вось, уласна, і свабодны рынак. Ты ўжо можаш вырашаць, які табе інструмент выкарыстоўваць.
У другой частцы мы абмяркуем з Яўгенам Сяргеевым трансфармацыю найму ў эпоху AI, лёс джуніёраў і ВНУ, якія іх рыхтуюць, і тое, як крос-каманды замяняюцца крос-спецыялістамі. Не пераключайцеся!
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.