Founder ng Instagram na si Mike Krieger tungkol sa Fable 5 at ang hinaharap ng AI-driven na software development

Guest: Mike Krieger, founder of Instagram

Host: Dan Shipper

Pinagmulan ng podcast: Every

Pinapayagan ni Mike Krieger ang Fable 5 na mag-code habang siya ay natutulog

Air date: June 11, 2026

Si Mike Krieger, dating sa kanyang pagiging co-founder ng Instagram, ay direktang nagbuo ng isa sa pinakamalaking consumer app sa mundo sa nakaraang dalawang dekada. Ngayon, nasa pinakamataas na harapan ng pagbuo ng “AI-native” na produkto bilang pangulo ng Anthropic Labs, pinangunahan niya ang kanyang tim na pagsisikap na sagutin ang isang pangunahing tanong: Ano ang hangganan ng teknolohiya kapag isinigaw ang pinakamahusay na AI model sa mundo sa mga tunay na developer?

Limang buwan bago ang pormal na paglalabas ng Fable, nang unang beses niyang makamit ang pag-access sa modelo sa loob, ang pagkabigla at pagkawala ng kontrol ay nanatiling malinaw sa kanyang alaala. “Sige, naramdaman kong muli akong isang ganap na baguhan,” sabi niya sa kanyang team nang mapagkatawan. Bigla niyang naramdaman na ang lahat ng kanyang mga prinsipyo na nadiskubre sa loob ng ilang dekada tungkol sa pagpapabuti ng epekto, pagsasagawa ng pananaliksik, at kahit paano ang pagpaplano ng oras, ay naging walang kwenta sa isang sandali. Ang bilis ng pag-unlad ng modelo ay lubos nang nalikom sa kanyang dating proseso ng trabaho.

Sa patalastas na ito, ang host ay nagkaroon ng malalim na talakayan kay Mike Krieger upang iwan ang mga spectator na makatingin sa karanasan ng pagtatrabaho kasama ang Fable—isang modelo na nagdudulot ng pagbabago sa panahon—sa pagbuo ng software. Sa bagong normal na pagkakaisa ng tao at makina, ano ang mga bagong ritmo sa pag-unlad, mga malalaking hamon, at mga posibilidad na puno ng imahinasyon ang nabuo?

Paano ng buong-buoong binago ng Fable ang workflow ni Mike

Kailan gamitin ang Sonnet, kailan ang Fable

Ang Agent-native architecture na nagmula sa Fable 5

Ang pagkakabuo ay nagsagwan na

Patay na ba ang software engineering?

Mechanism ng pag-verify at presyo

Dynamic workflow

Host Dan Shipper: Ang bisita natin sa episode na ito ay si Mike Krieger, ang head ng Anthropic Labs at co-founder ng Instagram. Mike, gusto kong marinig mula sa iyo ang iyong tunay na karanasan pagkatapos magsagawa ng malalim na paggamit sa model na ito. Kapag may isang tao na gumagamit nito nang araw-araw at sabihin niya: "Sobrang lakas nito sa mga lugar na ito, talagang nagbago nito ang aking workflow, pero sa iba pang lugar, hindi naman ganun kahalaga"—mabibigyan natin ang mga tao ng mas malinaw na pag-unawa kung paano talaga isasama ang teknolohiya sa kanilang araw-araw na buhay.

Mike Krieger:

Totoo. Ang karanasan mismo ay interesante. Sa mga buwan bago ang pormal na paglabas ng Fable, kami ay nagsagawa na ng ilang mga modelo ng antas ng Mythos sa loob. Noong panahong iyon, umaasa ako na makikita kung ano ang gagawin ng mga eksternal na developer nito, ngunit tulad ng sinabi mo, ang totoong pag-unlad sa pagkaunawa ay nanggaling sa ilang linggo ng intensibong patuloy na paggamit, at hindi sa unang araw na pagsubok.

Naranasan namin ang ganitong pagbabago ng pagkakaunawa sa dating modelo. Noong huling bahagi ng Disyembre taong nakaraan hanggang sa unang bahagi ng Enero, habang pinagsama-sama ng marami ang Opus 4.5 at 4.6, habang lumalalim ang paggamit, biglang naramdaman ng mga tao: "Hindi pa sapat ang aking pagpapahintulot sa kanya. Kailangan kong maglakad pa unti, at muling isipin kung saan talaga ang hangganan ng kakayahan ng modelo na ito."

Host Dan Shipper: Sa loob ng aming koponan ng Every, may ilan na kausap na gumagamit. May nag-feedback na: "Naramdaman kong kailangan kong magkaroon ng isang buong bagong skill tree upang makamit ang modelo na ito," lalo na ang mga kausap na walang teknikal na background at nasa field ng knowledge work, na kahit paano ay nahihiya; samantalang ang mga nagsasagawa ng Agent orchestration ay nagkomento: "Sobrang maraming bagong bagay na dapat matutunan."

Mike Krieger: Ang iyong pagbanggit sa “pagbabago ng workflow” ay tumutok sa tamang punto—hindi lamang ito tungkol sa mga tiyak na hakbang, kundi pati na rin sa pagbabago ng pananaw. Kakaibang pagkakataon, ang paglitaw ng modelo ay sumabay sa aking pagbabago sa trabaho: nasa puntong ito ay ako ay nagsimula na mula sa CPO (Chief Product Officer) patungo sa Labs, at bumalik na ako sa developer mode. Sa loob ng isang hanggang dalawang buwan pagkatapos ng paglipat, unang nagsagawa ng ganitong uri ng modelo sa loob ng kompanya. Nakaupo ako sa harap ng computer at isip ko: “Sige, muli akong nagsisimula.” Dahil natanto kong ang aking dating gawi sa pagsulat ng Prompt, kahit pa ang paraan kong paghahati ng mga gawain, ay naging lubos na lumang teknolohiya sa harap ng modelo na ito.

Dapat mong palawigin ang iyong pag-unawa sa panahon at iyong paraan ng interaksyon. Noong nakaraan, baka sabihin ko: "May ideya akong feature, simulan natin sa unang hakbang—" Ngayon, hindi na ito ang tamang paraan. Ang tamang paraan ngayon ay: ipaunawa sa ito ang mas malawak at mas kompletong intensyon, at pagkatapos ay buong-buo itong pabayaan na pumatakbo. Tanda ko noong Marso at Abril, ang kakayahan nito ay naging nakakatamis na—hindi lang ito makapagbigay ng isang beses na nakakagulat na resulta, kundi mas nakakatakot na ito ay nakakaintindi ng susunod na pag-unlad ng feature at ng buong konteksto ng proyekto.

At hindi ito pag-unlad na tumigil. Ngayong umaga, nag-usap ako sa isang tao tungkol sa trabaho—habang nasa eroplano, nalaman kong "maaari kong gawin ang karamihan sa aking trabaho mula sa layo". Hindi na ako naiisip kung sasabog ba ang Wi-Fi, dahil kung magkakaroon ng koneksyon, sasabihin ko na sa kanya ang tamang konteksto at mga utos (tulad ng isang loop command), at kaya niyang sundin ang gawain hanggang sa tapos.

Sa nakalipas na dalawang buwan, madalas kong nararanasan ang mga ganitong malaking sandali: bago matulog, sinasabihan ko si Claude ng magandang gabi, ibinibigay ko sa kanya ang isang kumplikadong gawain, at nang gumising ako sa susunod na araw, natatapos na nito ang lahat—karaniwan ay natapos na nito ang pangunahing bahagi noong alas-dalawa ng gabi, at ang natitirang apat na oras ay ginugol nito sa pagpapabuti ng mga detalye.

Ang pinakamasidhi sa akin ay ang kanyang kakayahang mag-auto-loop. Halimbawa, isipin nito: "Hinihingi ni Mike sa akin na patakbuhin ang isang kumplikadong gawain ngayong gabi. Ngunit nakakapagod ako dahil nasira ang remote server. Magandang ideya, unang isulat ko ang sarili kong mock backend upang pagsisilbing pahalili, i-record ito sa dokumentasyon, patakbuhin muna ang buong proseso at i-save, at iayos ito mamaya kapag nabalik na ang serbisyo." Para sa akin, ang karanasan ng pagbibigay ng ganitong antas ng gawain at pagkakaroon ng ganap na tiwala sa kinalabasan nito ay napakalaking pagpapabago.

