[TL;DR Daily] Sabihin ko nang malinaw: kapag nagsisimula nang mukhang Series A ang buwanang AI bill ng isang engineer, tumigil na ito sa pagiging simpleng kuwento ng tooling at nagsisimula nang mukhang ekonomikong eksperimento. Kaya ano nga ba ang tunay nating nakikita—ang susunod na operating system ng software engineering, o isang napakalaking makina para sa paggawa ng AI na basura sa industriyal na sukat? Malampat ay pareho. 🤖💸 🔥 Ang setup: isang trillion-token na flex na naging publikong debate sa gastos 📌 Ang mga headline numbers ay sinadyang absurd • Si Peter Steinberger, founder ng OpenClaw, ay nag-estimate na nag-spent ang kanyang team ng halos $10M sa token costs sa isang buwan para sa AI work, at agad niyang idinagdag: hindi lahat ng gastos na iyon ay nakatulong. • Isang iba pang viral na halimbawa ay mula sa Cursor profile ni Lauren Tan, na nagpakita ng halos 1.5 trillion tokens na ginamit sa 30 araw. • Gamit ang rough benchmark na $8 bawat 1M tokens, nag-estimate si Peter Piekarczyk na nasa halos $384k araw-araw, ~$11M bawat buwan, o $132M taun-taon. • Kahit may 90% enterprise discount, ang estimate ay nananatili pa ring nasa paligid ng $1.1M bawat buwan, o halos $13M taun-taon. 📌 Bakit nag-panic ang mga tao: ang paggamit ay lubos na labas sa normal na dev behavior • Ang Jellyfish data sa 12k developer ay nagpapakita na ang median user ay kumakain ng halos 51M tokens bawat buwan. • Ang 90th percentile ay nasa paligid ng 380M tokens bawat buwan. • Ito ay ginagawa ang 1.5T token usage ni Lauren na halos 29,000x ang median, habang ang 603B tokens na na-share ni Steinberger ay nananatiling halos 12,000x. • Kapag naitranslate ang token usage sa payroll math, agad nagbabago ang narrative: hindi na ito “productivity tooling,” ito ay tila compute aristocracy. 📌 Ang totoong bill ay kumplikado, dahil hindi lahat ng token ay magkakasalapi • Ang mga token count na Cursor-style ay maaaring kasama ang standard input, model output, cache writes, at cache reads. Ang lahat ng ito ay may iba’t ibang presyo. • Gamit ang Opus 5.5-style pricing, ang 1M input tokens ay maaaring $4, output naman ay $20, at cache reads ay halos $0.20 lamang. • Isang screenshot ng paggamit ay nagpakita ng 73.3B tokens na nagkakahalaga ng halos $30k kabuuan, na nangangahulugan ng average na halos $0.41 bawat 1M tokens dahil pinanagis ang cached traffic. • I-apply ang blended rate na ito sa 1.5T tokens at bumababa ang buwanang gastos sa halos $615k, hindi $11M. • Sa pinakamababang fantasy na kaso kung saan lahat ay binabayaran sa cache-read pricing, ang 1.5T tokens ay magkakahalaga lamang ng halos $300k bawat buwan. • Binago rin ni Piekarczyk ang kanyang sariling claim: kahit na 10x masyadong mataas ang kanyang orihinal na estimate, ang buwanang gastos ay maaari pa ring nasa paligid ng $100k. 🔥 Kaya ano nga ba ang natanggap sa lahat ng gastos na iyon? 📌 Hindi “isang chatbot,” kundi isang buong agent org chart • Ipinaliwanag ni Steinberger ang ganitong uri ng trabaho bilang pag-aaral kung ano ang software development kapag ang token cost ay hindi na limitasyon. • Ang kanyang 3-tao team ay nagpapatakbo ng halos 100 Codex instances. • Ang mga agent na ito ay tumitingin sa PRs, sinascan ang commit history para sa security bugs, pinagsasama ang duplicate GitHub issues, isinusulat ang mga fix, sinusubaybayan ang performance regressions, at kahit sumasali sa mga meeting para mag-generate ng PR mula sa talakayan. • Ipinaliwanag ni Lauren ang kanyang sariling setup bilang isang team ng 20+ agents: isang chief-of-staff agent, isang PM agent, at higit sa 20 execution agents na gumagana nang autonomously. 📌 Ang pangunahing insight ay hindi ang paggawa—kundi ang pag-verify • Ang alegasyon ni Lauren ay ang bottleneck sa agent coding ay hindi ang pagsusulat ng code, kundi ang pagpapatotoo kung gumagana talaga ang code. • Ang kanyang proseso ay nagpapatakbo ng mga agent para i-run ang code, i-collect ang CPU traces at heap snapshots, i-launch ang iOS simulators, at makipag-interact sa mga app tulad ng mga user. • Ang layunin ay lumikha ng isang closed loop: kung makakaverify ng sarili nitong output ang isang agent, maaari itong mag-iterate hanggang matapos ang gawain. • Kung hindi ito makakaverify, ibabalik nito ang diff sa tao at humihinto—ibig sabihin, ang tao ay naging pinakamabagal na bahagi ng sistema. • Sa kanyang inaasahang scale ng 4,000 PRs bawat buwan, kahit magkaloob lamang ng 5 minuto ng human review bawat PR ay magkakahalaga ng halos 333 oras—tulad ng isang buong buwan ng trabaho para sa isang tao. Kaya hindi maaaring maging validation layer ang manual review. 📌 Ito’y nagbabago sa papel ng engineer • Sa ganitong modelo, nagsisimula nang mukhang hindi na engineer ang isang coder—kundi engineering manager para sa mga agent. • Ang punto ni Lauren ay direktang sinasabi: kung hindi mo mapagkakatiwalaan ang output ng isang agent, hindi mo maiiwasan na i-scale ito hanggang sa isang daan. • Ang kanyang pstack workflow ay binubuo ng structured playbooks—nagpaparegula sa pag-unawa, disenyo, coding, review, at validation sa iba’t ibang local at cloud agents. 🔥 Pero dito naging malinaw ang kuwento: lahat ng autonomy na ito ay nangailangan ng malupit na pagtatakda 📌 Dapat i-rebuild ang codebase para maging agent-friendly • Sinasabing nagsimula si GrokBot bilang fast vibe-coded software na may mahina architectural constraints at kaunting human code reading. • Ito’y nagiging madali para sa mga agent na pumili ng path of least resistance: mas maraming code, malabo ang mga boundary, tumataas ang performance risk. • Para maayos ito, sinabi ni Lauren na ginamit niya ang 600+ PRs para i-refactor ang sistema sa isang internal architecture na tinatawag na Dune. • Naging sobrang stricte ang CI rules: bananin ang useEffect, ipagbawal ang comments, at i-validate ang dependency graphs upang hindi mag-cross-import ang Electron main at renderer. • Sa madaling salita, hindi lang mas magandang models ang “smart” bahagi. Ito’y pag-redesign ng environment upang may kaunting paraan para sa mga agent na maging sloppy. 📌 Maaaring makapangyarihan si pstack, pero maaari ring maging malalim na non-portable • Ang kanyang package ay naglalaman ng 23 playbooks at higit sa 20 engineering principles. • Ito’y mas mukhang hindi universal dev workflow kundi isang mataas na tuned behavioral cage para sa mga model. • At okay lang ito—hanggang subukan mong i-copy-paste ito sa ordinaryong teams na may ordinaryong budget at ordinaryong legacy codebases. Dito maaaring mawala ang magic. 🔥 Ang backlash: ito ba’y innovation o simple lang compute theater para sa mayaman? 📌 Maraming critics ang sabing ito’y AI slop factory na nakapalibot bilang kinabukasan • Sa Reddit at sa iba’t ibang engineering circles, maraming devs ang sinabing ang pag-merge ng libu-libong PRs gamit ang walang hanggang token spend ay hindi isang revolusyon sa software engineering. • Ang kanilang alegasyon: ito’y brute-force compute na ginagamit para punuan ang codebase ng micro-changes habang iniwasan ang totoong bottleneck—long-term maintainability. • Sa madaling salita, mas mabilis mag-scale ang code generation kaysa judgment. At kapag underfunded ang judgment, masisilbi nito yung debt sa sinumang mananaig sa repo. 📌 Ang marketing value ay maaaring mas mataas kaysa engineering value • Ayon kay Theo, founder ng T3, maaaring mas malapit sa $25k–$50k bawat buwan ang totoong internal cost. • Ang kanyang pananaw ay simple: kahit sa antas na iyon, worth it pa rin ang exposure. Mayroong ilang kompanya na nag-spent ng $1M sa events pero nakakakuha sila ng mas kaunting attention kaysa sa isang viral post ni Lauren.• Mula sa pananaw ni Cursor, maaaring mas maliit ito bilang kuwento ng unit economics at mas maraming PR masterstroke. • Kilala rin ni Lauren ang kanyang pribilehiyo nang malinaw: nagtatrabaho siya sa isang AI lab na may walang hanggang tokens, kaya hindi niya sinasabing dapat kopyahin ng lahat ang kanyang eksaktong paraan. 📌 Ang mas malalim na tanong ay ekonomiko, hindi lamang teknikal • Kung ang agentic development ay nagtatrabaho nang maayos lamang kapag ang mga validation loop ay malaki ang subsidiado, ang tunay na produkto ay hindi “AI coding.” Ito ay ang pagkakaroon ng access sa mura at malawakang pag-verify. • At kung totoo ito, ang AgentFi ay naging mas interesanteng frame: hindi lamang kung ano ang kayang gawin ng mga agent, kundi sino ang kayang paboran upang sila ay mag-operate nang awtonomo. • Ang hinaharap ay maaaring hindi nanggagaling sa mga koponan na may pinakamahusay na prompts. Maaaring nanggagaling ito sa mga koponan na nagtatayo ng pinakamahusay na incentive systems, guardrails, at capital-efficient verification loops. Ang aking pag-unawa? Ang kuwentong ito ay kapaki-pakinabang eksaktong dahil ito ay nagpaparamdam ng kahinaan sa lahat. • Pinakamabuting kaso: ito ay isang maagang tingin sa isang bagong engineering stack kung saan ang mga agent ay naglalabas, nagtataas, nagpapabuti, at nagkukooordinasyon sa pagitan ng mga software system. • Pinakamasamang kaso: ito ay isang compute-subsidized spectacle na nagkakamali ng volume ng output bilang kalidad ng produkto. • Pinakamalikha: ang katotohanan ay nasa gitna. Maaaring totoo ang agentic software, ngunit nang walang disiplinadong arkitektura at makatwirang ekonomiya, maaari itong maging mas mabilis na paraan upang gawin ang tech debt. Kaya narito ang tanong na gusto kong iwanan sa iyo: Kung ang isang agent ay nakasusulat ng 4,000 PRs bawat buwan, ngunit ang maliit lamang na elite ang kayang bayaran ang validation bill, iyon ba ang hinaharap ng software—o simpleng demo ng kapangyarihan?