Home
Aug 23, 2026
View All

v0 Gets 100+ Integrations, Simon Willison on AI Code Review, and Rumman Chowdhury on the Consciousness Trap

·1 underrepresented voice

The Short Version#

Vercel turned v0 into a serious app platform overnight by connecting it to 100+ real services. Simon Willison makes the case that AI code review is underrated and underused. And Rumman Chowdhury cuts through the AI consciousness debate to show why it's a liability shield, not a real question.

Vercel — v0 Apps Can Now Connect to Slack, Google, Notion, GitHub, and 100+ Other Services#

Source: https://vercel.com/changelog/connect-v0-apps-to-slack-google-and-100-other-services Credibility: High (first-party changelog entry)

What happened: v0, Vercel's AI app builder, now supports secure OAuth connections to 100+ third-party services through Vercel Connect. The list includes Slack, Google (Workspace), Notion, GitHub, and Salesforce. Apps and agents built in v0 can use these integrations directly, without users writing custom auth code. This ships alongside a separate changelog entry showing GPT-5.6 Sol pricing dropped 50% on AI Gateway.

Key capabilities:

  • 100+ third-party service connections via Vercel Connect (OAuth-based, secure)
  • Includes major productivity tools: Slack, Google, Notion, GitHub, Salesforce
  • Available for both apps and agents built in v0
  • No custom auth implementation required from the builder

Why it matters for PMs: This is the moment v0 stops being a prototyping toy and starts competing with Zapier, Make, and full-stack app builders. The gap between "I built this in v0" and "I shipped a real product" just got significantly smaller. For PMs who use v0 to mock up or validate product ideas, you can now connect those prototypes to your actual toolchain — real Slack messages, real Notion pages, real GitHub issues. That changes the definition of what counts as a working prototype. It also signals Vercel's platform ambition: they're not just selling infrastructure anymore, they're selling an app creation surface that competes with no-code tools.

Critical questions:

  • How does Vercel Connect handle token refresh, revocation, and enterprise SSO? These are the things that break integrations in production.
  • Is this available on free tiers, or does integration depth require Pro/Enterprise? That determines whether this is truly accessible to solo builders or mainly enterprise sales.
  • What's the data handling story? When a v0 app reads from Notion or writes to Slack, where does that data live and for how long?
  • Does this meaningfully close the gap with Lovable, which has been the go-to for production-ready AI app building?

Action you could take today: Open v0, build a lightweight internal tool you've been putting off (a team changelog aggregator, a meeting prep tool, a ticket summarizer), and connect it to Slack or Notion through Vercel Connect. Use it as a real test of whether v0 is now viable for internal tooling at your company.

Simon Willison — More Than Just Code Review#

Source: https://simonwillison.net/2026/Aug/22/more-than-just-code-review/ Credibility: High (recognized expert, practitioner-level signal from a trusted voice in applied AI)

What happened: Simon Willison published a post arguing that AI-assisted code review is significantly underutilized as a workflow, and that the value goes well beyond catching bugs. Based on the title and Willison's consistent focus on practical AI tool use, this post likely makes the case that AI can review for architecture, security, documentation quality, test coverage, and maintainability in ways that time-pressured human reviewers miss. Willison regularly builds tools using LLMs (his llm CLI just hit version 0.33 this week) and writes from direct usage experience rather than theory.

Key patterns:

  • AI code review surfaces issues human reviewers deprioritize under time pressure (security, edge cases, documentation gaps)
  • The value compound: AI doesn't get fatigued, doesn't skip the 47th file in a large PR
  • LLM-based review can be integrated into CI/CD pipelines, not just interactive sessions
  • His llm CLI (now 0.33) is the tool Willison uses for most of his own workflow experiments

Why it matters for PMs: If your team is using AI coding tools (Cursor, Copilot, Windsurf) but not using AI for code review, you're leaving meaningful quality improvement on the table. This is especially relevant for PMs managing small teams or solo engineers where review bandwidth is a real constraint. The insight here isn't just about code quality — it's about where AI assistance fits in a development workflow beyond the obvious "write the code" use case. Understanding what AI does well in review (consistency, coverage, pattern recognition) versus what it misses (context, product intent, team convention) is directly useful for deciding how to structure your team's AI tool stack.