Sigurado kang kailangan mong i-review ang resulta pagkatapos—ito ay nagsasangkot ng isang buong mekanismo ng pag-verify, at maaari nating pag-usapan ito nang mas detalyado mamaya, dahil ito ay mahalagang bahagi ng loop. Ngunit ito ay talagang nagpapakilala sa akin na muli isipin: ano ang tunay na "epektibo" sa harap ng ganitong modelo? Noon, palaging isinusulong natin ang mga modelo na ito bilang "tulungan" o "kasama," ngunit ngayon, mas parang isang totoong "hardcore teammate" na maaaring magdala ng malaking bahagi ng core na trabaho at maaaring maging responsable.

Host Dan Shipper: So, ano talaga ang iyong araw-araw na workflow? Napansin ko ang isang phenomenon: kapag ibinibigay mo sa kanya ang isang malaking gawain, sinasabi mo ang mahabang paliwanag, at pinapagana mo ito nang ilang oras o kaya'y buong gabi—doon lang talaga mas mabuting magtatrabaho ito. Ngunit kapag nasa harap mo ang mga simpleng, maliit na gawain, parang masyadong mabagal at mahal ito, kaya hindi mo na gusto gamitin. Paano mo sinusukat ang balanse sa praktikal na paggamit? Saan naman ito nakaposisyon sa iyong teknikal na stack?

Mike Krieger:

Ngayon, mas marami akong ginagamit ito sa pagplano ng arkitektura at pagpapagkasundo ng solusyon sa unang yugto. Ito ay isang interesanteng pagbabago at patuloy na pinaglalaban ng lahat ng modelo.

Sa larangang ito, lubos akong nagpapasalamat sa aking karanasan sa Instagram noong unang panahon—mula sa pagbuo ng pinakasimpleng bersyon sa isang server sa Los Angeles, hanggang sa pagharap sa malaking concurrency at pag-scale, at sa huli ay ang buong pagpapalipat sa infrastruktura ng Facebook. Ang prosesong ito ang nagtuturo sa iyo ng isang intuisyon kung "sa anong yugto ng proyekto, dapat gamitin ang anong antas ng arkitekturang abstraktsyon at kumplikasyon."

Kaya patuloy akong magkakaroon ng madalas na pagtatalakayan kasama ang Fable. Minsan, ipinapakita nito ang isang tila perpektong solusyon, at sasabihin ko sa iyo: "Totoo, plano kong ilunsad ito sa malapit na hinaharap—kailangan nating isaisip ang kakayahan sa labas ng isang machine lamang." Mahalaga ang ganitong dalawang direksyon na interaksyon. Ngunit habang gumagawa ng arkitekturang plano, karaniwang hihingi ako sa iyo na lumikha ng isang HTML page upang ma-visualize ang aming pag-uusap, upang maibahagi ko ito sa aking team. Kahit isang Markdown file ay sapat, ngunit mas paborito ko ang may mga grapiko.

Nagkakaroon ito ng interesanteng paraan: isama ang iba sa pag-iisip nang malalim at pagpaplano, at pagkatapos ay gumawa ng dokumento para magkaisa ang team. Dahil saayos na ang bilis ng pagbuo ng mga prototype, kailangan mo ng mas malalim na pagkakasundo at pagkakaisa muna—kahit na plano mong gawin muna ang isang "maliit na mabilis na" Demo bago i-backtrack ang mas mahigpit na sistema arkitektura, mahalaga pa rin ang komunikasyon sa simula. At dito talaga nakapaloob ang pag-iisip at pakikipagtulungan ng tao sa buong proseso.

Sa pagpapatupad, kahit anong oras ng gabi o malaking bahagi ng araw, pagpapagana nito upang sagutin ang iba’t ibang module ng gawain nang sabay-sabay ay nangangahulugan na parehong pinapanatili ko ang mas maraming concurrent session kaysa dati. Minahal kong buksan ang isang matagal na nagpapatakbo na Claude Code session upang ipa-fork nito ang lahat ng gawain sa mga sub-Agent sa background, kaya ang pangunahing thread ay maaaring agad sumagot sa aking mga bagong utos; minsan ay diretso kong buksan ang lima o anim na tab sa browser upang sila ay magtrabaho nang hiwalay sa mga mahabang cycle na kumplikadong gawain.

Ang ganitong uri ng pagpapatakbo na may pananaw sa mahabang panahon at may damdaming "Huwag mag-alala, ibigay sa akin, kailangan ng oras" ay talagang may malaking potensyal. Kasalukuyan naming isinisiyasat sa antas ng produkto kung paano mas mabuting suportahan ang ganitong karanasan—siguradong nais mong i-balans ang parehong "agad na tugon" at "habang mahaba ang pagpapatakbo," at ang kanilang interaksyon ay napakaganda. Ang aking personal na pagpili ay: mayroon man lamang isang window ng Claude na may mataas na konteksto at napakabilis na tugon, na may intuitibong pakiramdam na "nandito ako kahit kailan, isang mensahe lang at agad kong i-start o ibibigay ang subtask."

Host Dan Shipper: Kung ikaw ay nasa daan at biglang may isang tanong—gagawin mo ba ang pagkuha ng Fable? Maraming times ba itong parang "paggamit ng rocket launcher para sa mga langaw"? O kaya ba'y madalas mong i-switch ang mga model?

Mike Krieger:

Kahit noong una, talagang ginagamit ko ang Fable sa lahat, at ang karanasan ay tulad ng sinabi mo—tinutok mo ang iyong paningin sa screen, habang pinapanood mo itong sumisikap nang husto.

Hanggang sa nakaraang linggo, nais kong malaman ang isang simpleng tanong na parang nakakahiya akong itanong, tungkol sa NBA Finals. Noong iyon, nag-switch ako sa mobile version ng Sonnet, at agad kong naramdaman: “Oh tama! Dati ko ito ginagamit para sa mga mabilis na tanong.” Ito ay hindi pareho sa antas. Kahit hindi ito tungkol sa ilang Token na nailalabas bawat segundo, kundi tungkol sa kung gaano karaming capacity ng isip ang kailangan para isipin ang tanong na iyon. May mga pagkakataon na ang isang simpleng sagot ay hindi kailangan ng sobrang pag-iisip.

Para sa aming tim ng produkto, ang tanong na ito ay mayroon ding malalim na kahulugan. Sa pangkabuuan, siguradong hindi mo gustong pilitin ang mga user na mag-isip araw-araw kung aling model ang pipiliin sa frontend. Sa ideal na sitwasyon, sa mahabang panahon, maaari nating i- consolidate ang mga ito sa ilang napakadaling maunawaan at ready-to-use na scenario buckets; o kaya’y direktang i-segment ang mga ito batay sa user interface—dahil sa totoo lang, sa karamihan ng mga pagkakataon, kapag binabasa ko ang iOS App, hindi naman ito para sa mga gawain na nangangailangan ng pag-activate ng Fable. Kaya’t maaaring isipin ang pagtatayo ng isang hindi nakikita na fixed model sa interface. Kailangan nating mas lalo pang pagsisiyasatin kung ano ang ibig sabihin nito sa antas ng produkto. Ngunit ang subtil na pag-iisip na “hindi ito karapat-dapat para kay Fable, dapat ko lang i-call si Sonnet para sagutin ito”—naramdaman ko talaga ito sa nakaraang panahon.

Tama ka, para sa mga mataas na kalikasan at detalyadong interactive na gawain, ang Fable ay natural na lalalim sa pag-iisip. Sa katotohanan, ang Fable ay ang unang modelong nakakakita ko na nagpapakita sa akin ng kailangan na i-ayos ang "antas ng pagsisikap" (Reasoning Effort)— minsan ako'y nakaupo at isip-isip: "Simpleng pagbabago ng UI style lang naman ang kailangan ko, sapat na ang i-set ang antas ng pagsisikap sa 'katamtaman' para makita ang epekto." Noon nang gumagamit ako ng Opus, halos hindi ko sinasadyang i-ayos ito dahil ang sakop ng pagkakapantay-pantay ng modelong iyon ay hindi gaanong malawak, ngunit ang sakop ng Fable ay talagang maaaring maging napakalawak.

Host Dan Shipper: Maaari mo ba kaming ipakita ang mga bagay na iyong ginawa gamit ito?

Mike Krieger:

