Themes from yesterday

  • The edge for agents is moving beyond raw model quality toward harnesses, context, verification, orchestration, and security boundaries.
  • Enterprise AI governance is moving from policy documents to endpoint enforcement, scoped authority, and auditable execution.
  • Data, retrieval rights, and synthetic environments are becoming strategic inputs alongside compute.
  • AI is lowering the cost of building and changing software, pushing faster operating rhythms in product, GTM, and management.
  • The web’s economics are being renegotiated as agents become first-class consumers of information.

1. Pretraining progress is mostly coming from data — dwarkesh.com

  • Why read: An evidence-based view of where frontier-model progress may be coming from.
  • Summary: At small pretraining scales, the study estimates that data improvements from 2019 to 2025 produced roughly 12x compute efficiency, compared with 3.7x from changes to model recipes. That makes data curation, filtering, extraction, and synthesis strategic capabilities, not back-office work. The authors note that frontier models may benefit differently because they can absorb more imperfect data. Model advances still matter because they enable larger, more stable training runs. The open question is whether synthetic data can continue expanding the supply of usable training data.
  • Read more

2. How AI Is Breaking the Internet Economy — X

  • Why read: A close look at how AI retrieval disrupts the traffic-for-content deal and what may replace it.
  • Summary: AI agents increasingly consume web content without sending readers back to publishers, weakening media businesses funded by advertising and referrals. The piece compares permissioned pay-per-crawl marketplaces with open HTTP-402-style machine-payment protocols. It argues that publishers are still largely acting defensively: blocking crawlers or negotiating private deals instead of posting open prices. Dynamic, proprietary, continuously updated information has more lasting pricing power than static content. Teams building search or agent products should expect attribution, access rights, and content payments to become infrastructure concerns.
  • Read more

3. Designing for Mistrust: Architectures for Building Around Untrusted AI — X

  • Why read: A practical security design for agents that can fail, be manipulated, or be compromised.
  • Summary: Treat models as proposers, not authorities. Run execution in sandboxes, keep authorization in an external policy layer, and give agents capabilities instead of raw credentials. Network egress, data access, and authority escalation should each be treated as separate privileged actions. Limit permissions to the task, and require human review at consequential boundaries such as sends, purchases, deletes, and permission changes. It is a useful checklist for agent products that handle private data or interact with external systems.
  • Read more

4. Context Engineering for Coding Agents — X

  • Why read: A practical breakdown of why agent sessions degrade and how a harness can prevent it.
  • Summary: The piece identifies four core harness components: memory, skills, language-server feedback, and compaction. It recommends saving only evidence-backed knowledge that changes future actions, instead of filling every context window with documentation. Skills support progressive disclosure by keeping specialized instructions out of routine sessions until they are needed. LSP diagnostics provide quick feedback after edits, while compaction removes stale tool output before it drags down context quality. Reliable coding agents depend as much on context lifecycle design as model choice.
  • Read more

5. Building Codex with Tibo Sottiaux — Substack

  • Why read: An inside view of how a leading coding-agent team approaches harnesses, workflows, and organization.
  • Summary: Codex was built in Rust to favor performance, security, and large-scale cloud execution, even though early models were stronger in Python and TypeScript. Its open-source approach supports trust, contributions, and multi-model compatibility. Inside OpenAI, Codex connects broadly to code, documents, and communications, making organizational context a core capability. The team expects agents to make maintenance, rearchitecture, correctness checks, and security reviews much cheaper. Code quality, sound abstractions, and test coverage still determine how much of that benefit teams can capture.
  • Read more

6. What we got wrong about AI spend — X

  • Why read: It points to an overlooked source of enterprise AI spending: decentralized employee agent use.
  • Summary: The author found that internal engineering usage cost more than customer-facing product AI. Organizations often have scattered bills across coding assistants, chat products, and personal API accounts, without one policy or view of spending. A gateway alone does not solve this if every employee must configure local tools themselves. The proposed answer is endpoint-level deployment through device management, including enforced routing and managed MCP configuration. For operators, the real control issue is governance coverage, not dashboard quality.
  • Read more

7. The Next AI Attack May Happen Inside the Data Center — Lava

  • Why read: A clear threat model for agentic workloads running in shared GPU infrastructure.
  • Summary: Neoclouds inherited systems designed for trusted operators, but now expose multi-tenant GPU, orchestration, management, and firmware layers to autonomous workloads. Small configuration errors can become privilege-escalation paths when agents probe continuously and combine signals at machine speed. The piece calls out GPU fabrics, BMCs, DPUs, management interfaces, and host reassignment as overlooked security boundaries. Reimaging an operating system may not clear state in lower-level programmable hardware. AI security needs to extend beyond prompts and models into the physical and control-plane infrastructure underneath.
  • Read more

8. Evolving computer use with code — X

  • Why read: A strong case for letting browser agents use code as their action language.
  • Summary: Vision-only computer-use models are brittle across different viewports, layouts, and long tasks. Browserbase found that agents work better when they can write browser automation code instead of relying only on specialized click tools. Because models are heavily trained on Playwright, the system lets them write familiar Playwright code and transparently maps it to a more efficient runtime. The stack combines code execution with snapshots and screenshots for context. The design principle is to use existing model strengths while enforcing safety through sandboxing and network policy.
  • Read more

9. The Complete Guide to pstack Pt. 2 — X

  • Why read: A rigorous way to use coding agents without giving up verification or architectural discipline.
  • Summary: The central claim is that agents become truly autonomous only when they can verify their own work. The recommended base is a reproducible, agent-friendly CLI for running, debugging, seeding, and inspecting the application. Feature maps provide concise, discoverable descriptions of product behavior and reduce the context cost of exploration. The piece also recommends code-backed prototypes, competing architecture sketches, and empirical evaluation over abstract planning. Verification infrastructure is a compounding productivity asset, not a one-off prompt.
  • Read more

10. The Company is the Product — X

  • Why read: Specific operating practices from Applied Intuition’s approach to building an autonomy company at scale.
  • Summary: Qasar Younis describes company-building as an engineering problem and says interpreting feedback is the central founder skill. The piece argues for focusing on real customer conditions instead of conference-room assumptions. It offers specific mechanisms: high hiring bars, monthly double-blind performance reviews, and manager evaluations by direct reports. Applied Intuition is also training managers to build software tools, treating AI fluency as an organizational capability. The takeaway is that AI adoption needs operating mechanisms, not just executive declarations.
  • Read more

11. The Founder-to-CEO Inflection Point — Andy MacMillan

  • Why read: A clear explanation of the operational shift founders face as companies scale.
  • Summary: The author argues that founders do not automatically fail at scale; the job changes. At roughly $10M–$20M in revenue and around Dunbar’s-number scale, direct oversight no longer works. The founder’s job is mainly to build a product, while the CEO’s is to build an organization that reliably delivers value without constant founder involvement. The answer is operational scaffolding: systems, rhythms, frameworks, and delegated decisions. This is useful for founders and operators building structure before growth makes informal coordination impossible.
  • Read more

12. I Never Want to Use Third-Party Software Again — X

  • Why read: A considered product thesis on AI-enabled hyperpersonalization.
  • Summary: Julie Zhuo argues that agentic software lowers the cost of building deeply personalized tools around individual workflows. Her examples include custom interfaces for managing coding agents and tailored learning content for children. The shift is from configurable mass-market software to malleable systems that users can reshape themselves. Product builders should make interfaces adaptable, accept natural-language preferences beyond fixed settings, and work across tool boundaries. The opportunity is strongest where repeated workflow friction adds up every day.
  • Read more

13. The Open Source AI Stack — X

  • Why read: A useful map of the layers needed to run open models effectively.
  • Summary: The framework separates the model, inference provider, gateway or router, harness, and tools such as skills and MCP. That separation lets teams use large models for ambiguous work and cheaper small models for well-specified tasks. It also makes provider switching possible without changing everyday workflows. The article recommends treating planning, implementation, and review as separate model workloads when appropriate. Its main organizational point is to build for experimentation, so model upgrades become configuration changes rather than platform migrations.
  • Read more

14. The software factory stack — X

  • Why read: A practical architecture for making agentic development measurable, governable, and improvable.
  • Summary: The proposed factory includes layers for code-defined configuration, context, compute, inference, improvement, orchestration, and access. Defining the factory in versioned code supports benchmarking, rollbacks, and controlled experiments across models, skills, and policies. The improvement layer should include traces, metrics, replay, scorers, and task-specific benchmarks. Orchestration must handle agent launches, recovery, steering, and shared visibility across harnesses. The core idea is to operate agentic development as infrastructure rather than as a collection of individual tool subscriptions.
  • Read more

15. Nobody cares about your new product (sorry) — Readwise

  • Why read: A GTM playbook for an environment where AI speeds up releases and splits attention.
  • Summary: Product releases are becoming frequent enough that every announcement cannot get a traditional months-long launch process. Rippling, Notion, and Profound separate customer availability from the public marketing moment, giving products time to mature before a larger announcement. Strong launches start with positioning: the product truth, audience, claim, and proof, rather than distribution tactics. Companies are increasingly building in public through product managers and engineers, then reusing one release across several attention moments. The operational implication is a lightweight, tiered launch system with clear product and GTM ownership.
  • Read more