What would you build first, if budget weren't the constraint?

Two weeks ago this issue asked whether we'll pay more or less for AI. The feed spent the next two weeks answering, and it kept coming back to the same move: efficiency.

The Atlantic called the build a trillion-dollar engineering disaster. Aaron Levie called out the frontier-plus-tuned-open-source arbitrage. The mid-year podcasts said token spend quintupled. Thinking Machines said stop renting one frozen giant and tune your own.

The money moved off the model and onto routing, context, learning loops, narrow paths, caching, and a build-vs-buy sharper than "buy everything."

Which is a strange backdrop for every org being told this year that the job is to become AI-native, to adopt it everywhere and rebuild every workflow around it. The efficiency turn points the other way, toward fewer models and narrower paths and more deliberate spend. Maybe AI-native was never about using more of it.

Aaron Levie posted a few thoughts on what's coming in AI. Good list, mostly familiar. My note from when I read it: "This is right especially the opportunity for combining frontier and tuned open source to deliver cost savings and arbitrage. That's probably a business to be honest custom on fly fine tuned models within a big harness."

Thinking Machines' manifesto, "The Future Worth Building Is Human," makes the case for owning your model outright and fine-tuning your own weights instead of renting one frozen frontier. I'm with half of it. The half worth owning is the layer above the model, the harness and the router and the context that decide which model does which job. Fine-tuning your own weights is the expensive, brittle part most operators never need to touch to get the efficiency the manifesto is really chasing.

Alex Reisner, writing in The Atlantic, called generative AI "an engineering disaster" and framed the industry's overbuild as a trillion-dollar problem. Back in April this newsletter ran a sanity-check on the "SaaS is dead, build everything" wave and flagged that the token subsidy has an expiration date. The Atlantic just ran that math for the whole industry.

Harry Stebbings, Jason Lemkin, and Rory O'Driscoll recorded the mid-year roundup and one theme ran through almost every story: companies quintupling their token spend in the first half of the year. The same episode has Anthropic wanting Chinese open source banned. Last issue had the counterweight: Coinbase's bill dropping toward half its peak while usage hit an all-time high, on routing. So spend is up, frontier prices are up, and the arbitrage is sitting right there. I don't think anyone's P&L has caught up to all three at once.

Revenue.io priced out what Gong actually costs in 2026 and it made the rounds: the pricing, the hidden fees, what to watch for. Still wild they've maintained this pricing power. I get it's hard to rip out and I see their value, but also...

A founder at a pricing-intelligence company went through 30 vendor ROI calculators to see how they'd hold up in a real deal. Most fall into one of six categories, and most are theater. Worth a read before you build one, and honestly before you believe one.

A LocalLLaMA user ran Grok Build CLI through mitmproxy and watched it upload the entire repo to xAI's cloud as a git bundle, full history and .env secrets included, no matter what the task was. The opt-out flag didn't stop it in his capture. One wire capture, not a pattern, but I'd still go check what your own coding CLI ships home before it sits inside the repo that runs your business.

Tim van Lew wrote it: "The Company That Built Claude Didn't Vibe Code Their GTM Stack. Why Do You Think You Can?" SaaStr ran five reasons we won't all vibe-code our own HubSpot the same week.

Last issue was all build-vs-buy, and the counter-example is still standing: Profound built their own revenue platform and it works. Both backlash pieces end up at the same place that issue did. The question was never build-versus-buy for the whole stack, it's which layer you own.

Andrej Karpathy's "LLM Wiki" post pulled 19.6 million views, and the wave behind it is real: Kieran's rundown of the "AI brains" everyone is suddenly building, and Angela Sun on what 100+ practitioners taught her building an AI GTM brain. I run my own version (the content layer that feeds this newsletter), so I'm biased toward this being real and not a naming trend.

One survey that crossed my digest this week asked leaders a good question: if budget weren't a constraint, what's the next thing you'd build in your GTM data stack?

• A unified data layer that connects every GTM tool: 62%
• Continuous enrichment: 48%. Usable intent and signal feeds: 44%. A real-time signal engine: 42%
• Dead last, AI agents plugged in via MCP: 16%

Everyone's building the brain; the thing leaders say they're missing is the layer under it.

What I haven't seen anyone write is the maintenance bill a year in. Mine isn't small.

Vercel's COO Jeanne DeWitt Grosser told SaaStr she stood up a go-to-market engineering team six weeks into the job, and it now claims to do the old 10-person SDR team's work for about $5,000 a year in tooling. She ran GTM at Google and Stripe for a decade each, so take the claim seriously. The more useful read is the dividing line it draws: high-volume top-of-funnel is the work AI already does well. Renewals, multi-threaded deals, the judgment calls in the middle of a real pipeline — nobody's showing me that agent yet.

GTM Engineer Pulse #33 is about running the whole GTM motion out of Slack. The Slack as UI for this is real and interesting.

Same week, Platformer wrote about vibe coding escaping the terminal into real apps. The UI and what that'll look like in the future matters...

The top 10 GTM mistakes founders make, from The Revenue Architect. This is a fantastic list. Also refreshing to see first principles, not AI.