Nang ipinakilala namin ang bagong model na ito, gawa kami ng isang bagay—inaanyayahan namin ang buong tim na gamitin ito sa kanilang sariling personal na account, lalo na sa mga weekend. Nakakalibang ito, dahil mayroon ang Anthropic ng maraming custom na productivity tools, kaya minsan, nagpasya kaming magpaikli at bumalik sa pinakamadaling anyo: "Gagamitin ko lang ang pure Claude Code para gumawa ng ilang masayang maliit na bagay para sa aking sarili sa weekend." Ang pakiramdam ay napakaganda.

Host Dan Shipper: Sa terminal app o sa desktop app mo ba ito pinapatakbo?

Mike Krieger:

Magandang tanong. Karamihan pa rin ng oras kong ginagawa sa terminal. Ngunit kakaibang bagay ay ang asawa ko—hindi siya propesyonal na inhinyero, mas naka-focus sa UX (user experience) designer at PM (product manager)—siya ang naging lubos na mahigpit sa Claude Code sa pamamagitan ng desktop app. Naniniwala akong tinanggal ng desktop app ang maraming malalim at abstrak na konsepto para sa kanya. Gayunpaman, habang nagtatrabaho ako sa proyektong ito, gumagamit pa rin ako ng Ghostty at terminal.

Noong unang panahon, nais ko ng isang perpektong "media progress tracker"—karaniwang naglalaro ako, sumasayaw sa mga palabas, at natatanggap din ako ng iba’t ibang rekomendasyon mula sa mga kaibigan, kaya kailangan ko ng isang kasangkapan na lubos na sumasalungat sa aking paraan ng pag-aayos. Ang dalawang pangunahing pamantayan ko ay: una, madali lang magdagdag ng mga bagay—direktang sabihin o i-type sa Claude, at sasagot siya sa buong web, pumopopulate ang impormasyon, at isisikat ito sa tamang kategorya; pangalawa, aktibong ipapadala nito ang mga update, tulad ng kung may bagong season o sequel ng laro, sasagot ito nang awtomatiko.

Ang karamihan sa UI ay natapos ng Fable sa isang pagkakataon, na napakagaling na. Ngunit ang isang linis na patuloy kong sinisikap sa Labs sa taong ito ay: paano mo mapapalapit ang software team—ang team na ito ay Claude—sa software mismo?

Isang Sabado ng umaga, puno ang aking buong weekend ng mga gawain kasama ang aking mga anak, kaya ang pag-unlad ay ganap na "discontinuous": dadaan sa bundok kasama ang mga bata, bumalik, isulat ang dalawang linya, tapos lumabas muli. Minsan, habang nag-aakyat sa bundok, nakikita ko rin ang aking progress—kahit na hindi dapat magamit ang cellphone habang kasama ang mga bata, ang pakiramdam na makakatingin sa mobile phone at ma-monitor kung saan na ang proseso nito ay sobrang kasiyahan.

Noong noon, may naisip akong ideya: Maaari ba naming gawin ang isang masalimuot na eksperimento kung saan ang software ay magbabago sa sarili nito mula sa loob?

Ginawa kong parehong mobile at web version. Nagsimula na ako ng isang interface para sa chat, kung saan direktang pwede kong sabihin kay Claude, "Tulungan mo akong i-add ang URL na ito sa listahan ng pagsubaybay." Ngunit gustong-gusto kong lahat ng software ay mabuo ang ganitong kakayahan—hindi na ako gusto maghanap sa mga komplikadong menu para sa mga function.

Dan, sa maraming antas, talagang sinusubok kong ipagpatuloy ang agent-native architecture hanggang sa pinakamataas na hangganan.

Ang tinatawag na agent-native architecture, ang kanyang unang yugto ay: ang bawat pangunahing komponente at data sa produkto ay dapat bukas lamang sa agent, at may kaukulang interface para sa pagtawag ng tool. Ito ay mabilis na naging standard sa industriya ng software—kahit na nakakalungkot, ang karamihan sa kasalukuyang software sa merkado ay hindi kayang gawin ito.

Mayroon akong isang magandang positibong halimbawa: Noong nakaraan, binigyan ako ng isang tao ng rekomendasyon tungkol sa isang Brazilian na masterpiece na nagpapakita ng insidente ng pagkalansad ng radioactive material sa Goiânia. Ang pangalan nito ay sobrang haba at mahirap tandaan, kaya nagbigay lang ako ng bahagyang paalala sa sistema, at agad akong tinulungan ni Claude sa paghahanap at tamang pagkategorya nito. Mas maganda ang karanasan kaysa sa paghahanap ko mismo nang walang direksyon sa Google.

Ngunit ang susunod na hakbang na talagang nakakapagpapalipas ng aking interes ay: Sa isang mobile na sitwasyon, direktang baguhin ang software mismo mula sa loob nito—paano ito magiging?

Ginawa ko—o kaya't mas tama sasabihin, pinag-utos ko si Claude na gawin—ay isang interaksyon: kapag pinipilit ang button ng chat sa App, magkakaroon ng paggising sa aming托管 Agent upang tanggapin ang "mga utos para sa pagbabago ng code," at gamitin agad ang Vercel's Live Preview function para makita ang epekto. Halos isang beses lang ito pinagana, sobrang galing, at pagkatapos ay idinagdag ko pa ang ilang bagong ideya. Kung ikaw ay isang hardcore user, maaari mong tingnan ang Diff view (code difference) nito, o pumunta sa history ng chat ng托管 Agent upang tingnan kung ano talaga ang binago nito sa ilalim—ngunit halos hindi ko ito ginagawa, dahil para sa aking personal na project na toy, wala akong alam sa pangmatagalang maintainability nito (tawa).

Sobrang addictive ito. Habang naglalaro ako ng anak ko sa labas, nakita ko na "masyadong mababa ang posisyon ng floating button sa iOS," at agad kong sinabi sa App, at sarili nito itong naglalakad pabalik sa backend para ayusin ang code. Kasama ang Expo development toolchain, kumpleto pa nito ang hot reload direkta sa aking phone—ang experience noong iyon ay talagang pambihira.

Kailangan ba ng bagay na ito na maging production-level na kayang harapin ang concurrent na mga user na milyon-milyon? Hindi naman kailangan. Ngunit ibinigay nito sa akin ang isang napakagandang pakiramdam ng kontrol: hindi mo kailangang ipaghinto ang proyekto sa sandaling matapos ang weekend at isara ang iyong computer— maaari mong gamitin ito nang malakas habang pinapalitan mo ito nang sabay-sabay. Ang ganitong end-to-end real-time feedback loop ay nagpapahintulot sa iyo na mag-iterate nang walang hanggan.

Hindi ito lamang isang mahusay na pagpapakita ng kakayahan ng Fable sa pagbuo ng mga hardcode, kundi isang pagsasalin ng aming patuloy na pag-uusap tungkol sa huling tanong: Paano dapat i-embed ang Claude sa software? Dapat itong higit pa sa paggamit—dapat itong malalim na i-embed sa buto ng pagbuo ng software.

Host Dan Shipper: Gusto kong gawing malinaw sa inyo ang isang bagay: Ang mga kasangkapan tulad nito, maaari mong gawin noong sampung o dalawampung taon ang nakalipas, ngunit hindi ganito. Ang gastos sa pagbuo ng software ay nagsagawa ng malaking pagbaba. Isipin ang panahon ng paggawa ng Instagram—ilan ang mapagkukunan na kailangan upang ipagawa ang isang proyekto hanggang sa ganitong antas ng pagkakatapos? Gaano karami ngayon? Tulungan ninyo kaming ilarawan ang malaking pagbabago sa panahon na ito.

Mike Krieger:

Madalas kong tatalingkod sa mga araw na iyon. Sa mga unang panahon ng Instagram, palaging naniniwala ako na isang napakadali-daling engineer—napakalalim ang aking pagmamahal sa mobile development at napakalakas ang aking intuisyon sa direksyon ng produkto. Ngunit kahit ganito, mula sa isang ideya sa isip ko hanggang sa pagpapatupad nito nang buo, mayroon pa ring kahit apat hanggang limang gabi ng pagpapakapagod. Noon, ang paggising hanggang sa umaga ay aking pang-araw-araw: nagmamadali hanggang alas-kwatro ng umaga, tapos natutulog hanggang sa tanghali—ang ganitong takdang oras ay lubos na hindi nakakasama sa pamilya, ngunit iyon talaga ang aking "Builder mode" noong panahong iyon.

