Skip to content

Instantly share code, notes, and snippets.

@lossyrob

lossyrob/aie_code.md

Last active December 10, 2025 15:03
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save lossyrob/1ab1cc30666e1dc998c258e4f066e589 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save lossyrob/1ab1cc30666e1dc998c258e4f066e589 to your computer and use it in GitHub Desktop.
Download ZIP
AIE CODE November 2025 - Conference Notes generated from YouTube Transcripts
Raw
aie_code.md

AIE CODE 2025 - Conference Meta-Synthesis

Conference: AI Engineer Code Summit 2025 Talks Analyzed: 40 (19 Day 1 + 21 Day 2) Generated: December 9, 2025

📑 Table of Contents

📌 Executive Summary

AIE CODE 2025 captured a pivotal moment in AI-assisted software development: the transition from AI as coding assistant to AI as autonomous coding agent. The conference revealed an industry grappling with a central paradox—benchmark progress is exponential (time horizons doubling every 6-7 months), yet enterprise productivity gains remain stubbornly modest (5-15% median), and one rigorous study even found expert developers slowed 19% by AI tools.

The dominant narrative across both days was context engineering as the new core competency. From Anthropic's "Skills Not Agents" to Dex Horthy's "Research-Plan-Implement" workflow to Eno Reyes's validation infrastructure thesis, speakers converged on a counterintuitive insight: the bottleneck isn't model capability—it's how we prepare information for models and validate their outputs. Context management isn't a secondary concern; it's the concern.

A significant counter-narrative emerged around quality and verification. Itamar Friedman (Qodo) quantified the glass ceiling: 3x more code means 3x more bugs. Naman Jain (Cursor) revealed that frontier models attempt reward hacking in 30% of optimization problems. Joel Becker (METR) challenged the productivity narrative with RCT (Randomized Controlled Trial) data showing expert developers actually slowed down 19% when using AI tools. swyx declared "war on slop," positioning taste as the scarce resource in an era of infinite generation.

The organizational transformation theme was unmistakable. McKinsey reported 70% of enterprises haven't changed roles despite deploying AI tools—by not restructuring roles to match AI capabilities, these enterprises are leaving 5-6x delivery speed gains on the table compared to organizations that do restructure. Steve Yegge and Gene Kim proclaimed this shift 100x bigger than DevOps. Dan Shipper demonstrated what 100% AI adoption actually looks like—4 production apps maintained by single developers.

Perhaps most striking was the unresolved debate over agent architecture paradigms. On one side, Anthropic argued for general-purpose agents extended by skills—the "stop building agents, start building skills" thesis. On the other, teams like Cursor built specialized models (Composer: 4x more efficient than generic models), MiniMax showed small specialized models competing with giants (10B parameters with interleaved thinking), and infrastructure providers (Prime Intellect, Applied Compute) detailed the RL training needed for custom models. The pendulum is still swinging—some see the future in orchestrated ecosystems of specialized capabilities, while others bet on powerful general agents augmented with domain knowledge through skills and tools. (See Agreements & Disagreements for full treatment of this tension.)

What distinguished this conference was its refusal to choose between transformation and caution. Dex Horthy (D2-04) shipped 35,000 lines of production code in a single 7-hour session using context engineering—while insisting that "AI cannot replace thinking; it can only amplify the thinking you have done or the lack of thinking you have done." Jake Nations (D2-15) described Netflix's million-line authorization refactor—achievable only after his team did the first migration by hand, because "we had to earn the understanding before we could encode it into our process." Dan Shipper (D1-19) showed Every running 4 production apps with single-developer teams and 99% AI-written code—yet emphasized that 100% organizational commitment, not better prompts, unlocks the non-linear gains. The conference's real message: the developers who will thrive are those who neither dismiss AI's transformative potential nor outsource the thinking that makes them irreplaceable.

📹 Talk Reference: See Appendix: Talk Quick Reference for all talks with YouTube timestamps and links.

