Context

Claire Vo, host of How I AI and a working product leader (she builds ChatPRD), got early access to a new frontier model, GPT-6 Astra, and spends the episode screen-sharing what it actually let her build. This is not a benchmark recap. The whole episode is a live tour of one capability the model leads on, computer and browser use, plus a set of coding tasks she had failed to crack for six months with earlier models. It matters to PMs because the thing that changed is not "the model is smarter" in the abstract. It is that a model can now reliably operate real software, click buttons, drag nodes, use Figma, use Blender, and that quietly reverses a strategic assumption a lot of product teams have been building around.

The Big Idea

When AI can competently use a graphical interface the way a person does, the "no UI is the next UI" story flips: UIs and SaaS are not a legacy problem to route around with CLIs and MCPs, they become a surface both humans and agents can share.

Claire's repeated line is "UI is back, buttons are back, SaaS might be your savior," because an agent that can click a button means the product does not have to be re-expressed as a command line or a protocol to be automatable. The evidence is the demos: the model navigating a node-based CRM builder, a chaotic image-editing tool, and Figma with no human hands on the keyboard.

Key Insights

1. Computer use is the real unlock

The model's standout capability is not just browsing, it is operating arbitrary software: Excel, Unity, Power BI, Blender, Jupyter, document editors, node-based web apps. Claire says she now spends about 90% of her day watching the agent drive Chrome and other apps rather than typing herself. For a PM, the takeaway is that "can an agent use this" is becoming a real property of a product, not a thought experiment, and it changes which workflows are worth automating.

2. "UI is back" reverses a strategy bet

For a while the industry consensus was that agents would consume products through APIs, CLIs, and MCPs, so the UI was almost a liability. Claire argues competent computer use undoes that. Humans genuinely like buttons, and if an agent can also use those buttons, you do not have to rebuild your product as a protocol to make it agent-ready. The strategic implication: a UI-first product may be the right expression of the product after all, not a thing to apologize for.

3. Browser use is underrated for QA

The example that is easiest to copy: after shipping a fix for streaming and race-condition bugs in ChatPRD, she told the agent to test the branch in Chrome. It pulled up the preview branch, clicked through, sent chats, inspected the console for error logs, refreshed to trigger race conditions, and ran for one hour and 45 minutes, finding and fixing real issues a human would find tedious to reproduce. Her direct advice: if you are not using browser use for QA, start.

4. Vendors are selling time, not IQ

Claire reads the positioning clearly: with everyone spending heavily on tokens, model makers are under pressure to show ROI, so the pitch has shifted from raw intelligence to time saved on common tasks. The concrete framing she cites, apartment hunting going from six hours to 10 minutes, thumbnail generation from an hour to a couple of minutes, presentations, spreadsheets, and documents as headline use cases. For PMs pricing or positioning AI features, "hours removed" is becoming the unit customers are sold on.

5. Some tasks only break at a capability step

She had spent six months failing to build a "product intelligence" feature for ChatPRD that ingests data from Intercom, Granola, Linear, and GitHub, deduplicates insights, ranks priorities, and generates an auto-wiki of the product's state exposed over MCP. Earlier models understood the architecture but produced poor-quality insights. This model roughly one-shot it (90% in one prompt, finished in two or three more). The lesson is that some product ideas are not blocked by your spec or design, they are blocked by a model capability threshold, and they become viable suddenly, not gradually.

6. The human job moves to taste and verification

Across the demos, the pattern is the agent does the mechanical work and the human supplies judgment. Her designer Naomi's role on thumbnails becomes checking that the model did not give Claire extra fingers or an uncanny-valley face, not dragging nodes. Claire frames it plainly: the human job "like all humans" is to have good taste and catch where the model went wrong. That reframes team roles around review and quality control rather than production.

Mental Models & Frameworks

Buttons are back, protocols are optional

• What it is: a test for whether your product needs an agent-specific interface at all.
• How it works: if an agent can reliably operate your existing UI, you may not need to expose the product as a CLI or MCP just to make it automatable.
• When to use it: deciding where to invest agent-readiness effort. Before building a protocol layer, check whether computer use already covers the workflow through the UI you have.

Capability-gated backlog

Keep a short list of product ideas you know are valuable but that current models execute badly, and re-test them on each model release rather than rebuilding from scratch. Claire's product-intelligence feature, her hardware hack, and her 3D "Barbie bench" all sat failed for months, then cleared in one shot when the capability arrived. The model is: some bets are timing bets on capability, so hold them ready instead of abandoning them.

Agent as QA runner

Treat the agent as a tester that can do things humans find tedious: open a preview build, click through flows, watch the console for errors, and hammer timing-dependent bugs by refreshing repeatedly. Point it at a shipped branch and let it run long (the demo ran nearly two hours) to surface issues before real users do.

Trade-offs & Nuance

Impressive one-shots, imperfect output

Claire is honest that "one-shot" does not mean "done." The 3D Barbie game had rough clothing and shoes, the product-intelligence feature needed UI polish after the logic worked, and the thumbnails would still get a human pass. The nuance for PMs: a model clearing a task that used to be impossible is a real step change, but shipping still needs a taste-and-polish layer, so plan for review time rather than assuming the first output is final.

Faster and cheaper, but still slow and metered

She calls the model "kind of slow but not too slow" and flags cost directly: $10 per million input tokens and $50 per million output tokens, with a faster mode available. The trade-off is that computer-use autonomy runs long (an hour-plus QA session), which is great for offloading toil but has a real token bill attached. Weigh the hours saved against the token cost per run before wiring it into a production workflow.

Practical Application

Point the agent at your next QA pass

After your next front-end fix lands on a preview branch, ask the agent to test it in the browser: click the core flows, send real inputs, watch the console for errors, and refresh repeatedly to trigger timing bugs. Let it run unattended and review what it flags, the way Claire caught race conditions she would have missed by hand.

Keep a capability-gated idea list

Write down the two or three product ideas you have shelved because models could not execute them well enough. When a new model ships, spend an afternoon re-testing those exact ideas before assuming they are still out of reach, rather than starting the evaluation from a blank page.

Reprice around hours saved

If you own an AI feature, describe and price it in terms of time removed from a specific task (this replaces six hours of X with ten minutes) rather than model quality. That is the frame customers are being sold on across the market right now.

Redraw roles around taste

For workflows you hand to an agent, redefine the human's job as reviewing for quality and taste, catching the equivalent of "extra fingers", not doing the mechanical production. Make that review step an explicit part of the workflow so quality control does not silently disappear.

Questions to Consider

• Which workflows in our product would an agent operate through our existing UI today, and does that change our plan to build a separate CLI or MCP layer?
• What product ideas have we abandoned specifically because past models executed them poorly, and when did we last re-test them on a current model?
• Are we using an agent to QA our own product in the browser before shipping, and if not, what is stopping us?
• If we described our AI feature purely as "hours of a specific task removed," would the number be compelling, and do we even measure it?
• As agents take over mechanical production, have we explicitly defined where human taste and verification stay in the loop?

Bottom Line

The headline shift in this model is not intelligence, it is reliable computer use, and that reverses the assumption that agents need CLIs and MCPs instead of UIs. For PMs, that means re-testing shelved ideas against the new capability, using agents to QA your own product, and pricing AI features on hours saved, while still budgeting for the taste-and-polish pass that turns an impressive one-shot into something shippable.

Tools & Products

People to Follow

Claire Vo

Host of How I AI and a hands-on product leader who builds ChatPRD. She is worth following for practical, demo-driven takes on what new AI tools actually let a PM ship, tested against her own real product work rather than benchmarks alone.