Balikan ang V1 na bersyon ng Instagram—talagang may higit pang mga tampok kaysa sa aking media tracker na ginawa ko sa katapusan ng linggo, ngunit walang pangunahing pagkakaiba sa antas. At noong ginawa namin ang V1 na iyon, si Kevin at ako ay nagtrabaho nang walang tulog sa loob ng limang gabi: ako lang ang nagsagawa ng lahat ng frontend at backend, habang si Kevin ang nagsolba sa mga unang filter ng larawan. At ito ay batay sa aming parehong maraming taon ng karanasan sa iOS development.

Hindi na lang ang pagiging mapagod sa ritmo ng pag-update noong unang panahon. Pagkatapos ng matagumpay na paglunsad ng produkto, puno ang isip namin ng libu-libong bagong ideya, ngunit ang lahat ng ating enerhiya ay ginugol lang upang siguraduhing hindi mabubulok ang server sa malaking trapiko, o kaya’y kumikita ng kaunting oras para magdagdag ng isang maliit na function. Halimbawa, ang function ng Hashtag—nag-antay ako ng isang buong linggo para lang makapagsulat nito, habang may libo-libo pang gawain na nakakapit sa iyong listahan ng mga gawain.

Kaya, hindi ito tungkol lang sa pagkakabawas ng oras—kahit na ang pagbuo ng oras ay naikli sa isang nakakaloka antas—mas mahalaga ang kabilang panig ng coin: ngayon ay maaari mong i-iterate agad ang iyong mga kasalukuyang bagay sa isang napakasariwa, napakalawak na paraan.

At ang ganitong benepisyo ay nagsimulang magpalabas, lalo na sa labas ng mga grupo tulad ng akin bilang propesyonal na software engineer at founder. Noon, kung ikaw ay may isang napakagandang ideya sa negosyo ngunit hindi ka marunong mag-code, ang iyong mga pagpipilian ay dalawa lamang: o mag-hire ng outsourced—na kung saan ay mayroong napakalaking pagkawala ng impormasyon at kahina-hina ang output; o kailangan mong mag-raise ng pondo nang malakas. Ngayon, ang pagkakaiba sa pagitan ng "intensyon" at "paggawa" ay naging pantay na para sa mga karaniwang tao na hindi marunong mag-code.

Kilala ko ang isang internal na kapatid sa loob ng ilang araw. Tinulungan namin siya na i-configure ang isang internal tool na nag-uugnay sa mga kakayahan ng Fable at sa ilang internal na MCP (Model Context Protocol) access. Isang HR siya, at nagsabi siya sa akin nang may pagmamalaki: "Ito ang unang beses sa aking buhay na nadarama kong walang kalayuan ang mga bagay na isip ko at ang mga bagay na umiiral sa realidad. Diretso kong makakagawa nito."

Iyon ang isang makabuluhang sandali para sa kanya. Kung ito ay nangyari sa loob ng apat o limang taon, kung kailangan niya ng isang espesyal na business tool, kailangan niyang gamitin ang iba’t ibang available na software na pinagsama-samang may kakulangan, o kaya’y humingi ng tulong sa mga inhinyero ng internal tool team—na maaaring mayroon nang 50 na mas mataas na prioridad sa kanilang Jira backlog. Ngayon? Siya ay masaya sa pagtatayo ng kanyang sariling mundo sa code.

Ito rin ang aking pinakamalaking inaasahan para sa kinabukasan: walang hanggan ang pagkamalikhain ng tao, at ang pinakamalaking bagay na ginagawa natin ngayon ay ang walang hanggang pagpapalawak sa hangganan ng mga taong may kakayahang gawing totoo ang kanilang mga nais.

Host Dan Shipper: Buong-puso akong sumasang-ayon sa iyo. Ngunit naniniwala ako na marami sa mga tao ngayon ang may huling tanong: Pagkatapos ng lahat ng iyong sinabi, ang software engineering ba ay lubos nang tapos na?

Mike Krieger:

Dapat sabihin na ang kahulugan ng software engineering ay ganap na nagbago. Ito ay nasa gitna ng isang malaking pagbabago.

Kung tanungin mo ako noong panahon ng Instagram: “Ano ba talaga ang software engineering?” masasabi ko sa iyo: I-isip nang mabuti ang mga mahirap na design challenge, itayo ang system architecture, at tapusin ang maraming oras sa TextMate o Xcode. I-solve ang mga detalye sa ilalim ng Django ORM, at pagkatapos ay i-deploy at magtrabaho nang mabuti para i-fix ang mga bug. Ngayon, ang karamihan sa mga hakbang sa prosesong ito ay naibalik na, at patuloy na lumalapit sa hangganan ng product management. Ngayon, ang hangganan sa pagitan ng product manager at engineer ay naging napakalalim. Ito ay napakalalong nakikita sa aming sariling team ng pagpapalawak.

Ngunit kung makakalabas ka sa sobrang pilit na literal na depinisyon ng "software engineering" at susuriin mo ang mas malawak na "software production" o "software development"—hindi lang ang maliit na bahagi ng pagkakasulat ng code ng mga programmer—makikita mo na ang industriyang ito ay hindi lamang nabubuhay, kundi nasa pinakamalaking sentro nito sa kasalukuyan.

Ang pagkakaroon ni Fable ay talagang nagdala sa akin ng isang bagong antas ng tiwala sa mga modelong AI—nagsimula akong pagsisiwalat sa pagpapatakbo nito ng isang buong awtomatikong loop, kahit sa paggawa ng makabuluhang disenyo ng sistema. Sa aspeto ng teknikal na pagsasagawa, napakalayo na ng AI. Ngunit ang "pagpapanatili ng kaluluwa ng paggawa ng software"—tulad ng pag-unawa sa anong mga problema ng gumagamit ang iyong sinusugpo, o kung ang iyong likha ay may sapat na kahanga-hangang karanasan—ang mga ito ay mga pangunahing pagpapasya na nananatiling lubos na tao at hindi maaaring palitan ng makina.

Of course, this painful transition is not painless for many people.

Sa mundo na ito, marami ang dating lubos na nakasalig sa kasanayan ng "pagsusulat ng code nang kamay". Ganun din ako noong una. Ang kasiyahan sa paglutas ng isang bug na nagpapahinga sa akin ng tatlong araw—hindi ito maaaring palitan. Noon, kahit sa mga pangarap mo ay nakikipaglaban ka sa code—kung mayroon ka nang ganitong karanasan, ang mga pangarap mo ay puno ng mga logika na pinipigilan, at sa sandaling gumising ka, biglang naiintindihan mo ang solusyon. Ang malinis na panahon ng mga manggagawa na ito, malamang ay hindi na muling babalik.

Kamakailan ay nagsalita ako sa ilang mga pinakamahusay na hard-core engineer na kilala ko, at lahat sila ay nagpapahayag ng isang malakas na kumplikadong damdamin: ang malaking pagkawala sa pagmamasid sa pagkawala ng tradisyonal na kasanayan, kasama ang sobrang kasiyahan na "Wow, ang aking kasalukuyang concurrency productivity ay talagang napakalakas!"

Host Dan Shipper: Kung ang proposition na ito ay totoo—na ang software engineering ay hindi lang nabubuhay, kundi nabubuhay nang mabuti—paano ba talaga nila ginagawa ang kanilang sariling R&D sa loob ng Anthropic sa araw-araw?

Mike Krieger:

May ilang malinaw na palatandaan dito, at maaari kong pagtalakayin kasama ang buong buhay cycle ng software at ang aking araw-araw na nakikita sa pag-develop.

Una pa rin ang malaking dami ng "human alignment." Magkakalap ang mga tao sa meeting room, magbabahagi ng mga ideya tungkol sa susunod na direksyon ng Cowork, at sasagupain ang blueprint sa iba’t ibang responsibilidad ng mga miyembro. Mahalaga pa rin ang hakbang na ito, dahil maraming pangkalahatang konteksto na only humans ang kayang maunawaan—tulad ng totoong negosyong intensyon ng produkto, kasalukuyang development roadmap, at mga impormasyon tungkol sa iba pang mga produkto na malapit nang ipatigil o ihahalo sa isang napakaliliit na paraan.