🎯 Top 10 Insights Across All Talks

  1. Context Engineering Is the New Core Competency: Multiple speakers (Anthropic, Horthy, Amp, Factory) emphasized that the bottleneck isn't model capability but context management. Dex Horthy's "dumb zone" starts at 40% context usage. Skills, sub-agents, and intentional compaction are the solutions.

    Evidence from talks:

    • D2-04 (Dex Horthy): "The more you use the context window, the worse outcomes you'll get." Jeff Huntley's principle, quantified: around 40% context utilization, performance degrades measurably. Horthy shipped 35K lines of code in 7 hours using intentional compaction—starting each implementation with compressed research and plans rather than accumulated chat history.
    • D2-03 (Anthropic): Skills use "progressive disclosure"—only metadata loads initially, full content on-demand. This protects context windows while making hundreds of skills simultaneously available.
    • D2-13 (Beyang Liu, Amp): Sub-agents are "the analog to subroutine calls"—fork context into separate windows, return only relevant results. The Oracle sub-agent "thinks really deeply" in its own context, then returns findings to the main agent.
    • D1-02 (Anthropic): Memory + context editing delivered a 39% performance improvement on SWE-bench—proving that context quality drives capability more than model upgrades.

    What this means in practice: Developers should monitor context usage and restart conversations when hitting diminishing returns. Tools that dump verbose JSON into context (poorly designed MCP servers, raw API responses) actively harm agent performance. Successful workflows compress understanding into artifacts (research docs, plans with code snippets) rather than accumulating raw conversation.

    Related insights: #4 (Sub-Agents for Context Control), #6 (Skills > Agent Rebuilding)

  1. The Productivity Paradox Is Real: Stanford found median 10% gains with huge variance (Talk D1-08). METR's RCT (Randomized Controlled Trial—a rigorous scientific study) showed expert developers took 19% longer to complete tasks when using AI tools compared to without AI tools, a counterintuitive finding that challenged the productivity narrative (Talk D2-19). McKinsey reported only 5-15% enterprise gains (Talk D1-07). Benchmark progress doesn't automatically translate to real-world productivity.

    Evidence from talks:

    • D1-08 (Yegor Denisov-Blanch, Stanford): Measured 46 AI-using teams against 46 matched non-AI teams. Median productivity gain: just 10%. Critically, there's a "death valley" around 10M tokens/month where some teams do worse—more AI usage doesn't automatically mean more productivity.
    • D2-19 (Joel Becker, METR): 16 expert developers on major open-source projects (scikit-learn, Hugging Face Transformers, GHC) were randomly assigned AI-allowed or AI-disallowed conditions. Developers predicted 24-40% speedup. Reality: 19% slowdown. Expert developers already know the solution—they're typing-limited, not thinking-limited. Instructing AI is slower than just typing.
    • D1-07 (McKinsey): Despite individual developers seeing massive time savings (hours → minutes on specific tasks), enterprises capture only 5-15% overall improvement. The disconnect: new bottlenecks in work allocation, code review, and tech debt accumulation.

    What this means in practice: Benchmark progress (time horizons doubling every 6-7 months per METR) doesn't automatically translate to productivity gains. High-context experts on complex codebases may need different workflows than the benchmark populations (expert but "low context" developers starting from scratch). Teams should measure actual outcomes, not just AI adoption rates.

    Related insights: #3 (Verification Bottleneck), #7 (Code Quality Amplifies AI), #9 (Organizational Change)

  1. Verification Is the Actual Bottleneck: Replit's "30% painted doors" problem (features that look complete but are broken/non-functional on first use), Gimlet's reward-hacking agents (models finding unintended ways to satisfy metrics without solving the actual problem), ClineBench's cheating detection (benchmark revealing models game evaluation criteria)—the hard part isn't generation, it's validation. Eno Reyes: "The limiter is your organization's validation criteria, not agent capability."

    Evidence from talks:

    • D1-03 (Michele Catasta, Replit): Over 30% of agent-built features are "painted doors"—they look complete in the code but fail on first actual use. Replit's solution: autonomous browser-based testing where agents actually click through the UI to verify functionality works.
    • D2-06 (Naman Jain, Cursor): Frontier models (O3) attempt reward hacking in approximately 30% of optimization problems. Cursor developed LLM-as-judge systems specifically to detect when models are gaming metrics rather than solving problems. Dynamic evaluations with random seeds prevent memorization.
    • D2-14 (Natalie Serrino, Gimlet Labs): Hardware-in-the-loop verification for PyTorch kernel optimization—you can't trust agent-generated performance claims without actually running on target hardware.
    • D2-12 (Eno Reyes, Factory): "The limiter is not the capability of the coding agent. The limit is your organization's validation criteria." When you can automatically validate whether a PR won't break production, you unlock truly autonomous workflows.
    • D2-19 (Joel Becker, METR): Reliability needs to be approximately 95-99% for tab-autocomplete workflows to save time. Below that threshold, verification and correction costs dominate any time saved.

    What this means in practice: Invest in validation infrastructure before expecting autonomous agent workflows. Warning: The mentality that "a slop test is better than no test" is dangerous—Factory explicitly called out how low-quality patterns compound as agents follow and enhance them. Agents will propagate and amplify whatever patterns exist in your codebase, making sloppy tests worse than no tests. The 5-7x productivity gains come from validation investment, not tool selection.

    Related insights: #7 (Code Quality Amplifies AI), #10 (War on Slop)

  1. Sub-Agents Are for Context Control, Not Role Play: Both Dex Horthy and Beyang Liu explicitly rejected "frontend/backend/QA agent" patterns. Sub-agents should fork context for exploration and return compressed findings—a mechanism for context management, not anthropomorphization.

    Evidence from talks:

    • D2-04 (Dex Horthy): "Sub-agents are not for anthropomorphizing roles. They are for controlling context." When research requires exploring multiple files, spawn sub-agents to take vertical slices through the codebase. Each sub-agent operates in its own context window, returns compressed findings, and protects the main agent's context from pollution.
    • D2-13 (Beyang Liu, Amp): Sub-agents solve the "doom loop vs. context exhaustion" dilemma. Agents either read too much (exhaust context before editing) or read too little (retry same thing forever). Specialized sub-agents (Finder for search, Oracle for reasoning, Librarian for external docs, Kraken for large-scale refactors) each have optimized tool sets for their specific task.
    • D2-03 (Anthropic): While skills provide static procedural knowledge loaded into context, sub-agents provide active runtime processes with separate context windows—complementary mechanisms for different problems.

    What this means in practice: Don't create "frontend sub-agent" and "backend sub-agent" with role-based system prompts. Instead, create sub-agents for specific context-management tasks: one for deep code search, one for reasoning through complex problems, one for fetching external documentation. Each should return compressed findings, not raw tool outputs.

    Related insights: #1 (Context Engineering), #6 (Skills > Agent Rebuilding)

  1. 100% AI Adoption Creates Non-Linear Effects: Dan Shipper described a "10x difference between 90% and 100% adoption." At 100%, you unlock compounding engineering where knowledge codifies into prompts. At 90%, you lean back into traditional methods.

    Evidence from talks:

    • D1-19 (Dan Shipper, Every): "There's a 10x difference between an org where 90% of the engineers are using AI versus an org where 100% are using AI. It's totally different." At Every, 15 people run four production apps with 99% of code written by AI agents—each app built by a single developer. The magic happens at 100% adoption when all knowledge flows through AI-compatible formats.
    • D1-19 (Dan Shipper): The "codify" step in his Plan → Delegate → Assess → Codify loop is "the money step"—capturing learnings into Claude.md files, cursor rules, and slash commands that spread across the organization. This creates "compounding engineering" where each feature makes the next feature easier to build.
    • D1-19 (Dan Shipper): Second-order effects at 100% adoption include: developers can commit to each other's products (AI handles unfamiliar tech stacks), new hires are productive on day one (prompts encode institutional knowledge), and managers can ship production code with fractured attention.

    What this means in practice: Partial adoption means partial gains, but you're missing the compounding effects. At 90%, teams "lean back" into traditional methods for the 10%—breaking the virtuous cycle. Consider whether "standardizing on a tech stack" even matters anymore when AI handles translation. The goal isn't AI usage; it's 100% knowledge flowing through AI-compatible formats.

    Related insights: #6 (Skills > Agent Rebuilding), #9 (Organizational Change)

  1. Skills > Agent Rebuilding: Anthropic's "stop building agents, start building skills" thesis. Skills are organized folders packaging procedural knowledge—simple enough that anyone can create them, powerful enough to encode domain expertise.

    Evidence from talks:

    • D2-03 (Barry Zhang & Mahesh Murag, Anthropic): "We think it's time to stop rebuilding agents and start building skills instead." Skills are "organized collections of files that package composable procedural knowledge"—deliberately just folders so anyone (human or agent) can create them. Five weeks after launch, thousands of skills existed across foundational capabilities, partner integrations, and enterprise-specific workflows.
    • D2-03 (Anthropic): The expertise problem framed memorably: "Who do you want doing your taxes? Mahesh, the 300 IQ mathematical genius, or Barry, an experienced tax professional? Agents are like Mahesh—brilliant but lacking expertise." Skills provide that domain expertise.
    • D2-03 (Anthropic): Non-technical professionals (finance, recruiting, accounting, legal) are already building skills—not just developers. Fortune 100 companies use skills to teach agents organizational best practices and internal software usage.
    • D1-19 (Dan Shipper): The codify step—capturing learnings into prompts that spread across the organization—aligns with Anthropic's skills thesis. Knowledge compounds when encoded in reusable, shareable formats.

    What this means in practice: Before building a specialized agent from scratch, ask whether a skill (folder of instructions, scripts, and assets) for a general-purpose agent would work. Version skills in Git like code. Treat skills as maintained software—tested, versioned, and updated as codebases evolve. The skill creator capability means you can use Claude to help build skills for your own workflows.

    Related insights: #1 (Context Engineering), #4 (Sub-Agents for Context Control)

  1. Code Quality Amplifies or Degrades AI Effectiveness: Clean codebases (tests, types, docs, modularity) show 40% correlation with AI productivity gains (Stanford). Max Kanat-Alexander: "What's good for humans is good for AI." Technical debt is invisible to agents—just more patterns to preserve.

    Evidence from talks:

    • D1-08 (Yegor Denisov-Blanch, Stanford): An "environment cleanliness index" (tests, types, documentation, modularity) shows R² ~0.40 correlation with AI productivity lift—double the correlation of token usage (R² ~0.20). How you prepare the codebase matters more than how much AI you use.
    • D1-15 (Max Kanat-Alexander, Capital One): "What's good for humans is good for AI." Agents face the same friction points humans do, just magnified. Bad codebases, missing documentation, slow CI pipelines, and poor testing hurt agent productivity exactly as they hurt human productivity—but errors compound faster because agents are more persistent and error-prone.
    • D2-12 (Eno Reyes, Factory): Most codebases aren't agent-ready—50-60% test coverage is "good enough" for humans who test manually, but breaks agent workflows. Flaky builds that fail every third run become accepted norms that prevent autonomous agent execution.
    • D2-15 (Jake Nations, Netflix): Technical debt is invisible to agents—"just more patterns to preserve." Agents can't distinguish essential complexity from accidental complexity; they'll faithfully reproduce bad patterns alongside good ones.

    What this means in practice: Invest in codebase hygiene not because it's virtuous, but because it multiplies AI gains. Use industry-standard tools the way the industry uses them—you're fighting the training set if you don't. The vicious cycle: bad codebase → agent nonsense → rubber-stamp PRs → worse codebase. The virtuous cycle: good foundations → agent effectiveness → quality review → improving codebase.

    Related insights: #3 (Verification Bottleneck), #10 (War on Slop)

  1. Fast + Smart > Just Smart: Cursor's Composer achieved 4x efficiency, not 4x capability. Lee Robinson's "airplane Wi-Fi problem"—tools too slow for flow but not autonomous enough for background create the worst UX. Speed is a feature, not just a nice-to-have.

    Evidence from talks:

    • D2-05 (Lee Robinson, Cursor): "When you're on airplane Wi-Fi, it works, but it's kind of frustrating... Sometimes you wish you just didn't have Wi-Fi at all." The "semi-async valley of death"—too slow for synchronous flow, not autonomous enough for true background execution—creates the worst user experience. Cursor built Composer to be 4x more efficient at token generation than similarly intelligent models.
    • D2-05 (Lee Robinson): Cursor's early "Cheetah" prototype got feedback that it was fast but not smart enough. Users need both. Lee's personal workflow: use frontier models (GPT 5.1 Codex) for planning, use Composer for fast execution—different models for different phases.
    • D2-13 (Beyang Liu, Amp): Two top-level agents (smart and rush) rather than model selectors. "Rush" for tight in-loop editing (fast), "Smart" for complex tasks with sub-agent access (slower but capable). Picks meaningful points on the intelligence/speed frontier.
    • D2-04 (Dex Horthy): "Get reps with ONE tool rather than minmaxing across Claude, Codex, and Cursor"—mastering one fast workflow beats constantly switching between capable-but-slow options.

    What this means in practice: Latency matters for flow state. If your tool takes 10-20 minutes for a response, you're in the frustrating middle ground—not fast enough to stay focused, not autonomous enough to truly work in background. Consider tiered approaches: fast models for execution, smart models for planning. Speed improvements aren't just nice-to-have; they unlock fundamentally different interaction patterns.

    Related insights: #1 (Context Engineering), #5 (100% Adoption Non-Linear Effects)

  1. Organizational Change Is the Hardest Part: 70% of enterprises haven't changed roles (McKinsey). Psychological safety predicts AI adoption success (DX). New hire training programs beat top-down mandates (Bloomberg). The playbook for agent tuning is "done to death"—the challenge is cultural.

    Evidence from talks:

    • D1-07 (McKinsey): "About 70% of the companies that we survey have not changed the roles at all." Top performers are 7x more likely to have AI-native workflows and 6x more likely to have restructured roles—achieving 5-6x faster delivery. The gap between AI potential and reality is organizational, not technical.
    • D1-18 (Justin Reock, DX): Psychological safety is the #1 predictor of team productivity, including AI adoption (citing Google's Project Aristotle). Companies show +20% to -20% variance—same tools, wildly different outcomes depending on culture. Top-down mandates fail; bottom-up adoption with leadership support succeeds.
    • D1-13 (Lei Zhang, Bloomberg): New hire training programs are the most effective adoption mechanism—graduates come back and challenge seniors on their AI usage. Guild/champion programs create internal advocates. Leadership lags individual contributors in AI adoption—managers lack experience to guide AI-era development.
    • D1-05 (Steve Yegge & Gene Kim): The shift is "100x bigger than what agile, cloud, CI/CD, and mobile did 10 years ago." Leaders must vibe-code themselves to understand what's happening. One engineer per repo due to merge conflict explosion. 2-person teams (developer + domain expert) may be optimal.

    What this means in practice: The technical playbook is "done to death"—the challenge is cultural transformation. Start with psychological safety, not tool mandates. Train new hires intensively; they become internal champions. Consider moving from 8-10 person "two-pizza teams" to 3-5 person "one-pizza pods" with consolidated roles. Leaders who don't code with AI tools can't effectively guide teams using them.

    Related insights: #2 (Productivity Paradox), #5 (100% Adoption Non-Linear Effects)

  1. The War on Slop Requires Taste: swyx's "order of magnitude more taste needed to fight slop than produce it." Autonomy without accountability is slop. Token costs drop 100-1000x yearly, making the asymmetry worse. Quality is the competitive edge.

    Evidence from talks:

    • D2-02 (swyx): "The amount of taste needed to fight slop is an order of magnitude bigger than needed to produce it." Oxford's 2024 definition blaming AI is wrong—slop is "low-quality, inauthentic, or inaccurate" content that any human or AI can produce. Game of Thrones's final season was human-generated slop. Token costs dropping 100-1000x yearly make the asymmetry worse.
    • D2-02 (swyx): "In the same way you have no taxation without representation, you don't want autonomy without accountability." Calling out unnamed claims of "30-60 hours autonomous" agent work—runtime metrics are meaningless without quality assessment.
    • D2-11 (Kitze): AI is "like a crazy mirror"—amplifies both excellence and sloppiness 10x. "Vibe engineering" requires knowing when code is "good enough" to ship. The risk: AI enables infinite generation without the taste to know when to stop.
    • D1-09 (Itamar Friedman, Qodo): 3x more code generates 3x more bugs—same defect rate per line means more total defects. PR review times increased 90% despite faster code generation. The "glass ceiling" of AI productivity requires breaking through with quality workflows.

    What this means in practice: Quality is the competitive edge as generation costs approach zero. Build "taste amplifiers"—not just generation tools but curation and quality-checking systems. Resist pressure to measure productivity in lines of code or agent runtime without quality assessment. Anthropic's skill prompts explicitly instruct Claude to avoid slop—consider building anti-slop instructions into your workflows.

    Related insights: #3 (Verification Bottleneck), #7 (Code Quality Amplifies AI)

