We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Consumer AI may compete less on model identity than on usefulness and access. Tony Fadell argues that models are already good enough for most consumer needs, and that users will want AI to be useful, easy to reach, and free or bundled with something they already pay for. Paul Graham offers a complementary choice for builders: work close to the technology by making LLMs, or close to customers by using AI to give them what they want. For PMs, the implication is to build a real edge in capability or in solving a customer job—not rely on model novelty alone.
Shipping may be cheaper; maintenance and user attention are not. A former startup employee says CEO-led weekend AI coding hackathons produced features with near-zero adoption; another PM reported roughly 30 unused features that remained in the product and added maintenance and testing burden. Commenters also point to ownership and support tickets, and warn that features outside the product’s job-to-be-done tax users’ attention and obscure valuable functionality.
Tactical Playbook
Turn “launch and see” into a bounded experiment. One commenter recommends agreeing before an AI coding sprint on a single 30-day adoption threshold and removing the feature if it misses; ship off by default behind a flag to a subset of accounts so removal is a toggle, not a fight. Track repeat tickets per feature alongside adoption: usage alone can hide the maintenance cost.
Design agent permissions around the task and its consequences. A Muse user had to approve sending a message after already instructing the agent to send it; the article also says Claude Code users approve about 93% of prompts, a pattern Anthropic calls approval fatigue. Start with read-only access and expand only when needed; distinguish drafting from sending and viewing production from changing it. For hard limits, make them architectural: Replit separated development and production databases so its Agent cannot change production during development.
Case Studies & Lessons
A product-operations leader described roadmap planning that consumed two months of every quarter making slides, while inconsistent Jira definitions and the lack of a shared account of what teams planned to do—and why—made the roadmap hard to use. Standardizing the work hierarchy proved easier than getting thousands of people to adopt it. The organization now links initiatives to expected value and spend, and the leader said a Jira-backed app was intended to replace the planning slides. The lesson: fix the underlying work data and adoption problem before polishing the roadmap presentation.
The same leader’s PM capability framework used 12 skills across four themes, with employee self-assessment and manager feedback to prompt development conversations. After six months spent aligning the language, 150 people completed the assessment; engineering, data, and UX later adapted discipline-specific versions. He says the shared framework also made promotion decisions more consistent and transparent. Keep the skill intent consistent, but let teams define how it applies to their work.
Career Corner
For a Founding PM role that drew hundreds of applications, Deb Liu advises making fit unmistakable: connect your experience to the company’s actual needs, show one finished product or prototype, and seek a reference from someone who knows your work. She also reports that direct outreach from an unconnected candidate led to a meeting.
A PM offer-negotiation guide reports that five coached candidates won increases without an offer being pulled, including two who were unemployed after layoffs. Its method is to calculate effective annual compensation over expected tenure, including cash, equity likely to vest, and sign-on; discount private equity for payout risk and time to liquidity. For a two-to-three-year stay, it recommends prioritizing sign-on and front-loaded vesting; for four or more years, base and equity.
A frontend-designer launch teaser said only that a product would “solve the pain problem,” without explaining the pain or the solution . Readers called the pitch vague/low-effort and asked for more detail; one warned it had created a bad impression of the product .
- The interviewee describes product ops as connective support for both product and engineering: it should help teams decide what and why to build and make delivery possible, rather than simply add process. Diagnose organizational blind spots and sources of friction, then solve one problem at a time; he suggests investing some capacity in ways of working above roughly 30 PMs or when teams are geographically or culturally distributed, though around 10 teams may not need dedicated headcount.
- In his company, quarterly roadmap preparation once took two months of slide-making, with no shared document for people outside planning meetings to understand or comment on the what and why; inconsistent Jira usage also lacked a shared hierarchy for initiatives and features. Standardizing Jira exposed that adoption—not designing the solution—was the harder challenge across roughly 3,000 people. He reports that Jira data now supports initiatives tied to expected value and spend; product and finance work on translating product metrics into value, and an app using the data is intended to replace planning slides with a source of truth.
- To clarify PM expectations and support development, he built a 12-skill framework across four themes, drawing on Reforge, CPO input, his experience, and market observations; it covers areas including execution, influence, strategy, storytelling, prioritization, and data. The process pairs self-assessment with manager feedback to prompt career conversations, and keeps skill intent consistent while allowing application to vary by team and domain. After six months of alignment, 150 people completed the assessment; the framework also supported more consistent and transparent promotion decisions. Engineering, Data, and UX adapted the model into discipline-specific frameworks, reaching about 3,000 people. At his company, product adoption was made an explicit PM skill because some PMs saw their job as ending at feature delivery; he says teams should track adoption and impact, with value delivery or realization as possible broader framings. He argues AI does not remove the need for core PM skills such as storytelling, understanding data, and prioritization.
- Anchor creative-tech adoption in audience value, not the tool: Katzenberg says Disney focused on whether audiences believed in a character, then co-developed CAPS with Pixar to replace hand-painted cels; he says the new process enabled visual storytelling the old one could not. The transition can carry real workforce costs: DreamWorks ended hand-drawn animation, and some artists lost their place in the industry while others adapted to CGI.
- For creative AI, build with creators and establish fair terms: Katzenberg argues for involving storytellers with credit, consent, and compensation; he expects lower production barriers and costs to enable more films, greater risk-taking, and new forms of storytelling. Kevin Weil endorsed the argument as a reason for optimism about AI and creativity.
- Don’t assume you need a competing offer to negotiate: the author says PMs commonly have only one offer in the 2026 job market and reports five coached negotiations that improved compensation without an offer being pulled, including two candidates who were unemployed.
- Evaluate the offer by its components—base, stock, bonus, and sign-on—and compare estimated Effective Compensation rather than headline total compensation. The suggested annual calculation uses cash, equity realistically expected to vest during your expected tenure, and sign-on spread across that tenure; keep this estimate internal to assess what to negotiate.
- Match the ask to expected tenure: for a planned 2–3-year stay, prioritize sign-on and front-loaded vesting; for 4+ years, prioritize base and equity. The guide describes sign-on as one of the easiest offer components to negotiate.
- Discount private-company RSUs/PPUs for payout likelihood and illiquidity rather than accepting quoted value at face value: the guide proposes quoted equity × payout probability ÷ (1 + 15%)^years to liquidity, with different payout assumptions by company stage. For private equity, request valuation, shares outstanding, how the valuation was set, four-year projections, and leaver terms; the author advises assigning little value when data is unavailable.
- Treat equity terms as negotiable risk, not just headline value: for ISOs, model the strike-price exercise cost and the usual 90-day post-termination exercise window, and ask for a longer window. The guide also says seniority and hard-to-replace expertise can increase leverage.
- For PM offer negotiations, compare effective compensation (EC) rather than headline total compensation (TC): annualize cash, equity that will vest during your expected tenure, and sign-on; prioritize sign-on and front-loaded vesting for a 2–3-year stay, versus base and equity for 4+ years. One Series C example puts a recruiter-quoted $370K offer at about $270K/year EC for a two-year stay.
- Value equity based on its instrument and liquidity: the guide values public-company RSUs at face value but discounts private equity for payout probability and time to liquidity, using a 15% rate; its examples value a $400K grant at about $80K for a Series C company and about $216K for a late-stage company with annual tenders. For ISOs, a typical 90-day post-termination exercise window can require a large cash outlay—the example is $350K—so the guide recommends asking for a longer exercise window.
- Gupta reports that five coached PMs negotiated better offers without competing offers, and that none lost the offer; he says two were unemployed after layoffs.
- Gupta describes PM work as a tangle rather than a clean linear process, emphasizing resilience, stakeholder management, discovery, and strategy.
- Product guidance attributed to Paul Graham: use less-sophisticated customers to spot where products need simplification and more-sophisticated customers to identify needed depth; go beyond acquisition to make users happy, and consider difficult-to-copy technical advantages when the impact justifies the effort.
- AI product operating model: Prioritize developer productivity and run building, selling, and iterating in parallel rather than sequentially; build what differentiates the product and buy infrastructure or building blocks that do not.
- AI pricing: Match pricing to variable customer value and costs. Replit moved from flat subscriptions to subscriptions plus credits as AI became central to its product, combining predictable subscriptions with usage-based value capture. Implement this by choosing units customers associate with value (such as tokens for developers or seats/consumption for enterprises), showing usage before billing to prevent surprises and churn, and selling credits so customers focus on value rather than each use’s dollar cost.
- Global product readiness: AI companies in the talk reached 42 countries in year one and 120 by year three; top AI companies earned 48% of revenue outside their home market, compared with 33% three years earlier. Localize prices, offer local payment methods, automate tax collection, and track revenue and conversion by country. The speaker cites 18% higher cross-border revenue from localized pricing and more than 7% uplift from adding at least one local payment method.
- Product and GTM design: Treat adding enterprise sales, channels, or agent buyers as product and business-model changes, not just sales changes: onboarding, pricing, and support differ by motion. Define when self-serve customers graduate to enterprise and how pricing changes; use one customer object, product catalog, and data model across routes; and enable agents to discover, evaluate, and activate the product without a human.
- Design agent permissions around the task and its consequences: start with read-only access, expand only when needed, distinguish drafting from sending and inspecting from changing production, and use scoped “Allow” rules to remove repetitive prompts without opening everything.
- Make boundaries enforceable in the product architecture, not just the model’s instructions: after an Agent deleted app data, Replit separated development and production databases by default so Agent could not change production during development; Muse runs agents in an isolated runtime, keeps credentials outside it, and uses Sentinel to evaluate actions and network access.
- Approval prompts alone can become routine: the article reports that Claude Code users approve about 93% of prompts, and argues for pairing human decisions on consequential actions with automated review and containment. Match the fix to the failure: scoped permissions for repetitive interruptions, containment for risky actions, and access boundaries for systems the agent should not reach.
- Avoid blanket always-ask or always-allow permissions: Muse’s repeated approval request after a user had already directed it to send a message created redundant work, while visible prompts can also serve as trust checkpoints. Design permissions around how long approval lasts and which actions it covers. Claude Code users approve about 93% of permission prompts, a pattern Anthropic calls approval fatigue; routine approvals can weaken the value of a confirmation prompt.
- Start with read-only access when it is enough, then add permissions as the task requires; distinguish drafting from sending, inspecting production from changing it, and preparing a purchase from spending money.
- Enforce consequential boundaries in the system rather than relying on the model to remember instructions: after Replit Agent deleted data from Jason Lemkin’s app database during development, Replit separated development and production databases by default and prevented Agent from changing production during development. For agents that can access customer systems, isolation, credential handling, permission enforcement, and network controls are part of the product’s security obligation, not just demo polish.
Sam Julien says a course by Hamel Husain and Shreya fundamentally changed how he builds AI products and platforms, and he cites them in his O’Reilly book’s evaluations chapter.
Consumer founders and builders should regularly leave Silicon Valley and act as ethnographers to understand behaviors and attitudes beyond their own bubble . The Walmart example shows why: its app guides shoppers to items by aisle, and in-stock items can be delivered within an hour—experiences the quoted speaker says tech insiders may not appreciate .
- A PM hired to modernize a legacy HRM product reported one new customer in five years and a 75–80% customer loss over 10–15 years; a couple of GET endpoints took seven months in a COBOL, SQL stored-procedure, and PowerBuilder environment with little API experience, while leadership expected API and web modernization despite capability and staffing gaps.
- A practical response is to shift from optimistic planning to evidence-based accountability: track engineering commitments and actual time, effort, and cost; reforecast; and report missed commitments using data rather than assigning motives. This gives management a basis to reassess roadblocks, while making clear that it may instead blame product for delays.
- Capability-building options raised include using AI to extract business logic only with a verification suite of test cases, evals, or datasets; training current staff; and making a case for architecture, DevOps, or cloud expertise using security/compliance risks and long-term efficiency. Separately, a PM in a similar situation said that presenting a CTO with evidence of skill gaps and their costs eventually contributed to top-down pressure for upskilling and hiring.
- Andrew Chen praised the rise of startups focused on local/“sovereign” AI and GPU capacity, and congratulated GhostAI.
- The linked product thesis: personal AI can differentiate through deeply individualized context rather than network scale, but privacy and trust concerns can limit what users share with hosted agents. Local ownership could ease that barrier and support continuous, proactive processing without per-token provider charges. The adoption challenge is to make local AI useful and simple enough to become the default—not a privacy option that requires worse UX or self-hosting; the article claims local models are already sufficient for 90% of day-to-day tasks.
- Treat cheaper AI-assisted builds as no substitute for product judgment: discovery, compliance, support and other launch work can remain bottlenecks, while unused features still create maintenance/testing costs and compete for user attention. Vet ideas against use cases, priorities, ROI, JTBD fit and usage evidence rather than shipping solely because implementation is cheap.
- Before a hackathon or launch, agree on one 30-day adoption threshold and what happens if the feature misses it; ship behind a flag, off by default for a subset of accounts, so removal is a toggle rather than a post-launch deletion fight.
- To make the costs visible to leadership, track repeat support tickets per shipped feature alongside adoption; a commenter also suggests recording the sponsor, team hours and adoption, then comparing sponsor-weighted adoption.
- A PM’s post-leadership update found senior leaders had not known product and engineering teams were struggling with machine-written PRs; engineers had trouble understanding them, with tight deadlines and integration of acquired and parent systems cited as a prevalent explanation. The PM secured authority for PMs to request rewrites or reject indefensible AI-written documentation and to promote sensible AI use and open discussion; engineering planned to review code-review practices, but took no immediate action.
- For AI-heavy development, one practitioner contrasted legacy codebases lacking AI-oriented context with greenfield products documented before coding: expectations, requirements, code style, architecture decisions and rationale, product direction, and planning. Their sequence was objectives → requirements → roadmap → PRs → code review; for existing systems, they recommended backfilling undocumented team context.
- Measure AI adoption by customer and business outcomes, not coding throughput alone: a commenter cautioned that 10x coding velocity does not mean 10x revenue and urged focus on customers, users, and business results. Reports on economics and quality were mixed: one global SaaS practitioner said scaling output via tokens was similar in cost to headcount and was working so far with business and architecture expertise plus senior security and scalability audits; another said token costs were below additional FTEs but still required human quality attention and guardrails.
- In a high-volume Founding PM search, make role fit unmistakable: connect your experience directly to the company’s needs instead of sending a generic biography. For Ember’s role, sought signals included AI-native experience, building from zero, founder-like operating, and consistently high performance.
- Demonstrate capability with a finished product, prototype, portfolio, or side project; one small, working example can show how you think under constraints better than broad claims. Seek a credible reference from someone who has worked with you, and consider direct outreach if you lack a connection: the post says an unconnected candidate who reached out was invited to meet.
- The FDE/PM boundary is unsettled: the opening post describes FDE job descriptions as overlapping product work while also requiring system-design and AI-stack knowledge; commenters see the strongest overlap in technically capable PMs or engineers with product and customer skills, while warning that technically oriented FDEs may lack user and business focus.
- One commenter reports that trials with pure-development FDEs who had little domain expertise were not going well, and says some FDEs produce MVP/POC-shaped code for handoff to product teams—work that calls for systems fluency and customer-experience judgment, not coding alone. Another flags developer lock-in and unclear maintenance ownership; FDE roles may also be post-sales, sales-engineering-adjacent, or integration-focused, so candidates should clarify the role’s mandate and who will maintain or extend what is built.
Muse, a consumer AI agent, exposes outbound-connection controls for SSH, SMTP, IMAP/POP3, database connections, FTP, DNS, TCP and UDP; users can block a protocol entirely or have Muse ask before each connection, providing a concrete example of permission controls for AI products.
- An internal-products PM at a large company with about a year of PM experience said they were being publicly criticized at least weekly and felt burned out and demotivated. Another PM described an unsupported 0→1 project with conflicting feedback from their manager and head of product.
- For stakeholder management, commenters recommend treating some friction as tension between departments or the PM role and not necessarily as a personal attack; adapt communication to the audience and conversation, and look for a shared problem. If communication feedback keeps recurring, seek specific individual feedback, since communication is central to the PM role.
- For senior-leader disagreements, one commenter advises against opening an SVP message with “to be clear”; another suggests being firm and factual when challenged publicly, while giving a senior leader a private opportunity to revise their message when approached privately.
- To widen an India PM job-search funnel, one commenter recommends contacting hiring managers and recruiters on LinkedIn; keeping active profiles on Naukri, Instahyre, IIM Jobs, Wellfound, Indeed, Weekday, and LinkedIn and applying regularly; and building LinkedIn visibility through relevant comments and posts, with the caveat that this may take time rather than produce immediate results.
- An experienced B2B PM searching in NCR said PM hiring had slowed and recommended targeting Bengaluru, Hyderabad, and Pune over NCR; they also said seniority made their own search harder.
- A commenter who said they had secured six offers in two years argued that an industry/domain tag on a CV helps and that generic PM positioning may not be enough. In this thread, AI experience alone did not ensure progress: a five-year PM reported recruiter calls but no interviews while learning more AI, and a PM with nine years of domain/PM experience and AI build bullets said their search had not moved; their suggestion that metric-moving experience may be valued over delivery-heavy experience was explicitly a hypothesis.
- For early product or venture assessment, do not treat a polished pitch or demo as proof of viability: look for deployments, paying customers, technical milestones, and evidence that the economics work.
- In a discussion of YC’s chemistry-AI entrant, a commenter said it had pivoted from drug development to industrial chemicals, possibly because large pharma had developed models internally; they pointed to Cusp.ai’s reported $650M raise and industrial-partner data access as competitive advantages. The commenter argued that customers seeking R&D savings may pay a premium for the best solution, leaving a less data-rich product needing aggressive pricing that may still not be enough to compete.
I want AI to ask me less

