Spec-Driven Dev, DeployCo, and Cursor's Bugbot Levels

Lenny's Newsletter — Spec-Driven Development: The AI Engineering Workflow at Notion#

Source: https://www.lennysnewsletter.com/p/spec-driven-development-the-ai-engineering Credibility: High (first-party interview, Ryan Nystrom is Notion's VP of Engineering, published on Lenny's Podcast)

What happened: Ryan Nystrom walked through the specific AI-assisted engineering workflow Notion's team has developed, which they call "spec-driven development." The approach centers on writing detailed specs before any code is written, then letting AI agents do the actual implementation. The result: automated standups, PRs shipped from a single comment, and engineers spending their time on thinking rather than typing.

Key patterns:

• Spec-first, code-later: Engineers write thorough specs describing what should be built and why. Agents use the spec as ground truth. This shifts the value-add from "writing the code" to "writing the right spec."
• PRs from a single comment: Once a spec exists, an engineer can comment on an issue and an agent will generate and submit a PR. Human review happens on the output, not during creation.
• Automated standups: Status updates are derived from agent activity and commit history — not from engineers filling out forms.
• Agents do the coding, humans do the thinking: The explicit division of labor Nystrom describes is less "AI helps me code" and more "AI codes while I architect."

Why it matters for PMs: This is the most concrete description I've seen of what AI-native engineering actually looks like inside a real product team at scale. It's not about Copilot autocomplete — it's a workflow redesign. For PMs, this changes two things: (1) what you need to write and communicate before work begins (specs become more important, not less), and (2) how you should think about team velocity estimates when the bottleneck shifts from implementation to spec quality. If your eng team is moving this direction, the PM who writes better specs ships faster.

Critical questions:

• How do you maintain spec quality at high velocity? If specs are the new bottleneck, what's the failure mode when a spec is wrong or underspecified?
• What happens to knowledge transfer and onboarding when humans aren't writing the code? Does institutional knowledge get encoded in specs, or does it get lost?
• Does this workflow hold for greenfield features, or mainly for well-defined incremental work?
• Where does user research fit in? Writing a great spec still requires understanding what to build — does this workflow assume that problem is already solved?

Action you could take today: Look at the last three PRs your team shipped. If you had to write a spec detailed enough for an AI agent to implement each one correctly, what would be missing from your current discovery/requirements process? That gap is your homework.

OpenAI — DeployCo: A Dedicated Enterprise Deployment Company#

Source: https://openai.com/index/openai-launches-the-deployment-company Credibility: High (first-party announcement from OpenAI)

What happened: OpenAI launched DeployCo, a new standalone company whose job is to help enterprises bring frontier AI into production and generate measurable business impact. This is separate from OpenAI's core API and ChatGPT products — it's explicitly a professional services and deployment arm aimed at large organizations that have purchased AI access but haven't figured out how to scale it.

Key details:

• Positioned as an enterprise services layer, not a new product
• Mission is explicitly about turning AI access into "measurable business impact" — closing the gap between "we have a contract with OpenAI" and "AI is changing how we operate"
• Separate brand and company structure from OpenAI proper
• Targets organizations that have the budget and the intent but are stuck on execution

Why it matters for PMs: OpenAI is acknowledging something the market already knows: getting enterprises to buy AI is the easy part. Getting them to actually deploy it in ways that compound over time is the hard part. DeployCo is a direct admission that the current product experience — APIs, ChatGPT Enterprise, fine-tuning docs — isn't enough for many large customers. For PMs in enterprise software or AI tools, this is a signal worth watching: the deployment gap is real, validated by OpenAI's willingness to build a whole company around it. It also raises questions about whether this creates new competition for SI partners and consulting firms in the AI implementation space.

Critical questions:

• Is DeployCo a product failure signal? Does building a professional services arm mean the self-serve enterprise product isn't converting well?
• How does DeployCo's existence affect the build-vs-buy decision for enterprise customers who might otherwise hire an implementation team?
• Will DeployCo create feedback loops that improve OpenAI's core products, or is it a release valve that lets product debt persist?
• What's the exit strategy — does successful deployment through DeployCo eventually commoditize into a self-serve product feature?

Action you could take today: If you work on an enterprise product, audit your deployment metrics: what percentage of customers who purchase activate, and what percentage who activate hit their first meaningful outcome within 90 days? That activation-to-value gap is what DeployCo is being built to close — and it's worth knowing yours before a competitor names it.

Cursor — Bugbot Effort Levels#

Source: https://cursor.com/changelog/05-11-26 Credibility: High (first-party changelog)

What happened: Cursor shipped a new configuration option for Bugbot — its AI-powered PR reviewer — that lets Teams admins and Individual plan users choose from three effort levels:

• Default: Current behavior. Optimized for efficiency and speed.
• High: More thorough review. Presumably catches more issues but takes longer.
• Highest: Maximum effort. Full analysis, slowest.

This is a shipped configuration change, not a new feature — Bugbot already existed. But the addition of effort levels is a meaningful product decision about how much user control belongs in an AI feature.

Key details:

• Scoped to Teams admins and Individual plan users (not all tiers)
• Three-tier configuration, not a continuous slider
• Framed as "effort level," which is honest about the cost/speed tradeoff without requiring users to understand the underlying mechanics

Why it matters for PMs: This is a small but instructive product decision. Cursor is giving users control over an AI behavior that has real tradeoffs — speed vs. thoroughness — instead of making that call for them. The "effort level" framing is smart: it's intuitive, it sets accurate expectations, and it avoids exposing implementation details (token counts, pass counts, etc.) that most users don't care about. It's also a quality signal: the fact that three distinct levels exist implies Cursor has validated that Default isn't always right for everyone. For AI feature PMs, the pattern here is "when the optimal setting varies by user context, expose the dial — but label it in user terms, not system terms."

Critical questions:

• Why is this feature gated to Teams admins and Individual plans? If Bugbot is useful, shouldn't all users benefit from optimizing it?
• How does Cursor communicate the latency difference between effort levels? If "Highest" adds 10 seconds, users might not bother. If it adds 2 minutes, they definitely won't.
• Is this a stepping stone toward automatic effort calibration (e.g., "use High effort on files touching payments logic")? That would be the natural next move.
• What does usage data tell them about which level people actually choose? If 95% stay on Default, the feature may be solving a perception problem more than a real one.

Action you could take today: If you have an AI feature that makes a quality/speed tradeoff invisibly, write down what the three "effort levels" would be if you exposed that tradeoff explicitly. If you can't articulate them cleanly, that's a sign you don't fully understand the tradeoff either.