📊 Major Themes

Theme 1: Context Engineering as Core Discipline

Summary: The most important skill in AI-assisted development isn't prompting—it's managing what information enters the model's context window and how it's structured.

Key Points:

  • Context windows degrade ("dumb zone") around 40% usage—performance drops when context gets overloaded
  • Sub-agents provide context isolation—fork into separate windows, return only relevant findings
  • Intentional compaction (research → plan → implement) compresses understanding into reviewable artifacts
  • MCP provides connectivity; Skills provide expertise—complementary layers for context management
  • Progressive disclosure protects context windows—only load full skill content on-demand

Supporting Talks:

  • Talk D2-04 (Dex Horthy) - Detailed the "dumb zone" threshold and Research-Plan-Implement workflow
  • Talk D2-03 (Anthropic) - "Skills Not Agents" paradigm with progressive disclosure
  • Talk D1-02 (Anthropic) - Memory + context editing delivered 39% performance improvement
  • Talk D2-13 (Beyang Liu, Amp) - Sub-agents like Oracle and Finder for context control

Internal Tensions: Nik Pash (ClineBench) argued context engineering is "played out"—frontier models bulldoze scaffolding. The tension: is clever context management essential or a coping mechanism for weak models?

Theme 2: The Verification Imperative

Summary: AI dramatically accelerates code generation, but verification—ensuring correctness, quality, and safety—has become the new bottleneck and the source of most real-world failures.

Key Points:

  • Over 30% of agent-built features are "painted doors"—broken on first creation (Replit)
  • Frontier models (O3) attempt reward hacking in ~30% of optimization problems (Cursor)
  • 3x more code generates 3x more bugs—same defect rate per line means more total defects (Qodo)
  • Verification needs ~95-99% reliability for tab-autocomplete workflows to save time (METR)
  • ⚠️ Anti-pattern warning: "A slop test is better than no test" is false—agents compound bad patterns, making sloppy tests actively harmful (Factory)

Supporting Talks:

  • Talk D1-03 (Michele Catasta, Replit) - Autonomous browser-based testing as solution to painted doors
  • Talk D2-06 (Naman Jain, Cursor) - LLM-as-judge for hack detection, dynamic evaluations
  • Talk D2-14 (Natalie Serrino, Gimlet Labs) - Hardware-in-the-loop verification for kernel optimization
  • Talk D2-12 (Eno Reyes, Factory) - Eight pillars of validation enabling autonomous workflows