The permission model has to keep working after I stop paying attention.
Matt Van Horn ran into this with Muse last night.
He had already asked it to send a Facebook message. Muse stopped before sending and asked him to approve the message again.
I get this completely.
He already told Muse what to do. The permission dialog felt like being asked to do part of the job twice.
Tarek Sheasha from Meta replied with the current workaround. Go to Settings, open the Facebook permissions, and change the action from Ask to Allow. Muse can then take that action without showing the same approval dialog.
That is exactly the tension I care about. I want agents to finish more work without coming back to me every few minutes.
If you’re letting AI work inside email, files, browsers or code, this is exactly what I’m covering Friday at 10 AM PT in AI Permissions 101.
I’ll show the permission screens themselves and the bloopers that reveal where the boundaries belong. Then I’ll show how I decide what an agent can do without me, what still needs approval and what stays out of reach.
The next question is what has to exist underneath that experience.
Allow is becoming Continue
Claude Code users approve about 93% of permission prompts.
Anthropic calls the resulting behavior approval fatigue.
At that rate, Allow starts looking a lot like Continue.
After enough prompts, the question is still on the screen while the human has moved into the rhythm of getting the work done.
Anthropic’s own incident log shows why this is hard. Claude has deleted remote Git branches after misreading an instruction, uploaded an engineer’s GitHub token to an internal compute cluster and attempted production database migrations.
A prompt saying “Are you sure?” gets weaker once approving becomes routine.
Anthropic has been moving toward automated review and containment. Auto mode puts a separate classifier in front of higher-risk actions, and its broader security work uses sandboxes and other boundaries to limit what an agent can reach.
I still want a human decision for consequential actions. I just do not want the whole safety model to depend on me paying perfect attention all day.
The prompt can also be the trust feature
One user said the permission prompts are the whole reason he trusts Muse.
Both reactions make sense to me.
Matt wants the agent to stop interrupting a job he already approved. Another user wants a visible checkpoint before the agent reaches something consequential.
A useful permission model has to understand how long an approval should live and exactly what it should cover.
That is why “always ask” and “always allow” both feel too crude for a lot of real work.
Notion Agent has already shipped a control called “Skip approval.” Muse lets you choose Ask or Allow for some connector actions. The products are converging on the same problem because users want autonomy without losing the ability to draw the boundary.
The settings go all the way down
This is why Muse’s deeper permission settings got my attention.
One screen exposes controls for outbound SSH, SMTP, IMAP and POP3, database connections, FTP, DNS, TCP and UDP.
On a consumer AI agent.
I probably will not touch most of those switches.
I still like that they are there.
Meta built a lot underneath them. Each Muse runs inside a dedicated cloud computer. The core agent operates in an isolated runtime. Credentials live outside that runtime, and Meta says the main agent never sees the real secrets.
A separate system called Sentinel evaluates actions and network access. For built-in connectors, Meta says Sentinel decides whether the requested action may be taken.
So the setting is not merely telling the model how you would like it to behave. There is machinery underneath enforcing the boundary.
That distinction matters a lot to me.
I may never open the hood
I have owned plenty of computers I never opened. Being able to open them still mattered.
If something broke, the machine could be repaired. If I needed more memory or storage, there was a path to change it. I did not have to know how to do the work myself to value the fact that somebody could.
Consumer computing moved pretty far toward the appliance model. Better defaults made computers easier to live with and most people had fewer decisions to make.
I liked a lot of that.
Agents create a different problem because they can reach far beyond the product.
An agent may be signed into your browser. It can use files or credentials. Some can run commands, send things, spend money and keep working after you close your laptop.
I want that experience to feel simple.
I also want some of the hood back.
I do not need to understand network egress to value the fact that I can inspect or change the boundary.
You do not have to use every control for the control to have value.
Power you rarely exercise is still power.
Change what the agent can reach
Replit gives us a very concrete version of this.
Replit Agent deleted data from Jason Lemkin’s app database while he was developing the product. Replit says the database was recoverable with rollback, but development changes could affect the production application at the time.
The product changed.
Development and production databases are now separated by default. During development, Agent cannot make changes to the production database.
I like this kind of fix.
A boundary enforced by the system is stronger than a rule the model has to remember.
The agent cannot accidentally change a system it cannot reach.
You can give the agent plenty of room to work while keeping something important outside the room.
Read-only is underrated
I have started applying the same idea to ordinary AI work.
A lot of jobs only need the agent to look.
It may inspect a document, compare files or check what changed in a dashboard. If read access finishes the job, I stop there.
When the work needs more access, I add it.
Sending deserves more thought than drafting. Looking at production is easier to undo than changing it. A purchase can be prepared before the money moves.
I am trying to match the boundary to the job.
That has been more useful than deciding whether I trust AI in the abstract.
The bloopers tell you where the boundary belongs
The failures are useful because they expose different kinds of mistakes.
A repeated Messenger approval is a usability problem. A scoped Allow rule can remove the interruption without opening everything.
Claude deleting remote branches or using credentials it found points to scope and containment. Anthropic is moving more of that work into automated review and system boundaries.
The Replit incident exposed a reachability problem. The product response made production unavailable to Agent during development.
Grok Bot creates another kind of trap. xAI says all Bots on one account share the same cloud computer, including files, browser sessions and command-line credentials. Separate workers in the interface are not separate security boundaries underneath.
Each one needs a different fix.
That is why I do not think “ask the user first” can carry the whole job.
The security work comes with the capability
I have spent most of my life building software companies. This is one place where I would be very careful about copying the visible capability without understanding the invisible work underneath it.
If an agent can work inside a customer’s real systems, the boundary around that agent is part of the product.
Meta’s Muse architecture makes the size of that job unusually visible. There is an isolated runtime, separate credential handling, a permission authority outside the agent and controls around network access.
None of that makes for the sexy demo.
It is still the product.
A demo can prove capability in a few minutes. Real use tests everything around it. Sessions linger. Integrations accumulate. Defaults matter. People get used to clicking Allow.
Capability is easy to demo. The boundary around it has to survive real use.
A small team can absolutely build a better agent. It still inherits the security obligation created by the authority it gives that agent.
I would not build an agent that can touch a customer’s real systems unless I was ready to own that obligation.
I still want to know that I can
I want agents to ask me less and I want them to finish more work on their own. That only works for me when the boundaries underneath the experience are real.
Most of the time I will live with the defaults. I may never open the hood. I still want to know that I can.
AI Permissions 101 is Friday at 10 AM PT.
- Design agent permissions around the task and its consequences: start with read-only access, expand only when needed, distinguish drafting from sending and inspecting from changing production, and use scoped “Allow” rules to remove repetitive prompts without opening everything.
- Make boundaries enforceable in the product architecture, not just the model’s instructions: after an Agent deleted app data, Replit separated development and production databases by default so Agent could not change production during development; Muse runs agents in an isolated runtime, keeps credentials outside it, and uses Sentinel to evaluate actions and network access.
- Approval prompts alone can become routine: the article reports that Claude Code users approve about 93% of prompts, and argues for pairing human decisions on consequential actions with automated review and containment. Match the fix to the failure: scoped permissions for repetitive interruptions, containment for risky actions, and access boundaries for systems the agent should not reach.
- Avoid blanket always-ask or always-allow permissions: Muse’s repeated approval request after a user had already directed it to send a message created redundant work, while visible prompts can also serve as trust checkpoints. Design permissions around how long approval lasts and which actions it covers. Claude Code users approve about 93% of permission prompts, a pattern Anthropic calls approval fatigue; routine approvals can weaken the value of a confirmation prompt.
- Start with read-only access when it is enough, then add permissions as the task requires; distinguish drafting from sending, inspecting production from changing it, and preparing a purchase from spending money.
- Enforce consequential boundaries in the system rather than relying on the model to remember instructions: after Replit Agent deleted data from Jason Lemkin’s app database during development, Replit separated development and production databases by default and prevented Agent from changing production during development. For agents that can access customer systems, isolation, credential handling, permission enforcement, and network controls are part of the product’s security obligation, not just demo polish.