Kahit na mayroon tayong maraming Claude towers para sa bawat miyembro ng aming team, sa pagpapatakbo, bawat isa ay mayroon pa ring titulong DRI (Directly Responsible Individual, Direktang Sagot na Indibidwal) at may sariling responsibilidad sa isang partikular na module ng produkto. Naniniwala ako na ang mekanismong ito ay hindi magkakaroon ng pagtatapos sa maikling panahon, dahil may malaking pagkakaiba sa pangkalahatang pananaw na "magkakasama ang team sa distributed collaboration upang gawing perpekto ang produkto" at sa konkretong pagpapatupad na "paano ko ito gagawin ngayon para maipasa ang task na ito sa Claude." Kahit na malakas naming ipinopromote ang minimal meeting policy, kailangan pa rin ng mga ganitong pre-workshop at alignment meetings.

Pangalawa, ang malaking bilang ng "asynchronous orders." Marami sa aming mga inhinyero ang nagmumodify ng kanilang sariling personal dashboard upang masubaybayan kung ano ang ginagawa ng kanilang mga Claude army: "Nasaan na ang aking isang Claude Code?" , "Mayroon bang naka-queue na naghhintay ng aking pag-approve?" , "Mayroon bang PR na kailangan kong i-intervene at baguhin—dahil tinanggihan ito ng ibang kaklase o ng code review ng isang malaking model?"

Ngayon, malaking bahagi ng pagsisikap ng mga inhinyero ay nakatuon sa pagpapanatili ng ganitong uri ng trabaho. Ang ilang mga kasangkapang pangkakasundo ay sinusubukan nating i-standardize, ngunit ang karamihan ay nananatiling may malakas na personal na estilo ng geek—tulad ng dati ay paborito ng mga programmer na personalisahin ang kanilang sariling desktop window, ngayon ay personalisado nila ang kanilang sariling workflow para sa malalaking modelo.

Bukod dito, ang pag-unawa sa totoong paggana ng code sa production environment. Ito ang isa pang nangungunang harapan na pinagsisikapang lutasin ng mga malalaking modelo. Nakikita na ng Fable ang malaking pag-unlad sa aspetong ito, ngunit mayroon pa ring mahabang daan: tulad ng pag-unawa nang malalim kung ano ang mangyayari pagkatapos i-deploy ang code. Maaaring mabigo ang sistema at maaaring magkaroon ng iba’t ibang hindi inaasahang kakaibang pagkabigo—seryoso, sa mga taon mula 2012 hanggang 2016 sa Instagram, halos kalahati ng aking buhay ay ginugol sa pagharap sa mga insidente sa production at pagpapalawak ng arkitektura. Sa pagharap sa mga biglaang insidente sa production, ang papel ng senior engineer ay patuloy na hindi mapapalitan: kailangan mong gamitin ang iyong maraming taong karanasan sa pag-sosolba ng insidente upang manatiling kalmado, makalap ang lahat ng log data, magpatupad ng emergency containment, at pagkatapos ay mag-isip ng mga pangmatagalang solusyon.

Ang huling punto na gusto kong bigyang-diin ay: ang papel ng "engineering prototype" ay ganap na nagbago ngayon.

Dapat mong malinaw na tukuyin kung ang bagay na nasa iyong kamay ay isang Demo o isang production-level na code na handa na para i-deploy. Noon, sa Silicon Valley, may isang pahayag na sinasabing "Ang code ang mananalo sa mga talakayan" (Code wins arguments), at sa personal kong pananaw, hindi ako lubos na nagustuhan ito dahil ang implikasyon nito ay ang sinumang marunong mag-code ay may kontrol sa pag-uusap. Ngunit ngayon, ang sitwasyon ay naging napakaganda sa pagbabalik-balik: minsan, habang naka-stalemate tayo sa isang direksyon ng produkto, madalas ay may isang PM na hindi nagkakode na lumapit at sasabihin: "Bago ko lang ako mismo gumawa ng isang Demo, at bagaman mayroon pa akong 8 na detalye na hindi pa maayos—tingnan ninyo, ang daang ito ay tiyak na maaaring magtrabaho!" At agad ito ay nagbukas ng isang lubos na iba’t ibang mataas na antas ng talakayan.

Tingnan natin ang nakaraan, ang lahat ng aming kasalukuyang mga pag-unlad ay lubos na nagbago kumpara sa anim na buwan ang nakalipas. Ang pinakamalaking katangian ay ang takot na pagkakasunod-sunod ng pag-unlad, at ang kritikal na pangangailangan ng team na mag-abstrak sa mataas na antas ng kanilang workflow.

Ngunit isa lamang ang hindi nagbago mula simula hanggang wakas: ang "pagmamay-ari at pagkakaroon ng responsibilidad" ng tao sa mga produkto.

Host Dan Shipper: Ang Fable ay sobrang mahal. Habang sinubukan ko ito, parang bata sa isang tindahan ng kandila ang nararamdaman ko, nagsisigaw nang excited: "Gusto ko ito, ito, at ito!" Pero nang dumating ang panahon na magbayad, bawat beses na pinipindot ko ang Enter, may nag-iisip sa loob ko: "Baka biglaan akong magkost ng $100 o higit pa?" Naniniwala ako na ang mataas na presyo nito ay nagtatag ng isang hindi nakikita na hadlang sa kung sino ang makakagamit nito at kung ano ang gagawin nito. Paano mo ito isasalin sa value-for-money sa negosyo?

Mike Krieger:

Sa propesyonal na larangan ng software engineering, ang aklat na ito ay may pinakamalinaw na pagkalkula. Tungkol sa pagtatakda ng presyo, mayroong maraming dimensyon sa loob na pinag-uusapan. Totoo itong mas mahal kaysa sa Opus, ngunit kung iyong ihahambing ang napakalaking dami ng trabaho na ipinapadala nito sa bawat pagkakataon, sa maraming aspeto ng negosyo, parang libre lang ito. Samantala, mayroon man lamang bawat tao ang kanyang sariling ekonomikong aklat.

Mula sa pananaw ng software team, kung ang unang yugto ay ang kompanya na nagpapakilala sa AI programming sa mga empleyado—ang model ay paunang yugto at ang mga kasangkapan ay hindi pa handa; ang ikalawang yugto ay ang paglikha ng leaderboard upang makita kung sino ang pinakamaraming gumagamit, na maaaring magdulot ng hindi ideyal na mekanismo ng insentibo; ang ikatlong yugto ay ang pag-unawa kung sino ang pinakaepektibong gumagamit, at pagsiguro na sila ay magagamit nang mas marami, habang may malinaw na proseso upang maiwasan ang pagkawala.

Ang modelong Fable ay perpektong tumutugma sa lohika ng yugto 3. Kung kayang mong patuloy na magbigay ng malalakas na output at gamitin ito nang totoo upang lumikha ng tunay na halaga sa negosyo, magkakaroon ng positibong flywheel budget mechanism sa loob ng kumpanya na magpapatuloy na susuporta sa iyo.

Sa personal use, sa pagsubok ko mismo, gumagamit ako ng aking sariling credit card at nagbabayad ako ng aking pera para sa aming sariling serbisyo. Sa ganitong sitwasyon, talagang naging mas maingat at mas mapagkumpitensiyo ka. Ngunit interesante, ang media tracker na ginawa ko sa weekend, kung ikukumpara, halos pareho lang ang gastos kaysa sa karaniwan—hindi pa naman umaabot sa libo-libong dolyar ang gastusin para sa isang personal project.

Ang mga taong tunay na nakakapag-iiyak dahil sa presyo ay ang mga open-source enthusiast o indie hackers na hindi nasa ilalim ng proteksyon ng malalaking kumpanya at sobrang sensitibo sa presyo. Ang aking payo sa kanila: Magpahintulot na umabot, tingnan kung gaano karaming bagay ang maaari nitong ipagkaloob nang hindi sumasailalim sa walang-wakas na "pagpapalit-palit".

Ang kasalukuyang ‘gastos’ ay naging isang maramihang konsepto—hindi lang kailangan mong kalkulahin ang ‘gastos sa isang pagtatanong’, kundi ang ‘komprehensibong gastos sa pagkumpleto ng isang gawain’. Ang pinakamasidhi sa Fable ay ang huli: ito ay palaging nagtatangkang gawin nang tama sa isang pagkakataon, nang hindi kailangan kong upo sa harap ng computer at maglaban ng walong siyam na round, na umiiyak nang desesperado: “Hindi iyan! Iyon ang ibig kong sabihin!”