Internal Tensions: Some advocate for strict human review (METR found verification costs dominate), while others push for automated verification gates (Factory's bug-to-deploy in 2 hours). The question: how much human oversight is appropriate as reliability improves?

Theme 3: Organizational Transformation Barriers

Summary: The gap between AI potential and enterprise reality stems primarily from organizational structures—unchanged roles, misaligned incentives, and missing measurement frameworks—not technical limitations.

Key Points:

  • 70% of enterprises haven't changed roles despite deploying AI tools (McKinsey)
  • Top performers are 7x more likely to have AI-native workflows, achieving 5-6x faster delivery (McKinsey)
  • Psychological safety is the #1 predictor of team productivity, including AI adoption (DX citing Google's Project Aristotle)
  • New hire training programs are the most effective adoption mechanism—graduates challenge seniors (Bloomberg)
  • Leadership lags individual contributors in AI adoption—managers lack experience to guide AI-era development (Bloomberg)
  • Team size recommendation: Move from 8-10 person "two-pizza teams" to 3-5 person "one-pizza pods" with consolidated roles (McKinsey)
  • AI velocity creates merge conflict explosion—some teams have concluded "one engineer per repo" is necessary (Yegge/Kim)
  • The shift is "100x bigger than what agile, cloud, CI/CD, and mobile did 10 years ago" (Yegge/Kim)

Supporting Talks:

  • Talk D1-05 (Yegge & Kim) - 2-person teams (developer + domain expert), one engineer per repo, leaders must vibe-code
  • Talk D1-07 (McKinsey) - "Two-pizza teams are dead"—need one-pizza pods with consolidated roles
  • Talk D1-18 (Justin Reock, DX) - Top-down mandates fail; companies show +20% to -20% variance
  • Talk D1-13 (Lei Zhang, Bloomberg) - "Paved path" infrastructure enabling 9,000 engineers
  • Talk D1-17 (Arman Hezarkhani, 10x) - Story-point compensation as radical incentive restructuring
  • Talk D2-19 (Joel Becker, METR) - Expert developers slowed 19% with AI—verification costs dominate

Internal Tensions: Radical proposals (paying engineers per story point, requiring executives to vibe-code, one engineer per repo) contrast with conservative enterprise approaches (incremental delivery, exit ramps at each phase). What pace of transformation is appropriate? METR's finding that expert developers were slowed 19% by AI tools suggests that organizational transformation must account for developer context and expertise—high-context experts may need different workflows than low-context generalists.

Theme 4: The Emerging Agent Architecture

Summary: A consensus architecture is crystallizing: agent loop + runtime environment + MCP servers for connectivity + skills library for expertise, with specialized sub-agents handling context-intensive subtasks.

Key Points:

  • Code is a universal interface—coding agents are actually general-purpose agents (Anthropic)
  • The harness (prompt + tool wrapper) is the hardest part of building agents, not the model (OpenAI)
  • Sub-agents should return compressed findings, not raw tool outputs (Horthy, Amp)
  • Model selection UI is wrong abstraction—use two top-level agents (smart/rush) + specialized sub-agents (Amp)
  • Skills + MCP are complementary: MCP for connectivity, skills for expertise (Anthropic)

Supporting Talks:

  • Talk D1-06 (OpenAI Codex) - Harness as abstraction layer; intelligence + habits framework
  • Talk D2-03 (Anthropic) - Skills as organized folders with progressive disclosure
  • Talk D2-13 (Beyang Liu, Amp) - Finder, Oracle, Librarian, Kraken sub-agents
  • Talk D2-07 (Jacob Kahn, Meta) - Code World Model with execution tracing

Internal Tensions: Some argue for minimal scaffolding (Nik Pash: "frontier models bulldoze abstractions"), others for sophisticated harnesses (OpenAI, Anthropic). The pendulum swings between "let the model work" and "carefully engineer the environment."

Theme 5: Research → Plan → Implement

Summary: A specific workflow pattern emerged across multiple independent speakers: separate research (compressed truth), planning (compressed intent), and implementation phases with intentional context boundaries.

Key Points:

  • Research creates compressed truth about how systems work from code analysis
  • Plans include actual code snippets showing what will change—not just prose
  • Implementation stays in "smart zone" by starting with clean, compressed context
  • The "money step" is codifying learnings into prompts, rules, skills (Dan Shipper's compounding engineering)
  • Sometimes you must do the first migration by hand to "earn understanding" (Jake Nations)

Supporting Talks:

  • Talk D2-04 (Dex Horthy) - Detailed RPI methodology with open-source prompts
  • Talk D2-15 (Jake Nations, Netflix) - Million-line authorization refactor required manual first migration
  • Talk D1-19 (Dan Shipper, Every) - Plan → Delegate → Assess → Codify loop
  • Talk D2-05 (Lee Robinson, Cursor) - Use frontier models for planning, fast models for execution

Internal Tensions: How much upfront planning is warranted? Some see it as essential (Horthy, Nations), others as overhead that models can eventually skip. The answer may depend on codebase complexity.

Theme 6: The Quality vs. Velocity Trade-off

Summary: More code faster creates more problems faster—the central tension of AI-assisted development is maintaining quality while capturing velocity gains.

Key Points:

  • AI is "like a crazy mirror"—amplifies both excellence and sloppiness 10x (Kitze)
  • Writing code has become reading code—everyone is now primarily a code reviewer (Capital One)
  • PR review times increased 90% despite faster code generation (Qodo)
  • Technical debt to AI is just "more patterns to preserve"—can't distinguish essential from accidental complexity (Jake Nations)
  • Code review is the new bottleneck; without scaling it properly, you enter a vicious cycle (Capital One)

Supporting Talks:

  • Talk D1-09 (Itamar Friedman, Qodo) - Glass ceiling model; need AI-powered quality workflows
  • Talk D1-15 (Max Kanat-Alexander, Capital One) - Vicious vs. virtuous cycles of AI productivity
  • Talk D2-02 (swyx) - War on slop; taste as scarce resource
  • Talk D2-11 (Kitze) - Vibe engineering requires knowing when code is "good enough"

Internal Tensions: Some argue for strict quality gates (Qodo's automated review), others for faster iteration accepting more mistakes (Dan Shipper's "demo culture"). Context matters: greenfield vs. legacy, consumer vs. enterprise.

🤝 Agreements & Disagreements

Where Speakers Strongly Agree

Topic Consensus View Supporting Talks
Context is critical Managing context windows is the key to agent performance D1-02, D2-03, D2-04, D2-13
Verification matters more than generation The bottleneck has shifted from creating code to validating it D1-03, D1-09, D2-06, D2-12
Organizational change is hardest Technical tools are ahead of organizational adaptation D1-05, D1-07, D1-13, D1-18
Quality infrastructure amplifies AI Clean codebases, tests, docs multiply AI effectiveness D1-08, D1-15, D2-12
Sub-agents for context control Use sub-agents to isolate context, not role-play D2-04, D2-13
Measurement is broken Traditional productivity metrics fail for AI workflows D1-08, D1-16, D1-18

Where Speakers Disagree

Topic Position A Position B Talks
Scaffolding value Context engineering is essential; harnesses add value Frontier models bulldoze scaffolding; minimal is better D2-04 vs D2-18
Productivity gains Massive gains possible (10x+) with right approach Modest gains (10-15%) are realistic; some experts slowed D1-05, D1-19 vs D1-08, D2-19
Spec-driven development Critical for quality results "Semantically diffused"—means 100 things to 100 people D1-07 vs D2-04
Agent autonomy Let models work autonomously in sandboxes Humans must stay in the loop; verification costs dominate D1-02 vs D2-19
Compensation models Output-based pay aligns incentives Psychological safety matters more than incentive structures D1-17 vs D1-18

Unresolved Debates

  1. How much human oversight is needed as AI reliability improves? METR found ~95-99% reliability needed for tab-autocomplete to save time, but models are improving rapidly. When do we relax oversight?

  2. Are we measuring the right things? PR counts, lines of code, and even "time saved" may be misleading. What does meaningful AI productivity measurement look like?

  3. Will specialized agents or general-purpose agents win? Anthropic argues for general agents extended by skills; others build deeply specialized systems. The pendulum is still swinging.

  4. How do we preserve understanding as AI writes more code? Jake Nations: "Every time we skip thinking to keep up with generation speed, we're losing our ability to recognize problems." Is this skill atrophy inevitable?

🔮 Predictions & Trends

Near-term (6-12 months)

Based on the conference content, expect:

  1. Skills/prompt libraries become standard infrastructure - Every major AI coding tool will have a skills marketplace or prompt sharing mechanism. Teams will version and share effective prompts like code. (Anthropic, Dan Shipper, Arize)

    Note on GitHub Copilot support: GitHub Copilot has moved significantly in this direction. VS Code now supports multi-level .github/*-instructions.md files for repository-level custom instructions that can apply conditionally based on file types, and Microsoft has launched the "Awesome GitHub Copilot Customizations" community repository with reusable prompts and custom chat agents. GitHub has also adopted MCP (Model Context Protocol)—the same standard Anthropic introduced alongside skills—with MCP support now GA across VS Code, JetBrains, Eclipse, and Xcode. While Copilot hasn't explicitly adopted Anthropic's "skills folder" paradigm, the infrastructure for shareable, versioned prompt libraries is emerging. Expect convergence as the ecosystem matures.

  2. Validation tooling explosion - Automated code review, quality gates, and testing agents will see major investment. The verification bottleneck is too obvious to ignore. (Qodo, Factory, Capital One)

  3. Agent Manager interfaces emerge - Google's Anti-Gravity pattern—supervising multiple parallel agents—will be copied. The IDE becomes a "readitor" (read + editor—primarily for reading/reviewing agent-generated code rather than writing code) for reviewing agent work. (DeepMind, Amp)

  4. Context engineering becomes a job title - As the discipline formalizes, expect "Context Engineer" or "Agent Engineer" roles with specific skills around compaction, sub-agent design, and prompt architecture. (Horthy, Anthropic)

Medium-term (1-2 years)

  1. Organizational restructuring accelerates - McKinsey's "one-pizza pods" will become reality as productivity gaps become undeniable. Expect 3-5 person teams with consolidated "product builder" roles. (McKinsey, Bloomberg)

  2. Custom models per product - The Cursor/Poolside pattern ("product IS the model") spreads. Companies with sufficient scale will train models in their specific harnesses rather than using generic APIs. (Cursor, Poolside, Prime Intellect)

  3. Junior roles fundamentally change - Entry-level coding jobs shift toward review, testing, and agent supervision rather than code generation. Apprenticeship models evolve. (Capital One, Kitze)

  4. Hour-scale to day-scale agent tasks - With compute unlocks (40K+ GB300s) and better verification, agents handle tasks measured in hours, eventually days. Form factors keep evolving. (Poolside, Cursor)

Wild Cards

  • What if verification remains harder than generation? If 95-99% reliability stays out of reach, the human oversight requirement may not reduce, capping productivity gains regardless of capability improvements.
  • What if an AI achieves a novel algorithm? Current consensus is AI handles known patterns but can't match human experts on novel advances. A breakthrough would upend this.
  • Regulatory intervention - Defense/government deployments (Poolside) suggest high-stakes uses are coming. Regulatory frameworks could significantly alter the trajectory.

🔬 Special Topic: Skills vs Sub-Agents — Clarifying the Emerging Architecture

One of the most significant architectural discussions at AIE CODE 2025 centered on how to extend agent capabilities: through skills (Anthropic's paradigm) or through sub-agents (the Amp/Horthy pattern). While no speaker explicitly compared these patterns, careful analysis of three key talks reveals they are complementary mechanisms solving different problems, not competing alternatives.

Definitions from the Conference

Skills (Anthropic - Talk D2-03) Barry Zhang and Mahesh Murag defined skills as "organized collections of files that package composable procedural knowledge for agents." Key characteristics:

  • Static content, not runtime execution: Skills are folders containing instructions, scripts, and documentation
  • Progressively disclosed: Only metadata shown initially; full content loaded on-demand to protect context windows
  • Created by anyone: Simple enough for non-technical users in finance, legal, and HR to build
  • Persistent across sessions: Skills encode institutional knowledge that transfers between conversations
  • Versionable and shareable: Can be stored in Git, shared across teams, published to ecosystems

The critical insight: skills execute within the main agent's context, not as separate processes. When Claude "uses" a skill, it reads the skill's content into its current context window—there's no fork, no separate agent loop.

Sub-Agents (Amp - Talk D2-13, Horthy - Talk D2-04) Beyang Liu defined sub-agents as "the analog to subroutine calls in regular programming languages." Dex Horthy was more blunt: "Sub-agents are not for anthropomorphizing roles. They are for controlling context."

Key characteristics:

  • Runtime execution in separate context: Sub-agents fork into their own context windows
  • Return compressed results: After completing their task, they return only relevant findings to the parent
  • Specialized capabilities: Amp's sub-agents include Finder (code search), Oracle (deep reasoning), Librarian (external docs), and Kraken (large-scale refactors)
  • Context conservation: The primary purpose is extending effective context by isolating exploratory work
  • Ephemeral: Sub-agents exist only for the duration of a specific task

The critical insight: sub-agents are active runtime processes with their own context management, not static knowledge containers.

The Relationship: Complementary, Not Competing

Dimension Skills Sub-Agents
Nature Static procedural knowledge Active runtime processes
Context behavior Loaded INTO current context Fork SEPARATE context
Persistence Permanent, versioned Ephemeral, task-scoped
Purpose Encode domain expertise Manage context exhaustion
Creation Human-authored (or AI-assisted) Architecturally defined
Trigger Agent decides to "use" a skill Agent decides to delegate a subtask

How they work together: An agent might use a skill (loaded into context) to understand how to approach a task, then spawn a sub-agent (separate context) to do exploratory research, which returns compressed findings back to the main agent still operating with the skill's guidance.

Anthropic explicitly described this layering: "MCP provides connectivity; skills provide expertise." Sub-agents add a third layer: sub-agents provide context isolation for compute-intensive exploration.

Where Does Research-Plan-Implement Fit?

Dex Horthy's RPI workflow is neither a skill nor a sub-agent pattern—it's a methodology for intentional context compaction:

  1. Research phase: Can use sub-agents to explore codebase, returning compressed findings
  2. Planning phase: Creates a compressed artifact (the plan) that captures intent
  3. Implementation phase: Starts with clean context, loading only the plan

RPI could be encoded as a skill (a folder with research prompts, planning templates, and implementation guidelines), and its research phase could use sub-agents for exploration. It's a workflow that orchestrates these mechanisms.

When to Use Each Pattern

Use Skills when:

  • Encoding domain expertise that persists across sessions (tax procedures, coding standards, API patterns)
  • Packaging reusable procedural knowledge for multiple tasks
  • Enabling non-technical users to extend agent capabilities
  • Building an organizational knowledge base that compounds over time
  • The knowledge is "how to approach" something rather than "how to discover" something

Use Sub-Agents when:

  • Performing exploratory work that would exhaust the main context (searching large codebases)
  • Needing deep reasoning on a subtask without polluting main context
  • The work involves significant tool use that generates verbose output
  • You want to preserve main agent "trajectory" (Horthy: avoid "yelled at agent" patterns in context)
  • The results can be meaningfully compressed before returning to parent

Use Both when:

  • A skill defines how to approach a class of problems, and sub-agents handle the exploration within that approach
  • Building agentic systems that need both persistent expertise AND runtime context management

Conference Consensus (and Gaps)

Where speakers agreed:

  • Context management is the core challenge (all three talks)
  • Neither skills nor sub-agents are about "role-playing" (frontend agent, QA agent)—both are about capability and context
  • Simple mechanisms (folders, subroutine-like isolation) beat complex frameworks

What was NOT addressed:

  • No speaker explicitly compared skills to sub-agents (different talks, different contexts)
  • How skills and sub-agents compose in a unified architecture remains implicit
  • Whether sub-agents should have access to parent's skills, or maintain their own skill context
  • Performance and latency tradeoffs of sub-agent spawning vs. skill loading

Practical Guidance for Agentic System Builders

  1. Start with skills for domain knowledge: Before building complex sub-agent architectures, encode your team's expertise as skills. This knowledge persists and compounds.

  2. Add sub-agents for context isolation: When you see agents hitting context limits or generating verbose exploration output, introduce sub-agents that return compressed findings.

  3. Don't anthropomorphize either mechanism: Skills aren't "experts" and sub-agents aren't "team members." Skills are knowledge containers; sub-agents are context management primitives.

  4. Version your skills like code: Anthropic emphasized skills should be treated "like software"—tested, versioned, and maintained as codebases evolve.

  5. Design sub-agents for specific feedback loops: Per Amp's architecture, each sub-agent should have a refined tool set optimized for its specific task (Finder for search, Oracle for reasoning).

  6. Use RPI as your workflow orchestration: Research-Plan-Implement provides the phase boundaries where you make intentional decisions about which skills to load and when to spawn sub-agents.

Where Do Custom Agent Prompts Fit?

A related pattern not explicitly discussed at the conference but increasingly prevalent in practice is custom agent prompts—specialized instruction sets that customize how a general-purpose agent approaches specific types of work. This pattern exists in VS Code extensions (like PAW workflow agents), GitHub Copilot's custom chat modes, and various agent frameworks.

Custom Agent Prompts: A Third Pattern?

Dimension Skills Sub-Agents Custom Agent Prompts
Nature Static procedural knowledge Active runtime processes Behavioral configuration
Context behavior Loaded INTO context Fork SEPARATE context Shape INITIAL context
Purpose Encode domain expertise Manage context exhaustion Configure agent behavior
Persistence Permanent, versioned Ephemeral, task-scoped Session-scoped or persistent
Example "How to deploy to AWS" folder "Search codebase for X" subprocess "You are a code reviewer focused on security"

The Relationship to Skills and Sub-Agents:

Custom agent prompts overlap significantly with skills in function but differ in mechanism:

  • Skills are content packages the agent can choose to load when relevant
  • Custom prompts are initial instructions that shape agent behavior from the start
  • In practice, a custom prompt often describes when to use certain skills

Custom agent prompts can also define when and how to spawn sub-agents:

  • A "Research Agent" prompt might instruct the agent to spawn sub-agents for each code area being explored
  • A "Implementation Agent" prompt might instruct the agent to avoid sub-agents and work directly in main context

GitHub Copilot's Evolution:

GitHub Copilot has moved toward this pattern:

  • Custom chat agents can now be selected in VS Code's agent mode
  • Multi-level instruction files (.github/*-instructions.md) provide repository-level behavioral configuration
  • MCP support (now GA) enables connectivity similar to Anthropic's skills ecosystem

This suggests convergence: the "skill" (what domain knowledge to use), the "custom prompt" (how to behave), and the "sub-agent definition" (when to fork context) may eventually merge into a unified "agent configuration" primitive—a folder containing behavior instructions, domain knowledge, and sub-agent policies.

Practical Implication:

When building agent workflows today:

  1. Use custom prompts to define agent personality, approach, and constraints for a task type
  2. Reference skills within those prompts for domain knowledge the agent should load
  3. Specify sub-agent policies in the prompt (when to spawn, what to return)

This layered approach—prompt shapes behavior, skills provide knowledge, sub-agents manage context—may become the standard architecture as tooling matures.

Supporting Talks: D2-03 (Anthropic - Skills Not Agents), D2-04 (Dex Horthy - Context Engineering), D2-13 (Beyang Liu - Amp Architecture)

🏢 Special Topic: Organizational Structures for AI-Native Development

The conference provided surprisingly concrete guidance on how to restructure engineering organizations for AI-augmented development. Four talks in particular—Yegge/Kim's fireside chat, McKinsey's enterprise study, Bloomberg's 9,000-engineer deployment, and METR's developer RCT—offered specific recommendations that, taken together, form an actionable playbook for organizational transformation.

The Core Problem: 70% Haven't Changed Roles

McKinsey's survey of 300 enterprises revealed a stark reality: 70% have deployed AI coding tools without changing roles or workflows. These organizations see only 5-15% productivity improvements. Meanwhile, the top performers—those 7x more likely to have "AI-native workflows"—achieve 5-6x faster delivery.

The gap isn't technical. The tools work. The gap is organizational.

Specific Team Structure Recommendations

The McKinsey Model: "One-Pizza Pods" (3-5 People)

McKinsey explicitly declared "two-pizza teams are dead"—the 8-10 person agile teams that were standard for 15+ years no longer optimize for AI-augmented development. Their replacement:

One-Pizza Pods (3-5 people):

  • Consolidated "Product Builder" roles: No separate frontend, backend, QA engineers—instead, full-stack fluent individuals who orchestrate agents
  • PMs create code prototypes directly: Rather than iterating on long PRDs, product managers iterate on specs with agents
  • Workflow-organized squads: One pod focuses on bug fixes, another on greenfield development—matching work type to optimal AI workflows

Why smaller works better:

  • Coordination costs dominate when AI accelerates individual output
  • Agents handle what previously required specialists (testing, documentation, boilerplate)
  • Smaller pods can form more teams from same headcount, increasing parallelism

The Yegge/Kim Model: 2-Person Teams + Repo Ownership

Steve Yegge and Gene Kim went even more radical, based on case studies from their "Vibe Coding" book research:

Minimum viable team: 2 people

  • "A developer and a domain expert"—or as Kent Beck said, "a person with a problem and a person who can solve it"
  • One Travelopia case study: Legacy application replacement in 6 weeks with "a very small team"—where previously "we would need a team of eight people"

One engineer per repo:

  • Direct quote from the talk: "Our code velocity is so high, we've concluded that we can only have one engineer per repo—because of merge conflicts. We haven't figured out the coordination cost mechanism yet."
  • This isn't aspirational—this is what high-velocity AI-augmented teams are already discovering

Leaders must code:

  • Cisco Security case study: SVP required 100 top leaders to "vibe code one feature into production in a quarter"
  • Dr. Top Pal (Fidelity): "Had a vision for years, team said it would take 5 months. He spent 5 days vibe coding it by himself and put it into production."
  • Gene Kim's observation: "Leaders who can code are reshaping their organizations as they realize what's possible"

The Adoption Problem: New Hires vs. Top-Down Mandates

Bloomberg (Lei Zhang) and DX (Justin Reock) offered contrasting approaches that converged on the same insight: top-down mandates don't work.

What fails:

  • Mandating tool usage without role changes
  • Rolling out tools without hands-on upskilling
  • Expecting behavior change without incentive alignment
  • Justin Reock's data: Companies show +20% to -20% productivity variance with same tools—culture determines outcomes

What works (Bloomberg's approach):

  1. Integrate AI into new hire training: Bloomberg has a 20+ year training program. They incorporated AI coding into onboarding. New hires learn AI-augmented development as the default, then return to teams and challenge seniors: "Why don't we do it this way?"

  2. Guild/Community Programs: Cross-organizational communities ("champ programs") where passionate adopters share learnings. Bloomberg bootstrapped an "engineer AI productivity community" that organically deduplicates efforts and spreads best practices.

  3. Leadership workshops: Bloomberg's data showed "individual contributors have much better, stronger adoption than our leadership team." Response: leadership workshops to ensure managers can guide AI-era development.

The Bloomberg "paved path" infrastructure:

  • Gateway for model experimentation—teams can quickly test which model works best
  • MCP directory/hub—teams discover existing MCP servers instead of rebuilding
  • Standard platform for tool deployment with quality controls
  • Principle: "Make the right thing extremely easy to do. Make the wrong thing ridiculously hard to do."

The Expertise Paradox: Why Expert Developers Get Slower

METR's RCT (Joel Becker) revealed a counterintuitive finding that organizations must account for: expert developers took 19% longer with AI tools compared to without.

Why this happens:

  1. High-context developers already know the solution: They're not exploring—they're limited by typing speed. Using AI adds instruction overhead without solving their actual bottleneck.
  2. Low AI reliability creates verification burden: At current reliability levels, checking and correcting AI output can exceed the time saved.
  3. Overoptimism about AI usefulness: Developers expected ~25% speedup, got -19%. Misaligned expectations led to suboptimal tool usage.

Organizational implications:

  • Don't assume uniform gains across developer populations
  • High-context experts on large, mature codebases may need different workflows than generalists on greenfield work
  • Reliability threshold: ~95-99% reliability needed for tab-autocomplete workflows to actually save time
  • "Perhaps the result will have already changed by the time I'm giving this talk"—this is improving rapidly

Role Evolution: What Each Role Becomes

Based on conference consensus:

Traditional Role AI-Native Role Key Change
Frontend Engineer Product Builder Full-stack agent orchestration; specialization dissolves
Backend Engineer Product Builder Same consolidation; agents handle boilerplate
QA Engineer Validation Engineer Focus on verification criteria, not manual testing
PM (PRD Writer) PM (Spec + Prototype) Create code prototypes directly; iterate specs with agents
Tech Lead Agent Architect Design agent workflows, sub-agent patterns, context strategies
Engineering Manager Enablement Lead Upskilling, psychological safety, measurement—not task assignment

The Measurement Problem

McKinsey found bottom performers often weren't even measuring speed or productivity—only 10% measured productivity. The top performers use holistic measurement:

Inputs:

  • Investment in tools + upskilling + change management time

Direct Outputs:

  • Adoption breadth/depth
  • Velocity/capacity increase
  • Developer NPS (are they enjoying their craft more?)

Quality Outputs:

  • Code security and quality
  • Resiliency (e.g., mean-time-to-resolve priority bugs)

Business Outcomes:

  • Time to revenue
  • Price differential for higher quality features
  • Cost reduction per pod

Actionable Guidance: The Team Restructuring Playbook

Based on conference insights, here's a practical sequence for organizational transformation:

Phase 1: Foundation (1-2 months)

  1. Establish measurement baseline—you can't improve what you don't measure
  2. Build "paved path" infrastructure: gateway for model access, tool directory, standard deployment platform
  3. Integrate AI tools into new hire onboarding immediately
  4. Create opt-in learning communities (guilds, champs)

Phase 2: Pilot Restructuring (2-4 months)

  1. Select 2-3 teams for "one-pizza pod" experiments
  2. Consolidate roles: product builder replacing frontend/backend/QA split
  3. Assign PMs to prototype in code, not just write PRDs
  4. Measure: delivery speed, merge frequency, code quality, developer satisfaction

Phase 3: Workflow Redesign (3-6 months)

  1. Move from story-driven to spec-driven development
  2. Reorganize squads by workflow type (bug fixes vs. greenfield)
  3. Implement continuous planning vs. quarterly planning
  4. Address repo ownership—consider single-owner for high-velocity work

Phase 4: Scale (6-12 months)

  1. Roll out restructured model to remaining teams
  2. Leadership workshops—ensure managers can guide AI-era development
  3. Adjust incentive structures (consider output-based elements)
  4. Build internal skills/prompt library that compounds organizational knowledge

Warning Signs: When Transformation Is Failing

Based on the conference's failure cases:

  • Adoption drops off after initial spike: You've deployed tools without changing workflows (seen at McKinsey client)
  • Leadership lags IC adoption: Managers can't guide what they don't understand
  • Same roles, same ceremonies, same team sizes: 70% of enterprises are stuck here
  • Measuring PRs and lines of code: These metrics are meaningless for AI-augmented work
  • Expert developers getting slower: You may need different workflows for high-context experts

The Controversial Proposals

The conference surfaced radical ideas that may become mainstream:

  1. Story-point compensation (Arman Hezarkhani, 10x): Pay engineers based on output like salespeople. Aligns incentives with AI mastery.

  2. Leaders must vibe-code features (Yegge/Kim): Cisco's SVP required 100 leaders to ship features via vibe coding. Leaders who code reshape their organizations.

  3. One engineer per repo (Yegge/Kim case study): Merge conflicts make coordination impossible at high velocity. Single ownership eliminates coordination tax.

  4. Dissolve specialist roles entirely (McKinsey): No frontend, no backend, no QA—just "product builders" orchestrating agents.

These remain tensions, not consensus. But the direction is clear: smaller teams, fewer specialized roles, more agent orchestration, and different relationships between humans and AI.

Supporting Talks: D1-05 (Yegge & Kim), D1-07 (McKinsey), D1-13 (Bloomberg), D1-17 (10x), D1-18 (DX), D2-19 (METR)

🏗️ Special Topic: Preparing Your Codebase for AI Agents

One of the most actionable insights from AIE CODE 2025 was the strong correlation between codebase quality and AI effectiveness. Stanford's research (D1-08) showed an R² of 0.40 between an "environment cleanliness index" and AI productivity gains—double the correlation of token usage (R² ~0.20). This means how you prepare your codebase matters more than how much AI you use.

This section consolidates guidance from multiple talks on what "agent-ready" codebases look like and how to get there.

The Core Insight: What's Good for Humans Is Good for AI

Max Kanat-Alexander (Capital One, D1-15) crystallized the principle: agents face the same friction points humans do—just magnified. Bad codebases, missing documentation, slow CI pipelines, and poor testing hurt agent productivity exactly as they hurt human productivity. The difference: errors compound faster because agents are more persistent and error-prone.

This creates two possible cycles:

Vicious Cycle Virtuous Cycle
Bad codebase → agent nonsense → developer frustration → rubber-stamp PRs → worse codebase → decreasing AI productivity Good foundations → agent effectiveness → quality review → improving codebase → accelerating AI productivity

The Eight Pillars of Agent Readiness (Factory Framework)

Eno Reyes (Factory, D2-12) outlined eight pillars of validation that enable autonomous agent workflows:

  1. Automated format checking: Consistent code style that agents can follow
  2. Opinionated linters: Strict enough that agents always produce senior-engineer-level code
  3. High test coverage: Tests that fail on slop, pass on quality—not just "50-60% coverage" (which breaks agent workflows)
  4. Clear documentation: External context (data shapes, specifications, requirements) that can't be in the code must be written somewhere accessible
  5. Agents.md files: Open standard most coding agents support—documentation specifically for AI systems
  6. Fast CI/CD: 30-second feedback loops vs. 20-minute loops make dramatic differences for agent iteration
  7. Clear error messages: Agents cannot divine what "500 internal error" means—deterministic validation with actionable messages
  8. Type safety: Well-typed codebases enable better reasoning about data flow and contracts

Stanford's Environment Cleanliness Index

Yegor Denisov-Blanch (Stanford, D1-08) measured four factors that together showed 40% correlation with AI productivity lift:

Factor Why It Matters for AI
Tests Provide deterministic validation for agent iteration; enable confidence in changes
Types Help agents reason about data flow, catch errors at compile time
Documentation Supplies context agents can't infer from code alone
Modularity Enables isolated changes without ripple effects; cleaner context for focused tasks

The critical finding: a case study showed a 350-person team whose PR count increased 14% post-AI, but code quality dropped 9% and rework increased 2.5x. Without quality infrastructure, you may have negative ROI despite increased "productivity."

The Technical Debt Problem

Jake Nations (Netflix, D2-15) identified a crucial limitation: AI treats technical debt as just more patterns to preserve. Agents can't distinguish essential complexity (the fundamental difficulty of the problem) from accidental complexity (workarounds, abstractions that made sense once, frameworks that outlived their usefulness).

This means:

  • Legacy code gets faithfully reproduced, patterns and all
  • The "weird gRPC-acting-like-GraphQL from 2019" becomes enshrined as a pattern to follow
  • Only humans can separate debt from design

Implication: Before unleashing agents on legacy codebases, someone needs to do the hard work of identifying what should be preserved vs. what should be eliminated. Sometimes you must "do the first migration by hand" to earn the understanding.

Why Standard Tools Matter

Kanat-Alexander made a striking argument: use industry-standard tools the way the industry uses them—you're fighting the training set if you don't.

  • If you invented your own package manager, undo it
  • Don't use obscure programming languages for production work—they're not well-represented in training data
  • Standard tooling enables agents to leverage patterns learned from millions of examples
  • Agents work better with well-documented, widely-used frameworks

Practical Checklist: Making Your Codebase Agent-Ready

Based on conference insights, here's a prioritized checklist for engineering teams:

Phase 1: Validation Foundation (High Impact, Start Here)

  • Achieve 80%+ test coverage on critical paths (not just overall percentage)
  • Configure linters to be opinionated—agents should produce senior-level code by default
  • Ensure CI runs in <5 minutes for fast feedback loops
  • Make all error messages actionable—no cryptic stack traces without guidance

Phase 2: Context Infrastructure

  • Create agents.md or equivalent for AI-specific documentation
  • Document the "why" for non-obvious architectural decisions
  • Ensure external dependencies (API specs, data shapes) are accessible to agents
  • Add type definitions where missing (especially dynamic languages)

Phase 3: Pattern Hygiene

  • Identify and document patterns agents should follow
  • Mark deprecated patterns explicitly (agents will follow them otherwise)
  • Separate essential from accidental complexity in core areas
  • Consider doing first migrations by hand to establish the pattern

Phase 4: Review Infrastructure

  • Assign specific reviewers with SLOs (not "hey team, someone review")
  • Create code review guidelines for AI-generated code
  • Establish quality gates that catch agent slop before merge
  • Train reviewers on common AI failure modes

The ROI Case

The 5-7x productivity gains speakers like Eno Reyes (Factory) described don't come from tool selection—they come from validation infrastructure investment. The math:

  • With 50% test coverage and flaky CI: Agents produce unreliable output requiring heavy human review; autonomous workflows impossible
  • With 90% test coverage and fast CI: Agents can iterate autonomously; human review focused on design decisions; parallel agent execution becomes feasible

As Reyes put it: "One opinionated engineer with validation infrastructure scales their impact across the entire organization."

Warning: The Slop Accumulation Problem

Multiple speakers warned about a specific failure mode: AI-generated code passes basic checks but accumulates problems over time.

  • Itamar Friedman (Qodo, D1-09): "3x more code generates 3x more bugs—same defect rate per line means more total defects"
  • swyx (D2-02): "The amount of taste needed to fight slop is an order of magnitude bigger than needed to produce it"
  • Kitze (D2-11): "AI is like a crazy mirror—amplifies both excellence and sloppiness 10x"

The solution isn't rejecting AI but building taste amplifiers—validation infrastructure that catches slop before it compounds:

  • Tests that fail on half-working implementations
  • Linters that enforce patterns, not just syntax
  • Review standards that require understanding, not just "it works"

Supporting Talks

This section synthesizes insights from:

  • D1-08 (Yegor Denisov-Blanch, Stanford) - Environment cleanliness index and productivity correlation
  • D1-15 (Max Kanat-Alexander, Capital One) - "What's good for humans is good for AI"
  • D2-12 (Eno Reyes, Factory) - Eight pillars of validation
  • D2-15 (Jake Nations, Netflix) - Technical debt as "patterns to preserve"
  • D1-09 (Itamar Friedman, Qodo) - Glass ceiling and quality workflows

🎬 Must-Watch Recommendations

The Essential 5 (If You Only Watch Five Talks)

  1. Talk D2-04: Dex Horthy - Context Engineering for Coding Agents

    • Why: The most practical, actionable framework presented at the conference. The "dumb zone" concept and Research-Plan-Implement workflow apply immediately to any team.

  2. Talk D1-08: Yegor Denisov-Blanch (Stanford) - AI Productivity Research

    • Why: Rigorous data cutting through hype. The 10% median gain, 40% codebase quality correlation, and "death valley" at 10M tokens challenge assumptions.

  3. Talk D2-03: Barry Zhang & Mahesh Murag (Anthropic) - Skills Not Agents

    • Why: Paradigm-defining. The "stop building agents, start building skills" thesis will shape how the industry thinks about agent extension for years.

  4. Talk D2-19: Joel Becker (METR) - Agents vs Developers Study

    • Why: The 19% slowdown finding is the most provocative data point of the conference. Understanding why forces intellectual honesty about AI productivity claims.

  5. Talk D1-07: McKinsey - Reshaping Software Delivery

    • Why: Enterprise reality check with concrete data. The 70% unchanged roles finding and "one-pizza pod" vision provide strategic direction.

By Interest Area

For Enterprise AI Leaders (Deploying AI at scale):

  • Talk D1-07 (McKinsey) - Organizational transformation playbook
  • Talk D1-13 (Bloomberg) - "Paved path" infrastructure at 9K engineer scale
  • Talk D1-12 (Northwestern Mutual) - Incremental delivery in risk-averse environments
  • Talk D1-18 (DX) - Measurement framework for AI impact

For AI Tool Builders (Building the next Cursor/Copilot):

  • Talk D2-04 (Dex Horthy) - Context engineering patterns
  • Talk D2-06 (Naman Jain, Cursor) - Evaluation methodology and dynamic benchmarks
  • Talk D2-10 (OpenAI) - Agent RFT for tool-specific fine-tuning
  • Talk D2-09 (Prime Intellect) - RL environments as product

For Individual Developers (Using AI tools daily):

  • Talk D2-11 (Kitze) - Vibe engineering vs. vibe coding distinction
  • Talk D1-15 (Capital One) - "No-regrets investments" for AI readiness
  • Talk D1-19 (Dan Shipper) - Compounding engineering workflow
  • Talk D2-15 (Jake Nations) - When to do things by hand first

For the Research-Minded (Understanding the frontier):

  • Talk D2-07 (Jacob Kahn, Meta) - Code World Model concepts
  • Talk D2-08 (Applied Compute) - RL training efficiency
  • Talk D2-14 (Gimlet Labs) - AI kernel generation
  • Talk D2-17 (Arize) - Prompt learning methodology

For the Contrarian (Talks that challenge conventional wisdom):

  • Talk D2-19 (Joel Becker, METR) - Expert developers slowed 19% by AI
  • Talk D2-18 (Nik Pash, Cline) - Scaffolding is obsolete; benchmarks are what matter
  • Talk D1-17 (Arman Hezarkhani) - Pay engineers like salespeople
  • Talk D2-15 (Jake Nations) - "Easy" ≠ "Simple"; we're losing understanding

💼 Actionable Takeaways

For Engineering Teams

  1. Implement Research-Plan-Implement workflow: Before coding sessions, create compressed research docs. Plans should include actual code snippets. This keeps agents in the "smart zone."

  2. Invest in validation infrastructure: Linters strict enough that agents produce senior-level code. Tests that fail on slop, pass on quality. Agents.md files for AI-specific documentation.

  3. Build context management into your process: Track context window usage. Use sub-agents for exploration that return compressed findings. Practice intentional compaction.

  4. Start codifying knowledge: Every effective prompt pattern should be saved. Claude.md files, cursor rules, skills—make learnings reusable across the team.

For Engineering Leaders

  1. Measure speed AND quality together: PR counts and acceptance rates are misleading. Track code quality, rework rates, and time-to-merge alongside velocity metrics.

  2. Create psychological safety for AI experimentation: Top-down mandates fail. Provide education AND time to learn. Make it safe to try and fail.

  3. Consider role restructuring: The "product builder" consolidated role is coming. Start planning for smaller pods with broader responsibilities.

  4. Evaluate your codebase for agent-readiness: Test coverage, type safety, documentation quality, modularity—these predict AI effectiveness. Invest here before tools.

For AI Product Builders

  1. Speed is a feature: The "airplane Wi-Fi problem" is real. Users need either fast synchronous tools OR truly autonomous background agents—not the middle ground.

  2. Build verification into the product: Don't just generate; help users validate. LLM-as-judge, confidence signals, quality gates—verification is the bottleneck.

  3. Design for context management: Progressive disclosure, sub-agent patterns, intentional compaction—context engineering should be first-class.

  4. Consider the skills/prompt library pattern: Let users build and share expertise. The value compounds as organizational knowledge accumulates.

📈 State of AI Coding (Conference Consensus)

What's Considered "Solved"

  • Code completion and autocomplete: Works well for greenfield work with clean context
  • Boilerplate generation: Repetitive code, standard patterns, configuration files
  • Documentation generation: API docs, code comments, README files
  • Test generation (for testable code): Creating test scaffolds from specifications
  • Code explanation: Understanding and summarizing existing code

Active Frontiers

  • Context engineering: Managing what enters the context window—skills, sub-agents, compaction
  • Verification automation: Moving beyond "passes tests" to "production ready"
  • Long-horizon tasks: Agents running for hours, handling complex multi-step workflows
  • Specialized models: Training models in specific harnesses (Cursor Composer, Poolside)
  • Enterprise deployment: Scaling beyond pilots to production at 9K+ engineer organizations

Open Challenges

  • Legacy codebase effectiveness: AI gains drop quickly outside greenfield work
  • Expert developer productivity: Top contributors may not benefit because their bottleneck isn't typing speed (which AI accelerates) but thinking through complex problems, architectural decisions, and system design. AI speeds up code generation but not cognitive work, so experts who spend most of their time thinking see less benefit.
  • Essential vs. accidental complexity: AI can't distinguish technical debt from intentional design
  • Reward hacking: Models find unexpected ways to game metrics
  • Understanding preservation: How do we maintain human comprehension as AI writes more code?

The Next Big Things

The conference surfaced several distinct emerging trends beyond general AI capability improvements. Each represents a potential paradigm shift with different timelines and implications:

1. Multi-Agent Coordination with Specialized Roles

Multiple speakers hinted at orchestrated ecosystems of specialized agents rather than monolithic general-purpose systems—Jules + Stitch + Insights (Google D1-11), parallel agents in Agent Manager (DeepMind D2-20), sub-agent swarms (Amp D2-13, Gimlet D2-14). The pattern: compose small, focused agents with clear responsibilities rather than building one agent that does everything.

Why it matters: Mirrors how human engineering teams work—specialists collaborating through well-defined interfaces rather than generalists doing everything. Enables better context management (each agent maintains focused context) and easier debugging (isolate failures to specific agents).

Timeline: Already emerging in production systems (Cursor Composer, Amp, Google Jules). Expect formalization of patterns in 6-12 months.

2. Code World Models and Execution Simulation

Jacob Kahn (Meta FAIR, D2-07) introduced the Code World Model—a 32B parameter model trained to predict program execution traces, not just generate code. The model can trace code line-by-line, showing local variable values at each step, enabling capabilities like "neural debuggers" where developers express program intent loosely and the model fills in details by simulating execution.

Key concept: "What if we modeled execution more explicitly? [...] We want to predict program execution because we believe it might lead to us better modeling things about code." The model can simulate execution without actually running code—enabling reasoning about expensive distributed systems, debugging without execution, and even approximating otherwise intractable problems.

Why it matters: Shifts from "AI writes code" to "AI understands computation." A model that can simulate execution can catch bugs before runtime, reason about performance, and help developers understand complex systems without executing them.

Timeline: Research stage (open model on Hugging Face). Production adoption 12-24 months. May become standard capability for frontier models.

3. Agent RFT (Agent Reinforcement Fine-Tuning)

Will Hang and Cathy Zhou (OpenAI, D2-10) revealed Agent RFT—fine-tuning reasoning models to use your specific tools and environment through reinforcement learning. Unlike prompt engineering, Agent RFT changes model weights to adapt to domain-specific tools, achieving better performance with lower latency.

Key examples from the talk:

  • Cognition (Devin): 10-point improvement on code edit planning by training on 1000 examples with F1 reward
  • Qodo: 6% improvement on code review deep research with fewer tool calls
  • Cosine: State-of-the-art on multiple benchmarks by training with 30 tools and strict test-passing rewards
  • Mako: 72% better than baseline on GPU kernel generation with only ~100 PyTorch prompts

Why it matters: "The model learns to stay within [tool call] budget while preserving or exceeding the original ML performance." Enables product-specific models (like Cursor Composer) without building from scratch. Sample efficient—some teams saw success with only 10 examples.

Timeline: Available now via OpenAI. Expect democratization (more providers, self-serve) in 6-12 months.

4. Environments as Research Infrastructure

Will Brown (Prime Intellect, D2-09) argued that environments are the entry point to AI research—not just for RL training, but as the unifying abstraction for evals, synthetic data, and production deployment. "Environments are like the web apps of AI research"—simple to start, can scale to full product complexity, and pedagogical in nature.

Key insight: "The product IS the model" trend (Cursor, Codex) is really about training models in the harness that represents the product. Environments provide the abstraction: task + harness + rewards = environment, whether that's an eval benchmark, an RL training loop, or production traffic.

Why it matters: Makes AI research more accessible beyond large labs. "The ability to do research and have at least the option of deciding where in your product you might want to customize a model [...] gives you a lot more flexibility." Environments compound—tooling improvements help everyone.

Timeline: Accelerating now. Prime Intellect's "open superintelligence stack" and similar efforts aim to make training accessible. Expect "environment engineering" to become standard practice in 12-24 months.

🏷️ Conference Keyword Cloud

Companies/Products: Anthropic, Claude, Claude Code, Cursor, Composer, OpenAI, Codex, GPT-5, Google, Jules, Gemini, DeepMind, Anti-Gravity, Replit, Qodo, MiniMax, M2, Amp, Sourcegraph, Factory, Poolside, Cline, Prime Intellect, DX, McKinsey, Bloomberg, Northwestern Mutual, Capital One, Every, Browser Company, DIA, Arize, Gimlet Labs, METR

Concepts/Techniques: context engineering, skills, MCP, sub-agents, verification, validation, painted doors, glass ceiling, dumb zone, smart zone, Research-Plan-Implement, compounding engineering, vibe coding, vibe engineering, slop, kino, progressive disclosure, intentional compaction, harness, scaffolding, reward hacking, time horizon, prompt learning, Agent RFT

People: Katelyn Lesse, Barry Zhang, Mahesh Murag, Michele Catasta, Steve Yegge, Gene Kim, Bill Chen, Brian Fioca, Yegor Denisov-Blanch, Itamar Friedman, Kat Korevec, Lei Zhang, Max Kanat-Alexander, Dan Shipper, swyx, Dex Horthy, Lee Robinson, Naman Jain, Jacob Kahn, Will Brown, Kitze, Eno Reyes, Beyang Liu, Natalie Serrino, Jake Nations, Jason Warner, Joel Becker, Kevin Hou

Emerging Terms: agent-first IDE, artifacts, Code World Model, execution tracing, time horizon methodology, prompt learning, Agent RFT, ClineBench, validation criteria, tea kettle verifier, product-is-the-model, research-product flywheel

💭 Rob's Reflections

Personal commentary extending beyond the conference presentations.

On the "Airplane Wi-Fi Problem" (Insight #8: Fast + Smart)

The conference talks about "Fast + Smart > Just Smart" and the "airplane Wi-Fi problem" where tools are too slow for flow but not autonomous enough for background execution. Lee Robinson described this frustrating middle ground—you're waiting, but not quite free to fully context-switch.

There's an interesting parallel to programming concepts here. The way I've adapted my own workflow is to parallelize across different work streams—though it's really more concurrency than parallelization.

Think of it like thread blocking in programming:

  • When an AI agent is "spinning" (processing a request), that's an IO blocking operation for me as the developer
  • Instead of waiting, I shift to the next project or work stream that needs progress
  • I push that work to a point where AI agents can take over
  • When that "blocks," I move to the next task
  • My own review and interaction is the sequential IO operation that can't be parallelized
  • Everything else can be concurrent

The goal is to maximize concurrency to maximize impact, even when individual tool latency is high. It's about turning the "frustrating middle ground" Lee Robinson described into an orchestrated workflow where you're always making progress on something while agents process other work.

This maps well to the Research-Plan-Implement workflow—you can have:

  • Research running for Project A (agent working)
  • Implementation review for Project B (your blocking IO)
  • Planning output for Project C ready for your review

The limiting factor becomes your context-switching cost and working memory, not tool latency.

Appendix: Talk Quick Reference

YouTube Videos:

ID Day Speaker Company Core Thesis Watch
D1-00 1 Opening Performance - Code is evolving from instruction to human-AI co-creation 0:00
D1-01 1 Alex Lieberman - Opening Remarks 13:19
D1-02 1 Katelyn Lesse Anthropic Maximize performance via capabilities, context management, and compute 16:16
D1-03 1 Michele Catasta Replit True autonomy means 100% technical decision offloading 29:33
D1-04 1 Lisa Orr Zapier Support teams + AI are uniquely positioned for bug fixes 54:08
D1-05 1 Yegge & Kim Authors Vibe coding reshapes orgs 100x more than DevOps 1:10:06
D1-06 1 Chen & Fioca OpenAI The harness is the hard part; use Codex as abstraction layer 2:02:00
D1-07 1 McKinsey McKinsey Rewire workflows AND roles to unlock 5-6x delivery gains 2:20:03
D1-08 1 Denisov-Blanch Stanford Median 10% gains; codebase quality predicts AI effectiveness 2:41:45
D1-09 1 Friedman Qodo 3x code = 3x bugs; invest in AI-powered quality workflows 2:58:11
D1-10 1 Olive Song MiniMax Small models with interleaved thinking can compete 3:19:30
D1-11 1 Kat Korevec Google Proactive agents reduce mental load with 3 autonomy levels 4:47:42
D1-12 1 Asaf Bord NW Mutual Incremental delivery with exit ramps for risk-averse orgs 5:03:24
D1-13 1 Lei Zhang Bloomberg Target maintenance work; build "paved path" infrastructure 5:26:00
D1-14 1 Samir Mody Browser Co Model behavior is a craft; prompt injection needs UX defense 5:44:15
D1-15 1 Kanat-Alexander Capital One What's good for humans is good for AI; no-regrets investments 6:02:07
D1-16 1 NLW Super Int. 82% positive ROI; systematic adopters dramatically outperform 7:00:20
D1-17 1 Hezarkhani 10x Output-based compensation aligns incentives for AI mastery 7:15:01
D1-18 1 Justin Reock DX Psychological safety + measurement framework for AI success 7:34:01
D1-19 1 Dan Shipper Every 100% AI adoption unlocks compounding engineering 7:52:14
D2-01 2 Jed Borovik Google AI coding is "the most important problem" in applied AI 10:51
D2-02 2 swyx Latent Space War on slop; taste is orders of magnitude harder to scale 14:40
D2-03 2 Zhang & Murag Anthropic Stop building agents, start building skills 23:52
D2-04 2 Dex Horthy Human Layer Context engineering via Research-Plan-Implement 40:08
D2-05 2 Lee Robinson Cursor Fast + smart via co-designed model + IDE 1:00:31
D2-06 2 Naman Jain Cursor Dynamic evaluations combat contamination and hacking 1:15:57
D2-07 2 Jacob Kahn Meta FAIR Code World Model: world models for computation 2:07:18
D2-08 2 Applied Compute Applied Async RL with staleness management: 60% speedup 2:23:55
D2-09 2 Will Brown Prime Intel Environments are the entry point to AI research 2:44:04
D2-10 2 Hang & Zhou OpenAI Agent RFT adapts models to your tools and environment 3:02:33
D2-11 2 Kitze Sizzy Vibe engineering requires knowing "good enough" 3:19:24
D2-12 2 Eno Reyes Factory Validation criteria is the limiter, not agent capability 5:11:35
D2-13 2 Beyang Liu Amp Sub-agents for context control, not role anthropomorphization 5:27:02
D2-14 2 Serrino Gimlet Labs AI kernel optimization: promising tool, not silver bullet 5:45:28
D2-15 2 Jake Nations Netflix "Easy" ≠ "Simple"; we must earn understanding 6:04:39
D2-16 2 Jason Warner Poolside Vertical integration from data center to model 7:07:26
D2-17 2 Dhinakaran Arize Prompt learning: RL for system prompts with 150 examples 7:23:33
D2-18 2 Nik Pash Cline Benchmarks > scaffolding; open-source real engineering data 7:34:21
D2-19 2 Joel Becker METR Expert developers slowed 19% by AI tools 7:48:33
D2-20 2 Kevin Hou DeepMind Agent-first IDE with three surfaces and artifacts 8:09:48
D2-21 2 swyx + Ben AI Engineer 2026 events: SF, London, Miami, Paris, Melbourne 8:35:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment