Daily Digest — 2026-08-10

Nate B Jones argues that a significant portion of AI engineers and general employees harbor resentment towards AI initiatives, with a survey showing nearly 30% admit to sabotaging AI. To overcome this, leadership must establish trust and lead with integrity through a three-principle roadmap: The Contract, Where You Start, and Pilot To Scale.

Principle One: The Contract emphasizes making a public commitment to your team about AI adoption. Leaders often avoid direct conversations about AI's impact on jobs, but employees hear media narratives (e.g., Jack Dorsey cutting 4,000+ roles at Block, citing AI focus) and naturally worry about job security and headcount reductions. Leaders must explicitly address these fears by stating that AI is not designed to destroy jobs or eliminate roles. Instead, the commitment should focus on the well-being of the team as a whole. This transparency builds trust and avoids the perception that AI is a covert tool for layoffs. Leaders should frame AI as an enhancer and an opportunity to expand horizons, much like Jensen Huang’s approach at Nvidia, which focuses on tremendous productivity gains without employee reductions, challenging companies cutting staff for lacking 'imagination'. This vision-driven approach helps secure team trust by demonstrating a shared future, rather than focusing on job cuts.

Principle Two: Where You Start focuses on scoping the first change honestly. It’s crucial to select a meaningful pilot project that defines success properly, moving beyond mere activity metrics (e.g., 'people use the tool') to tangible business outcomes (e.g., 'better work' or real value creation). The pilot should have a bottom-line impact, be tied to problems AI already does well (proven pattern), and not be an unsolved problem (lower risk). For example, AI can be applied to streamline routine customer service calls with AI agents, while humans handle more complex inquiries. Or, in engineering, AI can assist with certain tasks to learn AI-native ways of working. This specific, honest approach helps avoid situations like Uber’s AI budget overruns due to unchecked token usage, which led to confusion and distrust among employees. Leaders must define success in terms of measurable value that aligns with business goals, ensuring the project provides early signals of success and encourages further adoption across the organization. This builds leadership-created trust by demonstrating clear purpose and positive results.

Principle Three: Pilot To Scale focuses on learning, architecting, and then expanding AI solutions. After a successful pilot, leaders must find the ground truth by thoroughly diagnosing any failures or unexpected outcomes. This involves understanding the interplay between data (information access), tools (tool calling), and business systems (how work flows). Technical details inevitably become people details, as changes impact how employees perform their daily tasks. To scale successfully, the architecture must support a broader vision. Leaders need to communicate the scale-up by highlighting customer impact and business benefits from the pilot, explaining why AI matters to the business as a whole, and articulating a long-term vision for how humans and AI agents will collaborate without deep-diving into overwhelming technical specifics. The core principle is to design systems so both humans and AI agents can succeed together, focusing on human judgment (vision and taste) for strategic oversight and AI agents for execution (scale and speed). This approach recognizes that AI is blurring boundaries between jobs, creating ambiguity. By protecting the 'human edge'—the professional work requiring human judgment—and framing AI as a tool for accelerated iteration and enhanced analysis, leaders can demonstrate that AI is not a threat but a pathway to more valuable, higher-level work. Nate concludes that leading AI adoption is a leadership transformation, not just a technology shift, and requires honesty, clear vision, and a commitment to integrating humans and AI effectively.

Matt Dailey's talk at the AI Engineer World's Fair focused on a critical challenge in modern software development: the phenomenon he calls 'Velocity Sickness.' This occurs when individual engineers, empowered by AI tools, achieve a 10x increase in their output, but the collective team's velocity doesn't scale proportionally. This leads to increased stress and output without corresponding impact.

Dailey identifies four key problems contributing to Velocity Sickness: 1. Too many PRs to merge: Individual engineers push an overwhelming number of pull requests, leading to merge conflicts and bottlenecks in the integration pipeline. 2. Moving in too many directions: Both individuals and teams lack cohesive focus, with agents working on disparate tasks, leading to fragmented efforts and an inability to collectively achieve strategic goals. 3. Declaring agent bankruptcy: Engineers frequently discard AI agent work and restart, feeling like they're doing a lot but repeating the same work, wasting both human effort and token resources. 4. Critical decisions made by agents: Engineers cede control over critical architectural and design decisions to AI agents, effectively losing ownership of their code and product.

To combat Velocity Sickness, Dailey advocates a shift in the software engineering process. Traditionally, the process involved Plan, Implement, Polish, with tools like IDEs and CLIs primarily supporting individual implementation and polishing. With AI, Dailey suggests that implementation often becomes largely automated by agents. The critical human roles now reside in planning and polishing.

Dailey emphasizes that the planning phase should be exploratory, creative, and collaborative. This is where engineers express their craft and strategically decide the future direction of the system. The challenge is that current tools, particularly chat interfaces, are often insufficient for this new planning paradigm. Chat-based interactions with agents tend to be isolated and ephemeral, leading to 'brain off' decisions that aren't shared, durable, or clearly documented. This exacerbates the problems of moving in too many directions and declaring agent bankruptcy.

Dailey proposes a solution centered around a concept he calls 'Docs, Not Chat.' This doesn't mean abandoning AI agents or communication, but rather leveraging documentation as the central artifact for decision-making and collaboration. The key principles are: Brain on, shared, durable, key decisions are clear: Documents should capture the collective intelligence, ensure decisions are shared across the team, and provide a lasting record of architectural and design choices. This contrasts with chat, which is often 'brain off,' isolated, and ephemeral. Separate action from state: Engineers should aim to build stateless agents that operate on well-documented plans. This allows for parallel agents and a durable decision log, preventing the need to 'declare agent bankruptcy' and facilitating easier collaboration. When an agent's output is based on a clear, shared plan, other agents (or humans) can pick up the context and continue the work without restarting.

This new approach leads to several benefits: Easier code reviews: By reviewing plans early, the most critical architectural decisions are aligned upon before extensive code is written, making subsequent code reviews simpler and more focused. Better alignment: Early alignment on plans ensures the team is moving in a cohesive direction, reducing wasted effort and preventing engineers from pursuing conflicting or unaligned paths. Elimination of agent bankruptcy: Since agents are stateless and operate on durable plans, restarting an agent or bringing a new one into the workflow doesn't mean losing critical context or work. The 'human context' can be rebuilt by simply reading the docs. Humans own decisions: The core of this paradigm shift is ensuring that humans, as engineers and product builders, retain ownership of critical decisions, leveraging AI for implementation and exploration, but not for defining the strategic direction. * More collaboration: By centralizing plans and decisions in a durable, shared format, it becomes easier for teams to collaborate, fostering a multiplayer engineering environment.

Ultimately, Dailey argues for a shift from code velocity to idea velocity. Instead of measuring productivity by the sheer volume of code generated, the focus should be on the speed and effectiveness with which novel, impactful ideas are explored, validated, and translated into meaningful products. He encourages engineers to: 1. Think plan then polish: Deliberately separate the planning and polishing phases, recognizing the distinct cognitive gears required for each. 2. Treat plans as portals: View plans as interactive gateways into the software system, allowing for flexible exploration and decision-making. 3. Share a plan: Embrace sharing plans with teammates for early feedback and collective alignment, rather than working in isolated chat environments.

Dailey concludes by highlighting that his company, ref.tools, is building tools specifically designed to facilitate this decision layer in AI-driven development workflows, integrating with existing implementation tools to bridge the gap between human creativity and AI execution.

The video delves into the transformation of the Model Context Protocol (MCP), an industry standard for connecting AI agents to applications. The speaker begins by referencing a '2025 throwback' to highlight the problems with the original MCP specification. He describes it as bloated, massively overrated, and resource-intensive due to its stateful nature. This meant that every MCP server required a dedicated connection to the client's wallet, even if the client rarely used it, leading to significant wasted resources and a preference for local hosting in many cases.

He then introduces the new MCP spec, officially named `MCP 2026-07-28` (though he humorously suggests a simpler name like 'MCP 2.0' would be better for branding). The core improvement in this new version is its stateless core. Previously, MCP operated on a bidirectional stateful protocol, where a client's requests were sticky-routed to a specific server instance. This necessitated a shared session store and an intelligent load balancer to maintain persistent connections, as illustrated in the 'Before' diagram.

With the `2026-07-28` specification, MCP transitions to a request/response stateless protocol. This means servers can now be deployed on serverless and edge infrastructure, simplifying the experience of building and scaling MCP servers. The 'After' diagram shows a client interacting with a load balancer that uses a simple round-robin strategy to route requests to any available MCP server, eliminating the need for sticky routes and shared session stores. This change makes MCP significantly more reliable and scalable.

Other notable improvements in the new spec include Standardized extensions through MCP Apps and Tasks, offering a formal framework for adding capabilities like interactive UIs and long-running tasks without altering the core protocol. Auth hardening now aligns with production OAuth 2.0 and OIDC deployments, allowing MCP servers to connect to enterprise identity systems without workarounds. Critically, the new spec eliminates the handshake and sessions that previously required two HTTP requests (one to initialize a session and obtain a `Mcp-Session-Id`, and another to call the tool). Now, a single HTTP request carries all necessary information, including protocol version, client identity, and client capabilities in `_meta`.

The speaker demonstrates the practical impact of these changes. In the old MCP, every time a new thread or sub-agent was spun up in a tool like Codex, it would establish multiple stateful MCP connections, leading to significant overhead and CPU usage (especially on macOS with `syspolicyd` monitoring). With the stateless core, these issues are resolved. Now, each agent simply makes a random endpoint hit and receives JSON data, making interactions far more efficient.

The speaker highlights the developer-friendly nature of the new spec, as demonstrated by Simon Willison's new `mcp-explorer` and `datasette-mcp` CLI tools. These stateless Python CLI tools allow interactive probing of MCP servers and querying databases without complex setup. This ease of implementation and use for simpler tools is a massive step forward. The speaker enthusiastically states that MCP is now 'good' because it actually understands developers' needs, offering a simpler, more elegant, and properly scalable solution.

However, he raises a critical concern about adoption due to backward incompatibility. While the new spec is a vast improvement, existing implementations on the client and server sides that expect stateful connections will not work with the new stateless protocol. This could lead to a fragmented ecosystem, where different tools and platforms support different versions of MCP. He likens this to the complexity of USB-C, where simply having a USB-C port doesn't guarantee compatibility with all USB-C devices. He argues that given the power and iterative capabilities of large language models (LLMs) in writing and updating code, companies building agentic tools should prioritize updating their MCP bindings to the new standard to remain relevant and competitive.