This piece takes posts published on X between March and June 2026 from 9 product company leaders and operators(developer tools, design tools, content companies) posted on X between March and June 2026,and reassembles them by topic— instead of writing a separate profile for each person, it groups together “who is making the same judgment, and when,” to help you grasp durable conclusions that cut across individual products: how to price in the agent era, why design becomes more valuable after “execution becomes free,” what kinds of organizations and roles will emerge, and whether SaaS is actually dead.
All of these people are building AI products with their own hands and making money from them, so their words carry more “mud on the boots” than pure commentators — they expose real pitfalls (for example, vibe-coded projects blowing up, security breaches, benchmarks that fail to measure real capability).
When to open this:
- You are wondering how to price an AI product or feature (per seat? by usage? by outcome?) and want to see how frontline leaders debate it
- You are a PM worried “if execution gets cheaper, what value do I still have?” and want a clear framework for taste, design, and judgment
- You hear claims like “SaaS is dead,” “management is dead,” “one person can build a billion-dollar company,” and want to know which are real trends and which are slogans
- You want to understand why this group keeps saying “agents will use 100x more software than people” and “every company will become a software factory”
- You want to explain to your team that “AI won’t reduce our workload — it will increase it” — this piece contains the most complete argument for that (Levie)
Who’s talking (who's who)
Get to know the people before reading their views. The “identity + one-sentence stance” of each person below shapes the angle from which they speak.
| Person | handle | Identity | One-sentence stance |
|---|---|---|---|
| Amjad Masad | @amasad | Replit CEO | Vibecoding lets everyone run a business; parallel agents + vertical integration = moat; opposes Apple’s cut |
| Aaron Levie | @levie | Box CEO | The most “thesis-driven” person in this group: AI = Jevons paradox (more work, not less), software goes “headless,” the bottleneck is data not models |
| Guillermo Rauch | @rauchg | CEO of Vercel, creator of Next.js | Code is output, not input; the software factory is the moat; the Web is AI’s natural medium |
| Dan Shipper | @danshipper | CEO of Every (AI media + products), podcast host | Rebuild from scratch every 3–6 months; pirates/architects; the AI sandwich; compound engineering |
| Ryo Lu | @ryolu_ | Head of Design at Cursor (early Notion/Stripe) | After execution becomes cheap, taste/soul grows scarcer; “glass” transparency, humans stay at the wheel |
| Nan Yu | @thenanyu | Head of Product at Linear | Design is intent, not output; PM workflows are already AI-native; opposes “hallucinatory” polish |
| Peter Yang | @petergyang | Product at Roblox, author of a 140,000-subscriber AI/product newsletter | Your job is to automate your own job; taste pushes you past “average”; opposes slop |
| Madhu Guru | @realmadhuguru | Former Google product lead (Gemini/Veo/Nano Banana) | In the AI era, PMs must be “inventors,” not “process executors”; ambition and happiness can coexist |
| Peter Steinberger | @steipete | Creator of OpenClaw (“ClawFather”) | “How would we build software if tokens were free?”; let agents act as QA/reviewers; build tools for yourself |
Signal-to-noise note: @realmadhuguru has only 4 tweets in this roundup (having just left Google); the volume is low but every one is high-signal, not low-signal — it just has narrower coverage. The other 8 people are all high-signal, large accounts.
1. Headless software & agent pricing (levie + rauchg + amasad)
Why this is the number-one topic: If you run SaaS or any “sell software” business, this section directly affects whether you will still be able to collect revenue 18 months from now. Core judgment:The primary users of software are shifting from “humans” to “agents,” and agents cannot be charged on a per-seat basis.
"Agents will use software 100X more than people."(Agents will use 100 times more software than humans) — Levie [2026-03]. From this follows the “headless software” thesis: software in the future must be fully drivable by agents without any interface,and the software itself degenerates into “guardrails + business logic”, while the human-facing interface layer becomes secondary.
"If you're building software that can't work fully headlessly the way agents want, you're not prepared... If you can't connect to wherever agents want to do that work, you're DOA." Translation: If the software you build cannot run completely without an interface the way agents want, you are not ready… if you can’t connect to where agents need to get work done, you are DOA (dead on arrival). —— Levie [2026-03]
Levie asked 20 IT leaders, “In 3–5 years, will you still keep vendors that don’t have good APIs?”The unanimous answer was “No.”[2026-04].
How pricing changes (Levie’s [2026-05-01] thread is the most systematic):
- Seats are for humans, but every seat must be bundled with API usage quotas, so agents can spend on behalf of that person;
- If agents perform “stateful” ongoing work, they may also have “seats,” but the pricing model is completely different(similar to the OpenClaw model);
- For automated usage beyond seat allocations,the dominant model is consumption-based pricing; in the future, APIs priced by “outcome” may also emerge.
- A simple mnemonic:"Seats for the people, consumption for the agents."(humans by seat, agents by usage)
Rauch makes the same point from an infrastructure angle:"Every company will become an AI factory, wherein the unit of production is the token."(Every company will become an AI factory, and the unit of production is the token) — and tokens create a “metering/billing” problem that did not exist in the SaaS era. For this, Vercel built an AI Gateway/v1/report API specifically to solve cross-model billing.
Masad, meanwhile, takes aim at “the opposite extreme of per-seat pricing” —opposing sales gates:"You shouldn't be forced to talk to us to buy the product."(you shouldn’t be forced to talk to our sales team just to buy) [2026-04]. Self-serve purchase + usage-based pricing is the default posture for the agent era.
Translation for non-technical PMs: In the past, selling software was like selling gym memberships(one card per person, charged per person). Now the real “members” are agents; they never sleep, they can run hundreds of instances in parallel — you can’t issue them membership cards either, you can only charge them based on how much utilities (tokens/number of calls) they consume. So the pricing model needs to become “humans pay a base monthly fee + agents pay for what they use,” or even “charge based on the outcome you help deliver.”
2. After execution becomes free, why design/taste becomes more valuable (ryolu + thenanyu + petergyang)
Why: When AI can spit out working interfaces and code in seconds, “being able to make it” is no longer scarce. This section is the one product/design people should read most — it gives you a hard-nosed argument for “why I am still irreplaceable,” and it is not motivational fluff; it is the working creed of the design leads at Cursor and Linear.
Core consensus: The easier it becomes to make things, the more freely slop (lazy, mediocre junk) floods in, and so “taste/judgment/saying no” becomes the bottleneck.
Ryo Lu(Cursor)[2026-03]:"as agents make it easy to add features, design matters more, not less."(Agents make adding features easy, so design becomes more important, not less) — the role of design is no longer “pushing pixels,” but deciding what should exist, how it fits together, and how humans stay in control.
Two of his flagship long threads are worth remembering:
- “When software had a soul”[2026-03]: The Mac around 2005 had “the bouncing dock, Genie effects” — “none of it strictly necessary. all of it felt like someone cared.” Then A/B testing sanded down the edges, and design systems standardized away personality, and we “optimized our way into a world where everything works perfectly but nothing feels like anything.” His fear is not that AI replaces people who care, but "it will drown them out."(that it drowns them out)
- “Glass vs. black box”[2026-04, Cursor design manifesto]: AI makes the “black box” even more addictive — “you type a wish and pull the lever... you became a product of the model.”“Glass” = everything is visible and controllable: agents are visible, the diff is right there, the plan is editable, the state is clear."as AI gets more powerful, glass gets more important... stay glass."(The stronger AI gets, the more important glass is… stay glass)
- There is also “overcooking”[2026-04]: It is not caused by one bad decision, but by the accumulation of many individually reasonable decisions into chaos (a sparkline for every number, a confirmation dialog for every action). AI drives the cost of “adding things” toward zero, making overcooking worse. The antidote is “see through the chaos, return to what this thing actually is, and cut everything that does not serve it.”
Nan Yu (Linear) adds the knife twist from another angle:"A design is an intention. Not an image or a prototype. Output without intention is hallucination."(Design is intent, not images or prototypes; output without intent is a hallucination) [2026-04]. He even pulled back a generative AI feature he had worked hard to build, on the grounds that “it made it too easy for people to press a button and skip the work they were supposed to do themselves” [2026-03] — AI features can short-circuit the value and learning users were supposed to gain.
Peter Yang turned this into a spreadable one-liner:"AI gets you to average fast. Your taste is what pushes past it."(AI gets you to average fast; taste is what pushes you past average) [2026-04]. He also described the “slop compounding trap”: An AI-generated file has 5% slop, and you don’t bother fixing it; later files reference the earlier ones;"5% slop becomes 10% and then more", and eventually you are sitting on a pile of AI garbage you can’t even understand yourself 🥲.
Translation for non-technical PMs: In the past, “being able to draw in Figma and write code” was the barrier; now AI gives you ten versions in a second. What is valuable has shifted from “being able to make it” to “judging whether it is right, daring to cut, and knowing what the thing essentially is”. The three people use three words — Ryo’s “soul/glass,” Nan’s “intent,” Peter’s “taste” — to describe the same thing:Your value is to be the person who “says no” and “sets direction,” not the person who “cranks out output.”
3. “If tokens were free” — agent-saturated development pipelines (steipete + danshipper + petergyang)
Why: This is the most concrete sample of what “the future of development actually looks like.” Even if you don’t write code, understanding this workflow will help you judge “how big a product a small team can sustain with agents,” and the counterintuitive but useful trick of “agents as reviewers/QA.”
Peter Steinberger’s most important thread:"How would we build software in the future if tokens don't matter?"(If tokens were free, how would we build software in the future?) [2026-05-15] — he literally ran the open-source project OpenClaw as the answer:Roughly 100 codex instances run continuously in the cloud, auditing the security of every PR and every commit; agents automatically close old issues that have been untouched for 6 months (and attach the exact reference needed to fix them); agents reproduce complex bugs on ephemeral machines, record before/after comparison videos, and post them to PRs; agents listen to meetings and open PRs proactively as soon as a feature is discussed."All that automation allows us to run this project extremely lean."(These automations let us maintain the project with very few people)
A few work patterns you can copy directly:
- Adversarial review:"Ask it to review code for bugs and it will tell you all good. Tell it there is a bug and it will LOOP AND LOOP and will find issues."(If you ask it to find bugs it says there are none; if you tell it "there is a bug," it will search over and over and actually find it) [2026-05-30]. The same bias shows up in evaluations — he removed model names from the judging agent because "Claude always ranks itself first."
- "Yielding agents is a skill."(Letting agents push forward on their own is a skill) — paired with
/goal+ automated review, his tasks went from the "30–60 minute" level to the "4–10 hour" level. - "The more skills you give codex, the less you have to prompt."(The more skills you give an agent, the less verbose your prompts need to be) + skills should be "token-efficient and syntactically relaxed"; don’t write a book in every skill description and stuff it into the context.
Dan Shipper (Every) paired this whole "agents are effectively free" workflow with a mental framework:
- Pirate + Architect[2026-03]: In 2026, engineering teams have only two roles —Pirate vibe-coding like crazy to discover what is valuable enough to ship;Architect turning that surface into a reliable, structured machine. "Every product needs pirates, but most products only need architects after reaching PMF, and usually not full-time."
- The AI sandwich[2026-04]:The model is the filling(writing, testing, iterating),Humans are the two slices of bread(framing the problem at the start, judging whether it is correct at the end)."Humans are indispensable at the beginning and end of every process."(Humans are irreplaceable at the start and end of every process). The companion idea is compound engineering: plan → execute → review → compound(write lessons back into the repository so agents don’t repeat the same mistakes), so one engineer can output like a five-person squad.
- "An agent is just a folder."(An agent is nothing more than a folder) — he calls this "an excellent mental model."
Peter Yang translated this playbook for solo builders: Josh Pigford’s tricks —use git worktree to develop multiple features in parallel(to prevent context rot and isolate errors),have GPT review Claude’s work and vice versa("GPT always finds 3–5 bugs that Opus missed"), and build a /learnings skill that distills every failure into a new rule.
Translation for non-technical PMs: Imagine you are no longer "hiring 5 programmers," but instead "running 100 interns who never tire, and whose wages are roughly equal to the electric bill." At that point the real work becomes setting goals for the interns, having one batch of interns pick apart another batch’s work, and writing every pitfall you step into as a rule posted on the wall. "Adversarial review" is especially counterintuitive but effective: you can’t ask AI "is there a problem?" (it will say no); you have to say directly "there is a problem here, find it" — and then it will get serious.
4. Is SaaS actually dead & is "management is dead" true or false (levie + rauchg + danshipper + petergyang)
Why: "SaaS is dead," "one-person billion-dollar company," and "management is dead" have been the loudest slogans of the past six months. This section breaks the slogans down into "which parts are true, which parts are overstated" to help you decide "whether to keep buying / keep building a given SaaS."
Rauch’s version of the "SaaSpocalypse" is the most radical:"Almost every SaaS app inside Vercel has now been replaced with a generated app or agent interface."(Inside Vercel, nearly every SaaS has been replaced by self-generated apps or agent interfaces) [2026-03]. But he left a critical opening —systems of record (such as Salesforce/Snowflake) stay; what gets replaced are the tools that "you can generate yourself to be prettier and better aligned to business problems." His underlying formula:"UI is a function 𝑓 of data, and that 𝑓 is increasingly becoming the LLM."(Interfaces are a function of data, and that function is increasingly becoming an LLM)
But Dan Shipper and Peter Yang offered a calmer take: "SaaS isn’t dead, it just needs to become agent-native":
- Shipper spoke together with Linear’s Karri Saarinen [2026-04]: Linear shifted to serving both humans and agents(Codex, Coinbase, and Brex all run agents inside Linear), and the lesson was that after ChatGPT blew up, Linear didn’t chase the trend and build a me-too chatbot, but waited didn’t chase the trend and build a me-too chatbot, but waited"running your own agents makes you more willing to pay for SaaS, not less"(Running agents yourself actually makes you more willing to pay for SaaS, not less); "chat is the wrong interface for design";"review is the next bottleneck"(review is the next bottleneck).
- Peter Yang’s layered judgment [2026-06] is the most practical:Large enterprise SaaS that can do many kinds of work (such as Figma) will most likely be fine; simple SaaS that solves only one narrow scenario will be hard to monetize— because (1) AI skills can solve the same problem more flexibly and personally; (2) an AI agent that has your context/memory understands you better than an isolated SaaS; (3) people are willing to pay hundreds or thousands for "human service," yet compare a $20/month SaaS against their own Claude/ChatGPT subscription.
"Management is dead / hierarchies are no longer needed" — multiple people explicitly disagree:
- Shipper[2026-04]:"organizations don't need hierarchies anymore because of ai is silly... As long as context rot is a thing you're going to need specialization."(Saying AI makes organizations no longer need hierarchies is silly… as long as 'context rot' still exists, you need specialized division of labor) — there will be fewer middle managers, but hierarchies won’t disappear.
- The line from Ramp’s CPO that Peter Yang relayed "Management is probably dead... optimize to be the best builder in the world"(management is basically dead… optimize to be the world’s best builder) is the voice on the other end — so on this matter there is inherent disagreement, not a settled conclusion.
"One-person billion-dollar company": Masad directly endorsed "One person billion dollar company has been achieved."(the one-person billion-dollar company is already here) [2026-04], and keeps amplifying real ARR stories from solo builders (someone who started with $400 reached $8M ARR a year later).
Translation for non-technical PMs: Don’t be scared by "SaaS is dead," but don’t act like nothing is happening either.What is truly dead is narrow tools that "only do one small thing, have no memory, and have no context about you" — the kind an AI skill can replace in one sentence.What thrives is two categories: ① big platforms that hold "systems of record" (your customer data, order data all live there); ② agent-native tools that can be invoked by both humans and agents. The judgment criterion is one sentence (provided by Levie):"When agents outnumber humans 100 to 1, which parts of software will grow because agents are doing more work?"— If the answer is "it will grow," buy it / build it.
5. AI won’t make work less; it will make more (Levie’s home turf + petergyang + corroborating evidence)
Why: This is the most systematic, most counterintuitive set of arguments across Levie’s entire feed, and the most useful for your and your team’s mindset. If you’re worried "if AI finishes all the work what will we do," or need to reassure the team / explain to the boss, this section is your ammunition depot.
Levie’s core is Jevons paradox— efficiency gains actually drive up total demand:
- "Jevons paradox is happening in real time."[2026-03] Companies (especially outside tech) can now afford software projects they couldn’t afford before → software gets used in entirely new parts of the economy. "All advice telling you not to study engineering is wrong."
- Second-order effects[2026-04]: Making a skill more efficient will induce demand for it— more code → more security risk → more security jobs; more AI-written legal documents → more lawyers; 10x the video/graphics → more media people. Historical corroboration: the PC and the internet both made law more efficient, yet the number of practicing lawyers in the U.S. rose from ~400,000 in 1975 to ~1.37 million in 2025.
- "Don't confuse task completion with eliminating the whole job."(Don’t confuse "completing a task" with "eliminating an entire job") [2026-04] — he calls this "Gell-Mann amnesia for AI jobs": you use AI to do your own work and see all the "last mile" dirty work; when you look at other people’s work, you assume AI can instantly replace them.
- His most viral post(4.8K likes) [2026-05-24]:"CEOs are uniquely prone to AI psychosis because they're sufficiently distant from the last mile of work."(CEOs are especially prone to "AI psychosis" because they are far enough from the last-mile work) — they only see the happy path of "look I built a prototype," not the 10–20 things still needed to ship. Advice: CEOs should use AI heavily themselves to experience both the ceiling and the real workload at the same time.
Peter Yang’s "three frontiers" added a timeline to the same judgment:"Coding is the first frontier. Knowledge work is the second. Personal agents are the third."(programming is the first frontier, knowledge work the second, personal agents the third) [2026-05] — and emphasized "Human ambition has no ceiling — the economy is changing, not shrinking."(human ambition has no ceiling — the economy is changing, not shrinking).
Another corollary from Levie is new job types:FDE / internal agent engineer will become the defining new role — "identify the highest-leverage workflows, feed context to agents, decide where humans step in, rerun evaluations when models/data change." It requires "technical skills (Skills/MCP/CLI) + business understanding." He says selling agents "far closer to a customer buying from a professional services firm than implementing traditional technology"(is more like customers buying professional services than implementing traditional technology) — so every wave of technology will "spawn a new generation of consulting firms."
Translation for non-technical PMs: Use a life analogy —after washing machines appeared, people washed more clothes, not fewer.Because each wash became cheaper, you wash every day and wash more kinds of things. That’s what AI does to work: as each task becomes cheaper, you do more things you previously thought too troublesome to do, and total work actually rises. The trap to watch out for, as Levie points out, is:the farther you are from the front line (especially CEOs/executives), the easier it is to overestimate AI and underestimate "those 10–20 dirty tasks before launch"— so the best antidote is to use it hands-on every day yourself.
6. A few scattered but valuable long-term judgments
A few items that don’t form a theme but each stand on their own, kept for quick reference.
- Rebuild from scratch every 3–6 months (Shipper):"models move so fast that you have to be willing to throw everything out every few months."(Models change too fast; you have to be willing to throw everything away and redo it every few months) — small teams win because they have no coordination costs and can restart more easily. Levie says the same: "What you spent 6 months polishing 12 months ago is already outdated,resetting is better than rescuing. "
- "Code is output, not input" (Rauch):"Code is an output. Nature is healing." For too long we treated code as input to beautify and IDE-ify; now attention should return to the real inputs — requirements, specs, feedback, design inspiration, how users actually use things in production. "The best engineers have always seen code as a means, not an end."
- PMs should be "inventors," not "playbook executors" (Madhu Guru):"A generation of PMs is struggling to adapt to AI because they were trained to execute playbooks. AI requires inventing them."(One generation of PMs struggles to adapt to AI because they were trained to execute playbooks; AI demands inventing playbooks) — "You can’t A/B test your way to a breakthrough AI product… PMs need to unlearn the old stuff."
- CEOs’ AI failure mode (Madhu Guru): Many CEOs have AI FOMO but "are used to remote-style leadership and lack the muscle for hands-on use," so they issue vague, crude AI instructions → employees deliver "performative, low-investment demos" → "two years go by with no real progress, and a startup led by someone who actually uses the stuff themselves disrupts you."
- The adoption sweet spot is "one or two steps back from the frontier" (Nan Yu):"The sweet spot is just a couple steps behind"Don’t chase the bleeding edge — because at the bleeding edge you keep changing your approach as the industry learns; the sweet spot is things that are "relatively new but have already survived the churn."
- Ambition and happiness can coexist (Madhu Guru):I've seen friends who made over $10M and were miserable, and others who earned less and were happy—"Whether you're happy is independent of your bank account... Silicon Valley treats ambition and happiness as mutually exclusive, that's a trap; you can have both." Peter Yang's version hits harder: don't let your tombstone read "He got divorced, neglected his kids, but at least made it to D2 at FAANG."
- Security is the defining issue of the AI era (Masad + steipete + rauchg):Masad—"In the 2020s every company is an AI company; after 2025 every company is a cybersecurity company"; Steipete—AI-generated security reports will overwhelm some open source projects (Linux kernel security reports went from 2–3 per week two years ago to 5–10 per day now); Rauch's hard-won lesson—"Deletion does NOT imply Rotation."(Deleting a secret key ≠ rotating a key; rotation means invalidating the old value and issuing a new one on the vendor side).
History
- 2026-06-05 v1.0 created —— follow-builders daily tweet subsystem, theme-driven synthesis of prebuilt digests from 9 authors in the founders-products topic bucket (amasad / danshipper / levie / petergyang / rauchg / realmadhuguru / ryolu / steipete / thenanyu). Sources are X tweet digests (2026-03→06 window). No images.
2026-06 to 09 historical supplement: Let evaluations connect to real work
The following is based on the local original tweet text added in this supplement; batch-by-batch close-reading notes are in sources. Short links, images, and videos were not expanded. Earlier identities, model names, prices, and growth figures all belong to their historical windows and should not be treated as today's product catalog or verified performance. Vendor evaluations and business cases in the new material are likewise self-reported by the authors.
First distinguish things that can be verified immediately from things that require external feedback
Levie repeatedly pointed out on June 7, July 16, and August 3 that coding is not only technically mature, but also has digital context, runnable tests, and technically literate users. Sales, contract negotiation, and marketing plans may require customer feedback and have no single correct answer. Therefore, "code can run continuously for hours" does not directly prove that other kinds of work are suitable for unattended continuous operation. (See batches 01, 03, 04.)
Takeaway for PMs: clearly specify for each task who accepts the result, when feedback is given, and who judges the outcome; separate "was the information retrieved correctly?" from "was the recommendation ultimately effective?" A counterexample is treating a nicely formatted financial summary as direct evidence that the analysis is correct. Box's historical evaluation cases involved starting accounting periods, cost definitions, denominators, and classification weights; their value is in reminding us to test business definitions; we do not repurpose their model scores or medical case conclusions as universal answers here.
Evaluations cannot just give the boss one total score
Madhu Guru's August evaluation series proposed four actionable improvements (batches 04, 05): first break down real failures into categories, such as wrong document, wrong paragraph, unsupported answer, guessing when clarification was needed; then locate problems by work stage, at a granularity fine enough to decide what to fix next. Tests must also be realistic and discriminating, avoiding scenarios where all systems get full marks or all fail.
A single average score can mask regressions in critical scenarios; a weighted total score does not eliminate the human tradeoffs behind the weights. Therefore, retain prioritized sub-scores and failure samples. As users shift from short-text summaries to multi-file analysis, and from passive Q&A to continuous monitoring, evaluations also need a roadmap. For articles in the series directory where only links were captured, we do not pretend to have read them.
For prototypes look at the ceiling first; for production look at the total cost of each qualified task
Guru advised on August 5 to first use a strong model to validate user experience, then optimize latency and cost; Levie repeatedly discussed using strong models for planning and cheaper models to complete well-defined subtasks. The prerequisite for this is that task boundaries and acceptance criteria are already clear. The original phrases "catch up in 6–8 weeks" and "15x savings" are respectively a prediction and a restatement of a specific experiment, and cannot be treated as budget promises. (Batches 02–04.)
Masad argued against token consumption leaderboards on June 14; Rauch emphasized governing budgets per user on September 1; both remind us that consumption is only a cost and activity signal, not an outcome. Production decisions should look at qualified completion rate, latency, retries, and human review together, rather than only comparing token unit prices. Prompts can also accumulate outdated rules; Guru's "delete half every time you update" should be understood as a reminder to check prompt debt, and actual deletions must be validated with regression tests.
2026-07 to 09 historical supplement: Workflows, permissions, and human-computer interaction
One entry point can connect many specialized agents
Rauch described Vercel's internal @v on August 3: it acts as a unified entry point that routes to sub-agents, while retaining a small number of dedicated entry points. The problem to solve is employees not being able to remember dozens of bots, not eliminating specialized division of labor. Nan Yu in July both supported parallel work and opposed showing off ten open windows at once, focusing on the burden of human micromanagement. (Batches 02, 03.)
When a long task finishes and only gives a two-paragraph summary, people lose a sense of control; Shipper explicitly mentioned this problem on July 4; Steinberger demonstrated prompts that supplement context when asking for help. For PMs, "what was done, where is the evidence, where is it stuck, and what do you need to decide now" can serve as the content standard for result and help-request interfaces. Reducing annoying wording also affects task completion: Nan Yu called this a conversation and rhetoric design opportunity on September 2. You cannot ignore user drop-off mid-process just because the backend model is stronger.
Being able to access data does not mean authorization is solved
Guru asked on July 25: what permissions do employee-generated agents and sub-agents inherit, when do they expire after a task ends, and how are they audited. Levie reminded on July 15 that permissions for enterprise sensitive information are not uniform, and training content into a shared model cannot replace external access controls; Rauch distinguished compute isolation from network isolation on August 11. These are all design questions, and the cited security incidents have not been externally verified. (Batches 02–04.)
The applicable scenario is when agents start reading and writing materials across teams. First clarify on whose behalf they act, which data they access, and which actions they are allowed to take, before discussing shared memory and automatic improvement. ZDR (Zero Data Retention) is a vendor condition that helped adoption in Levie's August experience; it does not mean all scenarios are automatically compliant, nor does it make auditing, permissions, and reliability unnecessary.
From demand signals to articulable value
Guru recalled in August that early user prompts already included "build me an app," even though models were not good at completing it at the time; unmet requests can also expose the outcomes users really want. He also criticized making ordinary users learn terms like models, MCP, and context before they can get things done. Model selection can be abstracted away, but it must be supported by scenario evaluation and ongoing maintenance; you cannot hide costs and data uses that require user decisions. (Batches 04, 05.)
Nan Yu emphasized on July 10 that marketing stories are not only for the first reader, but must also be passable from sales to customers, from users to buyers, and from champions to the organization. For PMs: helping trial users clearly articulate specific tasks, actual changes, and limitations is more conducive to internal spread than only showing technical jargon. Voluntarily shared success stories and follower growth numbers do not constitute overall success rates.
2026-06 to 09 historical supplement: Let users participate in judgment, let agents proceed on evidence
Which frictions are worth keeping
Nan Yu reviewed a project update feature on June 20: one-shot ghostwriting, while saving steps, gradually made users stop thinking; changing it to ask "what's most important, what should be emphasized, what background is still missing" instead helped users give more intentional updates. The applicable condition is that key information and judgment still rest with the person. A counterexample is repeatedly interrogating users about clear, low-risk small operations, which only adds burden. Batch 09 (Local reference materials)
Guru's advice to PMs in the same period was not to produce more documents, but to personally do research, analysis, and multiple prototypes, then take responsibility for judging why and what to build. On July 28 he defined a good product review as one that lets domain experts test the plan early; it should produce new understanding, not just be a presentation. But simulated reactions in meetings still need verification from real users. Nan added in August: first ask about the problem behind a colleague's idea; some good solutions emerge from fusing multiple ideas. Batch 09 (Local reference materials), 10 (Local reference materials), 11 (Local reference materials)
From auto-fix to resumable workflows
Nan described Linear's Issue→Agent→PR→Release practice on August 1–2: first combine monitoring and logs to study root causes; when evidence is insufficient, leave a context-rich question and ask the reporter to supplement reproduction information, then continue after the answer arrives. He self-reported that about 30% of bugs went through this full flow, which cannot be used as a completion rate or auto-release promise for other teams. PMs should clearly define the conditions for "continue, ask for help, stop," rather than only giving the agent a goal to keep working indefinitely. Batch 10 (Local reference materials)
Rauch pointed out in June that agents face not only model output changes, but also distributed system problems such as external API failures and rate limits. Therefore, troubleshooting records must distinguish model judgments, tool returns, and environment failures. Steinberger added recordings and shared session records to UI change PRs in August, a practice that lowers reviewers' comprehension cost; results still need to be checked against actual acceptance criteria. Rauch advocated in September for providing agents with executable checks alongside skills, such as design spec checkers; passing checks only covers the parts expressed in the rules. Batch 09 (Local reference materials), 11 (Local reference materials)
Preserve choice for model changes, set permissions for collaborative work
Guru broke model replaceability into three things in July: business evaluation, model selection by quality/cost/latency, and an execution layer that unifies tools and result handling. Preserve both basic tasks that cannot regress and target tasks that are not yet done well. When exploring new experiences in prototypes, first look at the ceiling of strong models; if replacing a clearly defined traditional machine learning task, small models may also be suitable. The task conditions for the two pieces of advice differ, and they are not contradictory. Batch 08 (Local reference materials), 10 (Local reference materials)
Evaluations must also observe execution trajectories: which steps were used to complete the same task, and which repeated calls added no value; fewer steps do not automatically equal better results. When a service provider says routing is "optimal," verify the evaluation objective and commercial incentives. Open weights, local deployment, and third-party hosting are also different data flows; you cannot judge where data went based on a model's origin or the word "open source." Batch 06 (Local reference materials), 10 (Local reference materials)
Levie's June shared workspace suggestions included plans, policies, drafts, corrections, and decisions, whose value lies in giving collaboration continuous context; agents in group chats should have independent roles and permissions appropriate to that group, and cannot automatically inherit all the personal capabilities of any one member. In August–September he continued to emphasize stable software controls, document classification, and anomalous access alerts. Shared memory improves efficiency but does not eliminate the need for access controls. Batch 09 (Local reference materials), 11 (Local reference materials)
Outcomes, inputs, and experience must be observed separately
Model benchmarks, platform token share, spend share, and call speed are not the same metric. Rauch's Gateway data only describes that platform; Levie's restatement of per-capita investment at engineering-oriented enterprises also carries sample bias. They can be used to spot trends worth verifying, but cannot be directly extrapolated to market share or used to set team budgets. Batch 07 (Local reference materials), 11 (Local reference materials)
Shipper's show description used repeatedly revising emails to illustrate that "more interaction does not equal more value"; Granola pre-generating large numbers of unopened pre-meeting briefs likewise indicates that proactive services must also observe usage benefits and generation costs. We only read local show descriptions here and did not treat timestamped directories as complete interviews. Guru also distinguishes consumptive activities where people enjoy the process from burdens they want finished as quickly as possible: the same person may have different automation preferences for different tasks. Batch 07 (Local reference materials), 09 (Local reference materials)