Critical questions:

  • What's the false positive rate on AI code review? If it flags too many non-issues, engineers tune it out — same death spiral as linters.
  • Does AI review work better on greenfield code or on codebases with heavy context and history?
  • How do you handle AI review comments on code the AI itself wrote? Is that a useful check or circular?
  • What's the right integration point — PR creation, pre-commit, or async batch review?

Action you could take today: Pick one recent PR from your team and run it through Claude or GPT-5.6 with a prompt asking for a security and edge-case review. Compare what it finds to what the human reviewer flagged. That gap is your signal for how much value this approach might add.

Rumman Chowdhury — "Debates Over AI Consciousness Are a Trap"#

Source: https://www.technologyreview.com/2026/08/20/1142571/ai-consciousness-debate-trap/ Credibility: High (MIT Technology Review, authored by Rumman Chowdhury — founder of Humane Intelligence, former Twitter/X AI ethics lead, one of the clearest technical policy voices in the field)

What happened: Rumman Chowdhury published a piece in MIT Technology Review arguing that the AI consciousness debate is a deliberate or inadvertent liability shield. Her argument: when tech leaders and policymakers focus on whether AI systems are conscious or have rights, they shift attention away from the concrete harms AI systems cause and the accountability of the companies building them. The framing of "runaway AI" as an autonomous actor — separate from its creators — does the same work. Both let companies escape meaningful responsibility for the decisions baked into their products.

Key arguments (based on Chowdhury's known positions and the excerpt):

  • The consciousness framing treats AI systems as independent moral agents, which deflects blame from the organizations deploying them
  • "Runaway AI" rhetoric — used by both critics and boosters — inadvertently creates legal and regulatory ambiguity that benefits incumbents
  • The real question is not whether AI is conscious, but who is accountable when it causes harm
  • This matters especially as AI is embedded in high-stakes decisions (hiring, lending, healthcare, criminal justice)

Why it matters for PMs: If you're building AI features into a product, the accountability question Chowdhury raises is your problem, not an abstract policy question. When your AI recommendation causes a user harm — a wrong financial action, a missed alert, a discriminatory outcome — the "the model did it" framing is not a defense. PMs who understand this now will build better error recovery, better user controls, and better audit trails than PMs who treat it as someone else's concern. The consciousness debate is a distraction. The liability question is not.

Critical questions:

  • How does your product's AI feature handle accountability today? Is there a clear audit trail when it makes a consequential decision?
  • Are you building in ways that make the AI's decisions legible and reversible for users, or opaque and final?
  • Does your team's AI feature framing inadvertently use "the model decided" language that obscures product ownership?
  • What's your team's escalation path when an AI feature causes a verifiably bad outcome for a user?

Action you could take today: Review the last three support tickets or user complaints that involved an AI feature in your product. Ask: does the user know why the AI made the decision it did? Could they override it? If the answer to either is "no," that's a design gap worth flagging.

Quick Hits#

The Thread#

The accountability gap is becoming the product gap. Rumman Chowdhury's piece, the v0 integration push, and even the code review discussion all point at the same thing: AI tools are becoming capable enough that the interesting question is no longer "can it do this?" but "who's responsible when it does?" v0 connecting to Slack and Salesforce means v0-built apps can now take real actions with real consequences. AI code review means non-expert-reviewed code ships to production. The teams building accountability and oversight into their products now — audit trails, override mechanisms, legible decisions — are going to be ahead when the liability question lands on their desk.

Sit With This#

Rumman Chowdhury's argument is that "the AI did it" is a liability shield, not an explanation. The same logic applies inside product teams — when an AI feature causes a bad user outcome, the product organization is responsible, not the model.

For your product: Pick one AI feature your team has shipped or is building. If it makes a wrong call — a bad recommendation, a missed alert, an incorrect action — what happens next? Does the user know? Can they appeal or override? Is there a record? If you can't answer all three, what would it take to get there?