Host Dan Shipper: Ang pinakamakapagpapahinga sa akin ay ang pagbibigay mo ng isang makro na gawain, at kapag isinumite nito, nakikita mong sinuri nito ang bawat detalye, kahit sa pinakamaliit na sulok—ang nakakalilimot na detalye na hindi ko pa nararanasan sa anumang modelo dati. Maaari mo bang ibahagi ang ilang paliwanag tungkol sa pagtuturo? Ano talaga ang kinain upang makabuo ng ganitong takot na pag-unawa?

Mike Krieger:

Sa maraming antas, ito ay patuloy na pagkilos ng team—nagpapakita ako ng malaking paggalang sa aming pre-training at RL team. Ang pinakamalinaw na pag-unlad para sa akin ay ang "pagkakaroon ng pagkaunawa sa buong sistema," hindi lamang sa kasalukuyang trabaho.

Madalas akong naaapektuhan ng ilang mga "god-like" na pagkilos nito. Halimbawa, agad itong magpapakita ng isang mensahe kapag tapos na itong sumulat ng isang code: "Sir, alam kong sa totoong production environment, maaaring iba ang configuration dito. Naka-on ba ang iyong feature toggle? Kung hindi, hindi magiging epektibo ang aking isinulat na bagay."

O kaya, tingnan kung paano ito sumasagot sa feedback sa code review—ano man ang galing sa tao o sa ibang Claude—hindi ito simpleng sinasabing, "Oh, tama, ito ay isang problema, i-aayos ko ito." Tunay na isinusuri nito kung dapat tanggapin ang panganib sa kasalukuyang antas ng fidelity, o ipagtanggol ito laban sa isang ibang reviewer—madalas ay isang ibang Fable model—at sabihin, "Naiintindihan ko ang iyong punto, ngunit ipagtatanggol ko ito; naniniwala ako na mali."

Mahalaga na magkaroon ang modelo ng ganitong kakayahan sa pagpapasya. Kung dapat kong tukuyin kung saan ito nagkaroon ng pinakamalaking pag-unlad, iyon ay ang paghinto nito sa pagmamaliit na agad na sabing "Oo, oo, pupunta ako para ayusin ito"—kundi mas katulad ng "Hayaan mo akong isipin muna. Patuloy akong hindi sumasang-ayon." Ang kakayahan na ito ay napakalaking tulong.

Ang pagkakaroon ng produkto tulad ng Claude Code sa merkado ay napakahalaga, dahil mayroon kang tunay na bagay na maaaring sabihin ng mga tao: "Ito ang magandang bahagi ng model, at ito ang hindi magandang bahagi nito." Isinasaalang-alang namin ang mga kasamahan ng Every bilang isa sa mga pinakamataas na prioridad sa mga pinagkakatiwalaang pinagmumulan ng feedback, dahil sila ang nagpapasa sa model sa paulit-ulit, matagal at intensibong gawain, na napakahalaga para sa aming pag-iisip kung ano ang dapat pagbutihin sa susunod na henerasyon.

Host Dan Shipper: Ang chat ba ang pinakamahusay na interface para sa model na ito? Hindi ito isang round-based na interaksyon, kundi mas tulad ng pagkakaloob ng isang gawain sa isang tao. Paano ito magiging epekto sa paraan kung paano mo dapat gamitin ito, o kung paano mo ito pinapahalagahan?

Mike Krieger:

Ang basic na modelo ng pagpapadala at pagtatanggap ng mensahe ay hindi lubos na mali, ngunit kailangan nating umunlad sa ilang direksyon.

Una: Ang iyong laptop ba ang tamang lugar? Ito ang lugar kung saan nabanggit ko na ang mobile device ay napakagagamit para sa mga personal na proyekto. Laging nasa harap ng kalahating hakbang ang mga tagagawa ng Claude Code sa paraan ng paggamit ng mga modelo; noong halos siyam na buwan ang nakalipas, nagsabi siya sa akin: "Ikinuha ko ang aking karamihan sa mga gawain sa Claude Code sa mobile." Naging skeptiko ako noon, ngunit lalo na sa antas ng Fable, dahil ito ay nakakapagpanatili ng session, at mayroon tayong remote development machine sa Anthropic, kaya ang unang punto ay: i-decouple ang lugar kung saan nangyayari ang gawain mula sa lugar kung saan pinag-uusapan ko ang gawain.

Ikalawang punto, kasunod ng aking nabanggit kanina: Paano mo hahawakan ang lahat ng pinag-usapan, pinasyalan, at inirerekumenda ni Fable, at gawin itong maunawaan? Ito ang larangan kung saan kami nag-iisip. Mayroong ilang skill na makakagawa ng mga grapiko, ngunit ang kasalukuyang UI ng chat ay hindi sapat; minsan ay ibibigay ni Fable ang sobrang dami ng teksto, kaya kailangan mong maglakad-lakad bago ka handa na maunawaan ito. Isang bagay na sinimulan kong gawin ay: "Mas marami ang iyong konteksto sa bagay na ito kaysa sa akin. Maaari ba nating bumalik—gawin natin ang mas maraming pagpapakita ng kumplikasyon nang paunti-unti?"

Ang ikatlo ay ang multi-player mode, at kasalukuyan pa naming sinusubukan ito sa mga maagap yugto. Sa ilang paraan, dahil mayroon tayong DRI at istruktura ng ownership area, karaniwan ay isang mahalagang gawain ang pagpapalipat sa isang tao at ilang Claude. Ngunit may ilang kaso kung saan hindi gaanong malinaw—halimbawa, ang pagtugon sa aksidente, kung saan maraming tao ay nag-iisip nang sabay-sabay; o mga proyekto kung saan nagkakasalubong ang maraming cross-functional na larangan. Ang pagbabahagi ng chat ay nakakatulong sa ilang bahagi, ngunit naniniwala akong mayroong kinabukasan na pangangailangan: mayroon ka na isang independiyenteng Claude na pinagsimulan ng isang tao at gumawa ng maraming trabaho, ngunit kaya ba nito na mag-sync sa lahat ng iba pang ginagawa ng team? Ito ang susunod na interesante at hindi sapat na pag-aaral na harapan. Nakakaligayahan na ang mga modelo ay may kakayahang maging totoong kasamahan, at halos hinaharap natin sila dahil wala tayong tamang abstrakson.

Host Dan Shipper: Ilang beses ko ito ginagamit para sa aking sariling vibe coding project, pero may isang problema kapag ginagamit mo ito sa loob ng isang organisasyon: Naiintindihan ko ba talaga lahat ng bahagi na ginawa ng model? Paano ko isasalin sa aking isip ang konteksto ng lahat ng ginawa ng model? Ito ay isang malaking bottleneck. Paano mo ipinapakita ang linya kung gaano karaming impormasyon ang kailangan mong malaman, at paano mo siguraduhing may sapat kang konteksto upang maramdaman ang kasiyahan?

Mike Krieger:

Dalawang malalaking bahagi. Ang unang bahagi ay ang pag-verify. Noong simula ng taong ito, lubos akong napaniniwalaan ng pag-verify, na may kaugnayan sa isang bagay na aking ginawa noong ako ay full-time na programmer: mahanap ang pinakamabilis na development cycle upang i-round out ang iyong ideya. Sa panahon ng Instagram, minsan ay nangangahulugan ito ng paggawa ng isang bagong build target sa Xcode na naglalaman lamang ng isang screen at synthetic data, at pag-iterate lamang sa cycle na ito. Ginagawang mentor ko ang mga bagong engineer na "Kung ako ay magtuturo lamang ng isang bagay, ito ang gagawin ko—gawin mo ito para sa iyong proyekto, mas mabilis ito."

