Autonomous Coding Agents Go Mobile, and Bad AI Software Gets Called Out
The Short Version#
Two things worth sitting with today: Alessio Fanelli's setup for running parallel coding agents from a phone is a real workflow, not a demo stunt, and Ben Tossell's critique of Perplexity's assistant lands as a sharp reminder that AI agent promises are outrunning AI agent reliability.
Lenny's Podcast / Alessio Fanelli (Kernel Labs) - Running Parallel Coding Agents From Your Phone#
Source: https://www.lennysnewsletter.com/p/how-i-run-autonomous-coding-agents Credibility: High (first-party video walkthrough via Lenny's Podcast Network, specific workflow demonstrated)
What happened: Alessio Fanelli published a video walkthrough on Lenny's newsletter showing his setup for running parallel coding agents asynchronously from his phone using OpenAI Symphony and Linear. The demo includes Codex hunting for underpriced Pokémon cards in real time. This isn't a hypothetical workflow — it's a specific tool stack with a specific use case, and Fanelli runs it from his phone.
Key workflow patterns:
- OpenAI Symphony as the orchestration layer for parallel agent runs
- Linear as the task/issue tracker that feeds work to agents
- Mobile-first management: launching, monitoring, and reviewing agent output from phone
- Codex used for an actual business task (pricing arbitrage in a collectibles market), not just code generation
- Parallel agents as the key unlock — not one agent, but several running simultaneously on different tasks
Why it matters for PMs: The "AI coding agent" story has mostly been about individual developers at their desk. This is the first concrete setup I've seen where the management layer is genuinely async and mobile. That's a meaningful shift. If agents are the workers, the PM-equivalent role becomes orchestration: what tasks go to which agent, how do you review output, how do you catch failures. The Linear integration is the part to pay attention to — it means agents are pulling from the same backlog humans use, which is how you'd actually integrate this into a team workflow rather than running it as a side experiment.
Critical questions:
- What's the failure mode when multiple agents are running in parallel and one goes off-script? Is there a clear recovery path, or does async monitoring create blind spots?
- How does this workflow handle tasks that require judgment calls mid-execution? Does Symphony support human-in-the-loop interrupts?
- Linear as the interface is interesting but assumes your entire task management is there. What's the pattern for teams using Jira, Notion, or other trackers?
- Is the Pokémon card demo representative of the kinds of tasks this actually works well for (structured data, clear criteria), or is it cherry-picked?
Action you could take today: If your team uses Linear, look at whether your current ticket format is agent-readable. Vague acceptance criteria that a human interprets fine will confuse an agent. Auditing five recent tickets for specificity is a 30-minute exercise that would tell you a lot about your agentic readiness.
Ben Tossell - "Bad AI Software" Critique Using Perplexity as a Case Study#
Source: https://x.com/bentossell/status/1915392814390694184 Credibility: Medium (Twitter/X post from a tracked practitioner with a strong record of direct product critique — limited to excerpt/summary available)
What happened: Ben Tossell posted a thread critiquing poor AI software quality, using Perplexity's assistant as the primary example. The specific failures: promised features around booking reservations and setting reminders that simply don't work as advertised. The framing is "bad AI software" — not "early AI software" or "AI software with limitations," but software that is making promises it can't keep.
Key patterns in the critique:
- Capability claims in marketing or onboarding that don't survive first use
- Agentic features (booking, reminders) are particularly exposed — they require real-world execution, not just text generation
- Perplexity specifically is called out as a case study, not a straw man
- The critique is about the gap between what users are told the product does and what it actually does
Why it matters for PMs: This is the question that product leaders building AI agents need to answer before launch: is this feature working reliably enough to ship as a first-class capability, or are we setting up users for disappointment? The "bad AI software" framing is worth internalizing because it's how users will describe your product if the gap between promise and delivery is too wide. Booking reservations and setting reminders sound like table-stakes agent tasks — if Perplexity's assistant can't do these reliably, that's a product positioning problem, not just a technical one. The onboarding and marketing surface is where the expectation gets set, and that's a PM decision.
Critical questions:
- How do you draw the line between "early access, rough edges" positioning and "this feature doesn't work" when shipping agentic capabilities?
- Is there an internal quality bar Perplexity set for these features, or did they ship on capability availability rather than capability reliability?
- What's the right user experience when an agentic feature fails? Silent failure (nothing happens) is probably worse than explicit failure with a clear message.
- Does Tossell's critique generalize? Are there AI assistants shipping agent actions (booking, reminders, emails) that actually work reliably?
Action you could take today: Run your own product's onboarding flow and identify every place where you make a capability claim — explicit or implied. For each agentic or semi-agentic claim, test it three times with realistic inputs. If it fails once, you probably have a positioning problem.
Simon Willison - sqlite-utils 4.0 Release Candidate, Mostly Written by Claude Fable#
Source: https://simonwillison.net/2026/Jul/5/sqlite-utils-fable/#atom-everything (covered previously) / https://simonwillison.net/2026/Jul/6/sqlite-utils/#atom-everything Credibility: High (first-person engineering log from a highly credible practitioner)
What happened: Simon Willison is releasing sqlite-utils 4.0, and the rc2 release was, by his own accounting, "mostly written by Claude Fable for about $149.25." rc3 followed on July 6. This is a real open-source Python library used by thousands of developers — not a toy project or demo. The cost figure is the detail worth sitting with: $149.25 for a release candidate of a production tool.
Key patterns:
- Cost-per-feature is becoming a real unit of measurement for AI-assisted development
- The $149.25 figure is specific — Willison is tracking spend the way you'd track any engineering resource
- Claude Fable (Anthropic's model) did the bulk of the implementation work for rc2
- This follows Willison's ongoing pattern of publishing detailed AI-assisted development logs — the sqlite-utils project is effectively a live case study in how a solo developer uses AI to maintain and ship open-source tooling
- rc3 shipped the next day, suggesting iteration speed is high
Why it matters for PMs: Two things here. First, the cost transparency is rare and useful. Most "I built this with AI" posts don't include the bill. $149.25 to ship a release candidate of a real library is a data point, not just a vibe. Second, Willison's approach — human directing, AI implementing, human reviewing — is a model for how PMs might think about AI-assisted product work beyond just code. The question isn't "can AI do this?" but "what does it cost, and is the output quality high enough to ship?"
Critical questions:
- What's the review burden that $149.25 doesn't capture? Willison presumably spent significant time reviewing, testing, and iterating on the AI's output.
- Does the cost scale linearly with complexity, or does it spike for harder problems?
- What's the right analogy for a PM team: is AI-assisted development more like hiring a contractor, or more like using a really good IDE?
Action you could take today: If you're running a vibe coding or AI-assisted development experiment on your team, add cost tracking from day one. Even rough token cost estimates per feature give you a unit of comparison that gut feel doesn't.
Quick Hits#
-
Teresa Torres: Continuous Discovery Habits turns five — Torres is running a month-by-month book club with in-depth reading guides. Good timing to re-examine the discovery habits your team has actually built versus what you think you're doing. (2026-07-06): https://www.producttalk.org/cdh-book-club-july-2026/
-
Ammaar Reshi: Built a game port with AI collaboration — first build took 40 minutes, followed by bug fixing sessions. Another concrete vibe-coding timeline data point from a practitioner. (2026-07-05): https://x.com/ammaar/status/2073636280781488143
-
Aravind Srinivas / Perplexity: Partnership with Intel to bring local models and hybrid inference to Intel Ultra Series 3 laptops. On-device AI inference as a distribution play — worth watching if you're thinking about privacy-sensitive AI features. (2026-07-06): https://x.com/AravSrinivas
-
AWS: Multi-step pipeline for automatically redacting PII in images using Amazon Nova + SAM 3 + Textract. Practical infrastructure pattern for anyone building AI features on documents with sensitive data. (2026-07-06): https://aws.amazon.com/blogs/machine-learning/automatically-redact-pii-in-images-with-amazon-nova/
-
Julie Zhuo: Posted about restoring vintage websites using AI — a small signal about how product leaders are using AI for personal technical projects, and what that experience reveals. (2026-07-06): https://joulee.medium.com/some-people-like-restoring-vintage-cars-i-like-restoring-vintage-websites-a293d02fd961
The Thread#
The gap between agent capability and agent reliability is becoming the central product problem. This week gave us three data points in quick succession: Notion's post-beta learnings on custom agents, Fanelli's phone-based parallel agent workflow showing what actually works, and Tossell's critique of Perplexity for shipping agent features that don't. The products figuring this out are the ones being explicit about the scope — what the agent can reliably do, not what it could theoretically do. The ones struggling are shipping capability claims first and reliability second.
Sit With This#
Ben Tossell called out Perplexity specifically for shipping booking and reminder features that don't work as advertised. That's a positioning decision that went wrong — the capability was available enough to ship, but not reliable enough to deliver on the promise.
For your product: Is there an AI feature you're currently shipping (or planning to ship) where the onboarding or marketing implies a capability that only works some of the time? What's your threshold for reliability before you make a capability claim — and who owns that decision?