This was a fun conversation at @sfelc_ . Thanks for being an excellent podcast host @grinich! Shared my learnings from working with dozens of engineering teams on what's making some teams more effective with AI.

73% of engineering leaders cite code review as a top pain right now. I've spent countless hours with frontier AI teams understanding how they're navigating the problem. Human review of every line of code is quickly getting replaced by new techniques.

Posting about the new bottleneck is the new bottleneck.

How I AI: Next time you need to write a strategy memo, write it in the style of a WSB DD reddit post. People will actually read it because it's entertaining, and you'll be forced to reduce your thinking into simple terms (not business jargon).

Everyone is talking about graph engineering. In simple terms, it means designing how several specialized AI agents hand work off to each other, instead of making one agent do everything in a single loop. This feels very similar to designing how a team works. Roles and responsibilities, handoffs between functions and teammates. Once you've designed the graph, you implement different sub-agents to do different "jobs" / parts of the workflow. Writing a PRD or a tech spec probably requires frontier intelligence (Opus 5, etc.). Once the tech spec is broken down into granular tickets, a smaller, cheaper model probably works (Sonnet 5, or Haiku 4.5 for the really mechanical stuff). Time for review? If it requires security review, you probably have a dedicated security review agent again using frontier intelligence, or even better, a fine-tuned security focused model. The analogy to team design is almost one to one. The PM does the PRD, the Tech Lead does the tech spec, the L1 new grad implements simple tickets, the security team does sensitive security review. If this is how software is developed in the future, you can pin specific model versions to different sub-agents / nodes in the graph. If you want to, you can run the same task through different "versions" of the graph with different models (A/B test) and eval which hits the cost/quality tradeoff you're comfortable with. Won't this be more powerful than using a model router that has no knowledge of your graph?

I really enjoyed this talk by @zachlloydtweets (starts at 4hrs55min): youtube.com/live/htM02KMNZnk… [1] I agree with his thesis - Software Engineering will become Factory Engineering. I'm seeing this with leading teams across the industry. [2] There's no technical jargon in this talk - it's super approachable for non-technical folks who want to understand how the discipline of software engineering is changing. [3] I love that they're building their factory in the open so you can see what it looks like in practice, even if still in early form.

The AI coding debate is focused too much on model selection - just see all the model router launches this week - Ramp, Cursor, etc. We studied 103 engineering teams and found big levers are also on the dev platform and human side: • +1 pt prompt clarity → ~27% lower token cost per merged AI line • +1 pt environment readiness → ~88% higher turn yield • +1 pt quality stewardship → ~39% fewer review cycles Prompts, environments, and stewardship shape every task and are things you can coach your team to improve today. Full report + a practical field guide below. Would love to hear what matches or contradicts your experience. span.app/research/agent-effe…

Well said. The moat is the memory & harness, not the model. "A company should be able to switch out a 'generalist' model without losing the 'company veteran' expertise built into their learning system. This is the key 'test' of your control and sovereignty in the era ahead."