Home
Apr 1, 2026
View All

Vibe Coding Best Practices, M365 Copilot Council, and OpenAI's $122B Raise

·1 underrepresented voice

The Short Version#

Teresa Torres just published a practical framework for avoiding the "doom loop" in vibe coding — the pattern where you skip planning, get stuck, and start over. Meanwhile, Microsoft shipped a genuinely interesting M365 Copilot feature (Council, which runs multiple models on the same prompt simultaneously), and OpenAI's $122B raise signals the infrastructure buildout is nowhere near done.

Teresa Torres — Vibe Coding Best Practices: Avoid the Doom Loop#

Source: https://www.producttalk.org/vibe-coding-best-practices/ Credibility: High (first-party post from a recognized PM craft expert with 6 months of personal vibe coding practice)

What happened: Teresa Torres — the continuous discovery author and PM coach — published a detailed post on vibe coding best practices, focused specifically on the failure pattern she calls "the doom loop": you dive into building without planning, hit a wall, the AI starts generating broken patches on top of broken patches, and eventually you scrap everything and start over. She's been vibe coding since March 2025 and says she's written more software in the past six months than her entire lifetime prior — which makes this worth paying attention to. This isn't a "here's what I heard about vibe coding" post. It's from someone who's been doing it consistently.

Key patterns:

  • Plan before you prompt: The doom loop starts when you hand the AI a vague goal and expect it to figure out the architecture. Torres's fix is writing a spec first — not a 30-page PRD, but a clear statement of what you're building, what success looks like, and what constraints exist
  • Code reviews as a forcing function: She recommends reviewing AI-generated code before accepting it, not to catch bugs (you may not know how), but to maintain a mental model of what the codebase is doing — which is what lets you course-correct when things go sideways
  • The doom loop trigger: It typically starts with scope creep inside a session. You add one more thing, the model loses context, and instead of stopping you keep prompting. The fix is ending sessions earlier and starting fresh with a clean prompt
  • Iteration discipline: Treat each prompt like a small testable hypothesis — ship it, verify it works, then move to the next thing — rather than asking the AI to build the whole feature in one shot

Why it matters for PMs: PMs are the most likely non-engineers to be vibe coding right now — building prototypes, internal tools, research instruments. Torres's framing is directly applicable: the doom loop is exactly the pattern you fall into when you're excited about the demo you just saw and want to build something immediately. Her framework — plan first, review as you go, keep sessions short and scoped — is the PM discipline equivalent of writing a brief before jumping into design. It also has an important implication for how we evaluate AI-assisted development on teams: the bottleneck isn't prompting ability, it's planning discipline. That's a skill PMs already have, and it transfers.

Critical questions:

  • How does this planning-first approach interact with the speed advantage vibe coding is supposed to provide? Is the overhead worth it for quick prototypes?
  • At what project complexity does the doom loop become unavoidable regardless of planning quality?
  • How do you do a meaningful code review if you don't know the language? Torres gestures at this but the mechanics aren't fully spelled out
  • Does this pattern generalize beyond individual developers to teams vibe coding together, where the spec-writing step has to be collaborative?

Action you could take today: Before your next vibe coding session, write a one-paragraph spec that includes: what you're building, what "done" looks like for this session, and one thing you explicitly won't build today. Keep it visible while you're prompting and use it to cut off scope creep mid-session.

Microsoft M365 Copilot — Council Feature Ships to Frontier#

Source: https://www.linkedin.com/posts/satyanadella_new-in-m365-copilot-council-you-can-run-activity-7444441543010258945-6cQP Credibility: High (Satya Nadella post announcing a shipped feature in M365 Copilot Frontier tier)

What happened: Microsoft shipped Council to M365 Copilot's Frontier tier — a feature that lets you run the same prompt through multiple AI models simultaneously, then see where they agree, where they diverge, and what each one adds uniquely. This is distinct from just picking a model; it's running parallel inference and surfacing the differences as part of the output. Nadella specifically called it out as something he's been "super excited to see go live," which in Satya-speak usually means it survived significant internal debate to get to this point.

Key capabilities:

  • Run a single prompt through multiple models at the same time
  • See model outputs side-by-side, with alignment and divergence highlighted
  • Understand what each model contributes uniquely — not just which is "better"
  • Currently available in Frontier (Microsoft's early access tier for enterprise)

Why it matters for PMs: This is a product decision with clear philosophical underpinnings: instead of picking the best model and hiding the others, Microsoft is making model disagreement visible to users. That's a different bet than what OpenAI or Anthropic are making — they're trying to build one model you trust completely; Microsoft is building a workflow where you consult multiple models like a council of advisors. For PMs thinking about how to build trust in AI features: showing disagreement may actually build more trust than showing a single confident answer. It also has direct implications for high-stakes decisions (legal review, financial analysis, product strategy) where seeing where models diverge is the most useful signal. The flip side: this may also train users to distrust any single model output, which complicates simpler use cases.

Critical questions:

  • Which models are in the council — is it Microsoft-curated, or can enterprise customers configure their own set?
  • How does Council handle cases where all models agree but are all wrong? The "alignment" signal can create false confidence
  • Is there evidence that seeing model divergence leads to better decisions, or does it just increase cognitive load?
  • What does the pricing look like — does running three models simultaneously cost 3x?

Action you could take today: If your team is evaluating AI for any high-stakes workflow (financial modeling, legal review, customer-facing responses), test the hypothesis manually: run the same prompt through Claude, GPT-5, and Gemini side-by-side and look at where they diverge. That's essentially what Council does — and doing it by hand once will tell you whether the divergence is signal or noise for your specific use case.

OpenAI — $122B Raise to Expand Frontier AI#

Source: https://openai.com/index/accelerating-the-next-phase-ai Credibility: High (first-party announcement)

What happened: OpenAI announced a $122 billion funding round aimed at expanding frontier AI globally, investing in next-generation compute, and meeting growing demand for ChatGPT, Codex, and enterprise AI products. This is a capital raise at a scale that's hard to fully absorb — $122B is roughly the annual R&D budget of the entire US pharmaceutical industry. The framing in the announcement is explicitly about infrastructure capacity and global expansion, not new product capabilities.

Key signals:

  • Explicit callout of Codex demand as a driver — not just ChatGPT or API
  • "Next-generation compute" language suggests continued investment in custom silicon or large-scale data center buildout
  • "Enterprise AI" is named alongside consumer — this is a dual-track business
  • The framing is infrastructure-first, not model capability-first

Why it matters for PMs: The infrastructure bet has direct product implications. When OpenAI raises $122B and names Codex demand as a driver, it's a signal that the coding agent market is large enough to justify frontier-level investment. For PMs building on top of OpenAI APIs, this is a mixed signal: more capital means more capacity and lower prices over time, but it also means OpenAI is building increasingly in direct competition with application-layer products. The "global expansion" framing also matters — if OpenAI is expanding data residency and regional availability, that opens enterprise deals that regulatory constraints previously blocked. That's a buy-vs-build consideration: waiting for OpenAI to solve your enterprise compliance problem may be cheaper than solving it yourself.

Critical questions:

  • How much of this capital goes to compute vs. research vs. sales/distribution? The framing suggests infrastructure, but the real allocation matters
  • Does this accelerate or slow OpenAI's move into application-layer products that compete with their customers?
  • At $122B, what does the path to profitability look like, and does that affect API pricing strategy?
  • How does this affect Anthropic's positioning — does it force them to raise similarly or double down on differentiation?

Action you could take today: If you're building on OpenAI APIs and haven't reviewed your vendor dependency risk recently, now is a good time. Map which features would break if OpenAI entered your market directly, and identify which of those have viable alternatives on Anthropic, Mistral, or open-weights models.

Quick Hits#

The Thread#

Planning discipline is the actual bottleneck in AI-assisted work. Teresa Torres's vibe coding doom loop, GitHub's agent-driven development post, and Stripe's 1,300-PR-per-week number are all pointing at the same thing: the teams and individuals who get value from AI coding tools aren't the ones with the best prompting skills — they're the ones with the strongest planning and review practices. The AI handles execution; the human still owns the spec and the sanity check. That's a skill PMs are well-positioned to bring to their teams, and it may be the most durable advantage non-engineers have in the vibe coding era.

Sit With This#

Teresa Torres describes the vibe coding doom loop as starting with a missing or vague spec — you skip the planning step because the demo made it look so easy, and an hour later you're patching patches.

For your team: Where are you currently shipping AI-assisted work — prototypes, internal tools, prompts, agent workflows — without a written spec or review step? Pick one. What would a "spec before you prompt" habit look like for that specific workflow, and what would the review step catch that you're currently missing?