Kasalukuyang sitwasyon ay: bawat beses na gumagawa ako ng isang bagay, paano ko masisiguro na ang bawat PR ni Claude ay may kasamang larawan o video—ano man ang iOS PR o pagbabago sa UI layer. Ito ang nagbibigay sa iyo ng maraming tiwala. Maaaring magtrabaho nang ilang oras ang Fable nang mag-isa, at pagbalik niya ay sasabihin niya, "Nakakumpleto na ako," at pagkatapos ay makikita mo ang "dito ang buong gallery ng screenshots ng UI"—at napakatulong nito. Sasabihin mo, "Sa screenshot na iyon, yung error state—kung saan ako ay hindi pa nagkakaroon, ngunit makikita ko kung ano ang mangyayari kung makakatagpo ang user nito. Palitan natin 'to." Ang pagsasagawa ng komprehensibong pag-verify ay isang malakas na fokus namin sa loob.

Ikalawang bahagi: Sa huli, ikaw ang responsable sa ginawa mong trabaho. Maraming tao ang gumagamit ng Claude araw-araw, ngunit mayroon pa ring pagkakasala—“Baka nagsulat ang Claude ng code, ngunit kailangan mong maunawaan ang anong mga makro na desisyon ang ginawa.” Nakikita ko ang isang malaking bilang ng mga inhinyero na nagpapatupad ng isang praktika: Pagkatapos gawin ng Claude ang trabaho, may sumusunod na talakayan—“Pwede ko ba siguraduhin na lubos kong nauunawaan ang lahat ng mga kompromiso na ginawa mo?” Anuman ang maliit na artifact na nailabas, kung makakatulong ito sa paggawa nito ng mas madaling maunawaan, worth it.

Kapag nagmumeon ang isang tao, "Naghanda na ako sa PR na ito," at ang isang iba ay sasabihin, "Ginawa mo ba ang X o Y?" at may sandaling paghinto: "Seryoso, hindi ako sigurado—aayusin ko iyon bago i-merge." Ang pag-adapt sa bagong normal na ito at pag-unawa kung paano magtrabaho dito ay kailangan nating lahat matutunan.

Host Dan Shipper: Ang "verification loop" na iyong nabanggit ay may malaking potensyal. Bukod sa automated screenshot at screen sharing, ano pa ang iba pang mas advanced na ideya na inyong sinusubukan?

Mike Krieger:

Ang aming pangunahing punto ay: Maaari mo ba itong gawing tumakbo sa tunay na proseso, hindi lang mag-inject ng static data? Habang lumalaki ang sistemang ito, mas mahirap ito. Halimbawa, kailangan naming gawing maaaring mag-login nang iisa ang iOS app na gawa ng Fable sa aming simulation environment, na gumagamit ng pinakatotoong test account at high-fidelity real data stream. Ngunit hindi namin gustong pagsikapan itong patakbuhin ang mahabang 8-hakbang na proseso ng pag-rehistro ng bagong user bawat beses na sinusubok ang pagpapalit ng isang simpleng button. Kaya, lumikha kami ng isang espesyal na sistema ng mataas na pahintulot at encrypted shared key para sa AI, upang makapag-iskip ito nang iisa ang mga unang hakbang at direktang makapasok sa pinakamahalagang bahagi ng negosyo, upang maging halos pixel-perfect ang karanasan ng pagsubok nito sa karanasan ng tunay na user.

Ang pangalawang bahagi ay ang kombinasyon ng kilalang path at kasalukuyang nagbabagong path—ang unang isa ay napakasanggunian para sa regression testing. Naisama na namin ang ilang idealisadong workflow sa pagsulat, na maaaring pagsuriin muli at muli ni Claude. At napakagaling ni Claude sa pagpapahayag ng kanyang intensyon sa kasalukuyang bahagi ng pagbabago, kaya ang bahaging ito ay mabubulag sa malalim na pagsasanay. Mahalaga ang kombinasyon ng dalawa.

Ang visual verification ay mahalaga rin, at ang video ay isang napakadaling hindi ginagamit na kasangkapan para sa Claude. Kamakailan ay gumawa ako ng isang prototype: ginawa kong video recording ang mga bagay na nilikha ni Claude, at isinumite ko ito sa kanya kasama ang FFmpeg, habang pinapanood niya ang bawat frame nang hiwalay, at sinasabi niya, "May stutter ang animation na ito, i-aayos ko ito." Hindi makakakuha ng screenshot ang ganitong pagkakataon, dahil nawawala ang sandaling iyon sa screenshot.

Para sa mga bahagi na mahirap end-to-end i-test, maaaring hayaan ni Claude na lumikha ng isang mapagkakatiwalaang simulated backend, o gamitin ang isang available na isa, na napakaganda rin. Sa panahon ng Artifact, mayroon tayong napakalawak na pagsubok mula pa noong bago ang LLM. Bawat bahagi ng infrastraktura ay may isang mahusay na memory implementation na maaaring mabilis na i-run sa unit tests. Ngayon, ipalawak natin ito sa larangan ni Claude: gumagawa ako ng isang bagay na may matatag na backend na mahirap i-start sa aking development server, ngunit bigla itong nagbigay ng isang mahusay na alternatibo. Habang lumalago, umuunlad din ang alternatibong ito kasabay ng pag-unlad ng sariling code. Noon, sasabihin ko, "Ang pag-sync nito ay sobrang pagod." Ngayon, isip ko lang, "Sasabihin ni Claude ang mga pagbabago, i-adapt ang alternatibo, at panatilihin ang parehong side na naka-sync."

Host Dan Shipper: Mayroong ilang napakagandang arkitektura: kapag nakatanggap ka ng isang bug, automaticong nag-aayos ang isang agent, at pagkatapos ay nagpapadala ng mensahe sa kliyente na "naiayos na". Nakita mo ba ang anumang pagbabago sa proseso na ito sa Fable?

Mike Krieger:

Mga aspeto. Sa antas ng tao at Claude, isang bagay na paulit-ulit kong nakikita: Kung may nagrereport ng bug sa feedback channel namin sa Slack, ang thread na iyon ay ipinapasa sa sesyon ng Claude Code. Dahil sa Slack MCP, maaari itong talakayin ang thread at magpadala pabalik sa pangalan ko: "Ito si Mike's Claude, naayos ko na ito, narito ang link ng PR." Pero pagkatapos ay sasabihin niya: "Huwag muna—hindi pa ito naka-deploy. Kapag naka-deploy na, iinformed ko kayo ulit." Ilang oras pagkatapos: "Nakapag-deploy na ang deployment na ito. Dapat subukan ninyo kung naayos na." Ang pagsusuri at pagtugon sa loop na ito ay relatibong bago. Mayroon akong ilang mahabang nagpapatakbo na sesyon ng Claude Code na nag-iinteraktibo sa pangalan ko. May ilang disclaimer din ako isinama doon.

Ikalawang bahagi ay bumabalik sa aming nakaraang pag-uusap tungkol sa lasa at paghuhusga. Isang antas ay "may bug na ipinapahayag, kaya kailangan kong ayusin ito," samantalang ang isa pang antas ay ang pagkakaroon ng mabuting paghuhusga. Naranasan ko ang isang sitwasyon noong weekend: mayroon kaming isang internal system na nagtatrabaho nang mahaba nang walang pag-restart at may memory leak. Ang mabuting paghuhusga ay: "Mike, weekend na. I-restart mo na lang ang server, agad ito ay lulusot, at ikaw ay magpapadala ng PR nang asynkrono para sa permanenteng pag-aayos." Kung gagamitin mo ang Claude sa proseso mula sa bug papunta sa pag-aayos, talagang gusto mong maintindihan nito ang anumang bagay na maintindihan ng anumang mabuting SRE o engineer: ayusin ang problema sa kasalukuyan, at ang pagbabago ng platform o pag-reconstruct ay isang iba pang usapin. Mahalaga ang pag-unawa sa balanseng ito.

Host Dan Shipper: Ang pinakamalaking nakakapagpapalakas ng loob sa mga bagong modelo na ito ay hindi lamang itinataas nito ang minimum, kaya makakagawa ng sariling App ang anumang karaniwang tao nang iisa lang ang pag-click, kundi pinapalabas din nito ang limitasyon ng mga eksperto. Kung ikaw ay isang propesyonal na inhinyero o tagapagsimula ng isang startup, may kakayahang mag-isa kang tapusin ang mga proyektong dating hindi mo kaya isipin. Sa iyong palagay, anong mga maunlad na larangan ang maaaring hindi pa nababatid ng marami, ngunit maaaring gamitin nang buong pagkakataon ang mga modelo na ito?

Mike Krieger:

Ilang ideya, maaaring magsimula muna sa mga nakakatuwa. Palagi mayroong maraming malikhaing ideya ang mga tao tungkol sa paano ipahayag ang kanilang kumplikadong mundo, at sa bawat larangan, mayroon kang isang bagay na lubos mong nauunawaan, at laging may bersyon na, “Paano ko ito ipapaliwanag sa iba? Maaari ko ba gamitin ang teknolohiya mula sa ibang lugar sa aking sarili?” Sa aking kaibigan na si Taitan, kanyang pinapagsisikapan ngayon ang environmental engineering—lalo na sa direksyon ng geothermal energy—na puno ng nakakapagod na mga matematikal na modelo at simulation ng fluid dynamics. Ngunit kasunod ng malaking pag-unlad ng Fable na henerasyon ng reasoning model, nakamit niya na mag-apply nang perpekto ang mga teknolohiyang lubos na nasa labas ng kanyang larangan sa kanyang sariling pananaliksik. Ngayon, kaya niyang utusan ang Fable na magtayo ng isang end-to-end deep learning simulation system na may buong PyTorch—na dati’y tila imposible para sa isang akademiko na hindi galing sa computer science.

Ang pangalawang bahagi ay ang kakayahan nito na mag-combine ng software upang lutasin ang mga problema na lubos na natatangi sa iyo. Sa loob, ang aming malaking gawain ay ang pag-MCP ng aming karamihan sa mga internal na sistema, kasama ang tamang istruktura ng pahintulot at pag-deploy. Mayroon ding magagandang PaaS platform sa labas na maaari mong tanungin si Claude, at sasagot siya sa iyo. Pero lubos kong pinapahalagahan ang pakiramdam na "ginawa ko ang isang bagay na palaging nais ko."

May isa pang bagay na lubos na nag-impluwensya sa akin. May isang kasamahan sa aming komersyal na tim na hindi nagmula sa teknikal na larangan, ngunit pinagsama niya nang malalim ang Claude sa bawat bahagi ng kanyang araw-araw na proseso ng negosyo. Ang pinakamakakatakot ay hindi siya tumigil pagkatapos makumpleto ang bersyon 1—ginamit niya ang kasangkapan na ito at nagsagawa nang tahimik ng maraming malakas na iterasyon sa likod, kasama ang malaking modelo, sa loob ng ilang buwan.

Ito ang eksaktong nagpapakita ng pinakamalaking underappreciated at pinakamagandang aspeto ng mga modernong reasoning model: sa ilalim ng antas ng pangangailangan ng mga nakaraang henerasyon, ang mga proyekto ay karaniwang may "天花板 ng kumplikasyon." Kapag ang iyong code o lohika ay tumagal na sa isang tiyak na dami, ang malaking model ay magsisimulang "mag-isip ng unahan at kalimutan ang likod," at kapag gustong idagdag mo ang isang bagong feature, ito ay magiging seryosong nagkakaroon ng error at direktang sasabogin ang iyong dating arkitektura.

Ngayon, ang kaniyang kolaborador na hindi nakaka-code, na may suporta ng modelo sa antas ng Fable, ay nagpapatuloy na pinag-aaralan ang kaniyang sistema sa background ng ilang buwan. Malinaw mong makikita ang software na parang isang buhay na organismo na lumalago, lumalago, at sumisibol nang palalim sa ilalim ng pagpapalaki ng AI. Ngayon, sinisimulan na niya ang pag-deploy ng napakalaking at kumplikadong sariling sistema sa buong komersyal na departamento ng ating kumpanya.

Isang karaniwang tao na walang anumang pagsasanay sa pag-program, ngayon ay nakakapag-iiwan ng isang kumplikadong software na may mahabang siklo hanggang sa isang antas na nakakalungkot—ito ay isang dakilang kagitingan na walang katulad sa kasaysayan ng teknolohiya ng tao.

Host Dan Shipper: Ang isa pang napakalakas na bagay na sinabi mo ay ang dynamic workflow, paki-paliwanag mo pa nang higit pa?

Mike Krieger:

Madalas namingay namin ang mga ganitong advanced na tool sa loob, at sasabihin ko sa mga inhinyero na sumusulat ng mga tool: "Kailan ba talaga ito ipapalabas sa publiko?" Minsan, dahil sa mga limitasyon sa pondo ng infrastructure, kailangan muna itong ipagana sa loob, ngunit pinopush namin ang lahat para maipalabas ang mga ito sa merkado nang maaga. Para sa akin, ang dynamic workflow ay isa sa mga tool na magiging nakakapagtaka sa buong mundo.

May dalawang malaking dahilan kung bakit ang mga modelo tulad ng Fable ay lalong makapangyarihan. Una, nakakatulong ito sa iyo na gumawa ng mga balangkas para sa malalim at may kahulugang trabaho. Ang pinakamaliksi kong ginawa gamit ito ay ang pagpapadala nang direkta sa Fable ng isang kumplikadong panloob na Python project, at itinuro ko sa kanya na i-reconstruct ang buong core business sa bersyon ng TypeScript—noong mayroon kaming isang partikular na pag-aalala sa online deployment.

Noong panahon sa Instagram, ang mataas na pamamahala ay nagsagawa ng napakaseryosong talakayan: "Dapat ba naming isulat muli ang buong pondo ng code ng IG gamit ang wikang Hack upang maipagsama nang walang pagkakamali sa imprastruktura ng Facebook?" Ang aming konklusyon noong panahong iyon ay: Hindi na lang, hindi ito praktikal o makakaya.

Ngunit noong nakaraang weekend, habang nagtatagpo ako ng isang magkakasalungat na core codebase, isinulat ko agad ang isang dynamic workflow sa background, at pagkatapos ay umalis ako para mag-enjoy ng weekend. Ang workflow na isinakay ko ay: malalim na pag-unawa sa umiiral na code, paglikha ng isang dokumento na parang spec na naglalarawan kung paano gumagana ang lahat, pagkakasunod-sunod na pagsasalin ng bawat module, incremental testing, adversarial validation, at pagsusuri sa mga nawawalang bagay. Nang bumalik ako sa lunes at buksan ang aking laptop, nangyari ang isang kagandahan—naging isang bagong sistema na tumatakbo sa TypeScript at Bun development stack na ito, at sa ilang arkitektural na antas, mas elegante at mas mabilis pa ito kaysa sa aking orihinal na Python version.

Ang isa pang mas nakakaakit na mahabang panahon ay: habang patuloy na masasakop ang dinamikong workflow, sa malapit na hinaharap, maaari nating i-distribute nang walang pagkakasala ang mga subtask na may iba’t ibang antas ng kahirapan sa mga modelo na sumasagot sa kanilang kumplikadong antas.

Host Dan Shipper: Para sa mga hindi pa nagagamit, ipaalam mo sa amin kung paano mo ginawa ang workflow na iyon. Paano mo ito istruktura? Paano mo sinigurado na ito ay mabuti?

Mike Krieger:

Ang buong proseso ay puno ng kakaibang kasiyahan ng pag-iterate. Nagsimula ako sa pagbukas lang ng Claude Code at sinabi ko sa kanya: "Bro, mayroon akong napakahirap na restructure project—sama ka muna tayo sa pagdisenyo ng isang awtomatikong workflow."

Ipinakita sa akin nito ang plano, at sinabi kong, "Malapit na ito, ngunit kailangan ko ng tatlo o apat pang antas ng pag-verify upang suriin ang mga nalilimutang tampok." Pagkatapos, sumagot ito: "Ito ang iyong plano. Handa ka na ba?" Ang workflow ay ipinapahayag sa code, at naniniwala akong napakalaking halaga nito, dahil makikita mo kung paano ito gagawin nang eksakto.

Pagkatapos ng kumpletong pag-port, may ilang maliit na pag-aayos pa ako na gagawin bilang mga mini-workflow, na nagpapatuloy sa output ng nakaraang workflow. Ito ay bumabalik sa tanong: ang chat ba ang tamang interface? Ang workflow ay isang mabuting gitnaan—ginagamit mo ang chat upang i-orchestrate ito, ngunit ito ay isinasaad sa code, at pinapagana sa isang malinis na UI kung saan ipinapakita ang bawat hakbang kung ano ang nangyayari. Naniniwala ako na gagamitin natin ang katulad na paraan sa hinaharap upang i-link ang mga mahabang paningin na gawain sa chat.

I-organize at I-compile: Deep潮 TechFlow